Firmware updates could solve a lot of issues, in the case of HP you could ASK HP(Enterprise 
) for rework even for this, because they may make this internal problem and release it only via their drivers updateā¦ And since HP is more Windows oriented, only your seller or their services could do more and even for this this is more interest of HP as enterprise than your niche marketā¦ And since there are voluntary hw stats which says that maybe still 45% boots are not UEFI and that remains the same since 2022, maybe some DMAR bugs is caused this. Coreboot is radical change for throwing old devices out of the ship so some https://canoeboot.org/ existsā¦ But thats unprobable way forward for some Intel thoughts how to approach this HP Windows way for Dell issues how to handle their Windows franchiseā¦ And since freelancing is hard, it only make some pci issues more more kernel devs Space approachableā¦ HP is a way to make smooth things, but Linux is not their first friendā¦ they maybe not have enough stuff and third options are not present on this franchiseā¦
Interesting articles on details of gpt.
I have always referred to this site, the author created gdisk as a replacement for fdisk for use with gpt drives when fdisk & parted did not support gpt.
Hi Hifron,
Well, itās been many moons since HP stopped maintaining the 8760w firmware - the latest update is dated 2012 (thatās the one I have), and the machine is not maintained anymore either.
In addition, Iāve been running for three years with this BIOS and specific partition config, went across three different LTS releases (all updates and upgrades included), so that does not make the firmware my main suspect.
Iām nearly done booting my disk using the Grub rescue console. Painfulā¦
Yes, I ran into it yesterday checking for pmbr_boot, and I found it quite good too!
Hi All,
I have solved the problem mentioned above starting this thread, but it was a long and hard journey.
First of all, something has been broken between Grub 2.06 and 2.12, and that resulted in my previous setup not able to boot anymore. Remember it had been installed in 2018 or so, fixed with native drivers in 2022 when my kernel landed after the 2TiB limit, and had valiantly resisted all upgrades and updates from 18.04 to 22.04.5.
I tried all possible ways to fix my pre-24.04 setup and get it to boot, to no avail.
Then I gave up and decided to go the mainstream way:
- Buy a new SSD (I picked up 8TB this time
) - format it GPT / bios_grub,
- Install a fresh 24.04 on it using a Live USB key into a small partition,
- create a partition on the rest of the disk and move the /home directory of my broken disk to it.
Now making a very long story short:
I used a 22.04.2 Live USB key to create the Ubuntu partition, using the option āerase disk and installā. Then Ubiquity did its job with no error message and offered to restart. At restart, I got a legacy BIOS message saying there was no OS on the diskā¦ Huh?!?
Rebooted the Live key.
Used GParted: Everything looked normal:
- Ubiquity had created sda1,
- set it as 1MB partition,
- installed the grub image bootblocks in it,
- set the bios_grub flag as it should have.
- And it has created a huge ext4 partition (sda2) with the whole rest of the disk, installing Ubuntu on it.
- The content of the root dir looked perfectly normal.
Booted a System Rescue live key.
Used the Find bootable partition option of System Rescue : It found it on sda2 and offered to boot it.
I accepted its offer to boot the partition it had found: That worked. I had a fully functional Ubuntu 22.04.2 on the disk, but just couldnāt boot it without the help of System Rescue. Not good enough.
Rebooted the Ubuntu Live key.
Installed wxHexEdit on it and looked at the Protective MBR (first sector of device sda).
Looked at the partition table: No partition was marked active (by value 80h on first byte of first partition table entry)ā¦
Well, no wonder legacy BIOS said it found no OS. There was indeed none marked active. Boooo.
Used wvHexEdit to change the MBR byte at 1B0h to 80, so legacy BIOS would recognize the partition as active and hopefully jump to sda1 to access the grub boot blocks.
Power off, rebooted.
Ah ah!
This time, I was in the Grub rescue console!
But Grub had spit an error message saying it didnāt have (hd0, gpt2). So I had half booted!
After numerous attempts at dark magic (like grub-installing with various combinations of options, including native drivers, all things that used to work in 18.04 and presumably up to 22.04), I decided to try to play 100% by the rules and fix what Ubiquity had done wrong with them rules:
- Rebooted the Live key
- launched GParted,
- resized the Ubuntu partition sda2 to 1TiB (so it ended well below the 2TiB lethal boundary).
Power off, rebooted the hard disk:
Success! Ubuntu 22.04.2 had booted just fineā¦
So Ubiquity has two problems:
- It knows it has a legacy BIOS machine, since it installed bios_grub and no EFI partition. BUT it doesnāt set the Active byte at 1BEh on the protected MBRā¦
- It knows it has a legacy BIOS machine that thus canāt reach boot files above 2TiB, but it still defaults to create a boot Ubuntu partition thatās well over 2TiB. Shouldnāt it instead limit the boot partition size to fit the 2TiB limit?..
Summary:
Ubiquity is not able to install a system that successfully boots on a legacy BIOS machine with a disk over 2TiB.
Finally, Grub 2.12 does something the Grub 2.0x didnāt do:
It obviously checks the size of the boot partition, and if it sees that it ends after the 2TiB limit, it fails the bootā¦ even if it has been configād with native drivers that could handle the 64-bit LBA and access huge-huge disks. Grub 2.0x didnāt check that, and just attempted to boot anyway.
Adding insult to injury, Grub 2.12 fails the boot with the wrong error message: ā(hd0,gpt2) not foundā is by no way useful. Grub could instead bother to indicate that it just does not want to handle a BIOS-boot partition that crosses the infamous 2TB barrier.
So that looks to me like two bugs in Ubiquity, and some serious shortcoming in Grub 2.12.
That was the short story. Iām not telling you the zillion of attempts that I did to systematically eliminate numerous other possible causes for problems. That kept me busy day and (and good part of) night for over a weekā¦ 
But heck, I now have it working!
Iām eventually going to report that as Ubiquity bugs.
And then I will start taking care of my /home directory to finish up the job I started. And probably regain some sleep before that!
Not sure they do much testing on BIOS boot of drives over 2TiB. Systems since 2012 when Microsoft required UEFI with gpt are all UEFI boot. And drives were a lot smaller back then. Normal install was to a partition for dual boot. My drive in my 2006 build was only 160GB and that was large.
Most suggestions and what I do, are to have a smaller / (root) and then use rest of drive for /home or data.
Grub does not use boot flag. And once booting starts BIOS should not care. But we have seen a few motherboards that want a boot flag. What motherboard do you have? I have seen the requirement for boot flag on gpt with Intel motherboards.
When I first started conversion from BIOS to UEFI, I added both a bios_grub and an ESP, so I would not have to totally redo drive. ESP also has some limit on how far into drive it can be. Usually ESP is first or near beginning of drive.
You do have a way to backup that large of a drive?
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.