Boot up from grub> prompt

Kardell · 2024-09-16 17:10:35

Hi,
I have a system that is stuck at grub> prompt.
I have worked out the boot partition where the kernel image is: (hd2,gpt2)
Root partition is (hd2,gpt3).

I have defined the root partition with:
set root=(hd2,gpt3)

Now I need to define the linux and initrd:
linux vmlinuz-4.18.0-372.9.1.x86_64 root=UUID=xxxxx-xxxx-xxxxx

The UUID I got by catting the fstab.

but I get invalid file name 'vmlinuz-4.18.0-372.9.1.x86_64'
I can see this file when I ls (hd2,gpt2)

What am I missing here?

Last edited by Kardell (2024-09-16 17:11:53)

Head_on_a_Stick · 2024-09-16 17:21:48

That looks like an Ubuntu kernel. Arch kernel images are not versioned.

Why not just chroot into the system and run grub-mkconfig? Then you wouldn't have to bother with the command line.

Kardell · 2024-09-16 17:26:33

Head_on_a_Stick wrote:

That looks like an Ubuntu kernel. Arch kernel images are not versioned.
Why not just chroot into the system and run grub-mkconfig? Then you wouldn't have to bother with the command line.

This is what I would do if I have the capabilities but unfortunately I only have access to a KVM console.

Head_on_a_Stick · 2024-09-16 17:30:23

Is there /boot/vmlinuz-linux on the Arch root partition?

Last edited by Head_on_a_Stick (2024-09-16 17:30:38)

Kardell · 2024-09-16 17:34:31

Head_on_a_Stick wrote:

Is there /boot/vmlinuz-linux on the Arch root partition?

so the boot dir inside the ROOT partition (hd2,gpt3) is empty but according to fstab the other partition (hd2,gp2) supposed to be mounted as boot and this one contains vmlinuz file

I think this:
set root=(hd2,gpt3)
assumes that I have / and boot on the same partition which is not the case.

Last edited by Kardell (2024-09-16 17:36:38)

Head_on_a_Stick · 2024-09-16 17:48:40

You need to set the partition that contains the kernel image as the "root" and then define the real root partition on the linux line.

Kardell · 2024-09-16 18:14:42

Head_on_a_Stick wrote:

You need to set the partition that contains the kernel image as the "root" and then define the real root partition on the linux line.

I tried this but it still complaints "invalid file name 'vmlinuz-......'
I checked the file name again for any typos but I cannot see any.
I put the vmlinuz filename in a single and double quotes but it didn't help.

Last edited by Kardell (2024-09-16 18:16:27)

Kardell · 2024-09-16 18:19:22

I think I know what the problem is
it needs / in front of the filename
linux /vmlinuz-...... root=UUID=.........

cryptearth · 2024-09-16 18:23:04

just for reference https://wiki.archlinux.org/title/GRUB#Configuration

Kardell · 2024-09-16 18:26:57

Thank you guys!

Kardell · 2024-09-16 21:22:22

On that subject.
Can you salvage the OS that was installed with Secure Boot enabled in BIOS but then someone disabled it?
I swear it was not me.

It has a separate EFI partition and mounted as /boot/efi so it was installed with EFI in mind.
It does not have the 1MB old school GRUB partition so I cannot even grub2-install anywhere.

I can boot the OS from grub> prompt by I have to type everything by hand.
If I enable Secure Boot in BIOS then I end up with blue screens in BIOS, "unable to load the device firmware verification failed 0x1a", enroll MOK keys etc.

When in GRUB mode I logged in to the system and ran grub2-mkconfig -o /boot/efi/EFI/os/grub.cfg but I reckon this has to be done while in UEFI mode.

Since I don't have a recovery pendrive or ability to chroot I have to either fix this (if possible) or go back to GRUB mode but then I have to carve out a new vfat partition if this can be done on a running system.

cryptearth · 2024-09-16 21:43:15

you throwing several things together

