You are not logged in.
Pages: 1
I've installed Arch a number of times, so not sure what I'm missing here...
I have 2 partitions on the SSD
512M ef EFI
2xxGB 83 linux
I've run all the grub config stuff including:
mkinitcpio -P (no errors)
grub-mkconfig (no errors)
fstab (checked UUID's, they're fine)
/boot seems to have all the necessary things.
When I try to boot to the nvme0 it says 'Enter boot menu' which brings up the screen to select a boot device, nvme0 is the only option, hit enter and it comes right back to the same menu. No error messages, nothing.
Secure boot and TPM 2.0 are disabled, along with anything else that looks like it might be trying to stop it form booting.
Any ideas? I've done this with T470 and other Thinkpad but never had this issue...
Offline
efibootgmr
BootCurrent: 001C
Timeout: 0 seconds
BootOrder: 0019,001C,0000,0017,0018,001A,001B,001D
Boot0000 Windows Boot Manager
Boot0010 Setup
Boot0011 Boot Menu
Boot0012 Diagnostic Splash Screen
Boot0013 Lenovo Diagnostics
Boot0014 Startup Interrupt Menu
Boot0015 Rescue and Recovery
Boot0016 MEBx Hot Key
Boot0017 USB CD
Boot0018 USB FDD
Boot0019* NVMe0
Boot001A* ATA HDD1
Boot001B* ATA HDD0
Boot001C* USB HDD
Boot001D PCI LAN
Boot001E* IDER BOOT CDROM
Boot001F* IDER BOOT Floppy
Boot0020* ATA HDD
Boot0021* ATAPI CD
fdisk -l
Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SAMSUNG MZVLW256HEHP-000L7
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbc671917
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 * 2048 1050623 1048576 512M ef EFI (FAT-12/16/32)
/dev/nvme0n1p2 1050624 500118191 499067568 238G 83 Linux
Disk /dev/sda: 28.64 GiB, 30752000000 bytes, 60062500 sectors
Disk model: Ultra USB 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbff8ee56
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 64 1531903 1531840 748M 0 Empty
/dev/sda2 1531904 1691647 159744 78M ef EFI (FAT-12/16/32)
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 669.2M 1 loop /run/archiso/airootfs
sda 8:0 1 28.6G 0 disk
├─sda1 8:1 1 748M 0 part /run/archiso/bootmnt
└─sda2 8:2 1 78M 0 part
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /mnt/boot
└─nvme0n1p2 259:2 0 238G 0 part /mnt
mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
-> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.17.5-arch1-1
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
-> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 5.17.5-arch1-1
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> Image generation successful
Offline
Your partitioning type is wrong. You should use GPT for an EFI boot. https://wiki.archlinux.org/title/Partit … tion_Table https://wiki.archlinux.org/title/GPT_fd … BR_and_GPT
Other than that your efibootmgr shows there are no NVRAM entries for GRUB, was efibootmgr installed before invoking and how did you invoke grub-install ? If GRUB doesn't appear there on it's own you might have to check your UEFI menu on whether there's an option to manually add new NVRAM boot entries, or try to populate the fallback path by running the appropriate grub-install command with the --removable option added.
But in any case you definitely should switch to GPT first.
Offline
Thanks for your response. Though the Arch Wiki https://wiki.archlinux.org/title/EFI_sy … oned_disks tells you to use "EFI System" as the partition type for the boot partition (which I've done on other systems). Also, GRUB entry was never created on NVRAM entries... In the end I solved it by installing
intel-ucode
which fixed the issue and can now boot.
efibootmgr
shows that
NVMe0
as the current boot.
So even though I got it working, I'm still kinda curious on the following:
1. GRUB entry in NVRAM seems not needed here - why is that? When/why is it needed?
2. What did intel-ucode actually do / change to make it boot?
3. Why didn't it throw an error when I invoked grub-install, grub-mkconfig or mkinitcpio?
Every time I install Arch Linux I learn something new, but its also a long time between new installs so I tend to forget some important steps!
Offline
NVRAM entry is needed if you are doing a "proper" EFI install. In which case your EFI needs to have a reference as to where a EFI binary ($esp/EFI/GRUB/grubx64.efi in that case) is stored so it can boot that, you can technically avoid that by populating the fallback path which sounds like that's what you're booting now but that wouldn't be created normally.
intel-ucode should not have had an effect at the stage where you were failing, as it sounds like you didn't even get to GRUB in the first place. If that's indeed all you changed and you did actually get to GRUB before then it's likely that your generated grub.cfg did include that as a initrd to be loaded (... due to the live disk mount point?) and because it wasn't present then loading of the entire kernel image failed outright.
there are many ways to run grub-install, grub-mkconfig and mkinitcpio in ways that are totally valid towards the actual operation of the tool in question while being the (technically) wrong approach for what you are actually intending to do. Of the three mkinitcpio is the least relevant and least likely to fail for what it sounds like what your issue was, which leaves the other two, both of which we don't know the actual command you actually ran, nor the actual output (e.g. what's your actual /boot/grub/grub.cfg and which exact command line did you invoke for grub-install?)
Offline
Pages: 1