You are not logged in.
For the past few days I have had the following weird issue where sometimes my system is not able to boot successfully, as it gets stuck after the GRUB menu.
I have the following setup:
- MSI B550 Tomahawk motherboard, with UEFI
- Two Kingston 1TB SSD's with Windows and Arch Linux in the first and second slot respectively
- grub bootloader
On a 'normal' boot, the following happens:
- Press power on
- After a second, MSI logo shows up and here I can choose to enter setup etc.
- Then relatively quickly the grub menu shows up, where I can select Arch, Windows or any of the other options.
- For either Arch and Windows the system seems to start up 'normally'
On a 'stuck' boot, the following happens
- Power on
- After a second, MSI logo shows up and here I can choose to enter setup etc.
- Then a black screen until grub loads.
- It then takes considerably more time to load the grub menu (which seems to have a different resolution than on the 'successful' boot, but haven't confirmed this)
- I can select the options like normally (grub is not slow or anything)
- When selecting Windows, boot hangs at
B1InitializeLibrary failed 0x000009a
- When selecting Arch, boot hangs at:
Loading Linux linux ...
Loading initial ramdisk ...
_
Interestingly, when I press F11 during boot, and select either Windows or Grub the system seems to boot without any issues (also when selecting GRUB and going through the grub menu).
I made a basic installation (without any display servers, user configurations, or grub options etc) a few months ago, and booting gave no issues. It was only when I attempted to change config options in grub (resolution, theme etc) when this issue occurred. Notably I entered a wrong resolution in the config, which may have started the issue (?), but I have since then reverted the option back to `auto`. The only options which I now have changed are:
GRUB_DEFAULT=saved
GRUB_TIMEOUT=10
GRUB_SAVEDEFAULT=true
GRUB_DISABLE_OS_PROBER=false
Since this issue I have done the following:
- Remake the grub config with only defaults
- Reinstall grub with
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
- Update the BIOS to the latest versions (and then reinstall grub for it to show up)
- Completely reinstall the system
- Reset the BIOS again using the 'clear CMOS jumper'.
I now have the following options in the BIOS changed:
- Safe boot disabled
- Fast Memory Boot disabled (I am not 100% sure if this corresponds to the 'Fast Boot' option referred in other issues)
- AMD SVM enabled (this option was off before the issues started, so I doubt this is the cause of the issue)
I heavily suspect this is an issue with the motherboard, or some interaction with grub, but I am out of ideas. If there is any additional information I need to provide, let me know!
Last edited by StenSipma (2022-08-29 21:30:45)
Offline
Are you by chance using a discrete GPU and if so, if your motherboard offers the option, are you trying to use that as the default monitor output? I've had Grub customization issues a few times when booting with an external GPU as the primary graphics adapters, and which resolved after switching to the motherboard-native output as the default. Just a guess, and if this fixes it then there is probably a mode-setting option or other graphics driver kernel parameter that can help (especially since you mentioned the different resolution when in the normal vs. stuck scenarios.)
It might help if you post your mkinitcpio HOOKS to make sure the initramfs is getting built correctly too, although in theory that of course shouldn't impact a Windows boot.
Offline
Thanks for the reply, I indeed have a discrete graphics card (AMD Radeon RX 5700 XT), and am using that as the monitor output. I thought it was not possible to use the motherboard output if there is no integrated GPU (which I do not have). Maybe I am missing something.
These are my mkinitcpio HOOKS, never adjusted anything here so I would assume its fine:
HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)
Offline
OK, then without an onboard GPU you may have to adjust some initramfs settings and/or kernel parameters to allow your graphics card to "behave" on boot. Maybe try configuring the initramfs for early kernel mode-setting.
I'm also still curious about the evidence trail behind why Windows also fails to boot. Googling the error your posted leads to a few things about a possibly corrupt or fragmented disk; perhaps it has to do with the size/content of your ESP. But I would try graphics-related initramfs/kernel parameter tweaks first.
Last edited by aldyrius (2022-08-29 18:07:34)
Offline
As I have the `amdgpu` drivers, I added the following to `/etc/mkinitcpio.conf`:
MODULES=(amdgpu)
and then regenerated with
mkinitcpio -P
This did not seem to resolve the issue however, as after rebooting the system now also fails when I select GRUB directly using the BIOS menu:
- Start
- Press F11, and select GRUB to boot
- grub menu shows, I selected arch
-
Loading Linux linux ...
Loading initial ramdisk ...
error: out of memory
Press any key to continue
- Press any key, and it then freezes at the Motherboard logo (which also shows briefly at startup)
Booting without selecting grub (which failed before) still does not work, but did not show the 'error: out of memory'.
As specified on the wiki, I checked that I did not have any `vga=` or `video=` parameters, which is not the case. The parameters which are present are (UUID omitted)
/vmlinuz-linux root=UUID= ..... rw loglevel=3 quiet
Offline
Based on this post, how big is your initramfs file?
Offline
Small update, after some additional attempts at rebooting, selecting GRUB does boot correctly without issues.
Also to make sure it was not some random grub config error I restored the following to their defaults:
GRUB_DEFAULT=0
#GRUB_SAVEDEFAULT=true
and regenerated grub.cfg.
Offline
Based on this post, how big is your initramfs file?
It seems to have a normal size (50MB):
$ ls -lah /boot
total 90M
drwxr-xr-x 4 root root 4.0K Jan 1 1970 .
drwxr-xr-x 17 root root 4.0K Aug 27 11:31 ..
drwxr-xr-x 3 root root 4.0K Aug 27 13:53 EFI
drwxr-xr-x 6 root root 4.0K Aug 29 20:55 grub
-rwxr-xr-x 1 root root 50K Jul 15 14:16 amd-ucode.img
-rwxr-xr-x 1 root root 52M Aug 29 20:17 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root 27M Aug 29 20:17 initramfs-linux.img
-rwxr-xr-x 1 root root 11M Aug 27 11:31 vmlinuz-linux
Which should be plenty for the 1G /boot partition.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 14.8G 0 disk
├─sda1 8:1 1 748M 0 part
└─sda2 8:2 1 78M 0 part
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:2 0 100M 0 part
├─nvme0n1p2 259:3 0 16M 0 part
├─nvme0n1p3 259:4 0 930.9G 0 part
└─nvme0n1p4 259:5 0 513M 0 part
nvme1n1 259:1 0 931.5G 0 disk
├─nvme1n1p1 259:6 0 1G 0 part /boot
└─nvme1n1p2 259:7 0 930.5G 0 part /
Offline
Have you gone back to turning off AMD SVM in the motherboard settings? (I am reading your initial post to indicate it is in fact still on, and seems like a good variable to test.)
Offline
Turned it off, and no change unfortunately.
Offline
If you remove "quiet" and replace it with "debug" for a kernel parameter we can hopefully see more of what's going on. And although it "shouldn't" make any difference since GRUB is attempting to load the image with your settings, maybe you could try switching to another bootloader, or no bootloader via efibootmgr, etc. I'd do one change each at a time and see if this illuminates any issues.
Offline
So, the 'debug' option did not really give any additional info (as expected)
I am currently in the process of setting up systemd-boot, which actually does seems to work for Arch. I am now trying to find out how to find the FS handle for windows in order to dual boot the system...
Offline
Alright, using systemd-boot seems to work without issues! I guess the issue was with grub after all...
I am still curious to the underlying issue though, any ideas on how to debug this?
Thanks for your help
Offline
Glad to hear it!
As to discovering more underlying info: The debug kernel parameter might require removing loglevel=3, or just setting ignore_loglevel, all of which should be covered on the wiki if you care to go back and look again.
My guess is it's still something related to the graphics adapter under the hood; just a corner-case of sorts that systemd-boot accounts for and GRUB does not. GRUB is very useful and versatile, but it doesn't surprise me that newer solutions fit the bill in this particular case, those having grown up organically in the era of UEFI, NVMe, etc.
Please mark as [SOLVED] unless you have other findings (in which case a wiki update might be better anyway.)
Happy to help. Enjoy your new system!
Offline
I have almost exactly the same problem! I have a Gigabyte X570 Aorus Master motherboard. Two SSDs and also Arch Linux and Windows 11 dual boot.
It has also only been happening in the recent few days.
My Windows 11 also fails to boot sometimes and enters autorepair mode, which apparently doesn't repair anything. I had to grub-install to make Windows bootable.
Arch Linux takes considerably longer to boot, but today I have seen for the first time that it actually failed to boot and froze at the "Loading ramdisk" step.
Last edited by anohigisavay (2022-09-02 05:33:04)
Offline
I would definitely recommend installing a different bootloader besides Grub (I used systemd-boot ). Have not had any issues since doing this.
Offline
This issue should NOT be marked as solved! I am struggling with the exact same issues on my B550 motherboard.
Switching to another bootloader is not a solution, but a work-around.
I don't regenerate my GRUB bootloader frequently, as there is no need for it, but the very recent news item (https://archlinux.org/news/grub-bootloa … ibilities/) and some YouTube content about that issue where the direct reason for me to take action, because both the bootloader and the config file MUST be recreated at the same time (forgetting so leads to direct boot problems).
Ironically, that got me struggling with this issue here, so I cannot successfully use my regenerated bootloader.
So I have to fall back to my old one from earlier this year that works without those issues (thankfully), all thanks to making backups from everything.
Extra info:
In my case, when I use F12 on boot to manually select the GRUB loader for Arch, the issue does not seem to happen at all, but it's just when used as the default boot option, then it starts behaving extremely buggy like mentioned here.
I have also cases where GRUB does not load at all, en other moments when I suddenly get a kind of out of-memory-errors, especially when selecting other operating systems.
Last edited by jongeduard (2022-09-02 21:36:24)
Offline