Failed boot Panic mode

hhh · 2018-05-29 19:03:48

sleekmason wrote:

So, one caveat so far. Upon installing a new kernel in BunsenLabs after running
# mount /dev/sda1 /mnt
# grub-mkconfig -o /mnt/boot/grub/grub.cfg
The grub menu will not show your new kernel version unless the above code is run again, because BunsenLabs now controls the mbr.
This is absolutely still a boon because there is no more need to update the mbr by rebooting into the other distro. The only downside I see is that the command must be entered manually, but you would have to do the same anyway from the other distro.

Set up a terminal alias if you don't want to enter long commands you repeatedly use. Open ~/.bash_aliases and add your alias with the format...

alias name='command'

... where "name" is what you want to use as an alias and "command" is the command the alias should call. So something like...

alias grubfix='sudo mount /dev/sda1 /mnt && sudo grub-mkconfig -o /mnt/boot/grub/grub.cfg

Logout so the new alias is loaded

sleekmason · 2018-05-29 19:05:42

couldn't this be used?

set root=(sda1)

chainloader +1

}

sleekmason · 2018-05-29 19:11:45

Sorry hhh - Didn't see your response. I guess I need some feedback. Is this command okay to use regularly?

# mount /dev/sda1 /mnt
# grub-mkconfig -o /mnt/boot/grub/grub.cfg

If this could wind up unstable in the future, the 40_custom would be better to use, yes?

unklar · 2018-05-29 19:39:11

sleekmason wrote:

So, If antiX for my setup is on sda1, Is my correction for auf /dev/sdb1 -> auf /dev/sda1 enough?

No!
sda(1) cannot be 'hd1'!

Grub2 counts:
1. HDD/drive = 0
1. Partition = 1

so your sda1 = hd0,msdos1

Correct would be

menuentry 'Chainload antiX17 (auf /dev/sda1)' {
	set root='hd0,msdos1'
	configfile /boot/grub/grub.cfg
}

unklar · 2018-05-29 19:52:24

Which Grub did you first install in the MBR? BL or antiX?

hhh · 2018-05-29 19:54:06

sleekmason wrote:

Sorry hhh - Didn't see your response. I guess I need some feedback. Is this command okay to use regularly?
# mount /dev/sda1 /mnt
# grub-mkconfig -o /mnt/boot/grub/grub.cfg
If this could wind up unstable in the future, the 40_custom would be better to use, yes?

For sure, just for the convenience. HoaS will have to respond to the first part, I've never used that command. I only ever run two partitions, so fixing grub and swap manually doen't bother me.

I can't speak to the chainloader entries for the same reason.

sleekmason · 2018-05-29 23:08:38

Which Grub did you first install in the MBR? BL or antiX?

From antiX in sda1. Sorry for the delay.

Sounds like the easy way for me is to re-install grub mbr to BunsenLabs, then chainload from here.

menuentry 'Chainload antiX17 (auf /dev/sda1)' {
	set root='hd0,msdos1'
	configfile /boot/grub/grub.cfg
}

Thank you for the correct code.

sleekmason · 2018-05-29 23:13:43

For sure, just for the convenience. HoaS will have to respond to the first part, I've never used that command.

I'm digging the simplicity of using an alias.

Last edited by sleekmason (2018-05-29 23:14:16)

Head_on_a_Stick · 2018-05-30 06:10:55

unklar wrote:

Why don't you use for your setup the intended
40_custom ?

It is actually possible to drop in an extra GRUB stanza via /boot/grub/custom.cfg — any file by that name will be added to the boot menu without having to run `update-grub` afterwards

unklar · 2018-05-30 17:06:54

unklar wrote:

Which Grub did you first install in the MBR? BL or antiX?
sleekmason wrote:
From antiX in sda1.

Then the antiX Grub will write itself back to the MBR during an update.
Grub "remembers" his 1st installation!

So if you want BL to place your main bootloader on the computer,
then you have to execute the following command in antiX:

dpkg-reconfigure grub-pc

and then select your antiX installation on sda1

unklar · 2018-05-30 17:26:36

HoaS wrote:

unklar wrote:
Why don't you use for your setup the intended
40_custom ?
It is actually possible to drop in an extra GRUB stanza via /boot/grub/custom.cfg — any file by that name will be added to the boot menu without having to run `update-grub` afterwards

certainly only for experts - the manual processing of grub.cfg is not warned for nothing - that's why you "hide" the details too

My solution with 40_custom is intended for the user and he can also forget the update-grub

If he then additionally removes the execution right for the 30_os-prober (in antiX above), the grub.cfg of BL does not grow into the immeasurable

sleekmason · 2018-05-31 11:26:43

