| 1 |
On Monday, 11 July 2022 01:25:00 BST Peter Humphrey wrote: |
| 2 |
> On Sunday, 10 July 2022 17:37:00 BST Michael wrote: |
| 3 |
> > This is happening if the EFI firmware for some reason has re-scanned the |
| 4 |
> > attached block devices to find bootable UEFI images. I've seen something |
| 5 |
> > as simple as rebooting with, then without a bootable USB drive causing |
| 6 |
> > this. Since the images boot order is editable, in your case via bootctl, |
| 7 |
> > then it should be a fixable problem. |
| 8 |
> |
| 9 |
> But, as I said, the order is unchanged, yet the BIOS displays them in |
| 10 |
> reverse order. I think the BIOS is not long for this world, as you will |
| 11 |
> see... |
| 12 |
> |
| 13 |
> This machine shows bizarre behaviour in booting as well. Often, as soon as |
| 14 |
> the POST is finished and the BIOS asks which kernel image to hand over to, |
| 15 |
> I have no keyboard or mouse - except for CTRL-ALT-DEL, which does reboot. |
| 16 |
|
| 17 |
Check your BIOS* firmware settings for USB and enable xHCI. Perhaps this |
| 18 |
setting was toggled to auto, which may not work reliably. |
| 19 |
|
| 20 |
* I use the word "BIOS" to describe the UEFI firmware menu on a modern MoBo, |
| 21 |
rather than the legacy CMOS stored BIOS. |
| 22 |
|
| 23 |
|
| 24 |
> The thing that got me exercised today was Gentoo complaining that it |
| 25 |
> couldn't mount /boot - wrong FS type or...etc. So I had to do something. |
| 26 |
|
| 27 |
You could have checked with fsck.fat to see what the /boot/EFI partition |
| 28 |
reported, but since you reformatted the ESP it's all new and in working order |
| 29 |
now. |
| 30 |
|
| 31 |
|
| 32 |
> So |
| 33 |
> today (well, yesterday now) I told the BIOS to load its standard optimised |
| 34 |
> defaults, then rebooted, then told it to load my tuned set and rebooted |
| 35 |
> again. Then I booted a SystemRescueCD (because the USB version showed that |
| 36 |
> same no- keyboard problem), formatted /boot with FAT32, zapped / then |
| 37 |
> recovered a week- old backup. Then, still in RescCD, a sync and |
| 38 |
> world-update brought the system back. |
| 39 |
> |
| 40 |
> Even then, running bootctl remove; bootctl install; replace /boot/loader/ |
| 41 |
> loader.conf; bootctl update - still left no UEFI boot option for the Gentoo |
| 42 |
> system, though it usually does create one. I had to use efibootmgr to create |
| 43 |
> a boot option, then do the bootctl dance again. |
| 44 |
> |
| 45 |
> Finally, a bootable, running system. |
| 46 |
> |
| 47 |
> Oh, one other thing. This machine has a small unformatted partition before / |
| 48 |
> boot, and gparted on the rescue CD showed me that it had lost its bios_grub |
| 49 |
> flag. Could that account for the wrong FS type error? |
| 50 |
|
| 51 |
Yes, it is probable you mixed up legacy BIOS (CSM) Vs UEFI booting. You need |
| 52 |
to make sure when you boot with Live media you boot in UEFI mode. |
| 53 |
|
| 54 |
The EFI firmware can be set up to emulate a legacy BIOS configuration, by |
| 55 |
enabling its Compatibility Support Module (CSM). This setting allows legacy |
| 56 |
OSs to boot with a conventional MBR boot loader from a GPT disk. The problem |
| 57 |
which arises on a GPT formatted disk is where to store GRUB's 2nd Stage image. |
| 58 |
Normally, on a disk with a MBR partition table, the space immediately after |
| 59 |
the MBR on sector 0 contains GRUB's 2nd Stage image. On a GPT disk the first |
| 60 |
sector is used to store the GPT partition table and therefore GRUB's 2nd Stage |
| 61 |
image has to be stored somewhere else - in the marked bios_grub partition. |
| 62 |
|
| 63 |
An EFI MoBo which boots an OS installed in UEFI mode, on a GPT formatted disk, |
| 64 |
does not require a CSM or a bios_grub flagged partition. I assume you've |
| 65 |
installed your OSs in UEFI mode and you do not intend to run WinXP on bare |
| 66 |
metal. In this case, disable CSM. |
| 67 |
|
| 68 |
|
| 69 |
> Should I consider re-flashing the BIOS? It's getting on for 10 years old. I |
| 70 |
> did that to another machine once, thereby killing it stone dead. |
| 71 |
|
| 72 |
As you attest some folk have had bad experiences with flashing new firmware on |
| 73 |
their MoBos. I first check if the new firmware is meant to address any issues |
| 74 |
which affect my OS and peripherals and if it does, then I go ahead and flash it. |
| 75 |
If the release offers fixes irrelevant to my kit and OS, I leave it alone. I |
| 76 |
have not yet had a single MoBo fail on me, even after multiple flash |
| 77 |
operations. As long as the flash operation is not interrupted and the image is |
| 78 |
the correct image for the hardware, I would think the flash operation should |
| 79 |
complete successfully without having to J-TAG the chipset. On a 10 year old |
| 80 |
MoBo I would consider replacing the NVRAM battery prior to (re)flashing. |
Archives