Full install of zorin OS on usb only boots on computer it was created on

I tried to create a full install of zorin os to a USB, as shown in this video here:

www.youtube.com

It worked, and I did get a USB that had zorin os on it, however, it did not boot on other computers. Even for exact matches (same vendor, same specs, even the same bios version and settings), it refused to even show up in the bios screen. This was tested on 2 relatively new HP desktops. I then tried with a Dell laptop. There it did show on the screen to select what to boot from but then when I clicked on it, it just sent me straight back to the bios.

All systems can boot from a USB and have the options enabled. When I use a live install of Zorin, it does show up and successfully boots on all of them. However, I need something with the ability to be locked, and a large persistent section for programs (60 GB +). I am trying to use this as a portable linux install with an easy-to-use UI to plug into any desktop to access personal programs.

What have I done wrong/why does this happen and what can I do to fix it?

1 Like

It sounds like you have installed the bootloader on your PC instead of your USB, can you boot into that usb and run lsblk -f. Also check if your other computers support UEFI boot mode.

2 Likes

It would also be useful to know if the other machines are running Windows and had the August update applied which prevents booting of any Linux from any device.

1 Like

This sounds like a cool idea and I hope you get it figured out because I would like to try it.

I watched the video and it seemed straightforward until the end. I couldn't tell if he was saying we needed to do that step only to fix those 2 files if they had not shown up, or to do it all the time. Did you do that step or skip it?

1 Like

Here is a reply to all of the posts in one go.

Somehow I didn't follow the install video properly and skipped the entire step of fixing the EFI partition. I didn't detect this at all because when I tested it first on the original PC it worked flawlessly. After I realized that, I reinstalled Zorin, following the steps accurately in the video this time round. It worked until the aforementioned chapter on fixing the EFI partition.

The video says that the USB should be mounted in /target after running lsblk, but in reality, it is mounted in /media/zorin/{Long string of numbers and letters}. I continued anyway, replacing all instances of target in his video with the equivalent mentioned before on my computer. However it failed at the last step:

sudo grub-install --target=x86_64-efi --removable --recheck --efi-directory=/boot/efi

This resulted in an error and did not happen. Therefore, I redid the install one more time and left it at the stage before the fixing the EFI chapter in the video, to have a clean slate to ask for help from. Can someone help me from here?

And also I think that all the computers do support UEFI, they are all fairly new (less than 5 years old) and running windows 10. I don't think it is running the august update as all of them can boot from a live install created with rufus with 0 problems.

In the end I found a solution which circumvented the problem in this video. Rather than following the steps shown in it, I decided to use the same steps that are shown here, replacing every instance of Ubuntu with Zorin and it worked perfectly, booting on other systems.

For anyone who is interested to go down the same route as me, remember to do the step which tells you to disconnect your existing hard drives from your system. I disabled them in bios, which works too. Not doing this step at all will result in a USB that only boots on the original system. Also occasionally on foreign systems, Ubuntu may not show initially in the boot menu. To make this happen, select your USB to boot off of, then immediately try to enter the boot menu again (often F12 or F9) and Ubuntu will show. Select that to boot into and now you have access to a full install of Zorin OS on any system.

1 Like

I just want to add a warning to anyone trying to do this. Now that I have done this process multiple times, many times if you simply disable the drive in bios, the windows boot manager boot option can vanish in the boot menu. All your data is fine, you just have to manually find its location which is normally in EFI/Microsoft/Boot/bootmgfw.efi . I'd go a step further and not name it windows boot manager, instead giving it a temporary name. Then I would use microsoft's media creation tool to do a fresh install of windows, keeping all files and programs, and delete the temporary windows boot option in the bios (if still present).

1 Like

MukZorinboot, you've implemented a good workaround to that installer flaw.
It is a variation of the Ubuntu bug forum's workaround(s) for that situation - when trying to install an Ubuntu-based Linux which uses the Ubiquity installer, to a separate USB drive, the created Linux drive will then only boot from that single computer.

This is a known flaw in the Ubuntu "Ubiquity" installer, it has been known for at least 8 years (within the small realm of Ubuntu tech folks and affected disgruntled users), but the Ubuntu tech teams did not feel it was significant enough to fix until 2023.
References:
Bug #1396379 installer uses first EFI system partition found
Bug #1396379 “installer uses first EFI system partition found ev...” : Bugs : ubiquity package : Ubuntu

Bug #1591352 “Ubiquity copies efi boot information to wrong ESP
Bug #1591352 “Ubiquity copies efi boot information to wrong ESP” : Bugs : ubiquity package : Ubuntu

Ubiquity mounts wrong ESP during install - (7-2016) - Ask Ubuntu
system installation - Ubiquity mounts wrong ESP during install - Ask Ubuntu

All of the workarounds, do something to hide the main computer's primary HDD/SSD drive or boot partitions from Ubiquity. Because the flawed Ubiquity installer doesn't notice or care what secondary/external drive you are installing Linux to, it just writes the GRUB boot records into the boot partition(s) of the Primary/First drive it finds - that being the internal HDD/SSD of the running computer.

Note, if one is installing Ubuntu-based Linux to a single physical internal drive, whether single or dual boot, it will correctly write the boot info to the single only internal drive. So most people don't encounter this bug.
It is really kind of sad that Ubuntu devs did not see fit to correct the flaw until 2023 (in their 9-month releases), so it didn't get fixed in the LTS until 24.04. With their new Flutter-code based installer one could now safely create an external drive with a live Linux install and the boot records would be properly written to the target external drive.

Note 2, other non-Ubiquity installers do not have that flaw, so Calamares and etc. work OK for external Linux installs.

This fix to the flawed Ubiquity installer of Ubuntu 16-22 (and possibly earlier), probably won't show up in Zorin until v 18 (just a guess on my part) since the bulk of the Zorin 17 is based on Ubuntu 22.04 LTS, which includes the flawed Ubiquity installer.
You can see this if you look at the package list. DistroWatch is a great resource for this kind of researching which distro's have flawed Ubiquity or not.

P.S. I did not test the various hide-the-boot-drive workarounds myself, as I was not in a position to dedicate a machine to that sort of testing. And being wary, I've still not tested it...

2 Likes