Jump to content

grub2 messed up ... something really strange


alphaomega

Recommended Posts

Greetings fellow BATL members. It's been quite a while since I've been

lurking around here but now I could use a few pointers if possible.

 

I rsync'd arch from one drive to another one (/dev/sdb2).

I rsync'd slackware from one drive to another one (/dev/sdb3).

 

So the current setup on this machine (the same one I'm posting from) is:

Drive A = XP (/dev/sda1) (no internet access)

Drive B = arch (/dev/sdb2) / slackware (/dev/sdb3)

 

Grub2 in on /dev/sda

 

I have options to boot any of the three (xp, arch, and slackware).

All was working just fine.

I was able to boot any of the three operating systems without issue.

Then I messed up something.

 

At one point I was reinstalling grub (from arch) and accidently did:

grub-install /sda

I noticed my mistake and then tried:

grub-install /dev/sda

 

Now something really strange is happening:

I can still boot xp and arch just fine but there is a weird thing happening w/slackware.

 

It starts booting just fine.

Then around the time kms would kick in and the font in the console would change ...

I get messages from arch as if I'm booting arch (will try to get a screenshot to post)

and I cannot get into slackware without using an install disk and chrooting in.

 

Any ideas? I'm totally confused.

Cheers & thanks in advance for any pointers.

Edited by alphaomega
Link to comment
Share on other sites

Here are the pics of slackware booting.

They are a little blurry because the scroll lock did not work.

 

In the first pic you can see that slackware is booting.

In the second pic you can see messages from systemd (arch).

In the third pic you can see a "welcome to arch" message.

 

DfmgUeNi.jpg

 

BRxdg77B.jpg

 

0gCRC7ZG.jpg

Edited by alphaomega
Link to comment
Share on other sites

V.T. Eric Layton

I don't know what you did here, and I'm no GRUB2 expert by a longshot, but it looks like you're attempting to boot Arch with a Slackware initrd.gz. I'm amazed this didn't just kernel panic from the get-go.

 

I think Roger (Sunrat) is more knowledgeable about GRUB2. Maybe he can jump in here and help you out. Be patient. We won't abandon you.

Link to comment
Share on other sites

I used my slackware 14.1 install medium (usb) and chroot'd into slackware on /dev/sdb3.

Installed lilo to /dev/sda.

 

I can get into slackware using the generic smp kernel w/an initrd file

and I can get into slackware using the huge-smp kernel.

 

this works to get me in using the generic-smp kernel w/an initrd

# Linux bootable partition config begins
image = /boot/vmlinuz
initrd = /boot/initrd.gz
addappend=" root=UUID=bc1ce3c8-6237-4a5b-86d7-a142fd75e967"
label = Linux
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends

this does not work to get me in using the huge-smp kernel

# Linux bootable partition config begins
image = /boot/vmlinuz-huge-smp-3.10.17-smp
addappend=" root=UUID=bc1ce3c8-6237-4a5b-86d7-a142fd75e967"
label = HugeLinux
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends

Was getting the errror:

Kernel panic - not syncing: Vfs unable to mount root - (0,0)

this does work to get in me in using the huge-smp kernel

# Linux bootable partition config begins
image = /boot/vmlinuz-huge-smp-3.10.17-smp
root=/dev/sdb3
label = HugeLinux
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends

The addappend option works with one but not the other?

 

slackware still works (I'm posting from it now).

Now to try and switch back over to grub2 again.

It was working once. I'm just not sure what happened to mess it up.

 

Edit: Solved.

 

I switched back to using grub and noticed that for slackware the huge-smp kernel

was working but the generic-smp kernel was not.

 

In lilo I was using the addappend= option on the kernel that worked and using

the root= option on the one that did not.

 

I guess the addappend= option works when using lilo in slackware but os-prober

in arch preferred that I use the root= option in lilo.conf instead.

 

All is working again.

Cheers

Edited by alphaomega
  • Like 1
Link to comment
Share on other sites

V.T. Eric Layton

UUID probably requires the initial ram disk to load the modules for that protocol. That's why when boot generic with the initrd, it works, but when you try to boot huge without an initrd (which is normal) it doesn't know UUID.

 

Just a theory, though...

 

Also, there's never a guarantee that GRUB and LILO will "see" partitions as using the same nomenclature. For example, GRUB may see a partition as /dev/sda, but LILO might see it as /dev/sdb. It all depends on how the the physical drive is installed on the buss. I used to run into issues like this when I ran multiple disks on the EIDE and the SATA busses simultaneously.

  • Like 1
Link to comment
Share on other sites

I used to run into issues like this when I ran multiple disks on the EIDE and the SATA busses simultaneously.

That is the situation I am in which is why I try to always configure things using UUIDs.

In arch I had switched to using os-prober so it would auto configure the other systems.

 

os-prober gets it's information from lilo.conf and things did not get configured

correctly when I used UUIDs. It did when I used root=/dev/sdX type entries.

Though I could go in and manually adjust /boot/grub/grub.conf to use UUIDs.

 

Using UUIDs also worked if I manually configured /etc/grub.d/40_custom for the other systems.

 

One caveat. I could not get the huge-smp kernel to work using a UUID.

All is back up and running again.

 

I'm sure I will run into problems again as I have a tendency to move drives around.

Plus, if I have a drive on the SATA bus it gets /dev/sda otherwise the drive on the EIDE bus gets it.

Also, if I have a flash drive in the USB port when I boot it gets /dev/sda.

 

These issues are why I started using UUIDs in the first place.

Edited by alphaomega
Link to comment
Share on other sites

Are you remembering to run the LILO command after any modifications to lilo.conf?

I usually remember to re-run lilo when I use it. I'm using grub and os-prober in Arch now.

It's just that os-prober in Arch is using the information in Slackware's lilo.conf file.

I can tell because it is picking up the same labels I have in lilo.conf.

 

If I use a addappend=" root=UUID=..." type entry in lilo.conf the os-prober generated entry in grub won't work.

If I use a root=/dev/sdX type entry in lilo.conf the os-prober generated entry in grub works.

I have not tested a root=UUID= entry alone (without the addappend= option) in lilo.conf to see how os-prober handles that.

 

Regardless, I figured out that I could just manually make any necessary corrections to the generated /boot/grub/grub.conf file or stop using os-prober and manually configure the other systems using the /etc/grub.d/40_custom file.

 

When I was using lilo I was using the addappend= option because of the way it was set up.

I had an append= option which applied to all entries in lilo.conf and I used the addappend=

option to add the root=UUID= option (because the distros were on different drives).

 

I hope I explained that correctly.

 

I just like to use UUIDs regardless of which boot manager I'm using because I frequently move drives around.

Link to comment
Share on other sites

V.T. Eric Layton

I hate UUID, but I'll have to admit that it is a far more logical and precise way of identifying drives on a system than the /dev/sd* method.

 

I know you know your way around Linux, A-O. I just mentioned running the lilo because it's the most commonly forgotten step in manipulating lilo.conf. :)

Link to comment
Share on other sites

I hate UUID, but I'll have to admit that it is a far more logical and precise way of identifying drives on a system than the /dev/sd* method.

 

I know you know your way around Linux, A-O. I just mentioned running the lilo because it's the most commonly forgotten step in manipulating lilo.conf. :)

 

And I have hit that road block way too often.

I actually prefer UUIDs.

It makes it easier on me when I move drives around.

I have accidently wiped the wrong drive on several occasions due to the fact that I was not

paying attention and the drives got moved around because I was using /dev/sdX type entries.

  • Like 1
Link to comment
Share on other sites

Greetings fellow BATL members. It's been quite a while since I've been

lurking around here but now I could use a few pointers if possible.

 

I rsync'd arch from one drive to another one (/dev/sdb2).

I rsync'd slackware from one drive to another one (/dev/sdb3).

 

So the current setup on this machine (the same one I'm posting from) is:

Drive A = XP (/dev/sda1) (no internet access)

Drive B = arch (/dev/sdb2) / slackware (/dev/sdb3)

 

Grub2 in on /dev/sda

 

I have options to boot any of the three (xp, arch, and slackware).

All was working just fine.

I was able to boot any of the three operating systems without issue.

Then I messed up something.

 

At one point I was reinstalling grub (from arch) and accidently did:

grub-install /sda

I noticed my mistake and then tried:

grub-install /dev/sda

 

Now something really strange is happening:

I can still boot xp and arch just fine but there is a weird thing happening w/slackware.

 

It starts booting just fine.

Then around the time kms would kick in and the font in the console would change ...

I get messages from arch as if I'm booting arch (will try to get a screenshot to post)

and I cannot get into slackware without using an install disk and chrooting in.

 

Any ideas? I'm totally confused.

Cheers & thanks in advance for any pointers.

I see that you ran "grub-install" but not "update-grub". "update-grub" is what searches all of your drives for where OS's are installed and creates the conf file. It MUST be run any time you change partitions around. And it must be run AFTER running "grub-install".

Link to comment
Share on other sites

I see that you ran "grub-install" but not "update-grub". "update-grub" is what searches all of your drives for where OS's are installed and creates the conf file. It MUST be run any time you change partitions around. And it must be run AFTER running "grub-install".

I could be wrong but as far as I know there is no update-grub in Arch.

I find no mention of it in the ArchWiki for grub.

https://wiki.archlin.../index.php/GRUB

 

I did come across this old post (2009) when looking for info on update-grub in Arch.

https://bbs.archlinux.org/viewtopic.php?id=87822

Edit: I found, on further looking, that update-grub is a Debian thing. In Arch it is not needed as the latest kernel is always called the same thing, i.e. "kernel26.img". Sorry to waste space.

Edited by alphaomega
  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Forgot to note that I did manage to straighten this out. The drives are ordered differently between arch and slackware. When I was configuring the grub2 entries in arch for slackware I needed to use the drive order as seen in slackware and not as seen in arch.

Link to comment
Share on other sites

This thread is a great argument for using UUID or Labels rather than /dev/sd*.

The order in my computer changes depending on whether the eSATA drives are switched on at bootup. No problem with UUID but chaos for /dev notation.

Link to comment
Share on other sites

And grub.cfg is a mess.

Looking at it still confuses me.

 

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
insmod part_gpt
insmod part_msdos
if [ -s $prefix/grubenv ]; then
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}

function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}

if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 ceea4dc6-4b46-43c0-8078-3edc24825f9c
else
search --no-floppy --fs-uuid --set=root ceea4dc6-4b46-43c0-8078-3edc24825f9c
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_input console
terminal_output gfxterm
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=30
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=30
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch Linux, with Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-ceea4dc6-4b46-43c0-8078-3edc24825f9c' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 ceea4dc6-4b46-43c0-8078-3edc24825f9c
else
search --no-floppy --fs-uuid --set=root ceea4dc6-4b46-43c0-8078-3edc24825f9c
fi
echo 'Loading Linux linux ...'
linux /boot/vmlinuz-linux root=UUID=ceea4dc6-4b46-43c0-8078-3edc24825f9c rw resume=UUID=0a0a6b8c-5c02-4c93-b71c-ac565722e353 hpet=force pci=use_crs ipv6.disable=1 quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initramfs-linux.img
}
menuentry 'Arch Linux, with Linux linux (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-ceea4dc6-4b46-43c0-8078-3edc24825f9c' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 ceea4dc6-4b46-43c0-8078-3edc24825f9c
else
search --no-floppy --fs-uuid --set=root ceea4dc6-4b46-43c0-8078-3edc24825f9c
fi
echo 'Loading Linux linux ...'
linux /boot/vmlinuz-linux root=UUID=ceea4dc6-4b46-43c0-8078-3edc24825f9c rw resume=UUID=0a0a6b8c-5c02-4c93-b71c-ac565722e353 hpet=force pci=use_crs ipv6.disable=1 quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initramfs-linux-fallback.img
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Linux (on /dev/sda3)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz--eacc8500-1e1d-44da-ba6b-11be2660f2d4' {
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 eacc8500-1e1d-44da-ba6b-11be2660f2d4
else
search --no-floppy --fs-uuid --set=root eacc8500-1e1d-44da-ba6b-11be2660f2d4
fi
linux /boot/vmlinuz ro hpet=force pci=use_crs vt.default_utf8=1 vga=normal
initrd /boot/initrd.gz
}
menuentry 'HugeLinux (on /dev/sda3)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-huge-smp-3.10.17-smp--eacc8500-1e1d-44da-ba6b-11be2660f2d4' {
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 eacc8500-1e1d-44da-ba6b-11be2660f2d4
else
search --no-floppy --fs-uuid --set=root eacc8500-1e1d-44da-ba6b-11be2660f2d4
fi
linux /boot/vmlinuz-huge-smp-3.10.17-smp root=/dev/sda3 ro hpet=force pci=use_crs vt.default_utf8=1 vga=normal
}

