The last online update with kernel upgrade to 3.4.28-2.20 made my system unbootable. This seems to be becoming a regular occurrence, when I upgrade the kernel with online update.
This time it was really screwed up.
Here is the default boot option in the menu.lst file:
title GNU GRUB 2 – openSUSE 12.2 - GNU GRUB 2
kernel (hd0,4)/grub2/core.img root=/dev/mapper/root luks_root=/dev/sda2 luks_swap=/dev/sda6 luks_home=/dev/sda3 luks=“root swap home” vga=0x323
It never asked me if I wanted to use grub2. That core.img file is located in a i386-pc subdirectory. Even changing for that, it won’t boot.
There was also a missing mkinitrd file. It seems that the upgrade script did not run mkinitrd, or it had crashed(?).
I had to run rescue disk, mount my partitions, mount --bind /proc, /sys, and /dev then chroot.
Then I had to run mkinitrd to generate the missing mkinitrd.
I used this command “root_dir=”" mkinitrd -M /boot/System.map-3.4.28-2.20-default -k /boot/vmlinuz-3.4.28-2.20-default -i /boot/initrd-3.4.28-2.20-default -d /dev/mapper/root -f block dm luks kparts network usb lvm2 /"
Then I had to us nano to edit my grub/menu.lst file to add a correct entry.
I added this:
title 3.4.28-2.20 – openSUSE 12.2 - 3.4.28-2.20
root (hd0,4)
kernel /vmlinuz-3.4.28-2.20-default root=/dev/mapper/root luks_root=/dev/sda2 luks_swap=/dev/sda6 luks_home=/dev/sda3 luks_mnt2=/dev/sdc1 luks=“root swap home mnt2”
vga=0x323
initrd /initrd-3.4.28-2.20-default
I had something similar for the previous kernel version.
The online updates are making my system unbootable too often.
I don’t like having to rescue my system after every kernel upgrade.
The upgrade scripts should be tested more thoroughly before they are released.
I am using a release (12.2) not a release candidate/beta.
On Wed, 06 Mar 2013 01:16:01 +0000, donharter wrote:
> I had something similar for the previous kernel version.
> The online updates are making my system unbootable too often.
> I don’t like having to rescue my system after every kernel upgrade. The
> upgrade scripts should be tested more thoroughly before they are
> released.
This reads more like a bug report than a request for assistance - please
submit this at http://bugzilla.novell.com so it can be properly tracked
and looked into.
FWIW, I’ve not had this problem with kernel updates on my system - it
looks like you’re using LUKS, and that may be the factor that’s causing
the issue - and it may be a test case that needs to be added.
If you are using Grub Legacy, you need to post a bug report since not using Grub 2 is an option with openSUSE 12.2 but consider the distro is headed straight long into using Grub 2 and there is no turning back. Such problems as you see should not occur and can be reported as a bug, but you are swimming upstream against the grub2 push in my opinion. Post bug reports here: Bugzilla Main Page
On 2013-03-06 02:16, donharter wrote:
> I don’t like having to rescue my system after every kernel upgrade.
Me neither.
I customarily look at the /boot directory after a kernel upgrade to see
if everything looks right. I also have a look inside menu.lst (grub1). I
don’t know how to do that with grub2.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
I can only quote myself from another thread - in all cases where I was able to obtain factual information this was due to mismatch between what YaST2 thinks and actual bootloader configuration.
Show result of “grep LOADER /etc/sysconfig/bootloader”.
In original post you told about menu.lst which implies you are using grub legacy, while YaST2 (and other tools that run when you install new kernel) believes you are using grub2. So start YaST2 bootloader configuration, select which bootloader you want to have and save it. To be sure it won’t happen next time.
Here is the result:
root:~>grep LOADER /etc/sysconfig/bootloader
LOADER_TYPE=“grub”
LOADER_LOCATION=“”
.
I submitted a bug report on a similar luks trouble. I fixed that by configuring /etc/crypttab. It seems that the kernel command line was being ignored, and only /etc/crypttab was being used/read
@ robin_listas Sort of off topic but you can learn quite a bit about grub2 and the upgrade process by reading through /etc/default/grub
Course you might not even have that file in openSUSE 11.xx
On 2013-03-07 14:56, anika200 wrote:
> @ robin_listas Sort of off topic but you can learn quite a bit about
> grub2 and the upgrade process by reading through /etc/default/grub
> Course you might not even have that file in openSUSE 11.xx
I have a 12.3 test system. I’m afraid that file configures how grub2
should be, not how it actually is, specially after a kernel upgrade. The
purpose here is to check that grub 2 has not been broken by the kernel
upgrade you have just done.
In grub1 you have a look at menu.lst.
In grub2, where? Not that default file. You have to look at several files…
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
On 2013-03-08 03:16, nrickert wrote:
>
> robin_listas;2532921 Wrote:
>> In grub2, where? Not that default file. You have to look at several
>> files…
> The actual configuration file is “/boot/grub2/grub.cfg”.
>
> The file “/etc/default/grub” and the files in “/etc/grub.d” are used to
> rebuild the configuration when “grub2-mkconfig” is run.
I will have to learn that. :-}
Or maybe not… Maybe I can survive without for some years, then I have
to buy a new UEFI machine, and by that time ‘gummiboot’ is the default
booter then
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
Exactly , which is after every kernel update and grub2 updates, this makes the file /etc/default/grub relevant to the situation.
In fact, in my current config /etc/default/grub differs from the drive I am actually booting off of and what appears in /boot/grub2/grub.cfg. This is why once in a while after a kernel update or a grub2 update my system will not boot and I have to go into the Bios and switch the drive to the one pointed to in the /etc/default/grub file. I happen to know this is a problem so it is no big deal when it happens. Once booted I then change back to boot from the /root device in Yast2 and then change the bios again and all is well.
If I look in yast >> bootloader and check under bootloader options , there I can see the exact listing as is in the /etc/default/grub file. I actually have the boot from root partition checked so this gets ignored, thankfully. I am not actually sure when this information would actually be used which is kinda scary but it does seem to happen after kernel and grub2 updates.
