I just tried installing Ubuntu Budgie spin on a USB and it seemingly deleted/replaced my Linux Mint bootloader from an internal drive so I could no longer boot Mint without plugging in the Ubuntu USB. When I tried to boot from the Mint drive I just got a blank Grub prompt instead of a list of kernels.
Thankfully I was able to reverse this using Timeshift.
How do you avoid this? I didn’t see any relevant options in the Live USB install process. And I have had similar problems like this before.
The behavior I want is to have two standalone Linux bootloaders on separate drives. I suppose I could just disconnect all system drives during install so that the Ubuntu install process can’t fuck with it…
Short version: Downloaded Ubuntu ISO, checked checksum, burned to USB using Rufus, booted from live USB, chose 64 GB USB as install target allowing the installer to “auto configure” partition structure, and waited. The diagram seemed to only show changes to the USB drive.
Yeah, I booted a live usb installer for Ubuntu with budgie (I created this by writing the Ubuntu ISO to a 32 GB USB drive using Rufus). Then I booted from the Live USB and chose another USB 64 GB drive to install to. It seemed to take quite a long time (all night) but the installer was showing a prompt to restart and a completed message when i woke up.
I actually was never able to boot from the new Ubuntu install other than using the target USB drive’s bootloader to boot into my old Linux Mint on another drive.
The Linux Mint kernel was listed on the Ubuntu Grub menu along with Ubuntu and Ubuntu Recovery and I was able to select Mint and successfully boot to Mint. After installing Ubuntu, when trying to boot from my Mint drive without the Target Ubuntu USB connected, it gave an empty Grub prompt.
From there I ran timeshift to restore the old bootloader and everything else.
The reason I’m fairly certain it was a new boot loader is that it had a gray background where my old one had a black background.
I have Windows on a 1 TB NVME, Mint on a 200 GB SSD, and a 1 TB data HDD, as well as the 32 GB USB live stick and the second 64 GB which I chose as the target to install to. Because the sizes are all different, I think it was unlikely that I chose the wrong disk to target, as I double checked the name and size was correct.
Right now, I don’t need help fixing it Windows and Mint are as I want them after a Timeshift restore. I just want to know how not to ruin my old Mint Grub next time I install a second Linux on USB.
Edit: switched around to match chronological order. To clarify, when I say “target usb” I am referring to the 64 gb usb I installed to from the Live environment.
I understand now. You’re following the wrong approach for installing on a USB. Installing to USB is done purely by burning an ISO to it. If you run a standard traditional installer, it will think the USB is just another disk on your computer, and will hence modify the host computer’s bootloader accordingly.
There may be a way to do what you’re trying to do without burning a ISO, but I’m not sure. But the way you’re doing it is definitely not right.
But that’s a live environment that doesn’t save anything you install, right? That’s not what I want.
I can’t even install Nvidia drivers permanently which means I can’t actually “try” it properly. The generic drivers/nomodeset can’t run high refresh rate so I can’t see how laggy it does or does not feel.
Based on what you’re saying, I guess the only way to not remove the old bootloader would be to physically disconnect the other Linux system drive while it installs. Because having to use the USB to load the local system is really really not ideal.
Edit: I learned you can make a live usb with persistent storage which lets you install and update programs. However, there are limitations.
I think there’s a way to make persistent changes to a USB environment, but admittedly I am not sure.
Sorry I can’t be of help here, but at least I can tell you the original approach is meant for regular installs, not installing on a remote USB.
You can use Live USBs with persistence