Score:2

Create USB stick for old non-uefi system

km flag

I am struggling a lot with the creation of a bootable usb stick for Ubuntu. I used various tools (gnome disk, unetbootin) to accomplish that but the problem is that none of the methods created a USB that could be booted on an old system with no UEFI bios (Dell XPS l502x). Basically, whenever I boot from USB I get the "Operation System not found" message. The same USB on a recent (UEFI) laptop boots up nicely.

I suspect the reason might be that I need to created an MBR partition table instead of the GPT. However none of the tools I tested offeres the option to manually select MBR or GPT. I read about Rufus, but I have no access to a Windows machine to test that. I have this problem since 20.04.

I guess I could accomplish it using dd from CLI, does anybody have any suggestion?

thanks

hu flag
Ubuntu ISOs should be able to boot on both UEFI and BIOS systems. There is no need to manually create an MBR partition table. Dell XPS l502x is from 2011 or thereabout, and I can attest such old PCs work well, though can't say anything specific about Dell. In adition to `dd` you could try a smaller USB - 4 to 8 GB.
Alessandro Borgogno avatar
km flag
thanks for your answer, I am already using an 8GB usb2 stick.
Hannu avatar
ca flag
inspect the possibilities to divert the BIOS to boot from USB. There might be an "Boot menu" option (F12?), see what options you have there, possibly enable or even disable "Legacy mode" if such an option exists.
Score:2
cn flag

As already stated in comments, Ubuntu ISOs are tested and if written currently as per documentation

they will boot on

  • legacy BIOS/csm hardware
  • uEFI hardware
  • Secure uEFI hardware

ISOs up to Ubuntu 20.04 LTS were pretty consistent in format, with few real changes between releases (alas with differences between architectures).

From Ubuntu 20.10 and later an effort is made to ensure all architectures of a given release boot the same way, thus small variations in ISO exist for releases newer than Ubuntu 20.04 LTS. Thus if using software to write an ISO >20.04, it needs to be updated to cope with the release you're wanting to use (as do procedures if you're reformatting the ISO yourself; older procedures only work up to 20.04 - which is the release you mention).

If you use a pure clone (can be called dd-write or dd-mode on some software) all ISOs will write however, the issue relates to programs or procedures that re-format the ISO causing it to differ to the ISO you download from ubuntu.com. Some of these re-format options can write an ISO that boots only in specific modes (such as uEFI only, or BIOS only), but it will fail to boot elsewhere.

Wrong architecture

Another reason a modern ISO may fail to boot, is user-procedural, ie. you try and boot it on hardware that's incapable of executing it. eg. trying to boot an amd64 ISO on i386 hardware may produce a

"Kernel requires an x86-64 CPU but only detected i686"

