Xubuntu Dualboot on Fujitsu LH532

Convert Ubuntu to Legacy Mode with Boot-Repair

You may skip to the acutal setup.

Background

After using Win 7 & 10 for six years on my Fujitsu LH532 , Windows 10 often falls into blue screen. Sometimes, it won’t even start up.

Give Xubuntu a try

Hoping to give a second life to my old , I’ve decided to try this popular lightweight distro.

Initial partition setup

I followed the instructions from Danatela’s question, including the optional setup of separate /var and /tmp partition.

Everything ran smooth until grub-efi-amd64-signed package failed to install”, so the installed Xubuntu won’t boot.

/dev/sdaX mount point
6 /
7 /home
8 /boot
9 /var
10 /tmp

Understanding BIOS Legacy vs UEFI

The installation process was far from easy: I had to install it in BIOS Legacy the mode, but my 64-bit live USB booted in UEFI mode from the BIOS (Version 1.10). In the live session, I double-checked the existence of the folder /sys/firmware/efi/; in Win 10, I ran “msinfo32” to confirm that it’s installed in BIOS Legacy mode.

I can’t find a way to boot a 64-bit live USB in BIOS Legacy mode. I booted the live session by pressing <F12> after switching on, thus booting from BIOS. There’s only one relevant entry for USB stick, so it certainly booted from BIOS, but into UEFI mode due to the presence of an EFI partition made by Rufus. I’ve also tried UNetBootIn and Linux’s disk image writer with 64-bit OS ISO file. All of these methods lead to a live session in UEFI mode.

After some searching, I’ve understood that the mode of the live session (BIOS Legacy/UEFI) determines that of the installed OS.

First boot-repair attempt

At this stage, I was tempted to convert Xubutnu to Legacy mode. The Community Help suggested using “Advanced options” in Boot-Repair. However, I was faced with another error: this software told me to “close all package managers” and try again later.

I wasted hours finding the possible causes, but that’s fruitless. Someone says Boot-Repair doesn’t support separate /var partition.

It could still boot into Win 10, so I didn’t dare to overwrite the MBR. (An OS will try to overwrite the MBR so that it’s bootable. Problem arises when you try to install another OS. As a result, boot menu setup is needed, either automatically or manually.)

Here’s the partition table generated by Boot-Info.

Drive: sda _____________________________________________________________________
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sda1               2,048    33,558,527    33,556,480  27 Hidden NTFS (Recovery Environment)
/dev/sda2    *     33,558,528    33,968,127       409,600   7 NTFS / exFAT / HPFS
/dev/sda3          33,968,128   366,962,687   332,994,560   7 NTFS / exFAT / HPFS
/dev/sda4         366,964,734   475,252,735   108,288,002   5 Extended
/dev/sda5         366,964,736   383,963,135    16,998,400  82 Linux swap / Solaris
/dev/sda6         383,965,184   433,963,007    49,997,824  83 Linux
/dev/sda7         433,965,056   453,963,775    19,998,720  83 Linux
/dev/sda8         453,965,824   454,940,671       974,848  83 Linux
/dev/sda9         454,942,720   465,096,703    10,153,984  83 Linux
/dev/sda10        465,098,752   475,252,735    10,153,984  83 Linux

I also found the line “BIOS is EFI-compatible, and is setup in EFI-mode for this live-session.

Manual GRUB fix attempt

I also tried the commands on How to Ubuntu, with an additional command.

sudo mount --bind /var /mnt/var

However, when I update-grub, it complained the lack of EFI partition.

Blow-up and rebuild

Ubiquity installer

After searching on the matter for another several hours, I decided to redo the installation according to IT’zGeek’s installation guide to verify the above claim about /var.

I don’t remember the exact partition size type, but their approximate size.

/dev/sdaX mount point Size
5 (swap) 8.2GB
6 /boot 500MB
7 / 30GB

Use the partition scheme for BIOS Legacy even though the live session is running in UEFI mode. This will introduce errors which will be fixed by Boot-Repair later.

As expected, the installer collapsed in the middle of the installation, when it tried to install grub-efi-amd64-signed. I got into the same error dialog box.

Second Boot-Repair attempt

Noonetheless, Boot-Repair’s “Recommended repair” worked this time: it suggested three commands (that I’ve forgotten) to be issued in a dialog box. I followed the suggested steps. Despite the error message displayed in the program, I finally managed to have a GRUB 2 menu when I restarted the machine.

An error occurred during the repair.

Please write on a paper the following URL: http:// paste.ubuntu.com/p/csGtkmSs6d/

In case you still experience boot problem, indicate this URL to: boot.repair@gmail.com

You can now reboot your computer.

The boot files of [Ubuntu 18.04 LTS] are far from the start of the disk. Your BIOS may not detect them. You may want to retry after creating a /boot partition (EXT4, >200MB, start of the disk). This can be performed via tools such as gParted. Then select this partition via the [Separate /boot partition:] option of [Boot Repair]. (https://help.ubuntu.com/community/BootPartition)

In this live session, the roles of /dev/sda and /dev/sdb were inverted. Since the link to Ubuntu Pastebin is temperarory, I intentionally added a whitespace in the middle so that Google Bot won’t complain about the dead link in a year or later.

Last steps

The GRUB2 menu didn’t show Win 10. This is easily solved by os-prober and update-grub, both run as sudo. Then, I continued the apt installation by running update and upgrade and restarted the machine. I found three Win 10 entries in the boot menu.

*Ubuntu
 Advanced options for Ubuntu
 Windows Recovery Environment (on /dev/sda1)
 Windows 10 (on /dev/sda2)
 Windows 10 (on /dev/sda3)

Fabrizio C provided an excellent answer on how to remove any one of them. The instance ${OS} in the for loop represents each line of the output of sudo os-prober.

$ sudo os-prober
/dev/sda1:Windows Recovery Environment:Windows:chain
/dev/sda2:Windows 10:Windows1:chain
/dev/sda3:Windows 10:Windows2:chain

For example, ${LABEL} takes value in the third column with ^ replaced by whitespace.

You may have a look at my /etc/grub.d/30_os-prober (lines 158–166) for details.


No comment