Xubuntu 24.04 LTS installer ignores bootloader device

[Peter Lee]

Xubuntu 24.04 LTS Installer ignores specified legacy boot loader installation device

NOTE reported against ubiquity because ubuntu-desktop-bootstrap not yet known to launchpad

xubuntu 24.04 LTS
ubuntu-desktop-bootstrap version 0+git.eef0e0fd6 revision 205
Legacy BIOS mode installation

System is Lenovo H520S bought 2013. HDD GPT sda, SSD GPT sdb. Legacy BIOS mode. Installing to sda13 /, sda14 /home, sda11 /boot, and bootloader device sde, a USB thumbdrive, MBR, one empty ext2 partition.

Installer ignored specified device sde and attempts to install boot loader on sda, which fails.

Note that first run of installer reported that updated installer was available, update was accepted and installer restarted.

Screen photos:
 snap list showing installer version
 manual partitioning display showing sde specification
 installation summary showing bootloader going to sda not sde
 installer failure display
 installer log indicating attempt to install legacy boot loader
   to sda failing because device is GPT not MBR

After installer failure, I was able to manually install the boot loader to sde, and successfully booted so far as the Xubuntu login screen, but since installer failed before user logins had been installed (and presumably no cleanup of unneeded packages, etc, I could get no further.

This is a show-stopper for me.

Note that with the ubiquity installer, one had the option of executing it from the command line with the -b option to tell it to skip grub setup completely. Is there any way to do this with ubuntu-desktop-bootstrap? (See also Launchpad bug report 696926 where a related issue was raised after a change to ubiquity removed the choice of skipping grub installation from the gui.)

[Chris Peterson (cpete)]

Hi and thanks for your report,

Could you please also attach the contents of /var/log/installer? This will help with debugging the issue.

[Peter Lee (billiardmarker)]

I'm currently on holiday, will do this when I return in about a week. PL

On 29.06.24 01:45, Chris Peterson wrote:
> Hi and thanks for your report,
>
> Could you please also attach the contents of /var/log/installer? This
> will help with debugging the issue.
>
> ** Changed in: subiquity
> Status: New => Incomplete
>

[Peter Lee (billiardmarker)]

As requested. PL

On 29.06.24 01:45, Chris Peterson wrote:
> Hi and thanks for your report,
>
> Could you please also attach the contents of /var/log/installer? This
> will help with debugging the issue.
>
> ** Changed in: subiquity
> Status: New => Incomplete
>

[Chris Peterson (cpete)]

Hey Peter, thanks for the logs. I see a couple of partitions with the boot flag and there could be a bug in the handling around that. It also looks like you're pre-partitioning the drives, is that correct? Could you describe the exact steps you take during the install?

Thanks,
Chris

[Peter Lee (billiardmarker)]

Hi Chris

You are correct, partitions on HDD sda and SSD sdb already existed, and USB stick that was intended target for initial grub bootloader in MBR had a small ext2 partition, needed because otherwise grub-install cannot find device to write bootloader.

H520S machine bought in 2013 came with just hdd sda and preinstalled WIN8. At that time, the only way I found to install a working Xubuntu 12.04 LTS Precise was to have firmware set to legacy BIOS and to put grub bootloader on a USB stick, and I continued to use this method subsequently for fear of finding myself with an unbootable machine.There are 2 sets of / /home and /boot partitions on sda so that when upgrading to a new LTS I still had the previous one available in case of serious problems with the new. I continued this practice after adding SSD sdb which is where the active working Xubuntu installations currently go.

Installation procedure was as follows:

Installer USB stick is a Ventoy multiboot with the 24.04 desktop iso copied into its bootable image directory. I found that if I copied the iso to a usb stick with dd then it would not boot on the H520S system. My apologies for omitting this factor on my original report, it didn't seem relevant at the time. Previous LTS dd'd isos didn't have that problem, and the same dd'd 24.04 usb stick did boot properly on another system (Acer C720 chromebook with firmware locked into legacy bios mode). There is a picture of the "no system found" display from the dd'd iso boot attempt in the information attached to my initial report. (I haven't reported that problem (yet)).

So, booted Ventoy multiboot usb stick; selected 24.04 desktop iso to load, selected normal builtin Ventoy loading method (alternative goes via grub2 - see later). With 24.04 live session running:

sudo snap refresh ubuntu-desktop-bootstrap (to save prompt from installer and restart)

Start installer. Select English language, Swiss keyboard, accepted wired internet, selected interactive install, desktop installation, selected 3rd party and additional media stuff, then a manual disk setup. Disk partition and boot device you have from materials attached to the initial report - note that reformatting is requested for / /home and /boot. Afterwards specified initially-installed user and accepted the offered Zürich timezone.

I've just rerun the installation up to the point where it would start writing to the target devices and attach the output of a parted --list command in case this helps (Parted.log), I think that should be consistent with the install run originally reported. Refreshed ubuntu-deskup-boot snap on rerun "0+git.9b015d0d6 231".

Addendum. As noted, Ventoy gives a choice of a builtin loader for the selected iso file or loading via grub2. I've rerun the installation (yet) again selecting the Ventoy grub2 method. It shows the usual initial installer grub menu followed by 24.04 splash screen while loading, which the internal method did not, but everything else appears the same. parted --list output for this attached as Parted2.log, there's an sdc instead of an sdd but otherwise it looks identical. I didn't let the installation continue because of the time it takes an...

[Chris Peterson (cpete)]

Thanks for the info! With the information you've provided and after reviewing the logs again, I think there's enough information to facilitate an investigation; so I'll go ahead mark this as triaged to keep it on our radar. For the time being, it's not clear to me what a sufficient work around would be unfortunately.

[Peter Lee (billiardmarker)]

See above - placing /boot filesystem on usb boot device during the installation is a workaround that results in Grub bootloader going to MBR of usb stick. It's trivial to later rsync /boot contents to the desired hdd or ssd partition and then adjust /etc/fstab to point to it. PL

Could someone look a question 817666, please.