You are not logged in.
2023.07.01 and 2023.08.01 versions of Arch Linux ISO can't boot system. Symptoms are:
- GRUB is loading, menu is appearing
- I can load memtest86+, reboot to UEFI also works good
- when I select "Arch Linux install medium" (first or second menu) screen is blank for 3-5 second, then message appears:
error: cannot load image.
error: you need to load the kernel first.
Press any key to continue...
And then GRUB menu returns.
Last working version is 2023.06.01.
My PC is kinda usual: MSI B560 motherboard, Core i5-11400F, AMD 5700XT, WD NVMe, nothing special. I have Arch Linux installed, with latest kernel, and it works fine.
Tested with three different USB sticks, with all ports, and nothing is changed.
What can I do to debug this situation? Can I get some logs? Or, maybe, this is some known problem?
Offline
Or, maybe, this is some known problem?
It’s that kind of problems that occur when you use a image altering software like unetbootin instead of writing the image 1:1 to the stick, like for example dd does. How did you write the image to the stick?
english is not my first language. If you find a mistake in this post, please mention it in your reply – this way I can learn. TIA
Offline
Or, maybe, this is some known problem?
It’s that kind of problems that occur when you use a image altering software like unetbootin instead of writing the image 1:1 to the stick, like for example dd does. How did you write the image to the stick?
#cat archlinux-2023.08.01-x86_64.iso > /dev/sde
Every time since 2023.01.01 when I installed Arch for first time. And version 2023.06.01 still works!
Offline
Switching the ISO's UEFI boot loader to GRUB has brought nothing but pain and suffering...
Can you access GRUB's shell (press c in the boot menu)?
Run:
set
and post the values of ARCHISO_HINT, ARCHISO_UUID and root.
To sidestep the issue entirely, if you have an Ethernet connection, you can use the Netboot image instead of the ISO.
Offline
post the values of ARCHISO_HINT, ARCHISO_UUID and root
ARCHISO_HINT='hd0'
ARCHISO_UUID='2023-08-01-12-17-20-00'
root='hd0'
btw, I know almost nothing about GRUB, but when I tried to find some logs or boot something manually, I found ls command, and it's output is:
(memdisk) (hd0) (hd0,msdos2) (hd1) (hd1,gpt1) (hd2) (hd2,gpt1) (hd3) (hd3,gpt1) (hd4) (hd4,gpt1) (hd5) (hd6) (hd6,gpt2) (hd6,gpt1) (hd7) (hd7,gpt1)
Yes, I have plenty of drives... Two NVMe, four HDD, one BR-ROM.
My current Arch installation is on NVMe, with systemd bootloader and EFI parition. Maybe, it is some misdetection that leads to wrong mount points (or something like this)?
Also, BIOS boot menu shows my USB stick two times:
UEFI: UFS 2.0 Silicon-Power16G1.00, Partition 2 (UEFI: UFS 2.0 Silicon-Power16G1.00)
UEFI: UFS 2.0 Silicon-Power16G1.00
Offline
Can you see the kernel in the hd0 device?
ls (hd0)/arch/boot/x86_64/vmlinuz-linux
Offline
Can you see the kernel in the hd0 device?
ls (hd0)/arch/boot/x86_64/vmlinuz-linux
Yes.
I can even do
linux /arch/boot/x86_64/vmlinuz-linux
, with all kernel parameters as in GRUB config, and it finished quietly. And then I can do initrd, and it also finished quietly.
btw, I make small mistake when describe boot sequence.
For the first time when I select to boot linux from GRUB menu, it just returns to menu after couple of seconds. And only second time it shows errors.
Offline
For the first time when I select to boot linux from GRUB menu, it just returns to menu after couple of seconds. And only second time it shows errors.
Does it show any messages the first time it returns?
Offline
ImmortAlex wrote:For the first time when I select to boot linux from GRUB menu, it just returns to menu after couple of seconds. And only second time it shows errors.
Does it show any messages the first time it returns?
Nope.
But I also found one strange thing.
When I select memtest+ just after boot to GRUB, it loads and starts tests.
But when I select linux, return to menu and then start memtest, it shows
error: cannot load image.
Press any key to continue...
And memtest starts only after keypress.
Seems like something happened even on first unsuccessful start of linux.
Offline
Still have same issue with version 2023.09.01.
Offline
Still have same issue with version 2023.09.01.
I am having the exact same problem here
Offline
I've the same exact problem with a cheap chinese tablet.
I've tried with two different pendrives that works flawlessly on another machine.
The set command of the uefi shell does not return any of the required variables :
set
path = FS0\efi\tools\;FS0:\efi\boot\;FS0\;FS1\efi\tools\;FS1:\efi\boot\;FS1\;FS2\efi\tools\;FS2:\efi\boot\;FS2\;
nonesting = false
lasterror = 0xE
profiles = Driver1;Install1;Debug1;network1;network2;acpiview;
uefishellsupport = 3
uefishellversion = 2.2
uefiversion = 2.40
homefilesystem = BLK4;
(btw - the memtest entry doesn't appear in the grub menu).
Offline
Can my uefi be too new ?
Its version is indicated as 2.40
As I enter the uefi Shell I see a lot of aliases.
The first 3 represents block devices.
Then if I issue the ls command i get the error
ls: current directory not specified
In order to get a direcory listing I need to issue the command "fs1:"
After that the ls command reports:
09/01/2023 12;45 <DIR> 2.048 EFI
09/01/2023 12:45 940.352 shellia32.efi
09/01/2023 12:45 1.047.616 shellx64.efi
2 File(s) 1.987.968 bytes
1 Dir(s)
However if I exit from the shell, and then reenter it, I loose the current directory.
In order to boot I suppose I can insert "set" commands in the boot script, But I'm unsure to what I must write.
Any suggestion ?
Offline
This isn't just https://bugs.archlinux.org/task/79439 is it?
Online
I don't think its related to this bug.
I've tried to blacklist them on the linux command line ,
module_blacklist rtsx_pci,rtsx_pci_sdmmc
but with no result.
I've noted that the mentioned shell variabled are not set.
I then opened the grub command line, issued the command
load_env --file /boot/grub/grubenv
After that I noticed that the variables where correctly set.
Then I entered manually the linux and the initrd commands, as specified in the boot sequence,
followed by the boot command
the "linux" and "initrd" commands did not caused any error, but the "boot" command returned immediately with the following error:
error: start_image() returned 0x80000003
Offline
Just out of curiosity, I tried several other live distribuitions.
Some of them where not detected by the Efi boot manager, with the following error:
System doesn't have any usb boot option. Please select other boot option in boot manager menu.
Here is the result of my tests :
Almalinux 9 latest not detected
SystemRescue 10.01 not detected
Linux Mint Xfce not detected
Lmde 5 Cinnamon not detected
Xubuntu 23.04 not detected
Linux lite 6.6 not detected
Bodhi Linux 7.00 not detected
Manjaro-Xfce 23.0 not detected
Debian 12.1.0 OK
Antix-23 OK
Fedora-XFCE_Live-38-1-6 OK
Pardus 21.4 XFCE OK (My preferred, after Arch)
All the distribuition that were detected booted regulary.
This could give some food for thoughts to the developers.
I hope to receive further suggestions, since I'd prefer to use Arch, given that I'm accustomed to it.
Offline
Add "rootwait" to the kernel parameters, unplug the usb key, start the boot, re-plug the key.
Online
No. I tried more than once.
As I press f10 to start the boot, the following message appears immediately:
error: unknown file system
error: you need yo load the kernel first
Press any key to continue...
And then it returns in edit mode.
Offline
Add "rootwait" to the kernel parameters, unplug the usb key, start the boot, re-plug the key.
I my case I got "Invalid buffer alignment: -1991495644".
Offline
Try to juggle the order of events, keep rootwait, but boot the kernel first, then, while it's hopefully waiting for the root device, re-plug the usb key.
Online
Try to juggle the order of events, keep rootwait, but boot the kernel first, then, while it's hopefully waiting for the root device, re-plug the usb key.
I probably didn't fully understand you.
I go to GRUB command line, then do
linux /arch/boot/x86_64/vmlinuz-linux archisobasedir=arch archisodevice=UUID=${ARCHISO_UUID} rootwait
then unplug usb stick
then do
initrd /arch/boot/x86_64/initramfs-linux.img
then replug stick
and nothing happened.
Offline
In grub you should™ be able to edit the commandline (e) and then boot the system (f10)
1. edit
2. boot
3. yank the usb key
4. plug the key
Online
In grub you should™ be able to edit the commandline (e) and then boot the system (f10)
1. edit
2. boot
3. yank the usb key
4. plug the key
By 'boot' you mean I need to wait when grub menu returns? Or just hit F10 then 'yank the usb key' immediately?
As I told earlier, for the first time when I select to boot linux it just returns to menu after couple of seconds. And only second time it shows errors.
Offline
Before you're somehow kicked back to grub, maybe after a second or so.
But w/ rootwait, you'd ideally not be returned to grub at all, but the kernel waits forever for the root device to appear.
Online
The set command of the uefi shell does not return any of the required variables
You should run set in GRUB's shell not the UEFI shell.
Can you access GRUB's shell (press c in the boot menu)?
Run:set
and post the values
Post the value of grub_cpu. If it's i386, the it's an IA32 UEFI. And from a simple test in VirtualBox, it looks like IA32 UEFI booting in archlinux-2023.09.01-x86_64.iso (grub 2:2.12rc1-1, linux 6.4.12.arch1-1), archlinux-2023.08.01-x86_64.iso (grub 2:2.12rc1-1, linux 6.4.7.arch1-1) and archlinux-2023.07.01-x86_64.iso (grub 2:2.06.r566.g857af0e17-1, linux 6.3.9.arch1-1) is broken.
start_image() returned 0x80000003
It looks like the i386-efi GRUB target has been broken for some while now.
Offline