menuentry 'Windows XP Media Center Edition (on /dev/sdb1)' --class windows --class os $menuentry_id_option 'osprober-chain-CC6C88186C87FF86' {
insmod part_msdos
insmod ntfs
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 CC6C88186C87FF86
else
search --no-floppy --fs-uuid --set=root CC6C88186C87FF86
fi
drivemap -s (hd0) ${root}
chainloader +1
}
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Slackware Linux 14.1 (generic-smp)" --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=UUID=eacc8500-1e1d-44da-ba6b-11be2660f2d4
search --no-floppy --fs-uuid --set=root eacc8500-1e1d-44da-ba6b-11be2660f2d4
linux /boot/vmlinuz root=UUID=eacc8500-1e1d-44da-ba6b-11be2660f2d4 ro quiet splash hpet=force pci=use_crs vt.default_utf8=1
initrd /boot/initrd.gz
}
menuentry "Slackware Linux 14.1 (huge-smp)" --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=UUID=eacc8500-1e1d-44da-ba6b-11be2660f2d4
search --no-floppy --fs-uuid --set=root eacc8500-1e1d-44da-ba6b-11be2660f2d4
linux /boot/vmlinuz-huge-smp-3.10.17-smp root=/dev/sda3 ro quiet splash hpet=force pci=use_crs vt.default_utf8=1
}
menuentry "Windows XP Media Center Edition" --class windows --class os {
insmod ntfs
set root=(hd0,1)
drivemap -s (hd0) (hd1)
search --no-floppy --fs-uuid --set CC6C88186C87FF86
chainloader +1
}
menuentry "Slackware (lilo)" {
set root=(hd0,3)
chainloader (hd0,3)+1
}
menuentry "System restart" {
echo "System rebooting..."
reboot
}
menuentry "System shutdown" {
echo "System shutting down..."
halt
}
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

### BEGIN /etc/grub.d/60_memtest86+ ###
### END /etc/grub.d/60_memtest86+ ###

Link to comment
Share on other sites

V.T. Eric Layton

This thread is a great argument for using UUID or Labels rather than /dev/sd*.

 

Yes, but why argue? Just do what feels right for you. ;)

Link to comment
Share on other sites

Showing your computer's age... B)

Yes but I only use XP for one thing at this point (tagging mp3s using mp3tag).

Have not found anything in linux that did not require a bunch of additonal libs.

I have been testing out easytag in arch but I messed up a batch of songs the last time I used it.

Link to comment
Share on other sites

securitybreach

I have been testing out easytag in arch but I messed up a batch of songs the last time I used it.

 

Thank goodness for backups...

Link to comment
Share on other sites

I have been testing out easytag in arch but I messed up a batch of songs the last time I used it.

I've used Easytag for years. It's a bit quirky but the only time I messed up tags was user error. :>

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...