Many distros no longer include both 32-bit and 64-bit bootloader support. Unfortunately some hardware including most based on the relatively recent Intel Atom processor architecture won't boot 'OOTB'. Whilst I wrote 'isorespin.sh' and 'isorespinner.sh' in part to address this issue I restricted their functionality to the Ubuntu 'family' of ISOs for support purposes. One of the most frequest questions I have been asked is 'can you add support for <insert distro> ISOs?'. Unfortunately distros, even those based on or derived from Ubuntu, are often built with different directory structures and packages. As a result writing a script that caters for multiple distros becomes complex and cumbersome. However with Ubuntu looking to move to a new snap-based installer I've revisited the 32-bit boot issue.
Initially I created a simple script 'treetoobitiso.sh' to just add the 32-bit GRUB bootloader to the Ubuntu 'family' of ISOs. But if a different distro uses a similar file system layout then essentialy there is no reason why it also wouldn't work so I've extended this script to include an '--unsupported' option to allow running, or at least attempt running, with any ISO.
Invocation is straightforward:
Usage: treetoobitiso.sh -h | [ --unsupported ] -i <ISO> [ --disk ]
treetoobitiso.sh: Exiting ... ISO not created.
linuxium@LINUXIUM:~$
being derived from 'isorespinner.sh'.
To create a bootable Ubuntu or similar ISO:
For other ISOs:
use the '--unsupported' option:
As long as the ISO has a file system layout that is recognised by the script, it should work otherwise you will be notified:
treetoobitiso.sh: Running in RAM ...
treetoobitiso.sh: Extracting treetoobitiso files ...
treetoobitiso.sh: Extracting ISO ...
treetoobitiso.sh: ISO structure currently not supported.
treetoobitiso.sh: Exiting ... ISO not created.
linuxium@LINUXIUM:~$
Once booted an installation will be dependent on the ISO's installer. Typically it will try to install a 64-bit GRUB bootloader however it may also fail as whilst it recognises that it was booted by a 32-bit bootloader it likely will not have the code to handle such an installation.
So I've created a companion script 'treetoobit.sh' to install a 32-bit GRUB bootloader during an installation attempt and again, whilst the Ubuntu 'family' of ISOs is supported, if the ISO is Debian/Ubuntu based (i.e. uses the 'apt' package manager) then it may also work using the '--unsupported' option.
For Ubuntu or similar ISOs perform the installation and then immediately before closing the final installation 'success' screen run the 'treetoobit.sh' script.
Some ISOs use the same partitions as Ubuntu for installation which simplifies running the script.
Others use a random name for the mount point and may not leave both the 'installation' and 'boot' partitions mounted at the end of the installation. It is best to first run 'lsblk -a' to see the current state and then perform any required mounting manually.
It is possible that an installation will finish leaving no sign of the partitions so both the mount point and paritions have to be set up first prior to running the script.
Unfortunately not all installations will complete successfully and depending on what the installer still had left to do means there may be additional manual steps required (hence the 'unsupported' caveat). In the case of Debian looking at the Calamares installer indicates that this includes removing the 'live-*' and 'calamares-settings-debian' packages.
Also if the installation does not support the 'apt' package manager then the script will refuse to run.
Finally, and perhaps of interest to anyone believing in 'snap' security or non-repudiation, specifically for the current 'canary' Ubuntu 22.04 ISO which uses the new Ubuntu desktop installer, it is necessary to run the 'treetoobit.sh' script before starting the installation. This will inject code into the desktop installer snap to use 32-bit GRUB packages as otherwise the installation will fail and recovery becomes tedious.
Please donate to help support the development if you find the script useful by following the link http://goo.gl/nXWSGf.
48 comments:
Please consider reading the Ventoy documentation, if not done already. Both the Win10 and Linux systems offer some convenient GUI tool capable of installing a GrUB2-based bootloader once the drive got "initialized" (as a GPT unit on my CherryTrail); Combined to 'rEFInd' i found the likeliness to survive an "update" has improved while dual-boot became 2nd nature. Plus, read-only "frugal" mode booting from an .ISO image file might actually save the day when time is short, etc...
Whilst 'Ventoy' addresses the booting aspect of ISOs on devices using a 32-bit bootloader, 'treetoobit' in particular is trying to simplify the installation issues for those devices especially for beginners looking to install an Ubuntu/Ubuntu flavoured ISO including when using the new Ubuntu 'snap' desktop installer.
Ian, thanks for your script. I could finally boot Manjaro on my X8pro with x5-z8350. Although it's build in 2020, they still haven't a 64 bit uefi on these cherry trail devices.
unfortunately i can't get it to work, either with a ubuntu server to prepare the ISO or a linux mint installation at the last step, i chmod 777 the .sh file, when using either .\ or bash treetoobit.sh it says the"this script runs as root" and then immediatly fails with "bash, command not found"
more testing, i've booted a clean mint 21 xfce iso from ventoy, downloaded treetoobit, and when run it gives me the "ISO must be an Ubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu GNOME, Ubuntu MATE, Xubuntu or Linux Mint desktop ISO." error, then quits.
aaand more testing, did a full install with the stock iso, then ran with --unsupported after the install.
now i get "cannot download 32-bit grub packages, exiting".
Manually running "apt download grub-efi-ia32-bin grub-efi-ia32" fails, i had to run one apt download per file.
Those downloads are tarballs, one of them(the -bin) has the .deb file the script is expecting. the other one has nothing
@L'Eliminateur: Yes, something appears to have changed with the dependency checking as this fails on 'jammy' with 'Handler silently failed' however works fine on 'focal'. Maybe removing 'shim-signed' first will fix this but I haven't tried as my test system is down atm.
that's unfortunate.
i did more testing, with ubuntu mate and mint as well, this time using treetobitiso.sh to generate the ISO.
After install, it still fails even when the efiboot32 file is present, after installation the only efi boot entry is shimx64.efi
@L'Eliminateur: I suppose a (rather tedious) workaround would be to install a 'focal' based release using 'treetoobit.sh' to install the 32-bit GRUB and then manually upgrade using 'do-release-upgrade' or equivalent to get to 'jammy'.
File treetoobit.sh have a bug. In line 247 is "apt-get download" instead "apt download"
@Andro: It is not exactly a 'bug' given I'm not using any options and functionally the commands are equivlent in this instance. But I get your point that the guidance is to use 'apt-get' over 'apt' in scripts to ensure backward compatibility so I'll look at changing this in scripts when releasing future versions.
Linuxium, I followed your instructions to build a Linux Mint x64 iso to boot and install from my Dell Venue 10 Pro 5055. It worked to boot the USB and install LM, but when booting from the built in storage I only get a grub prompt. Not sure what to do next.
@Unknown: Recently, most of the Ubuntu flavours have 'obsoleted' their 32-bit binaries so that might be the reason for the incomplete boot sequence once the ISO is installed.
You could try booting from GRUB by using 'ls' to find your root partition and then 'set' root to it, followed by explicitly setting the 'linux' kernel and 'initrd' initramfs binaries and then 'boot'. Just google 'booting from grub' if unsure.
Thx for getting back to me Linuxium. I am definitely not familiar with any advanced grub booting. I will search like you suggested and see what I can cobble together. Debian, from what I read is a multi-arch distro, and version 12 is supposed to release any day now. I'm wondering if the 64-bit version would automatically install the necessary 32-bit boot and grub files along with their 64-bit counterparts.
Alright, I started going through your instructions. The built in storage is /dev/mmcblk1. EFI is /dev/mmcblk1p1 and the main install partition is /dev/mmcblk1p2. I booted from my LM 21.1 USB drive with the bootia32.efi file in the /EFI/boot folder. I chose this file specifically in the UEFI of the tablet. I booted live image. (I had installed LM previously to the internal flash storage.) I then completed mounting the folders you said to mount, bound the ones you said to bind and chrooted /mnt. All of that completed without errors.
When I run the command "sudo apt -y purge --allow-remove-essential shim-signed" I get the list of apt options so I'm assuming something in that command must be missing.
When I run "sudo apt -y install --allow-remove-essential grub-efi-ia32 grub-efi-ia32-bin" I get an error saying...
The following packages have unmet dependencies:
shim-signed : Depends: grub-efi-amd64-signed (>=1.87.2~) but it is not going to be installed or
grub-efi-arm64-signed (>=1.87.2~) but it is not installable
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
When I run "sudo grub-install --force --target=i386-efi /dev/sda" I get..."grub-install: error: /usr/lib/grub/i386-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
I checked and triple checked I made no spelling mistakes, so what do you think could be the issue?
I wish I was better at this, but I really do appreciate you taking the time to help me through this.
Clayton
@Unknown: If the first purge command fails, or if any command fails, it is best to stop until we fix the error rather than carry on.
I'm not sure why 'sudo apt -y purge --allow-remove-essential shim-signed' fails so let's start by going back and running it again and pasting the output here for analysis. You will have to again mount all the file systems and perform all the binds as documented above, then 'sudo chroot /mnt' and run the command. After pasting the results here you should then 'exit' and perform all the above unmounts.
Dude! I noticed not long after posting my last message that Debian 12 had been released today so I decided to give it a go and it works. It booted up right after install. I may go back and try getting Mint running at some point just to learn what you have been teaching me, but for the moment, I'm going to mess around with Debian. I will get back to you when I do revisit LM. Thx for your help.
@Unknown: Okay, no worries.
Linuxium, I spoke too soon for Debian 12. It does boot without any issues, but so far it has been a worse experience than Windows 10. Slow, and things not working properly (screen brightness for example). Back to LM to see if I can get it to boot. If not, I will probably give an Arch distro a shot seeing as they are usually more bleeding edge, and if that fails, who knows! 😉
So, I managed to get further in the process this time. the issue with
sudo apt -y purge --allow-remove-essential shim-signed
was the -y. I removed it and it did its thing.
sudo apt -y install --allow-remove-essential grub-efi-ia32 grub-efi-ia32-bin worked, but
sudo grub-install --force --target=i386-efi /dev/mmcblk1 has given me an error saying that the EFI directly can't be found. I tried the same command to /dev/mmcblk1p1 (EFI partition) as well as to /dev/mmcblk1p2 (Partition where LM is installed) I always get the error that the EFI directory cannot be found.
Liuxium,
You are correct about what I am mounting. I ran the command you asked me to before doing the chroot command and this was the output...
sda
mmcblk1
mmcblk1
I then did "sudo chroot /mnt" (no quotes) and ran
"sudo grub-install --force --target=i386-efi /dev/" The results were...
Installing for i386-efi platform.
grub-install: error: cannot find EFI directory.
I am not sure why it's not finding the EFI directory seeing as when I cd into /mnt/boot, ls shows it there with with a BOOT directory that has several .efi files. BOOTX64.efi, bootia32.efi, fbx64.efi and mmx64.efi
@Unknown: Can you do it all again and instead of the command:
lsblk -no pkname $(mount | grep /mnt/boot/efi | awk '{print $1}')
can you just run:
mount | grep /mnt/boot/efi | awk '{print $1}'
at the same point of the instructions?
I'd expect to see '/dev/mmcblk1p1' returned together with '/dev/sda1'.
If it does, then use the following 'grub-install' command when relevant:
sudo grub-install --force --target=i386-efi /dev/mmcblk1
and if that doesn't work, try throwing in an extra couple of flags:
sudo grub-install --force --target=i386-efi --boot-directory=/boot/grub --efi-directory=/boot/efi /dev/mmcblk1
I started from scratch. Fresh install of mint. I was able to get through all the commands with no errors. I had to use the...
sudo grub-install --force --target=i386-efi --boot-directory=/boot/grub --efi-directory=/boot/efi /dev/mmcblk1 command
...to get grub installed, but after all of that, mint still will not boot from the internal storage. It just boots to the grub cmd. I went into the UEFI (bios) to check the boot entries and there were two. The linux mint usb I created to point to the bootia32.efi file and ubuntu, which would have been created after install I'm guessing. Although I don't know what it points to on the internal storage.
So, when I go to "Add Boot Option", the hierarchy of files and directories along with directory contents is as follows....
-mmcblk1p1/grub/unicode.pf2 (file)
-mmcblk1p1/grub/grub/i386-efi (with heaps of .mod files)
-mmcblk1p1/grub/grub/locale (en_CA.mo, en_GB.mo, en_AU.mo, en@quot.mo)
-mmcblk1p1/grub/grub/fonts (unicode.pf2)
-mmcblk1p1/grub/grub/grubenv (file with no extension)
-mmcblk1p1/EFI/ubuntu (grubx64.efi, shimx64.efi, mmx64.efi, BOOTX64.CSV grub.cfg)
-mmcblk1p1/EFI/BOOT (BOOTX64.EFI, fbx64.efi, mmx64.efi)
-mmcblk1p1/EFI/EFI/ubuntu (grub.efi, grubia32.efi)
-mmcblk1p1/EFI/EFI/BOOT (BOOTIA32.EFI)
I know the above is bit of a mess. If we could chat with viber or discord I could send you pics which would make things much easier to understand.
Anyway, after it failed to boot from internal storage, I tried grasping at straws by adding the BOOTIA32.EFI as a boot option, but it just takes me to the grub command line, as does the grub.efi and grubia32.efi files.
I am quite happy to keep plugging away at this if you are still up for helping me.
Clayton
I forgot to mention that mount | grep /mnt/boot/efi | awk '{print $1}' didn't display mmcblk1p1
mount | grep /mnt/boot | awk '{print $1}' did.
@Unknown: The way this reads it is seems to have installed GRUB under 'mmcblk1p1/EFI/EFI' for some reason.
Try running everything as a script by just copying and pasting this into the terminal after a clean installation. Note that some of these lines appear across two lines in this comment but are actually on the same line when running the command - copy and past should preserve this otherwise just check that each line starts with either 'sudo' or '#' for a comment.
# begin
sudo mount /mmcblk1p2 /mnt
sudo mount /mmcblk1p1 /mnt/boot
# bind the current filesystem to the installed one
sudo mount --bind /boot/efi /mnt/boot/efi
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /run /mnt/run
sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
# remove shim
sudo chroot /mnt apt -y purge --allow-remove-essential shim-signed
# install 32bit GRUB
sudo chroot /mnt apt -y install --allow-remove-essential grub-efi-ia32 grub-efi-ia32-bin
sudo chroot /mnt grub-install --force --target=i386-efi --boot-directory=/boot/grub --efi-directory=/boot/efi /dev/mmcblk1
# unmount everything
sudo umount /mnt/sys/firmware/efi/efivars
sudo umount /mnt/run
sudo umount /mnt/dev/pts
sudo umount /mnt/dev
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/boot/efi
sudo umount /mnt/boot
sudo umount /mnt
# end
Ya, that's exactly what it did. Not sure why either. When I first tried (up until this evening that is), not matter what I did, the EFI directory was never found, even though it was clearly where it was supposed to be.
mmcblk1p1 was mounted properly to /mnt/boot. When I would cd into that and "ls", there it was. (uppercase) EFI.
I'm trying to learn and understand what each of the commands is doing and where things are being installed. This command however, confuses me a some.
sudo grub-install --force --target=i386-efi --boot-directory=/boot/grub --efi-directory=/boot/efi /dev/mmcblk1
For instance, I look at it and I think, shouldn't the the --efi-directory= be /mnt/boot or /mnt/boot/EFI?
@Unknown: The 'grub-install' command is issued from within the mounted '/mnt' filesystem because it is prefixed with 'sudo chroot /mnt' so there is no need to prefix the '--efi-directory= ' option value with '/mnt'.
The latest attempt had no errors, but the tablet just boots to the "No bootable device" screen.
There was an old form discussion about this topic here...
https://unix.stackexchange.com/questions/296096/32bit-efi-with-64-bit-linux-os-can-it-be-done
Where a fellow shows pretty much the same /boot/efi/EFI folder structure I'm getting when the install completes (except I don't have grub_uefi or Windows), but his worked with an old version of ubuntu, but as we know, that functionality is long gone out of the box with ubuntu.
I was considering reinstalling Debian, which did boot from internal storage, it was just really slow (I mean, way slower than running mint from a USB drive). If I did, would I be able to copy specific files to a LM install and have it boot. If so, which files?
I'm really frustrated this won't work. If you have any more ideas, I'm game to try. Many thanks for everything thus far.
Clayton
@Unknown: Actually that error might not be such a bad thing as it is possible there is an old NVRAM entry pointing to a now deleted Windows installation. Can you boot from your ISO again and then enter the following (skip the comment lines):
type efibootmgr
# if the 'efibootmgr' is not installed try
sudo apt-get update && sudo apt-get install -y efibootmgr
# then remove any NVRAM entries that exist (note this may error at some point as it is doing a blanket wipe):
for i in $(seq 0 20); do sudo efibootmgr -b $i -B; done
# now create a boot entry for Linux
sudo efibootmgr -c -d /dev/mmcblk1 -p 1 -l \\EFI\\ubuntu\\bootia32.efi -L Linux
Then exit from your ISO and try a clean reboot. If this doesn't work the first time, perform it all again and then it should work.
I had to take a brain break from this for a couple days!
When I got back at it I started from a fresh install and went through installing grub again. I noticed that when I issue this sudo mount --bind /boot/efi /mnt/boot/efi, grub won't install. It says "failed to get canonical path of /cow". When I unmount that, the install goes through with no errors.
As always though, I get a grub prompt when trying to boot from bootia32.efi. Or the unable to find a boot device from any other efi file.
I managed to boot from the internal storage though. I had to issue these commands at the grub prompt.
set root=(hd0,2)
linux /boot/vmlinuz-5.15.0-56-generic root=/dev/mmcblk1p2
initrd /boot/initrd.img-5.15.0-56-generic
boot
Obviously this is definitely not optimal at all and would like to know why bootia32.efi is not calling the correct file (grub.cfg?) that has the vmliuz and initrd files in it.
I guess another question would be how is Debian able to make it work with what appears to be the same files that grub-install is placing in the efi/EFI/BOOT folder?
Also, the efi/EFI/ubuntu folder has only two files in it. grub.efi and grubia32.efi. What is their purpose. For kicks and giggles, I've tried setting a boot option in the UEFI for each of those and they don't do anything.
I know, so many questions from this crazy Canadian guy. Hope I'm not bugging you....too much! 😉
@Unknown: Have you tried the 'efubootmgr' commands above yet?
Oh ya, sorry. I forgot to mention that I did try the efibootmgr commands, but when choosing bootia32.efi it still went to the grub prompt.
@Unknown: Can you boot again into your installed system using GRUB and 'set root=(hd0,2)' etc, and then once in run:
sudo apt -y purge --allow-remove-essential shim-signed
sudo apt -y install --allow-remove-essential grub-efi-ia32 grub-efi-ia32-bin
sudo grub-install --force --target=i386-efi --boot-directory=/boot/grub --efi-directory=/boot/efi /dev/mmcblk1
Then run:
sudo find /boot/efi -iname \*.efi
which should return something like:
/boot/efi/EFI/ubuntu/grubia32.efi
/boot/efi/EFI/BOOT/BOOTIA32.efi
and maybe others e.g:
/boot/efi/EFI/ubuntu/bootia32.efi
Finally for each filename and path returned drop the leading '/boot/efi' and change each '/' to '\\' when repeating the command
sudo efibootmgr -c -d /dev/mmcblk1 -p 1 -l \\EFI\\\\filename -L
for example:
sudo efibootmgr -c -d /dev/mmcblk1 -p 1 -l \\EFI\\ubuntu\\grubia32.efi -L grubia32
sudo efibootmgr -c -d /dev/mmcblk1 -p 1 -l \\EFI\\BOOT\\BOOTIA32.efi -L BOOTIA32
sudo efibootmgr -c -d /dev/mmcblk1 -p 1 -l \\EFI\\ubuntu\\bootia32.efi -L bootia32
and then try booting and see what happens when you select each new option you created from the boot menu?
After booting from internal through the grub cli, I executed the commands in your last post without mounting or binding anything. Not sure if that's what you wanted me to do, but the results are as follows...
- The shim-signed had be removed so nothing more was done.
- The latest grub had been downloaded already.
- The install command resulted in an error stating, Failed to get canonical path of dev/mmcblk1p2.
That's as far as I went before writing this to you.
Clayton
I re-issued all of the commands to install grub again after formatting the EFI partition in gparted. The BOOTIA32.efi was installed to EFI/BOOT and grub.efi and grubia32.efi were both installed to the EFI/ubuntu folder. I've never had a bootia32.efi installed to the ubuntu folder though. This time I get no bootable devices, so I'll need to use the USB to get back in to fix it so I can at least boot from the grub cli.
@Unknown: So now after booting from your ISO you can recreate the NVRAM entries with:
for i in $(seq 0 20); do sudo efibootmgr -b $i -B; done
sudo efibootmgr -c -d /dev/mmcblk1 -p 1 -l \\EFI\\ubuntu\\grubia32.efi -L grubia32
sudo efibootmgr -c -d /dev/mmcblk1 -p 1 -l \\EFI\\BOOT\\BOOTIA32.efi -L BOOTIA32
and then reboot and see what happens when you select either of the two options from the boot menu.
Sorry dude, I see that I was vague in my last post. I did use the efibootmgr commands before messaging you, and all but the BOOTIA32.efi boot entries give me the no bootable devices message. BOOTIA32 takes me to the grub cli still.
@Unknown: As a last resort, boot your USB ISO and copy the working bootia32.efi from the ISO to the installed system but over one of the ones that isn't working.
Hi, please i need help. I'm trying to install Lubuntu 22.04. I modified the iso with your script, then I launched the installation (with usb stick), unfortunately the installation fails, with the following error:
The bootloader could not be installed. The installation command grub-install --target=i386-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --force returned error code 1.
can you help me solve the problem? thx
I tried running the treetoobit.sh --unsupported script also, but it crashes at the statement:
chroot ${TARGET} apt -y install --allow-remove-essential /usr/src/grub-efi-ia32.deb /usr/src/grub-efi-ia32-bin.deb ( row 270 )
the terminal remains blocked. Help pls :'(
I've grown tired of Ubuntu and have switched over to Debian (now 12.1) in most places. I have a T100HA which I am trying to revive and which @linuxium has been most helpful in the past. As I come back to this old machine I see the treetobit.sh routine to add the 32 bit loader into the Debian iso, which worked fine. My question is, do I need all the isorespinner stuff I used to need in the past as well or is that just not an issue anymore. Thanks.
@billP: if you just want to boot Debian on a device that requires a 32-bit bootloader then 'treetobit.sh' is fine. The 'isorespinner.sh' script is more for additionally running different kernels of adding useful packages and is purely Ubuntu focussed.
@Paul: Lubuntu (in their wisdom) decided to remove support for 32-bit packages which included GRUB. As part of respinning, I had to update the GRUB packages as some earlier versions included significant security vulnerabilities and were withdrawn from the *buntu package libraries. Now respinning Lubuntu tries to install the latest GRUB packages which it can't find for 32-bit so it fails. What's the solution? I've got an old respun Lubuntu ISO which you should still be able to boot from and then use to 'hack' an installataion. Alternatively seek out another distro that works or is simpler to respin/install.
@billP I have a T100TA! I would like to try installing Lubuntu because don't think Ubuntu runs well because it only has 2GB of RAM!
@Linuxium I would like to try installing Lubuntu because having very bare hardware I need a lightweight system. But if I use the old ISO can I get the 22.04 and subsequent updates?
and anyway I would need help to do this process :))
@linuxium can u help me please?
@Paul: Have you tried my old respun Lubuntu ISO available from the "ISOs" link above and if so, what specifically do you need help with?
@linuxium, sorry but I didn't understand where to find the ISO. Now downloaded and installed Ubuntu! everything works. Thank you so much for the support. you are the best!!!
Did somebody recently tried to use the treetoobitiso.sh script on KDE NEON? I get the message it's a not supported distro, although it's a Ubuntu flavor.
Post a Comment