Hi All,
I ran into a nasty problem 3 days ago upgrading from 22.04.5 to 24.04.x.
The upgrade upgraded Grub, and that broke my boot.
Hardware context:
An HP ELitebook 8760w (vintage 2011)
A 4TB SSD boot disk
BIOS-boot (the UEFI on this venerable machine is a prototype and is broken, so I have to use legacy BIOS, which is fairly good.
GPT partition table
sda1 is a 1 Mib partition for the boot blocks, no FS, BIOS-Grub flag.
sda2 is the linux / boot partition
I used grub-install (on the previous grub) with ādisk-module=ahci, because legacy BIOS drivers are limited to 32-bit LBAs, and that only maps 2TiB of data, not 4TiB, so the boot would be broken when the boot files land after the 2TiB limit. That happened to me back in 2022 with 18.04, and I fixed it using native Grub drivers with the above parm (the native drivers support 64-bit LBAs). And this worked fine during all upgrades until 24.04 three days agoā¦
ā¦ when the new Grub 2.12 broke this setup.
At boot, Grub now spits:
*Native disk drivers are in use. Refusing to use firmware disk interface.*
*error: disk 'hd0,gpt2' not found.*
*Entering rescue mode...*
I have since then tried various ways to reinstall Grub on the disk, to no avail. I can grub-install on the disk (using chroot or not, and the new āmodules=āahciā parameter that replaces the previous ādisk-module=ahci). grub-install seems happy and gives no error.
But at boot time, Grub insists on trying to boot from (hd0,gpt2) while the linux partition is in fact on (ahci0,gpt2) - I can confirm this from the grub rescue prompt.
The disk / partition / file system are still healthy:
First, because I checked them,
and then because the latest Rescuedisk (12.00) is able to locate the bootable partition (/dev/sda2, aka (ahci0,gpt2) for Grub, and boot in Gnome with my dual screen properly configād! Of course, when it does so, the keyboard and mouse end up dead, but still an achievement!
Would anyone of you All had an idea to fix this mess?
It shows that āGrub2 (v2.00) is installed in the MBR of /dev/sdaā, which means that the grub-installs I ran didnāt write there (?!?!):
The grub-install I used is 2.12, as confirmed by a grub-install --version
that says 2.12-1ubuntu7.1
Hi rubi1200,
Done boot-info (added as a P.S. in original message), but canāt do boot-repair:
As far as I know, boot-repair does not support Grub native drivers for partitions greater than 2TiB, so it could actually do more damage trying to fix thingsā¦
Never seen the need for requirements for grub over 2TiB.
For very large drives either / (root) or a /boot inside the limit at the beginning of drive. Then use rest of drive as /home or data partition(s).
HPs seem to have more issues with Linux than other brands.
For very large drives either / (root) or a /boot inside the limit at the beginning
of drive. Then use rest of drive as /home or data partition(s).
Problem is, there is no way to control where ext4 allocates spaceā¦ that already as 3.5 Tib in use!
And I donāt feel too much like completely reorganizing this disk yet, with a separate /boot partition. Manipulating disks this size is heavy and time consuming, even on SSDsā¦
HPs seem to have more issues with Linux than other brands.
I actually had little problems so far with my old Elitebooks, and this specific problem definitely looks like pure software - not finger-pointing grub, but stillā¦
Ah!
āThis question was voluntarily removed by its authorā, AskUbuntu says.
As for the others, they seem to be related to UEFI, which I very specifically disabled.
Well, thatās quite a set-up.
Congratulations for keeping a vintage legacy laptop alive with modern GPT and a whopper of a disk - splendid effort
Now, many moons ago, I remember something about conflict between the flags pmbr_boot and grub:bios_grub as shown in the boot-repair report
Line 134 - sda:4001GB:scsi:512:512:gpt:ATA Samsung SSD 870:pmbr_boot;
Line 135 - 1:17.4kB:1049kB:1031kB::grub:bios_grub;
My memory is hazy, but I think that you should set the flag pmbr_boot to off
Using parted in a live session should do this. flags (on or off)
Before you do anything, please ensure that you have data backups.
More news:
Whatever grub-info says (ā=> Grub2 (v2.00) is installed in the MBR of /dev/sdaā):
the grub-install that ran was the right 2.12 (from the liveCD 22.04.2): I suspect grub-info means to indicate this is Grub2 (rather than Grub1) but does not have the clue for the exact version of Grub2 / grub-install in the bootblocks.
It seems grub-install actually did write the bootblocks to sda1, because using different parameters (in āmodules=) resulted in an updated boot-info sda1 (āBoot Info Summaryā) that was consistent with the change:
=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 34
of the same hard drive for core.img. core.img is at this location and
looks for (,gpt2)/boot/grub. It also embeds following components:
modules
---------------------------------------------------------------------------
pci boot scsi ata ahci fshelp ext2 part_gpt biosdisk
---------------------------------------------------------------------------
Thanks for the congrats
Actually, this old machine is still more powerful than many modern ones I could buy. It was the Rolls of notebooks back then, and in some ways, it still is!
And thanks for the clue, Iām gonna study it immediately: I donāt even know what pmbr_boot is, time to look and learn.
Your original post also inspired me to look at alternative grub packages.
Of course, due to your hardware and installed OS, itās highly unlikely that anyone can reproduce your exact situation and offer a comprehensive ,reliable answer.
Therefore, all we can do is just offer a bit of educated guesswork.
I searched synaptic and came across grub-pc-bin
GRUB is a portable, powerful bootloader. This version of GRUB is based on a
cleaner design than its predecessors, and provides the following new features:
Scripting in grub.cfg using BASH-like syntax.
Support for modern partition maps such as GPT.
Modular generation of grub.cfg via update-grub. Packages providing GRUB
add-ons can plug in their own script rules and trigger updates by invoking
update-grub.
VESA-based graphical mode with background image support and complete 24-bit
color set.
Support for extended charsets. Users can write UTF-8 text to their menu
entries.
This package contains GRUB modules that have been built for use with the
traditional PC/BIOS architecture. It can be installed in parallel with
other flavours, but will not automatically install GRUB as the active boot
loader nor automatically update grub.cfg on upgrade unless grub-pc is also
installed.
Other grub packages with similar attributes are also listed - perhaps one or another may help?
In a nut shell, The pmbr_boot flag is a disk flag used in GPT (GUID Partition Table) disks to enable the boot flag on the GPTās protective MBR (Master Boot Record) partition. This flag is necessary for old BIOS (Basic Input/Output System) computers to boot from GPT disks, as it allows the boot loader and operating system to be GPT-aware.
BIOS with old MBR hid core.img in the sectors after MBR but before first partition. With gpt that space does not exist, so for BIOS boot with gpt, you have to have a bios_grub partition.
Windows also hid info in the sectors after the MBR, there used to be conflicts, until grub did a work around. With gpt Windows has a Microsoft reserved partition for its info, so no conflicts. Also Windows only uses UEFI boot with gpt.
Because of HP issues with early UEFI, I have seen a lot of users just use BIOS boot on old HPs.
While I booted old system with BIOS, I converted to gpt before new system with UEFI. But I added both bios_grub and an ESP - efi system partition as it also likes to be near āfrontā of drive as first two partitions on every new drive & larger flash drives. That was so I could move drive to new system without having to totally reformat it, just convert to UEFI version of grub.
Thanks, Iāll look at that too.
OTOH, Iām already deep enough into the dark, so it might not be the best time to add other packages in the picture and muddy things a bit more!
Hmmmā¦
I donāt see them flags conflicting, actually.
The fake partition table in the GPT MBR is supposed to redirect the boot to the boot blocks past GPT, and the bios_grub partition happens to be there.
And Iām thinking, this machine has booted for a few years with this ahci setup and those flags, too.
I should probably concentrate on why grub-install (with the ahci module) insists on chasing (hd0,gpt2) rather than (ahci0,gpt2) like it used to do.
The fact is, when the boot fails, the rescue prompt shows that the boot blocks only see ahcix disks.
running ālsā from the rescue console show that clearly.
OTOH, running āsetā from rescue console shows prefix and root are referencing hd0.
This now looks clearly to me like the root of the problemā¦