error message, alas not always (https://bugs.launchpad.net/ubuntu-cdimage/+bug/1895956)

Slow to boot - be patient

Some hardware takes awhile to boot, eg. I have hardware that takes >12 minutes to boot an ISO, which includes 9+ minutes where nothing is shown on screen (which makes users believe it's failed, when its just struggling with non-compliant BIOS firmware bugs). Some sites suggest using the aforementioned re-format options to allow a faster boot in these cases, where I'll suggest just waiting, as using the re-format options that speed it on one machine will mean it'll fail to boot on others. The issue with https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342 may or may-not be fixed for some releases, but the answer here is just be patient (wait 15 minutes).

I use hardware as old as from 2005 in my Quality Assurance testing of Ubuntu ISOs (mainly Desktop inc. some flavors), and all releases have booted on my hardware from 2005+. I used older hardware (2002+) for releases up to late-2021 that was i386 only, but newer ISOs aren't created for that architecture anymore.

guiverc avatar
cn flag
If not clear; the *slow to boot* issue relates **only** to the ISO used for install. Once installed, the system will boot fast, as the issue is unfixed bugs in the *firmware* of some older devices that isn't compliant with standards and will impact booting ISOs. It wasn't of course noticed on hardware that was sold with OS pre-installed. Use documented ISO writes methods & be patient my suggestion.
Alessandro Borgogno avatar
km flag
Thank you for your detailed answer. I believe there might be an issue specific to this hardware. I created the USB stick on the XPS l502x (although running Fedora 38) with Gnome Disk Creator. This stick works just fine on a recent HP Z book G7 as well as on a self-build desktop from 2010. I also tried on a Dell Mini 10 (Atom 32bit - 2009?) and as expected it did not boot, but at least I reached the GRUB menu. On the Dell XPS l502x I don't even reach the GRUB menu, I simply get the message Operation (operation, not operating as one might expect) system not found. Thanks
guiverc avatar
cn flag
Ubuntu will install (*when using BIOS*) without an ESP or uEFI System Partition, however on modern hardware (anything newer than 2011 can qualify, thus your machine maybe '*modern*') an ESP can be required to boot. You mention MBR and not GPT but not which device (thumb-drive? as that offer only occurs on reformat ISO write options meaning you're not writing ISO correctly & installs may not boot; is a great way to trigger https://bugs.launchpad.net/bugs/1396379 where installed system will not boot). When reformat options on writing ISO to media; you make it so it'll only install on some boxes
guiverc avatar
cn flag
You've provided no actual specifics; with Ubuntu ISOs available with 5 installers which all have differences. Your mention of a 32-bit atom makes little sense because it'll only use releases up to 19.04 as 32-bit *i386* or *x86* boot support ended with that release if you're talking about 20.04 or later, specifics help us understand decisions & thus issues, as the question is *vague*. The last Ubuntu Desktop release had 2 ISO choices; each using a different installer, Ubuntu Server used another, flavors had ... etc but you've mentioned nothing of which you actually are asking about.
Alessandro Borgogno avatar
km flag
I am not very technical on the BIOS/uEFI nor partition tables. I mentioned MBR as I had a feeling that might be the issue but if you believe that has nothing do to with the issue please disregard my comment. All I am saying is that I downloaded the Ubuntu iso file (ubuntu-22.04-desktop-amd64.iso) and put it on a usb stick (sandisk 8GB). I am unable to boot "live" on the Dell XPS l502x. The same stick boots fine on an HP Zbook G7 as well as on a Desktop assembled back in 2010.
Alessandro Borgogno avatar
km flag
I mentioned the Atom just to witness the fact that, although that CPU is not supported (32bit) and obviously Ubuntu live does not boot, at least I get to see the GRUB menu: on the XPS I do not even reach the GRUB menu. Because, if I was not clear enough, my problem is not that the OS does not boot after installing it on the hard drive. My problem is that on this XPS Ubuntu does not boot at all from USB. Thanks
guiverc avatar
cn flag
The common reaction from booting an *amd64* ISO on a 32-bit system is failure to boot & messages **ONLY** from your BIOS/firmware.... The fact that you saw grub means statistically your ISO was written incorrectly (*since nothing is the standard response due to operator error*), however it may also mean nothing as `grub` on *amd64* ISOs does actually show on a **small percentage** of 32-bit hardware. Your atom *i386* detail points more to invalid ISO & doesn't prove what you're trying to prove with it (Note: this is based on QA using various *amd64* ISOs on 12+ *i386* devices...)
Alessandro Borgogno avatar
km flag
Ok, I'll recreate the usb stick from an ubuntu installation and check again. This way I can make sure the usb stick is created properly. Then I'll try again on the machines I mentioned earlier (HP, Dell and Desktop).
Score:0
cn flag

As far as I know the only Ubuntu like system that has up to date installs for 32 bit is Emmabuntus created just for very old low resource systems. It works very well and I have used it on 32 and 64 bit systems. It is also very fast. Emmabuntus Description

Emmabuntus downloads 32 & 64 bit

Score:0
bq flag

First make sure you're using a 32-bit version of the OS, since hardware made before around 2008 won't even support 64-bit code. If the computer has a 64-bit CPU but not UEFI, even most modern distributions should support booting using conventional BIOS, just make sure the .iso file you download does.

You can't just put the .iso file on the CD, DVD, USB stick etc's existing filesystem, you have to dump it bit-for-bit to the device. There's a ton of graphical front-ends, tools etc. to do this, but the most direct way to write the image to a USB stick is with the command:

dd if=yourfile.iso of=/dev/sdX

...where /dev/sdX is the device that appears when you plug the USB device in. It will normally be "/dev/sd" followed by a single letter (a physical storage device) but no numbers (those are partitions on the device) For example /dev/sda1 and /dev/sda2 are the first 2 partitions on /dev/sda whcih may be a hard disk, ssd, optical disk, USB stick, or whatever. You can see them appear in the output of:

dmesg -wH

While this command is running in a terminal window, (re)plug your USB stick. Then once you see it, make sure it's the correct one (very important!!) with:

fdisk -l

Just be careful not to nuke the partition table on any of your other drive(s) by writing to the wrong one!!

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.