UEFI vs BIOS/legacy: you either run a system in new modern UEFI mode - or have it in legacy mode, also called CSM - Compatibility Support Module - it only differs for what type of boot loader you need and how to install it
as long as you can boot the system in any mode you should be able to boot any modern linux

EFI System Partition - ESP: old legacy bios used the first 512 bytes - so called MasterBootRecord - to store the first stage of the bootloader - from there the next stages were stored in the post-MBR-gap and the partition boot records
modern uefi has specified to put this central on an addition FAT32 partition - depending on what's installed on it it can be from about 20MB to over 1GB

folders and/or mountpoints /boot, /boot/efi, /efi: usually anything required for booting the system is stored in the folder /boot - it can be its own partition mounted there but it can also be a regular folder on the root partition - sames goes with the ESP: it can either be the /boot partition but also can be mounted to /efi or to /boot/efi
you can also go full ham and use 3 partitions: one partition for the ESP mounted to /efi or /boot/efi - a second partition mounted to /boot - and then at least a third partition as root partition - plus swap and home and whatnot

secureboot - as I got called out several times on this topic I keep it short: if enabling it causes issues - just disable it - end of story

you can use os-prober to discover the additional system and add an entry for it in the current config - read up in the wiki how to enable os-prober: https://wiki.archlinux.org/title/GRUB#D … ng_systems

Last edited by cryptearth (2024-09-16 22:07:36)

Kardell · 2024-09-16 22:24:59

cryptearth wrote:

you throwing several things together
UEFI vs BIOS/legacy: you either run a system in new modern UEFI mode - or have it in legacy mode, also called CSM - Compatibility Support Module - it only differs for what type of boot loader you need and how to install it
as long as you can boot the system in any mode you should be able to boot any modern linux
EFI System Partition - ESP: old legacy bios used the first 512 bytes - so called MasterBootRecord - to store the first stage of the bootloader - from there the next stages were stored in the post-MBR-gap and the partition boot records
modern uefi has specified to put this central on an addition FAT32 partition - depending on what's installed on it it can be from about 20MB to over 1GB
folders and/or mountpoints /boot, /boot/efi, /efi: usually anything required for booting the system is stored in the folder /boot - it can be its own partition mounted there but it can also be a regular folder on the root partition - sames goes with the ESP: it can either be the /boot partition but also can be mounted to /efi or to /boot/efi
you can also go full ham and use 3 partitions: one partition for the ESP mounted to /efi or /boot/efi - a second partition mounted to /boot - and then at least a third partition as root partition - plus swap and home and whatnot
secureboot - as I got called out several times on this topic I keep it short: if enabling it causes issues - just disable it - end of story

I know that UEFI can be a pain but disabling it does not fix this problem.

I can get onto the system from legacy BIOS/legacy but I need additional kernel params deployed with TuneD.
I use to push those to /boot/efi/EFI/os/grub.cfg.
Defaulting to BIOS/legacy mode is what I wanted to avoid on this particular system.

I use to stick to CSM mode on older systems.

I am looking into https://wiki.archlinux.org/title/Unifie … ecure_Boot as it mentions these MOK keys but I don't have shim-signed nor sbsigntools packages,
I can only generate a key with openssl and have efibootmgr on the system.

cryptearth · 2024-09-17 06:07:27

you still seem to confuse boot mode (uefi vs csm/legacy) with secureboot (which is available in uefi mode only)
again: if enabled secureboot causes issues - just disable it - how to do that please refer to the manual of your motherboard or contact the support if its manufacturer

Head_on_a_Stick · 2024-09-17 06:09:13

Kardell wrote:

On that subject

Your subsequent questions are off-topic for this thread, please open a new thread if you have questions about a different problem. Thanks.

Kardell · 2024-09-18 00:19:26

I can see that the system fails to boot because grubx64.efi is corrupt. I get "Volume Corrupt"
If I cannot chroot to the system can I just use grubx64.efi from another working system (same versions)?

I think they differ from system to system but the corrupt one is short of about 75kB.

