IRC:bootprompt [2020-02-18]

Boot from a grub-prompt (defective grub.cfg)

In some rare situations the grub.cfg (the file that defines the grub-menu) is defective and you might end at a command-line instead of booting into linux-mint.

grub>

Be aware there is a second similar command-line "busybox", which is related to different issues (often a broken initial ramdisk) and is not fully covered by this tutorial - see IRC:busybox-cli.htm for a related tutorial.

Although the grub-menu is not shown, you should still be able to boot into your installed mint.

From the installed mint you should be able to rebuild a valid grub.cfg - just read on.

Notes (1)

Keyboard layout is en-US

If you are using a foreign language keyboard, you will face an en-US keyboard layout at the grub command line.

People without an en-US keyboard will likely have to lookup some keys:

logo - [click to enlarge]

[click to enlarge]

workaround (for the lucky one)

If your installation isn't broken too much, the following might already get you back (in any case worth a try):

If any of the commands is failing (check first if you didn't have any typos), your installation seems to be more broken. Skip to Notes (2)

Lookup first which partition has been setup for your root-partition using:

grub> cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=8d06c327-c3ea-4eba-bb5e-6e4fbdd8165f /               ext4    errors=remount-ro 0       1
/swapfile                                 none            swap    sw              0       0

The interesting entry is the one defining the root fs / - in the sample output the 2 lines

# / was on /dev/sda1 during installation
UUID=8d06c327-c3ea-4eba-bb5e-6e4fbdd8165f /               ext4    errors=remount-ro 0       1

Although the 'correct'/current device-entry of the test-installation is the UUID=8d06c327-c3ea-4eba-bb5e-6e4fbdd8165f - you might first try using the given device-name from the comment above, as it should still be working as long you didn't add or remove drives later (which would reorder the partition-names) and isn't such a pita to type:

Note: you have to use your values shown from the cat-command and not the values given here in the sample ....

linux /vmlinuz root=/dev/sda1
initrd /initrd.img
boot

If you can boot now without issues, you can continue at Recreate grub.cfg

If you cant use the /dev/sdXY-entry for any reason - you have to go through the pain of typing the entire UUID-notation instead (without any errors):

linux /vmlinuz root=UUID=8d06c327-c3ea-4eba-bb5e-6e4fbdd8165f
initrd /initrd.img
boot

If you can boot now without issues, you can continue at Recreate grub.cfg

Notes (2)

As you are still reading, the "workaround (for the lucky one)" didn't seemingly work for you, and it's time to give you a bit more hints before you continue.

grub partition names

To get a first overview about devices/partitions being there run (sample output from the test-machine):

grub> ls
(hd0) (hd0,msdos1)

If you are an experienced linux-user you are likely used to partition names like /dev/sda1, /dev/sdb1, ... etc. (a physical disk would be /dev/sda, /dev/sdb, ... - just as info, not needed for the reboot)

At the grub command-line devices/partitions are named a bit different like (hd0,msdos1), (hd1,msdos1), ... etc. (a physical disk will be named (hd0), (hd1), ... - just as info, not needed for the reboot)

To get you some more 'fun', there is a difference between msdos/mbr formatted disks and disk using gpt-partitioning - where according partitions would be named (hd0,gpt1), (hd0,gpt2) ... and so on.

The important part at the moment is, that you have to "translate" the partition-naming shown by the grub command-line to the /dev/sdXY notation, used to define the root device at the linux -command later:

grub msdosgrub gpt/dev/sdXY-notation
(hd0,msdos1)(hd0,gpt1)/dev/sda1
(hd0,msdos2)(hd0,gpt2)/dev/sda2
.........
(hd1,msdos1)(hd1,gpt1)/dev/sdb1
.........
(hd2,msdos1)(hd2,gpt1)/dev/sdc1
.........

Use ls with grub notation partitions

Be aware that the ls command at the grub command-line does behave a bit different to what you might be used to.

To list files folders of a partition, you have to append a trailing / slash - (sample):

grub> ls (hd0,msdos1)/
lost+found/ swapfile etc/ media/ bin/ boot/ dev/ home/ lib/ lib64/ mnt/ opt/ pr
oc/ root/ run/ sbin/ srv/ sys/ tmp/ usr/ var/ vmlinuz initrd.img.old initrd.img
cdrom/ vmlinuz.old

To show some information about the partition itself, you omit the trailing slash (sample):

grub> ls (hd0,msdos1)
        Partition (hd0,msdos1): Filesystem type ext* - last modification time
2020-02-18 15:45:16 Tuesday, UUID 8d06c327-c3ea-4eba-bb5e-6e4fbdd8165f -
Partition start at 1024KiB - Total size 15726592KiB

... which is a way to determine a partition-uuid.

The ls-command does support the optional -l (long format) and -a (all files) options.

Set the pager

As there are no tools like more or less available and the common hotkeys like SHIFT+PgUp are not supported to scroll back output, you might want to turn on the inbuilt pager-support, to see longer output without it scrolling out of view by:

set pager=1

Use tab-expansion to auto-complete

The command-line does support TAB-expansion for commands and filenames, which is very helpful to select kernel- and related initial-ramdisk files.

To make use of it, you start typing a command or a filename and press TAB. If there is only 1 matching command or filename your entry will be completed.

If there are multiple matches the first press of TAB might not fully expand to a complete result - pressing TAB a second time will show alternatives being there starting with the same pattern.

After adding some more characters and repeating TAB will get you to the desired command or filename.

a more detailed workaround

Check $root

Check first if the environment-variable $root is already defined (and correct):

grub> echo $root
hd0,msdos1

If you get some value shown - you should check, if it's pointing to the correct partition holding a folder boot, containing the linux-kernels (vmlinuz-files) and initial-ramdisks (initrd.img-files) by (sample output):

grub> ls ($root)/boot
grub/ System.map-5.0.0-32-generic config-5.0.0-32-generic memtest86+.bin memtes
t86+.elf memtest86+_multiboot.bin vmlinuz-5.0.0-32-generic vmlinuz-5.0.0-37-gen
eric initrd.img-5.0.0-32-generic config-5.0.0-37-generic System.map-5.0.0-37-ge
neric ...<remainder omitted>

If the $root environment-variable is not set, or is pointing to the wrong partition, check the available partitions (using grub command-line notation) for available kernels by:

grub> ls
(hd0) (hd0,msdos1)
grub> ls (hd0,msdos1)/boot
grub/ System.map-5.0.0-32-generic config-5.0.0-32-generic memtest86+.bin memtes
t86+.elf memtest86+_multiboot.bin vmlinuz-5.0.0-32-generic vmlinuz-5.0.0-37-gen
eric initrd.img-5.0.0-32-generic config-5.0.0-37-generic System.map-5.0.0-37-ge
neric ...<remainder omitted>

If you found the right partition this way, set the $root environment-variable by (sample):

grub> set root=hd0,msdos1

Using an explicit/different kernel-version

As you are reading the detailed workaround, the "default"-kernel /vmlinuz and it's matching initial ramdisk /initrd.img didn't seemingly work. Both files are symbolic links pointing typically to the newest versions below /boot.

So, if you got issues using the most current version of the kernel and it's initial ramdisk, you should prefer to use an older/previous version instead.

Sticking to the samples above using a vmlinuz-5.0.0-32-generic -kernel and it's matching initial ramdisk initrd.img-5.0.0-32-generic coming from the partition (hd0,msdos1) the according commands would be (use TAB-expansion :)):

linux /boot/vmlinuz-5.0.0-32-generic root=/dev/sda1
initrd /boot/initrd.img-5.0.0-32-generic
boot

If you can boot now without issues, you can continue at Recreate grub.cfg

If you end up at busy-box with a command-prompt: (intitramfs): you either used a wrong root=/dev/....-parameter or the kernel- or the initial ramdisk-file is broken.

If you used a wrong root=/dev/....-parameter, you will likely notice a message some lines above the command-prompt, mentioning ALERT! /dev/.... does not exist. Dropping to a shell!

Either correct root=/dev/....-parameter if being wrong (read again grub partition names), or test a different kernel-version.

If none of the kernels seems to work at all: you should run a filesystem-check of your linux filesystems from a live-mint, as there might be something broken there.

Recreate grub.cfg

After you booted to your desktop, you have to recreate the broken grub.cfg. Open a terminal and run:

sudo update-grub

This should list found kernel-version and optionally other available OS like windows. If the command does finish without error-messages you should be done and can reboot to test that everything is back to working.

Related information

IRC:busybox-cli.htmstuck on busybox (initramfs) on boot - possible fixes
IRC:patch-grub19.htmgrub-menu patch for mint 19.3
IRC:bootparam.htmedit kernel params on boot, common use-cases

© 1998-2023 by ORCUS® GmbH - www.orcus.de (imprint) - we strictly do not track (period) - details: privacy - overview IRC: IRC support

note-1: not tracking does mean too - we are strictly NOT using direct external links within the content = we bother you having to copy&paste offered URLs