Recent Arch ISOs will not boot in UEFI mode on my old system

schatzs · 2024-02-14 13:32:37

The last few Arch ISOs will not boot on my old Sandy Bridge PC in UEFI mode from a USB stick. I found that the Jul of 2023 version could boot UEFI on my system, but that Dec, Jan and Feb will not boot. Not sure about the versions in between Jul & Dec. All work fine booting in BIOS mode. They all will start the UEFI shell. I just built my own ISO with the latest kernel and it will not boot.

I discovered this after a Jan kernel update caused my system to not boot and I needed to try and fix it. I've been using UEFI boot for years, but after the update it could not load initramfs due to a bad magic number. I found a few posts about problems like this, I eventually got it working by first switching to the LTS kernel, increasing the size of my boot/EFI partition, and going back to the standard kernel. Honestly I'm not sure why this fixed it. My gut tells me the problem will come back and it is somehow related to the problem with the installer ISOs.

I would like to help getting the ISO to work again and am willing to try things, but I'm not sure what to do next, or where/how to report an issue for this.

Steve

cryptearth · 2024-02-14 19:56:47

To anyone lost at intels naming scheme like me: sandy bridge / ivy brdige are the codenames for the core i-2000/-3000 series - from 2011!
I'm not sure when uefi2.0 started to get big - but it was with windows 8 and the new secureboot - somewhat in 2012.

So - just a wild guess in the blue: As linux starts to drop support for old hardware - it looks like your's is just getting too old for the most recent 6.x kernels.

schatzs · 2024-02-14 22:03:25

I'm sure that day is coming, but I don't think that is the issue here just yet. This computer is able to boot the latest kernel from an SSD with UEFI + GRUB. This computer is not able to boot from the most recent installation ISOs from a USB drive with UEFI + GRUB, but is able to boot from the USB with BIOS + GRUB. I suspect that if this were mainly a kernel issue none of these would work, but I'm not sure. It dies pretty early in the boot process, I think trying to load initramfs or just after.

Certainly my motherboard and CPU/chipset are old, but they are fairly vanilla x86-64 and as far as I can tell still fully supported. Once it boots everything is fine.

Steve

cryptearth · 2024-02-15 00:10:46

Something doesn't add up here ...

If this very system is able to boot up an installed running system in UEFI mode but fails to boot an archiso install - then either the archiso install image is bad, maybe even the flash drive - or something way different is happening. Do you use USB3.0? If so: Try to boot off of USB2.0. Also check your bios settings for something like XHCI hand-off.
It could be some issue related to USB itself - are you able to use an optical media instead? If you have a 2nd running system available: try PXE boot.

schatzs · 2024-02-15 12:11:06

I'm using my USB2.0 ports since only those are on the front panel. I've tried 2 different USB sticks with the same result. My BIOS has a setting for EHCI handoff in the USB section, it was disabled so I enabled it and got the same result. I burned a DVD, booted from it, selected the UEFI boot from the GRUB menu and got the same result.

Steve

schatzs · 2024-02-15 12:32:35

I will add that there are error outputs during boot, all ACPI Errors which happen on both unsuccessful and successful boots. From what I've researched the consensus is they can be ignored. But there are a lot of them and they push the very first messages off the screen.

I had to take a video to confirm it, but the very first output is "Initramfs unpacking failed: invalid magic at start of compressed archive". I only get this when the boot fails. There are a few posts for this, but none that I can find related to the install ISO.

Steve

V1del · 2024-02-15 12:47:10

there was a bug somewhere that a few systems might have problems with multi-core uncompressing of zstd files, try adding "maxcpus=1" to your kernel params before launching the bootable entry)

If you get the same issue that suggests the ISO was corrupted and either both of your sticks broken or the ISO having an issue, did you verify the ISO checksum from the download?

FWIW this topic came up a bunch of times ... https://bbs.archlinux.org/viewtopic.php … 3#p2144503 but till now no one that was affected has investigated deeply enough-

Last edited by V1del (2024-02-15 12:51:26)

schatzs · 2024-02-18 14:06:25

I tried "maxcpus=1" by typing it into the command line via GRUB, but still no UEFI boot.

I have verified the ISO download sigs, and I've tried a few different USB sticks.

I did go back and determine that the 2023.06.01 ISO is the last one that UEFI boots on my system, 2023.07.01 and all later do not UEFI boot. I uncompressed the initramfs of 2023.06 and 2023.07 and compared them hoping to get clue to follow. They used the save version of mkinitcpio (36), and they have different kernels (6.3.5 -> 6.3.9). But there are a lot of individual file changes because most of the 2023.06 files compressed to *.xz, and the 2023.07 and later compress to *.zst. I'm not sure how this could be relevant given that it works in BIOS boot, but it seems like a strange coincidence.

