When 'System Updates' updated the kernel the new kernel is not used and is missing the initrd file. For example,today a new kernel update was installed after which the new boot disk had the contents below: root@localhost boot]# ls -l total 23236 -rw-r--r-- 1 root root 440 Feb 3 20:43 boot.backup.sda -rw-r--r-- 1 root root 151150 May 16 16:48 config-3.12.20-desktop-1.mga4 -rw-r--r-- 1 root root 151132 Jan 24 13:58 config-3.12.8-desktop-2.mga4 drwxr-xr-x 2 root root 1024 Dec 28 15:00 dracut/ -rwxr-xr-x 1 root root 535552 Feb 3 20:43 gfxmenu* drwxr-xr-x 2 root root 1024 Feb 3 20:43 grub/ -rw------- 1 root root 9001670 Feb 3 20:42 initrd-3.12.8-desktop-2.mga4.img lrwxrwxrwx 1 root root 33 May 18 12:14 initrd-desktop.img -> initrd-3.12.20-desktop-1.mga4.img lrwxrwxrwx 1 root root 32 May 9 23:57 initrd.img -> initrd-3.12.8-desktop-2.mga4.img drwx------ 2 root root 12288 Feb 3 20:23 lost+found/ -rw-r--r-- 1 root root 224840 May 16 16:48 symvers-3.12.20-desktop-1.mga4.xz -rw-r--r-- 1 root root 224620 Jan 24 13:58 symvers-3.12.8-desktop-2.mga4.xz -rw-r--r-- 1 root root 2875983 May 16 16:48 System.map-3.12.20-desktop-1.mga4 -rw-r--r-- 1 root root 2871326 Jan 24 13:58 System.map-3.12.8-desktop-2.mga4 lrwxrwxrwx 1 root root 29 May 10 00:01 vmlinuz -> vmlinuz-3.12.8-desktop-2.mga4 -rw-r--r-- 1 root root 3819488 May 16 16:48 vmlinuz-3.12.20-desktop-1.mga4 -rw-r--r-- 1 root root 3817056 Jan 24 13:58 vmlinuz-3.12.8-desktop-2.mga4 lrwxrwxrwx 1 root root 30 May 18 12:14 vmlinuz-desktop -> vmlinuz-3.12.20-desktop-1.mga4 Note that the new kernel is in a link vmlinuz-desktop however the grub boot unchanged and is set to [root@localhost boot]# cat grub/menu.lst timeout 10 color black/cyan yellow/cyan gfxmenu (hd0,0)/gfxmenu default 0 title linux kernel (hd0,0)/vmlinuz BOOT_IMAGE=linux root=UUID=2fb1a87e-4681-4ccf-9c8f-4265561af7aa splash quiet resume=UUID=261ef23a-95b1-4c9d-83ce-34dee1880677 vga=788 root (hd0,0) initrd /initrd.img title linux-nonfb kernel (hd0,0)/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=2fb1a87e-4681-4ccf-9c8f-4265561af7aa resume=UUID=261ef23a-95b1-4c9d-83ce-34dee1880677 root (hd0,0) initrd /initrd.img title failsafe kernel (hd0,0)/vmlinuz BOOT_IMAGE=failsafe root=UUID=2fb1a87e-4681-4ccf-9c8f-4265561af7aa failsafe root (hd0,0) initrd /initrd.img I could relink this myself but the file initrd-3.12.20-desktop-1.mga4.img does not exist so the created link initrd-desktop.img -> initrd-3.12.20-desktop-1.mga4.img is invalid. Reproducible: Steps to Reproduce:
CC: (none) => remiAssignee: bugsquad => tmbQA Contact: (none) => qa-bugs
How much disk space is required by a kernel update? I ask because I only have a small boot partition (30MB). There weren't any errors when I did the update but maybe it fails silently if it runs out of disk space and doesn't complete the install, is that possible?
(In reply to Simon Geard from comment #1) > How much disk space is required by a kernel update? I ask because I only > have a small boot partition (30MB). There weren't any errors when I did the > update but maybe it fails silently if it runs out of disk space and doesn't > complete the install, is that possible? That is the issue. 30MB is not nearly large enough anymore, unfortunately. Even 50MB isn't always in some cases. It's a pain how quickly the size of the kernels and initrds have blown up in the last few years, leaving those of us with small boot partitions unable to use them anymore. On some systems my partitions were ordered in such a way that I was able to expand it, but on my laptop I had to abandon the use of the boot partition and just move the boot directory to my root partition, which works just fine in my case. But yes, it will fail to create the initrd if there's not enough space. This isn't really a bug, just a bummer. You'll have to adjust your /boot storage somehow.
Status: NEW => RESOLVEDResolution: (none) => INVALID
Thanks, I'll work on doing that. Actually I've never had a boot partition before my laptop, and I started using Linux around 1996 - my file-system history is ext2, Reisers and xfs. When I upgraded to Mageia4 this year I decided to try btrfs since my laptop only has ssd storage - and like all previous times I've tried to use btrfs I found it impossible to boot. To circumvent this (seemingly perpetual) problem I created a 30MB ext3 boot partition and all was well until the upgrades started failing. I'll probably reinstall and this time give the boot partition 1GB. The real solution is to be able to boot off btrfs but M4 an M3 can't do that (is that a bug?) - is that planned for M5?
If you wish to use btrfs then you'll need to use grub2 and depending on where you use btrfs you'll also need a separate /boot IINM. Please ask in the forums or mailing list if you need further help with that setup though. Thanks.
Thanks for that. I've tried to use grub2 but failed so I've reverted to using an ext4 file system for the root partition and I'm happy with that. When I tried using the 'Restore Bootloader' option from the installation disk it gave me the option of grub and grub2, when I selected grub2 I code an error, something like install_raw_grub2 which I can see now was reported in https://forums.mageia.org/de/viewtopic.php?t=2134&p=23963 which I think is in German so I don't understand it. I hope this information helps you fix this problem.
Please create a new bug for the new issue Simon, this one was closed.
commit df8433f2db7142b045a80391b74c21057a92b2d3 Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Apr 3 18:17:58 2015 +0200 split install_raw_grub2() out of install_grub2() thus fixing grub2 rescue (mga#13408, mga#13901) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=df8433f2db7142b045a80391b74c21057a92b2d3 Bug links: Mageia https://bugs.mageia.org/13408 https://bugs.mageia.org/13901