Yeah, I blew it! Ran reconfigure from Bunsenlabs first without changing antiX from mbr to sda1. After rebooting, . . .Nope:)

I had already decided to make BunsenLabs my primary with a dedicated $HOME, instead of just a 10 gig test. Reformat. The cool part is that thanks to you guys, I have solutions all over the place for grub now.

Head_on_a_Stick · 2018-06-01 05:45:17

@sleekmason, why do have GRUB installed in both operating systems?

Your situation would be *much* simpler if you had refused the installation of GRUB in the second distribution and added a custom menu to boot the /vmlinuz & /initrd.img symlinks (which would always point to the current kernel, even after an upgrade) instead.

sleekmason · 2018-06-01 10:13:07

Your situation would be *much* simpler if you had refused the installation of GRUB in the second distribution and added a custom menu to boot the /vmlinuz & /initrd.img symlinks (which would always point to the current kernel, even after an upgrade) instead.

I found this example in the arch wiki:

set root=(hd0,5)
linux /boot/vmlinuz-linux root=/dev/sda5
initrd /boot/initramfs-linux.img
boot

This should be added to 40_custom, yes? I like this idea best I think.
The mbr once updated would allow boot into another partition whether or not the initial controlling distro becomes corrupted or not.

I also found this entry in the Arch Wiki:

set root=(hd0,1)
chainloader +1
boot

Which is simpler than this:

menuentry 'Chainload antiX17 (auf /dev/sda1)' {
	set root='hd0,msdos1'
	configfile /boot/grub/grub.cfg
}

If one decides to chainload, is there a reason for the above instead of the Arch example? or something I'm missing?

Head_on_a_Stick · 2018-06-02 09:04:43

sleekmason wrote:

I found this example in the arch wiki:
set root=(hd0,5)
linux /boot/vmlinuz-linux root=/dev/sda5
initrd /boot/initramfs-linux.img
boot
This should be added to 40_custom, yes?

40_custom is the correct file, any menuentries found there will be added to the GRUB menu when it is updated.

But for Debian or Ubuntu this is the stanza you want:

menuentry 'Debian' {
    set root=(hd0,5)
    linux /vmlinuz root=/dev/sda5 ro quiet # add any other kernel parameters here
    initrd /initrd.img
}

Arch always calls it's kernel images "vmlinuz-linux" but Debian numbers it's kernel versions so the symlinks in the root directory must be used if the menuentry is to remain working after a kernel update.

Chainloading would only work if GRUB was installed to the partition rather than the MBR, this is not recommended.

EDIT: it may be more reliable to replace the root=/dev/sda5 bit with root=UUID=$uuid where $uuid is the actual UUID of /dev/sda5.

Last edited by Head_on_a_Stick (2018-06-02 09:06:37)

sleekmason · 2018-06-02 10:41:53

Arch always calls it's kernel images "vmlinuz-linux" but Debian numbers it's kernel versions so the symlinks in the root directory must be used if the menuentry is to remain working after a kernel update.
Chainloading would only work if GRUB was installed to the partition rather than the MBR, this is not recommended.
EDIT: it may be more reliable to replace the root=/dev/sda5 bit with root=UUID=$uuid where $uuid is the actual UUID of /dev/sda5.

menuentry 'Debian' {
    set root=(hd0,5)
    linux /vmlinuz root=/dev/sda5 ro quiet # add any other kernel parameters here
    initrd /initrd.img
}

Excellent. Looking forward to this later today:) Thank you for taking the time to clarify this for me.

*Edit - Works wonderfully:)

Last edited by sleekmason (2018-06-02 14:03:31)

#21 2018-05-29 19:03:48

Re: Failed boot Panic mode

#22 2018-05-29 19:05:42

Re: Failed boot Panic mode

#23 2018-05-29 19:11:45

Re: Failed boot Panic mode

#24 2018-05-29 19:39:11

Re: Failed boot Panic mode

#25 2018-05-29 19:52:24

Re: Failed boot Panic mode

#26 2018-05-29 19:54:06

Re: Failed boot Panic mode

#27 2018-05-29 23:08:38

Re: Failed boot Panic mode

#28 2018-05-29 23:13:43

Re: Failed boot Panic mode

#29 2018-05-30 06:10:55

Re: Failed boot Panic mode

#30 2018-05-30 17:06:54

Re: Failed boot Panic mode

#31 2018-05-30 17:26:36

Re: Failed boot Panic mode

#32 2018-05-31 11:26:43

Re: Failed boot Panic mode

#33 2018-06-01 05:45:17

Re: Failed boot Panic mode

#34 2018-06-01 10:13:07

Re: Failed boot Panic mode

#35 2018-06-02 09:04:43

Re: Failed boot Panic mode

#36 2018-06-02 10:41:53

Re: Failed boot Panic mode

Board footer