I also built my own ISO using the Archiso tool. I used the baseline profile, the only package I had to add was linux-firmware to get it to boot in BIOS mode (was missing FW for my NIC), but still no luck getting it to UEFI boot.

My main interest is just trying to help out - my computer is once again working so I'm not in need of a working install ISO for UEFI boot. But this should work and I'd like to help figure it out since I'm one of the few that can reproduce the problem. Any ideas about what else I can try/look into, or a better forum for discussing this are appreciated.

Steve

cryptearth · 2024-02-18 20:28:03

Well, if the difference is the compression xz vs zst then for some reason it seems to be an issue with the different algorithms - and in turn: The hardware seems to be too old - as I already suggested in my first reply.
Guess in the blue: The zst decompression binary uses some native hardware opcodes that the cpu doesn't support - or whatever the difference between CSM and UEFI might be.
Possible solution: recompilation of the pretty much every binary within the airootfs to be compatible with your system.

seth · 2024-02-18 22:25:41

ssue with the different algorithms - and in turn: The hardware seems to be too old - as I already suggested in my first reply.

That's complete and utter bullshit.
If anything it's an SMP issue and for my wild guess: related to spectre.
But in reality we don't know what's off there, everything is a bit anecdotal in this context.

@schatzs, where does the boot process hang? What's the last thing you see? Do you get more output when removing the "quiet" parameter and add https://wiki.archlinux.org/title/Genera … l_messages ?
Do you have secureboot disabled?

cryptearth · 2024-02-18 22:45:48

seth wrote:

ssue with the different algorithms - and in turn: The hardware seems to be too old - as I already suggested in my first reply.
That's complete and utter bullshit.

And here we go yet again after https://bbs.archlinux.org/viewtopic.php?id=292930 - the arch forums being as toxic as the opensuse ones are stupid ...
in the risk to get a ban: F you!

seth · 2024-02-18 23:02:34

This has nothing to do with "toxic" - your statement is objectively false, nonsensical and absurd. And it's not the first time your spouted this "OMG 10 yr old HW lol, that's probably no longer supported" bullshit.

You're not getting banned for calling me toxic, because I'm not a a millenial mental breakdown when somebody says something stupid.
But if the spreading of misinformation and derailing threads with discussions about your emotional deficits*, which you kindly linked another instance of, turns into or out to be systematic trolling, you might get a ban for that.

*I'd remotely get why you'd object to certain terminology, but Scimmia has merely pointed out the factual flaws in your post. Calling that "toxic" is ludicrous.

ewaller · 2024-02-19 00:13:55

Cryptearth, I can confirm that when the ban happens it will be because of misinformation and bad advice. We are not there just yet.

schatzs · 2024-02-19 12:26:32

@seth, I don't see quiet in the GRUB entry, but if I add debug there is a lot more info about starting up USB (it's hard to tell since it I'm capturing this on my phone video)

The last thing I see is:

No filesystem could mount root, tried:
  
Kernel panic not syncing: UFS: Unable to mount root fs on "" or unknown-block(0,0)
CPU: 1 PID: 1 Comm: swapper/ Not tainted 6.7.2-arch1-2 #1 96899bd75afcd7d7875d6a29e4be6d285bc2a7a8
Hardware name: System manufacturer System Product Name/P8P67 LE, BIOS 3801 09/12/2013
Call Trace:
  <TASK>
  dump_stack_lvl+0x47/0x60
  panic+0x334/0x360
  mount_root_generic+0x2e5/0x350
  prepare_namespace+0x64/0x280
  kernel_init_freeable+0x2cb/0x320
  ? _pfx_kernel_init+0x10/0x10
  ret_from_fork+0x34/0x50
  kernel_init+0x1a/0x1c0
  ? _pfx_kernel_init+0x10/0x10
  ret_from_fork_asm+0x1b/0x30

Without debug I see "Initramfs unpacking failed: Invalid magic at start of compressed archive" followed by several screens of ACPI BIOS errors about unresolved symbols and aborting method

seth · 2024-02-19 12:33:50

Without debug I see "Initramfs unpacking failed: Invalid magic at start of compressed archive" followed by several screens of ACPI BIOS errors about unresolved symbols and aborting method

That's https://bbs.archlinux.org/viewtopic.php … 8#p2150778 - assuming you didn't fudge "maxcpus=1" and have secureboot disabled (?) , does it help to https://wiki.archlinux.org/title/Improv … itigations ?

Stewart Little · 2024-02-19 15:59:07

Just for the record I've been following this thread and I've been getting the same problem with my hardware both two desktops and my Laptop, currently I'm having to use Debian as a fallback but I've tried the same as schatzs and got the same result my two desktops one of them is an Intel Core i7-4790K and the other desktop is an AMD FX-8350 processor and my Laptop is a Core i5-2450 processor. For me after it loads grub and goes past it it stops upon the udev bit and then the monitors go to standby mode and don't seem to want to wake up. I just thought it might be worth mentioning that schatzs isn't the only one having said problem.

