getting grub working right again

Questions about Grub, UEFI,the liveCD and the installer
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Locked
dhdurgee
Level 4
Level 4
Posts: 436
Joined: Thu Jul 02, 2009 7:56 pm

getting grub working right again

Post by dhdurgee »

I had some fun getting grub to work properly with maya on one of my systems, but once I got it working it was fine...until earlier today.

Earlier today I hit a freeze that appears to have been a cinnamon crash of some sort. I ultimately wound up restarting the system, when to my surprise I found myself at the sh:grub> prompt instead of booted to maya! The top line identifes this as "GNU GRUB version 1.97~beta4" and set shows some environment variables set, so it appears to have gone partway through my grub.cfg file. After looking a few things up, I finally tried to use the configfile command with the following results:

sh:grub> configfile /boot/grub/grub.cfg
<screen cleared>
error: Invalid mode: auto
<blank line>
Syntax error
Incorrect command
sh:grub>

looking at my grub.cfg shows "auto" only one place:

set gfxmode=auto

Some searching shows that this is the default, so I edited grub.cfg to remark this line out with the following results:

sh:grub> configfile /boot/grub/grub.cfg
error: No suitable mode found.
syntax error
Incorrect command
sh:grub>

I have also tried replacing "auto" with some specific modes, but I still get the "No suitable mode found." message

This is of course annoying, but I can boot maya manually by specifying:

sh:grub>linux /boot/vmlinux.... root=/dev/sda14 ro
sh:grub>initrd /boot/init....
sh:grub>boot

Any suggestions what I need to do to get my menu back? Any idea why it disappeared? Any further diagnostics I can run?

If it were another system I would likely simply try to regenerate/reinstall grub, but given all the "fun" I had getting grub to work here at all I would prefer another approach.

Dave
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
cwsnyder

Re: getting grub working right again

Post by cwsnyder »

I would recommend using your Live CD/DVD to do a grub-install to your hard drive.
usbtux

Re: getting grub working right again

Post by usbtux »

Boot and run from Live DVD
open a terminal, type these commands

1. sudo os-prober

see a list of OSes first.

here is a possible output:

mint@mint ~ $ sudo os-prober
/dev/sda1:Windows 7 (loader):Windows:chain
/dev/sdb1:Linux Mint 13 Maya (13):LinuxMint:linux
/dev/sdd1:Linux Mint Debian Edition (1):LinuxMint1:linux



2.

sudo mount /dev/sdb1 /mnt

3.

sudo grub-install --root-directory=/mnt /dev/sda


Where sda is the harddisk used to boot
dhdurgee
Level 4
Level 4
Posts: 436
Joined: Thu Jul 02, 2009 7:56 pm

Re: getting grub working right again

Post by dhdurgee »

I had stopped posting to this thread for two reasons, first I don't reboot this system very often and second grub started working again at one point! Unfortunately that changed recently again. Something strange happened at 2:20 on 5 October that appears to have crashed the system in the middle of a mintupdate run. I found the system on 6 October at the grub command prompt again. I manually defined linux and initrd and booted the system, only to find that updates were crashing. Eventually I corrected that problem by running sudo apt-get clean.

As the system was finally working at that point, but grub menus were still acting up, I decided to see if I could do something to simplify the manual process. I created some alternative simple files to use with the configfile command at the grub command prompt. I ran into an unexpected problem that perhaps someone here can clarify for me.

The first one contained the linux and initrd lines from the menu entry in the grub.cfg file, with everything after the ro truncated on the linux line. So this contained root=UUID=... to specify the root. This would boot, but would cause errors with mount.cifs:

Code: Select all