By the way the original boot entry in efibootmgr -uv points not to grubx64.efi but to shimx64.efi which tells me this OS was installed with SecureBoot ENABLED that was later DISABLED (not by me).
I reckon a config with a different set of BIOS settings has been deployed and f*** the system. What a goose chase.

Last edited by Kardell (2024-09-18 01:07:20)

cryptearth · 2024-09-18 05:44:52

I can just repeat myself:

1) it does NOT matter if the system in question was setup to work with secureboot enabled - the only thing that changes when sdcureboot gets disabled afterwards is that the signature are no longer done
a bit like this pseudo code:

if(secureboot)
{
    if(checkSignature(bootloader))
    {
        loadAndExecute(bootloader);
    }
}
else
{
    loadAndExecuteUnsecure(bootloader);
}

if a system with secureboot disabled runs shim it's transparent as if it wasn't there

2) although a live system is preferred so the main system drives not get mounted as long as you can boot the system in any way you can access both the data as well as the boot files
if you have a working bootloader that can boot linux all you need is to edit its config and add the other system
it's usually along

linux kernel root=... rw
initrd initrd

os-prober can help grub to discover the correct lines - but other bootloaders' config looks similar

3) when in doubt - C4 ...
as long as you have access to the data in question: make a backup and nuke it - you don't need a system running to access it's files - just access to its filesystems

4) usually bootloaders are built specific for the system they're installed on
grub knows the options

--no-nvram --removable

this constructs the grub binary specifically in a system-independent way suitable for removable media like cd or usb
the main difference is the path where grub loads its config and modules from:
on an install with the esp mounted to /boot and without additional parameter --boot-directory grub loads its config from /boot/grub/grub.cfg - which is on the fat32 esp
on a system with the esp not mounted to /boot but again without --boot-directory now /boot and maybe /boot/grub are on a different partition - so the grub binary needs to know where and has to have a driver for the filesystem - which can be anything from ext4 over xfs to btrfs or even zfs
the one can use --boot-directory to specify where the grub folder and by this grub.cfg are located so this gets added to the binary
this list goes on a bit - point is: due to all those specifics a boot binary from another system will likely not work unless it's specifically built generic with the --removable flag
this makes or breaks the difference between the standard grub console when grub can load its modules but not the config and the rescue shell when grub can't find anything often due to messed up UUIDs by either refornatting - or try to steal a binary from another system

again: it's a good practice to always have an arch install media on hand as it's kinda a swiss army knife for boot issues

we like to help - but currently it seems you either gave a hard time understanding or outright not listen

Last edited by cryptearth (2024-09-18 05:46:40)

Arch Linux

#1 2024-09-16 17:10:35

Boot up from grub> prompt

#2 2024-09-16 17:21:48

Re: Boot up from grub> prompt

#3 2024-09-16 17:26:33

Re: Boot up from grub> prompt

#4 2024-09-16 17:30:23

Re: Boot up from grub> prompt

#5 2024-09-16 17:34:31

Re: Boot up from grub> prompt

#6 2024-09-16 17:48:40

Re: Boot up from grub> prompt

#7 2024-09-16 18:14:42

Re: Boot up from grub> prompt

#8 2024-09-16 18:19:22

Re: Boot up from grub> prompt

#9 2024-09-16 18:23:04

Re: Boot up from grub> prompt

#10 2024-09-16 18:26:57

Re: Boot up from grub> prompt

#11 2024-09-16 21:22:22

Re: Boot up from grub> prompt

#12 2024-09-16 21:43:15

Re: Boot up from grub> prompt

#13 2024-09-16 22:24:59

Re: Boot up from grub> prompt

#14 2024-09-17 06:07:27

Re: Boot up from grub> prompt

#15 2024-09-17 06:09:13

Re: Boot up from grub> prompt

#16 2024-09-18 00:19:26

Re: Boot up from grub> prompt

#17 2024-09-18 05:44:52

Re: Boot up from grub> prompt

Board footer