seth · 2024-02-19 16:34:54

There've been quite some reports of failures to decompress the initramfs over the past months, it's just not clear what the cause is.
Restricting the CPUs has worked in some instances, but not all.
Feel free to test maxcpus=1 or disable the mitigations, more data is gonna be better…

Stewart Little · 2024-02-19 16:43:14

seth wrote:

There've been quite some reports of failures to decompress the initramfs over the past months, it's just not clear what the cause is.
Restricting the CPUs has worked in some instances, but not all.
Feel free to test maxcpus=1 or disable the mitigations, more data is gonna be better…

I've already tried maxcpus=1 or the mitigations but no change, however, I did notice that I started having said problems since this announcement https://archlinux.org/news/making-dbus- … us-daemon/

Though I'm not sure if its related. I've also tried nomodeset and did get past the issue but gdm or other login managers wouldn't then work.

seth · 2024-02-19 17:01:04

tried nomodeset and did get past the issue but gdm or other login managers wouldn't then work

Hold on, this isn't about the install iso at all?
And yes, GUI won't work w/o kms.

Please open a new thread and there provide a log, try to only boot the multi-user.target (2nd link below)

Stewart Little · 2024-02-19 17:04:33

seth wrote:

tried nomodeset and did get past the issue but gdm or other login managers wouldn't then work
Hold on, this isn't about the install iso at all?
And yes, GUI won't work w/o kms.
Please open a new thread and there provide a log, try to only boot the multi-user.target (2nd link below)

I know, but when attempting the install iso I had the same problem as my previous installed system. The nomodeset was tried when it use to be installed but when trying the more recent iso installs I've been having same problem which after udev it wouldn't load at all and the monitor goes to standby. Sorry for not clarifying it properly.

seth · 2024-02-19 23:29:46

same problem which after udev it wouldn't load at all and

Remove the quiet parameter (if present) and the debug parameter(s) and see whether you get "Initramfs unpacking failed: Invalid magic at start of compressed archive" or similar-ish errors or any usable errors at all. Is it also tied to the UEFI/BIOS (legacy) configuration of the firmware?

agapito · 2024-02-20 01:18:04

I don't think this is the case, but I want to remember that to boot the latest Arch Iso you need at least 1G of RAM on your system.

schatzs · 2024-02-20 11:58:04

@seth - I tried maxcpus=1 and mitigations=off together and separately and did not have any different result. Still no UEFI boot from the ISO/USB.

seth · 2024-02-20 14:51:33

For reference, https://bbs.archlinux.org/viewtopic.php … 2#p2149422 - but the december iso should still have a 6.6.x kernel.

Let's just throw more stuff at the wall…

maxcpus=1 mitigations=off  zswap.enabled=0 transparent_hugepage=never systemd.zram=0 rootwait rootdelay=30

This will for sure wait 30s before even attempting to mount the root device, so hold on for that.

schatzs · 2024-02-21 12:41:05

@seth - I tried this and still have the same issue. One odd thing - I tried rootwait rootdelay=30 on both a failing and a working ISO, but I see no difference in the time it takes to get to a failed or successful boot compared to not having those set. Maybe I'm not entering these settings correctly (I'm typing them at the end of the linux line in the grub command editor and pressing ctrl-x). I think that maxcpus=1 is doing something because I can see a small but consistent timestamp difference (about +0.04 sec) when it is set.

Arch Linux

#1 2024-02-14 13:32:37

Recent Arch ISOs will not boot in UEFI mode on my old system

#2 2024-02-14 19:56:47

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#3 2024-02-14 22:03:25

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#4 2024-02-15 00:10:46

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#5 2024-02-15 12:11:06

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#6 2024-02-15 12:32:35

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#7 2024-02-15 12:47:10

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#8 2024-02-18 14:06:25

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#9 2024-02-18 20:28:03

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#10 2024-02-18 22:25:41

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#11 2024-02-18 22:45:48

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#12 2024-02-18 23:02:34

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#13 2024-02-19 00:13:55

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#14 2024-02-19 12:26:32

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#15 2024-02-19 12:33:50

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#16 2024-02-19 15:59:07

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#17 2024-02-19 16:34:54

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#18 2024-02-19 16:43:14

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#19 2024-02-19 17:01:04

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#20 2024-02-19 17:04:33

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#21 2024-02-19 23:29:46

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#22 2024-02-20 01:18:04

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#23 2024-02-20 11:58:04

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#24 2024-02-20 14:51:33

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

#25 2024-02-21 12:41:05

Re: Recent Arch ISOs will not boot in UEFI mode on my old system

Board footer