Re: GRUB2 Behavior Question

[Matt Sickler]

>Gosh, I've no experience with anything like that.

It's honestly not that different than server administration, except that all 
administration has to be automated through scripts and Debian packages.
Oh, and you can't use ansible/chef/puppet/etc since each system is 
"standalone".  They're "embedded" in the customer's location (not necessarily a 
DC).


>Yes. That depends on whether the system uses UEFI or the old BIOS/MBR.

>(You might tell us that.)

It's BIOS/MBR.  Which might actually work to our advantage.


>My opinion is even more that you should consider a manual, simple, grub.cfg.  
>Otherwise I'd expect some grub update to break the boot sooner or later.  The 
>grub script machinery generating grub.cfg seems oriented towards desktop and 
>laptop use.

Yeah, the grub.cfg generation scripting definitely seems oriented towards 
laptops/desktops.  Even servers it's only sorta there.


>If that's too far off the beaten track, I suggest picking one install to 
>control grub and uninstalling grub from the others

That's not possible since each install are totally independent from each other. 
 None of them are "more important" or last longer than the others (they will 
get cycled out over the years as firmware gets updated).


>Also, you might consider using the "vmlinuz" and "initrd.img" symlinks.

That's a good idea.   I think we're going to try disabling the grub.cfg 
generation machinery, make our own (since I think they could be identical 
across all of the installs), and use those symlinks since they're 
kernel-version independent.

If that doesn't work, we have the workaround of running grub-install in a 
chroot of the "target" install before switching the @ symlink and rebooting.  
That seems to make things work too.