You are not logged in.
Hi everyone,
This will be my first post here so please be gentle ![]()
Computer specs: TOSHIBA PORTEGE R930 4GiB 1TB HDD Ram Serial: 4E102986H
BIOS: 6.8v
EC: 1.2v
Arch ISO Release: 2024.11.01
I wanted to discuss some issues I have been running into when trying to set up an EFI boot stub on my laptop. I'll start at the beginning of the install so you know my process and partition scheme.
I love the wiki BTW, so much knowledge! Kind of daunting, but I'm getting through it bit by bit (;
As per the wiki (I'm going to jump to "1.6 Verify the boot mode");
- I verify the it with the command listed and it returns "64".
- I connect to a wireless network using iwctl. Connection test succeeded.
- System Clock is updated (I have done this many times).
My partition layout is basic.
-Using fdisk I create a GPT table, partition 1G for EFI (changed type to ueif), 16G for SWAP (type swap), and the rest for root (type linux). I write to disk. Verified EFI partitioin has correct flags using parted (EFI has esp, boot flags).
-I format the EFI part to fat 32, root to ext4 and swap to swap. All using the same commands in the wiki.
I have tried many different ways of mounting (/mnt/boot/EFI/, Etc) but right now I'm mounting my EFI to /mnt/boot.
Install base, linux, linux-firmware, vim, efibootmgr, networkmanager.
genfstab as directed. here I now hostnamectl the host name and timedatectl the time zone.
I arch-chroot into the installation, make Initramfs and now start to mess with efibootmgr to efi boot stub.
THIS IS NOW MY ISSUE (for those who don't want to read my install process XD)
I use the the command
efibootmgr --create --disk /dev/sda --part 1 --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=/dev/sda3 rw initrd=\initramfs-linux.img'The output gives the correct boot order with Arch Linux at the top. Output feel slightly off though. It is as follows;
Boot0005* Arch Linux HD(1,GPT, <UUID>, 0x800, 0x200000)/\vmlinuz-linuxroot=/dev/sda3 initrd=/initramfs-linux.img Using " efibootmgr -v " produces an even weirder string. It is as follows;
Boot0005* Arch Linux HD(1,GPT, <UUID>, 0x800, 0x200000)/\vmlinuz-linux72006f006f0074003d002f006400650076002f007300640061003300200069006e0069007400720064003d005c0069006e0069007400720061006d00660073002d00690073002d006c0069006e00750078002e0069006d006700
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 c9 cc 73 16 ce 3c b5 4a 98 2d 86 66 33 92 09 20 02 02 / 04 04 2a 00 5c 00 76 00 6d 00 6c 00 69 00 6e 00 75 00 7a 00 2d 00 6c 00 69 00 6e 00 75 00 78 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
data: 72 00 6f 00 74 00 3d 00 2f 00 64 00 65 00 76 00 2f 00 73 00 64 00 61 00 33 00 20 00 69 00 6e 00 69 00 74 00 72 00 64 00 3d 00 5c 00 69 00 6e 00 69 00 74 00 72 00 61 00 6d 00 66 00 73 00 2d 00 6c 00 69 00 6e 00 75 0078 00 2e 00 69 00 6d 00 67 00 I did not expect this output.
Now if I go ahead with this and thinking its all done to continue on to make initramfs, passwd, and umount /mnt.
I reboot, and I get the error "insert system disk. Press any key to continue..."
That's it. FYI I was having the same issues with Grub install and also a with systemd boot loader.
Any and all help would be appreciated. I wanna gitgud where I can ![]()
Also exuse me potentially not using correct format of terminology.
Last edited by ArtemisGreyrat (2024-12-03 12:30:34)
Offline
First and main point, do not rely on /dev/sda3 to remain stable and you should not use it to refer to your root partition in such a context. Use one of the persistent identifiers: https://wiki.archlinux.org/title/Persis … ice_naming
For sensible unicode readback from efibootmgr use -u, so efibootmgr -uv. Maybe post the output of that and wrap it in [code][/code] tags
Generally speaking, whether this can work in any shape or form strongly depends on your UEFI being sensible. If you already failed with GRUB and systemd-boot I have very little hope for that. Did you verifiy secureboot is disabled, does the UEFI's own menu list an entry somewhere?
Offline
Hi V1del,
Thank you for your prompt response.
Cheers for the advice for on using persistent identifiers. I did previously do some research on UUIDs and I know my fstab file uses the UUIDs. Would you say its a good rule of thumb to use one of the persistent identifiers when possible?
Using your suggested modifier of -u gives me the same results of the initial output;
Boot0005* Arch Linux HD(1,GPT, <UUID>, 0x800, 0x200000)/\vmlinuz-linuxroot=/dev/sda3 initrd=/initramfs-linux.img efibootmgr -uv gives me the same output as -v;
Boot0005* Arch Linux HD(1,GPT, <UUID>, 0x800, 0x200000)/\vmlinuz-linux72006f006f0074003d002f006400650076002f007300640061003300200069006e0069007400720064003d005c0069006e0069007400720061006d00660073002d00690073002d006c0069006e00750078002e0069006d006700
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 c9 cc 73 16 ce 3c b5 4a 98 2d 86 66 33 92 09 20 02 02 / 04 04 2a 00 5c 00 76 00 6d 00 6c 00 69 00 6e 00 75 00 7a 00 2d 00 6c 00 69 00 6e 00 75 00 78 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
data: 72 00 6f 00 74 00 3d 00 2f 00 64 00 65 00 76 00 2f 00 73 00 64 00 61 00 33 00 20 00 69 00 6e 00 69 00 74 00 72 00 64 00 3d 00 5c 00 69 00 6e 00 69 00 74 00 72 00 61 00 6d 00 66 00 73 00 2d 00 6c 00 69 00 6e 00 75 0078 00 2e 00 69 00 6d 00 67 00 The bizarre thing is, that just to make sure that it wasn't firmware or hardware related, I used archinstall to try and get it to work. AND IT DID
. It worked for Grub and systemd-boot. (I didn't try others). It just seems to be that when manually installing it I get tied up. I'm 100% sure its user error (skill issues
) so its disheartening when an automatic installer can do it and I can't rn
But I have some hope...
At the start of all this I did ensure that secure boot was disabled. I can't gain access to any native UEFI menu (I'll do more digging on how to access/force that.)
Cheers
PS. Thanks on the pointers to use the wrap tags ![]()
Offline
It's very possible your UEFI implementation is just shit and it generally not working properly with that long of an NVRAM entry. archinstall will work because it installs both GRUB and systemd-boot to the fallback path which should be loadable by anything that remotely calls itself an UEFI implementation https://wiki.archlinux.org/title/Unifie … ble_drives (since the Windows installer populates that as well, some bad UEFI implementation simply check and verify they can boot that, if this is such a case there's not much you can do)
But generally using persistent names is the only way you can guarantee that the correct device is looked up, otherwise the mere presence of e.g. the arch boot stick might make it get /dev/sda which wouldn't match with your partition/device setup.
Last edited by V1del (2024-12-03 13:10:34)
Offline
I have been playing round with installing arch with the new ISO on other computers and my boot process and installation of grub worked first time! I think you are right about the UEFI implementation being the cause of my problems.
Cheers for the info on archinstall. It was strange when I used efibootmgr, to sus out how archinstall did the bootloading, only to find no efiboot entries. It wasn't what I expected. Plus seeing as that the grub interface displayed too was weird.
If I wanted to try and fix the NVRAM issues, can I do that through a separate UEFI terminal, or would I need to flash a new bios?
Also are there any tips on how to easily add the UUIDs into commands. They are pretty long and is there any short hand that can be used?
Offline