{"id":8467,"date":"2018-12-19T12:56:24","date_gmt":"2018-12-19T16:56:24","guid":{"rendered":"http:\/\/starlightcascade.ca\/blog\/?p=8467"},"modified":"2018-12-19T15:51:56","modified_gmt":"2018-12-19T19:51:56","slug":"linux-fedora-grub","status":"publish","type":"post","link":"https:\/\/starlightcascade.ca\/blog\/2018\/12\/linux-fedora-grub\/","title":{"rendered":"linux fedora grub"},"content":{"rendered":"<p><a href=\"http:\/\/starlightcascade.ca\/blog\/wp-content\/uploads\/2012\/08\/fedora-penguin.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-3278\" src=\"http:\/\/starlightcascade.ca\/blog\/wp-content\/uploads\/2012\/08\/fedora-penguin.png\" alt=\"\" width=\"256\" height=\"256\" srcset=\"https:\/\/starlightcascade.ca\/blog\/wp-content\/uploads\/2012\/08\/fedora-penguin.png 256w, https:\/\/starlightcascade.ca\/blog\/wp-content\/uploads\/2012\/08\/fedora-penguin-150x150.png 150w\" sizes=\"auto, (max-width: 256px) 100vw, 256px\" \/><\/a>For many years now, one linux fedora server I maintain had issues with every dnf upgrade that involved a new kernel. It would not place configuration information into boot\/grub2\/grub.cfg and would not boot into the new kernel. One had to run this command to make it work:<\/p>\n<p>root@S888:\/n # grub2-mkconfig -o \/boot\/grub2\/grub.cfg<br>Generating grub configuration file &#8230;<br>Found linux image: \/boot\/vmlinuz-4.19.9-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.8-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.6-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.5-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.4-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-0-rescue-25947e2761f2405084e99e0c2a4ea14f<br>Found initrd image: \/boot\/initramfs-0-rescue-25947e2761f2405084e99e0c2a4ea14f.img<br>device-mapper: reload ioctl on osprober-linux-sda3 failed: Device or resource busy<br>Command failed.<br>Even though the command failed, it did work and would reboot on command into the new kernel. The issue seemed to be with \/dev\/sda3 which is the root directory.<\/p>\n<p>[root@S888 etc]$ cat fstab<br># device-spec mount-point fs-type options dump pass<br>#dump seldom used=0 pass 0=donotcheck 1=1st 2=2nd<br>\/dev\/sda1 \/boot ext4 defaults 0 1<br>\/dev\/sda2 swap swap defaults 0 0<br>\/dev\/sda3 \/ ext4 defaults 0 1<br>#sda4 is extended partition<br>\/dev\/sda5 \/home ext4 defaults 0 2<br>\/dev\/sda6 \/web ext4 defaults 0 2<br>#<br>\/dev\/sdb1 \/mnt\/backup ext4 defaults 0 2<\/p>\n<p><\/p>\n<p>I think today we may have fixed this.<\/p>\n<p>root@S888:\/etc # os-prober<br>device-mapper: reload ioctl on osprober-linux-sda3 failed: Device or resource busy<br>Command failed.<\/p>\n<p>vi \/etc\/default\/grub and add line<br>GRUB_DISABLE_OS_PROBER=true<br>root@S888:\/etc\/default # grub2-mkconfig -o \/boot\/grub2\/grub.cfg<br>Generating grub configuration file &#8230;<br>Found linux image: \/boot\/vmlinuz-4.19.9-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.8-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.6-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.5-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-4.19.4-300.fc29.i686<br>Found linux image: \/boot\/vmlinuz-0-rescue-25947e2761f2405084e99e0c2a4ea14f<br>Found initrd image: \/boot\/initramfs-0-rescue-25947e2761f2405084e99e0c2a4ea14f.img<br>done<br>No errors! Should be fixed!<br>reboot<\/p>\n<p>It rebooted correctly.&nbsp; The true test will be the next kernel update&#8230;<\/p>\n<p>In the meantime we can manually remove some of the older kernels:<\/p>\n<p>root@S888:\/boot # dnf remove kernel-core-4.19.4<\/p>\n<p>root@S888:\/boot # dnf remove kernel-core-4.19.5<\/p>\n<p>After this, an inspection of grub.cfg shows that these two entries have indeed been removed!<\/p>\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>For many years now, one linux fedora server I maintain had issues with every dnf upgrade that involved a new kernel. It would not place configuration information into boot\/grub2\/grub.cfg and would not boot into the new kernel. One had to run this command to make it work: root@S888:\/n # grub2-mkconfig -o \/boot\/grub2\/grub.cfgGenerating grub configuration file [&hellip;]<\/p>\n","protected":false},"author":494,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[],"class_list":["post-8467","post","type-post","status-publish","format-standard","hentry","category-tech"],"_links":{"self":[{"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/posts\/8467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/users\/494"}],"replies":[{"embeddable":true,"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/comments?post=8467"}],"version-history":[{"count":7,"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/posts\/8467\/revisions"}],"predecessor-version":[{"id":8478,"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/posts\/8467\/revisions\/8478"}],"wp:attachment":[{"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/media?parent=8467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/categories?post=8467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/starlightcascade.ca\/blog\/wp-json\/wp\/v2\/tags?post=8467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}