You are not logged in.

#1 2014-07-07 19:47:30

computerwhiz1
Member
Registered: 2014-05-22
Posts: 16

Booting latest kernel without remaking grub.cfg

I currently have Arch Linux, Ubuntu 14.04, and Linux Mint 17 installed on my computer. I have installed grub to the MBR through Arch and use Arch to generate the master grub.cfg with os-prober and such. This works fine as Arch is able to detect the other operating systems and add menu entries for them. The only issue is when Ubuntu or Linux Mint does a kernel update to a new version of the kernel. This changes the name of the kernel file which means that my grub will now boot into the old kernel. The only way I can fix this is by updating the grub.cfg in the ubuntu install first, and then updating that master grub.cfg in Arch in order for it to pick up on the now updated kernel with a new version number in its name. This is tedious as it means booting into Ubuntu's new kernel requires first booting into Arch to update the grub.cfg.

I am looking for some way to perhaps have the grub.cfg always reference the latest kernel. I have tried to use symlinks and create a vmlinuz-latest and vmlinuz-fallback in Ubuntu that link to the latest version and the previous version respectively. This way the Arch grub.cfg could just reference those symlinks and all I would have to do is update the symlinks from within Ubuntu to get it to boot the latest kernel, but I haven't quite been able to get that to work properly. What is the best way to work this out?

Offline

#2 2014-07-07 20:16:00

clfarron4
Member
From: London, UK
Registered: 2013-06-28
Posts: 2,163
Website

Re: Booting latest kernel without remaking grub.cfg

When I used to triple boot Linux Mint, ArchLinux and Windows 7 on the same machine, I let Linux MInt handle GRUB2.

It tended to work out pretty well since Linux Mint would pick up the changes to the kernels for Mint and do the work for you and pick up ArchLinux (for which the initramfs files for [core] kernels keep the same name) and Windows 7.


Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository

Offline

#3 2014-07-08 01:29:40

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Booting latest kernel without remaking grub.cfg

computerwhiz1 wrote:

I am looking for some way to perhaps have the grub.cfg always reference the latest kernel. I have tried to use symlinks and create a vmlinuz-latest and vmlinuz-fallback in Ubuntu that link to the latest version and the previous version respectively. This way the Arch grub.cfg could just reference those symlinks and all I would have to do is update the symlinks from within Ubuntu to get it to boot the latest kernel, but I haven't quite been able to get that to work properly. What is the best way to work this out?

What exactly does not work properly? The initial ramdisk should be symlinked also. I would continue using symlinks, maybe creating one static grub.cfg and update it from time to time. Does Ubuntu use systemd by now? If yes, you could set up a service that monitors changes in /boot and run a script for updating the symlinks to latest kernels or replace old names in grub.cfg.

Offline

#4 2014-07-08 19:08:35

computerwhiz1
Member
Registered: 2014-05-22
Posts: 16

Re: Booting latest kernel without remaking grub.cfg

emeres wrote:
computerwhiz1 wrote:

I am looking for some way to perhaps have the grub.cfg always reference the latest kernel. I have tried to use symlinks and create a vmlinuz-latest and vmlinuz-fallback in Ubuntu that link to the latest version and the previous version respectively. This way the Arch grub.cfg could just reference those symlinks and all I would have to do is update the symlinks from within Ubuntu to get it to boot the latest kernel, but I haven't quite been able to get that to work properly. What is the best way to work this out?

What exactly does not work properly? The initial ramdisk should be symlinked also. I would continue using symlinks, maybe creating one static grub.cfg and update it from time to time. Does Ubuntu use systemd by now? If yes, you could set up a service that monitors changes in /boot and run a script for updating the symlinks to latest kernels or replace old names in grub.cfg.

Ok what I mean is that Ubuntu and Linux mint both by default have symlinks in the root directory of their file system called /vmlinuz and /initrd.img. Both of those are autoamtically kept up to date to boot the latest version of the kernel and ram disk. In GRUB if you reference those symlink files to boot it will boot properly and thats what I want it to do. I could set up a custom grub.cfg that would reference those files and it would work. The only trouble is I use this computer for testing various distrobutions with Arch being the only one that is always there. Therefore it would be nice to use os-prober to automatically generate the files instead of manually creating entires. The issue is that for some reason os-prober will reference a specific kernel and ram disk. Soemthing like /boot/vmlinux-3.13-30-generic and /boot/initrd.img-3.13 instead of the symlinks /vmlinuz and /initrd.img. The problem with this is whenever I update the kernel in Ubuntu or Linux mint it leaves GRUB still referencing the old files instead of the new ones, which means I have to regenerate the grub.cfg from within Arch. I was wondering if there is any way I could get os-prober to use the symlinks instead of referencing the static files? It seemed to pick up on them when I put my own symlinks in /boot, but I couldn't get the naming right and it complained about syntax being wrong.

Offline

#5 2014-07-08 19:23:14

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Booting latest kernel without remaking grub.cfg

What about creating a custom entry in /etc/grub.d/ then? You could add one with the symlink references, that entry would stay in grub menu unless you modify it. The os prober apparently ignores symlinks, I would refrain from changing that. It would have to be corrected after each update of whatever os-prober package it comes from (probably grub itself).

Edit: Maybe even copying the Ubuntu and Mint part of the generated grub.cfg and then replacing the names with those of symlinks would be sufficient.

Last edited by emeres (2014-07-08 19:27:48)

Offline

#6 2014-07-08 19:43:58

shulamy
Member
From: israel
Registered: 2010-09-11
Posts: 459

Re: Booting latest kernel without remaking grub.cfg

i vote for clfarron4, with arch and fedora.

ezik

Offline

#7 2014-07-09 01:31:51

computerwhiz1
Member
Registered: 2014-05-22
Posts: 16

Re: Booting latest kernel without remaking grub.cfg

Ok, so what I have ended up doing is a sort of hybrid of using os-prober and having a manual config in the /etc/grub.d/40_custom file. I used grub-mkconfig to output a grub.cfg which I simply used as a template. So here is what I did.
1.  I left os-prober turned on and generated a grub.cfg.temp
2.  I used this grub.cfg.temp to copy and paste the entires os-prober made into the 40_custom file. This means I didn't have to manually write them, but was still able to change the kernel and ram disk to the symlinks instead of the static ones so that it will boot the latest kernel and ramdisk without having to regenerate the config file.
3.  Now, disable os-prober
4.  Regenerate the grub.cfg using grub-mkconfig, this time for real putting the actual file in /boot/grub/grub.cfg.

What this essentially does it use os-prober to generate the entires, this allow you to manually modify them and add them to 40_custom. The solution isn't 100% ideal but it was the best thing I could come up with. I'm sure someone with enough scripting knowledge could maybe even write a script that would do just that.

Last edited by computerwhiz1 (2014-07-09 01:32:28)

Offline

#8 2014-07-12 21:51:08

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Booting latest kernel without remaking grub.cfg

I would leave os-prober exectuable. The custom entries in 40_custom could be printed to standard output and therefore to final grub.cfg simply by using cat << EOF content EOF. That would leave you with double entries for mint and ubuntu (under different names), but it would be more future-proof should something change on your system. And os_prober probably will get updated with new permission on update, so you would have to repeat the task.

Offline

Board footer

Powered by FluxBB