Oct  7 11:42:02 DG41TY kernel: [   24.613976] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
Oct  7 11:42:02 DG41TY kernel: [   24.614016] IP: [<ffffffff812dc33b>] crypto_larval_kill+0x2b/0x90
Oct  7 11:42:02 DG41TY kernel: [   24.614045] PGD 135fdb067 PUD 1342a0067 PMD 0 
Oct  7 11:42:02 DG41TY kernel: [   24.614072] Oops: 0002 [#1] SMP 
Oct  7 11:42:02 DG41TY kernel: [   24.614095] CPU 0 
Oct  7 11:42:02 DG41TY kernel: [   24.614101] Modules linked in: nls_utf8 cifs binfmt_misc nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek nvidia(P) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd ppdev soundcore snd_page_alloc parport_pc mac_hid dm_multipath psmouse serio_raw lp parport jfs floppy video r8169 zram(C)
Oct  7 11:42:02 DG41TY kernel: [   24.614306] 
Oct  7 11:42:02 DG41TY kernel: [   24.614321] Pid: 1015, comm: mount.cifs Tainted: P         C O 3.2.0-23-generic #36-Ubuntu                  /DG41TY
Oct  7 11:42:02 DG41TY kernel: [   24.614366] RIP: 0010:[<ffffffff812dc33b>]  [<ffffffff812dc33b>] crypto_larval_kill+0x2b/0x90
Oct  7 11:42:02 DG41TY kernel: [   24.614403] RSP: 0018:ffff880138547b68  EFLAGS: 00010296
Oct  7 11:42:02 DG41TY kernel: [   24.614422] RAX: 0000000000000000 RBX: ffff880135a26200 RCX: 00000000c0000100
Oct  7 11:42:02 DG41TY kernel: [   24.614444] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffffffff81c63ac0
Oct  7 11:42:02 DG41TY kernel: [   24.614466] RBP: ffff880138547b78 R08: ffff880138546000 R09: 0000000000000000
Oct  7 11:42:02 DG41TY kernel: [   24.614488] R10: dead000000200200 R11: 0000000000000001 R12: ffff880135a26450
Oct  7 11:42:02 DG41TY kernel: [   24.614509] R13: ffffffffa0cd3180 R14: 0000000000000000 R15: ffff880133c10000
Oct  7 11:42:02 DG41TY kernel: [   24.614532] FS:  00007fca6aa42700(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
Oct  7 11:42:02 DG41TY kernel: [   24.614564] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Oct  7 11:42:02 DG41TY kernel: [   24.614584] CR2: 0000000000000008 CR3: 0000000134fb1000 CR4: 00000000000006f0
Oct  7 11:42:02 DG41TY kernel: [   24.614606] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct  7 11:42:02 DG41TY kernel: [   24.614627] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct  7 11:42:02 DG41TY kernel: [   24.614650] Process mount.cifs (pid: 1015, threadinfo ffff880138546000, task ffff880133c10000)
Oct  7 11:42:02 DG41TY kernel: [   24.614682] Stack:
Oct  7 11:42:02 DG41TY kernel: [   24.614697]  ffff880135a26200 ffff880135a26450 ffff880138547b98 ffffffff812dcb9b
Oct  7 11:42:02 DG41TY kernel: [   24.614740]  ffffffff818385c0 0000000000000000 ffff880138547be8 ffffffff812dcddd
Oct  7 11:42:02 DG41TY kernel: [   24.614782]  ffff88013b002b00 0000000000000000 ffffffffa0ca3e32 ffff88013757a000
Oct  7 11:42:02 DG41TY kernel: [   24.614824] Call Trace:
Oct  7 11:42:02 DG41TY kernel: [   24.614843]  [<ffffffff812dcb9b>] crypto_alg_mod_lookup+0x6b/0x90
Oct  7 11:42:02 DG41TY kernel: [   24.614865]  [<ffffffff812dcddd>] crypto_alloc_tfm+0x6d/0xe0
Oct  7 11:42:02 DG41TY kernel: [   24.614891]  [<ffffffffa0ca3e32>] ? cifs_get_tcp_session+0x112/0x6a0 [cifs]
Oct  7 11:42:02 DG41TY kernel: [   24.614915]  [<ffffffff812e3c19>] crypto_alloc_shash+0x19/0x20
Oct  7 11:42:02 DG41TY kernel: [   24.614940]  [<ffffffffa0cbd241>] cifs_crypto_shash_allocate+0x21/0x1a0 [cifs]
Oct  7 11:42:02 DG41TY kernel: [   24.614975]  [<ffffffffa0ca3e46>] cifs_get_tcp_session+0x126/0x6a0 [cifs]
Oct  7 11:42:02 DG41TY kernel: [   24.615000]  [<ffffffffa0ca904d>] cifs_mount+0x8d/0x600 [cifs]
Oct  7 11:42:02 DG41TY kernel: [   24.615023]  [<ffffffffa0c96961>] ? cifs_do_mount+0x91/0x280 [cifs]
Oct  7 11:42:02 DG41TY kernel: [   24.615046]  [<ffffffffa0c96985>] cifs_do_mount+0xb5/0x280 [cifs]
Oct  7 11:42:02 DG41TY kernel: [   24.615068]  [<ffffffff811579c3>] ? alloc_pages_current+0xa3/0x110
Oct  7 11:42:02 DG41TY kernel: [   24.615091]  [<ffffffff8117b5d3>] mount_fs+0x43/0x1b0
Oct  7 11:42:02 DG41TY kernel: [   24.615112]  [<ffffffff81195e1a>] vfs_kern_mount+0x6a/0xc0
Oct  7 11:42:02 DG41TY kernel: [   24.615133]  [<ffffffff81197324>] do_kern_mount+0x54/0x110
Oct  7 11:42:02 DG41TY kernel: [   24.615154]  [<ffffffff81198e74>] do_mount+0x1a4/0x260
Oct  7 11:42:02 DG41TY kernel: [   24.615174]  [<ffffffff81199350>] sys_mount+0x90/0xe0
Oct  7 11:42:02 DG41TY kernel: [   24.615195]  [<ffffffff81664a82>] system_call_fastpath+0x16/0x1b
Oct  7 11:42:02 DG41TY kernel: [   24.615216] Code: 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 89 fb 48 c7 c7 c0 3a c6 81 e8 c3 f3 37 00 48 8b 13 48 8b 43 08 48 c7 c7 c0 3a c6 81 <48> 89 42 08 48 89 10 48 b8 00 01 10 00 00 00 ad de 48 ba 00 02 
Oct  7 11:42:02 DG41TY kernel: [   24.615451] RIP  [<ffffffff812dc33b>] crypto_larval_kill+0x2b/0x90
Oct  7 11:42:02 DG41TY kernel: [   24.615476]  RSP <ffff880138547b68>
Oct  7 11:42:02 DG41TY kernel: [   24.615492] CR2: 0000000000000008
Oct  7 11:42:02 DG41TY kernel: [   24.615510] ---[ end trace 6e3c5f67a2ec32a1 ]---
This lead me to create a modified file that replaced root=UUID=... with root=/dev/sdaXX, as that was what worked when I did this with individual commands. As expected this boots correctly. My question of course is why does the root=UUID=... parameter fail like this? My understanding is that the UUID method is safer as it will survive some partition issues that will cause the direct reference to fail. Perhaps there is a module that must be loaded first?

Dave
Locked

Return to “Installation & Boot”