I updated a machine with a 12.3* kernel. The kernel is changing from 3.7.10-1.16.1.x86_64 to 3.7.10-1.40.1.x86_64. The “16” version still works fine. The “40” version refuses to boot, saying it cannot find the root device. Looking at grub, it first had “root=/dev/sda3”, whereas the “16” version had a UUID. In fact, /dev/sda3 is the correct location of root according to fstab in “16”, but I thought that was odd, so I changed the “40” version to the same UUID as the “16” version. It still fails.** The precise message at the end is (forgive typos; I’m copying by hand):
1.724496] VFS: Cannot open root device “UUID=…” “/dev/sda3” when I have that]
1.725020] Please append a correct “root=” boot option: here are the available partitions:
1.725538] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
I suppose it’s important that no available partitions are listed, but i don’t understand why they’re not found.
thanks for any enlightenment
*A 13.2 install DVD won’t boot on the machine. I have no idea why; it simply kernel-panics, giving no useful information. So installing 13.2 appears to be out of the question.
**Additional context (if it helps). When I first tried the update, the /boot partition filled to 100%, and the update quit. I manually removed older kernels, and the update completed. Unfortunately, we have the current result.
Problem solved by removing the newer kernel from the boot menu. Curiously, the kernel shouldn’t even have been installed, as there isn’t enough room on /boot for it: 99MB v. 153MB for the update. Even that seems odd, though: the 1.16 kernel is only a few megabytes in size.
Anyone know the reason for the large package size?
More then a kernel is in boot all the initd stuff is there too as well as Plymouth. You need to allow for about 500 meg to be totally safe in boot size. Normal openSUSE keeps 2 kernels but there can be 3 with all their support stuff until the last to install is successfully booted.
Unfortunately, I’m still out of room, and thus unable to complete an upgrade. Any advice on how to fix this? I didn’t set up the computer; someone else set /boot size at 99M. I’m just stuck trying to make it work. :\
(NB I’ve already removed older kernels & the like, which seemed okay at the time. This update seems to put things over just a little too far.)
EDIT: I can manually install grub.cfg, but the error I have now is, “Initramfs unpacking failed: read error.” So, yeah, any suggestions would be appreciated.
I managed through 12.3 and 13.1 with a small “/boot” (94M in the smallest case). I did some repartitioning for 13.2, so that I won’t have to deal with that.
What I did for 12.3, was uninstall “plymouth”. That’s the software that gives fancy graphics during boot. The system can work with out it. After uninstalling “plymouth”, I then ran “mkinitrd” as root. That generates a smaller “initrd” because it no longer contains “plymouth”.
That was enough space savings that I could easily fit two kernels, and almost three. For safety, I would manually uninstall the oldest kernel after a new one had tested well. That way, I never needed more than two kernels.
Wham! Merely removing plymouth solved my problem. I ran “mkinitrd” with trepidation, but it freed up even more space, no trouble. I was afraid I’d have to delve into the dark art of resizing a partition, but I’m OK now. Don’t know if I have sufficient space for another kernel, but I have 2, & after a reboot, everything seems fine, even the kernel name. Thank you!
you can always remove the older kernels and disable it by editing
/etc/zypp/zypp.conf
There seems to be a systemd unit file (service) that can do that but i have no idea about it since i always disable the multiversion kernel in /etc/zypp/zypp.conf from the start.
I know it might bit me (or not) but i choose not to install a lot of kernels .
I may have been one of the first to run into that problem. I started a thread about it at the time. Here it is for reference: My first tumbleweed mishap
> What I did for 12.3, was uninstall “plymouth”. That’s the software that
> gives fancy graphics during boot. The system can work with out it.
> After uninstalling “plymouth”, I then ran “mkinitrd” as root. That
> generates a smaller “initrd” because it no longer contains “plymouth”.
Same here.
My boot is a bit bigger, 190M, and 91M are used. Three kernels currently.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
If you have a reasonable-sized HD, a 1-GiB boot partition would allow plenty of future room with negligible loss of disk space. This is now being recommended in many circles.
Thank you; this is definitely something I will keep in mind for the future. I guess a lot of people installing Linux are still stuck in the mindset where a 10GB HD was considered a luxury. That said, it would be no less wise for distributions to evaluate the space on disk before they start stuffing it with material & modifying grub after an incomplete upgrade. Filling the boot partition has happened to me more than once in the past, largely for the same reason, but this is the first time I remember encountering a non-bootable computer as a direct result.
Oh but they stuff it full because people want a GUI system with all the bells and whistles and don’t want to be bothered by silly things like manually configuring your system…
There are still distros the believe that small is beautiful like puppy and D.A.M.N. Small
On 2014-12-15 04:46, Fraser Bell wrote:
>
> If you have a reasonable-sized HD, a 1-GiB boot partition would allow
> plenty of future room with negligible loss of disk space. This is now
> being recommended in many circles.
Oh, absolutely! But 200 megs also looked to be ample, at a time when 20
megs sufficed
The initial recommendation, years ago, was “one track”.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I ran “mkinitrd” with trepidation, but it freed up even more space, no trouble. I was afraid I’d have to delve into the dark art of resizing a partition, but I’m OK now. Don’t know if I have sufficient space for another kernel, but I have 2, & after a reboot, everything seems fine, even the kernel name. 