FYI: update-grub / grub-mkconfig somewhat "broken"

[Robert Heller]

For what it is worth:

The default setup for grub-mkconfig is somewhat "broken". It poorly handles
the case where there is a shared /boot file system shared by two or more Linux
distros. I have two systems that can dual boot Ubuntu 18.04 (4.15.0-* kernels)
and CentOS 6.10 (2.6.32-* kernels). The default behaviour will include the
options to boot with a 2.6.32 kernel with the Ubuntu root file system (this
really won't work!)

I have managed to hack things (hacked 10_linux to skip centos kernels) to not
do this and created a grub-mkconfig helper script specificly for the CentOS
6.10 kernels (it is hardwired for my systems). I also had to disable
os-prober, since it was just not doing anything good, including trying to set
up booting a VM as a bare metal O/S (!).  Hopefully, apt-get dist-upgrade will
behave and not screw up my settings or overwrite my hacked 10_linux script.

I don't know if this is a bug or if my setup is just unique -- somehow I don't
really believe that -- I don't really believe that *I* invented the idea of a
separate /boot file system and multi-booting different Linux distros with a
shared /boot file system. A separate /boot file system is actually necessary
with LILO and grub 1.x when using LVM. I'm guessing with grub 2.x, you don't
need to do that (no it is not worth the effort to change how my disks are
partitioned).

Also I found an interesting passage in the grub manual:

" grub-mkconfig does have some limitations. While adding extra custom menu
entries to the end of the list can be done by editing '/etc/grub.d/40_custom'
or creating '/boot/grub/custom.cfg', changing the order of menu entries or
changing their titles may require making complex changes to shell scripts
stored in '/etc/grub.d/'. This may be improved in the future. In the
meantime, those who feel that it would be easier to write 'grub.cfg'
directly are encouraged to do so (see Chapter 5 [Booting], page 15, and
Section 6.3 [Shell-like scripting], page 25), and to disable any system
provided by their distribution to automatically run grub-mkconfig."

So it seems that even the grub devs don't full trust grub-mkconfig...


--
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                                                                                                         

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Bret Busby]

On 14/2/21 11:06 pm, Robert Heller wrote:

> For what it is worth:
>
> The default setup for grub-mkconfig is somewhat "broken". It poorly handles
> the case where there is a shared /boot file system shared by two or more Linux
> distros. I have two systems that can dual boot Ubuntu 18.04 (4.15.0-* kernels)
> and CentOS 6.10 (2.6.32-* kernels). The default behaviour will include the
> options to boot with a 2.6.32 kernel with the Ubuntu root file system (this
> really won't work!)
>
> I have managed to hack things (hacked 10_linux to skip centos kernels) to not
> do this and created a grub-mkconfig helper script specificly for the CentOS
> 6.10 kernels (it is hardwired for my systems). I also had to disable
> os-prober, since it was just not doing anything good, including trying to set
> up booting a VM as a bare metal O/S (!).  Hopefully, apt-get dist-upgrade will
> behave and not screw up my settings or overwrite my hacked 10_linux script.
>
> I don't know if this is a bug or if my setup is just unique -- somehow I don't
> really believe that -- I don't really believe that *I* invented the idea of a
> separate /boot file system and multi-booting different Linux distros with a
> shared /boot file system. A separate /boot file system is actually necessary
> with LILO and grub 1.x when using LVM. I'm guessing with grub 2.x, you don't
> need to do that (no it is not worth the effort to change how my disks are
> partitioned).
>
> Also I found an interesting passage in the grub manual:
>
> " grub-mkconfig does have some limitations. While adding extra custom menu
> entries to the end of the list can be done by editing '/etc/grub.d/40_custom'
> or creating '/boot/grub/custom.cfg', changing the order of menu entries or
> changing their titles may require making complex changes to shell scripts
> stored in '/etc/grub.d/'. This may be improved in the future. In the
> meantime, those who feel that it would be easier to write 'grub.cfg'
> directly are encouraged to do so (see Chapter 5 [Booting], page 15, and
> Section 6.3 [Shell-like scripting], page 25), and to disable any system
> provided by their distribution to automatically run grub-mkconfig."
>
> So it seems that even the grub devs don't full trust grub-mkconfig...
>
>

I do not know whether this applies to your scenario, but, on one of my
systems, I have both 20.10 and 16.04.x of UbuntuMATE installed, with the
system being originally a MS Win 8 system (it still has MS Win 8
installed, but that is unusable, as I forgot the password for MS Win 8,
and it was too difficult to use MS Win 8, anyway), and GRUB lets me
select whichever of the two UbuntuMATE versions to boot, without any
problem, and, that has applied, when the 20.10 was previous version
numbers, going back to 18.04.

On that computer, I had previously had three or four different version
numbers of UbuntuMATE installed, and, had no problems selecting and
booting into the different version numbers.

I currently have that system running 20.10, as, whilst I prefer 16.04, I
believe that EOL for 16.04, is due to occur in two months time, and so I
thought it better to get used to running the stuff on that system, in
20.10, before 16.04 EOL.

--
Bret Busby
Armadale
West Australia
(UTC+0800)
..............


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Liam Proven]

On Sun, 14 Feb 2021 at 16:39, Bret Busby <[hidden email]> wrote:

> I currently have that system running 20.10, as, whilst I prefer 16.04, I
> believe that EOL for 16.04, is due to occur in two months time, and so I
> thought it better to get used to running the stuff on that system, in
> 20.10, before 16.04 EOL.

Just checking: 20.10 is not a long-term support release. 20.04 is the
current LTS.

If you just wish to avoid EOL on Xenial, then 18.04 (Bionic) might be
an easier choice.

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: [phone] – ČR (+ WhatsApp/Telegram/Signal): [phone]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Robert Heller]

At Sun, 14 Feb 2021 23:37:03 +0800 "Ubuntu user technical support, not for general discussions" <[hidden email]> wrote:

>
> Content-Type: text/plain
>
> On 14/2/21 11:06 pm, Robert Heller wrote:
> > For what it is worth:
> >
> > The default setup for grub-mkconfig is somewhat "broken". It poorly handles
> > the case where there is a shared /boot file system shared by two or more Linux
> > distros. I have two systems that can dual boot Ubuntu 18.04 (4.15.0-* kernels)
> > and CentOS 6.10 (2.6.32-* kernels). The default behaviour will include the
> > options to boot with a 2.6.32 kernel with the Ubuntu root file system (this
> > really won't work!)
> >
> > I have managed to hack things (hacked 10_linux to skip centos kernels) to not
> > do this and created a grub-mkconfig helper script specificly for the CentOS
> > 6.10 kernels (it is hardwired for my systems). I also had to disable
> > os-prober, since it was just not doing anything good, including trying to set
> > up booting a VM as a bare metal O/S (!).  Hopefully, apt-get dist-upgrade will
> > behave and not screw up my settings or overwrite my hacked 10_linux script.
> >
> > I don't know if this is a bug or if my setup is just unique -- somehow I don't
> > really believe that -- I don't really believe that *I* invented the idea of a
> > separate /boot file system and multi-booting different Linux distros with a
> > shared /boot file system. A separate /boot file system is actually necessary
> > with LILO and grub 1.x when using LVM. I'm guessing with grub 2.x, you don't
> > need to do that (no it is not worth the effort to change how my disks are
> > partitioned).
> >
> > Also I found an interesting passage in the grub manual:
> >
> > " grub-mkconfig does have some limitations. While adding extra custom menu
> > entries to the end of the list can be done by editing '/etc/grub.d/40_custom'
> > or creating '/boot/grub/custom.cfg', changing the order of menu entries or
> > changing their titles may require making complex changes to shell scripts
> > stored in '/etc/grub.d/'. This may be improved in the future. In the
> > meantime, those who feel that it would be easier to write 'grub.cfg'
> > directly are encouraged to do so (see Chapter 5 [Booting], page 15, and
> > Section 6.3 [Shell-like scripting], page 25), and to disable any system
> > provided by their distribution to automatically run grub-mkconfig."
> >
> > So it seems that even the grub devs don't full trust grub-mkconfig...
> >
> >
>
> I do not know whether this applies to your scenario, but, on one of my
> systems, I have both 20.10 and 16.04.x of UbuntuMATE installed, with the
> system being originally a MS Win 8 system (it still has MS Win 8
> installed, but that is unusable, as I forgot the password for MS Win 8,
> and it was too difficult to use MS Win 8, anyway), and GRUB lets me
> select whichever of the two UbuntuMATE versions to boot, without any
> problem, and, that has applied, when the 20.10 was previous version
> numbers, going back to 18.04.
>
> On that computer, I had previously had three or four different version
> numbers of UbuntuMATE installed, and, had no problems selecting and
> booting into the different version numbers.
>
> I currently have that system running 20.10, as, whilst I prefer 16.04, I
> believe that EOL for 16.04, is due to occur in two months time, and so I
> thought it better to get used to running the stuff on that system, in
> 20.10, before 16.04 EOL.

I'm guessing that you have separate /boot directories for each version of
Linux and that all of your Linux distros use kernels >= 4.x and all are grub
2.x and are all in fact Ubuntu.  I expect that grub-mkconfig behaves properly
and creates sane, working menu entries. The default collection of helper
scripts can handle that case correctly and that my system is not being handled
properly with the base default helper scripts...

>

--
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                                                                         

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Robert Heller]

At Sun, 14 Feb 2021 16:45:32 +0100 "Ubuntu user technical support, not for general discussions" <[hidden email]> wrote:

>
> Content-Type: text/plain
>
> On Sun, 14 Feb 2021 at 16:39, Bret Busby <[hidden email]> wrote:
>
> > I currently have that system running 20.10, as, whilst I prefer 16.04, I
> > believe that EOL for 16.04, is due to occur in two months time, and so I
> > thought it better to get used to running the stuff on that system, in
> > 20.10, before 16.04 EOL.
>
> Just checking: 20.10 is not a long-term support release. 20.04 is the
> current LTS.
>
> If you just wish to avoid EOL on Xenial, then 18.04 (Bionic) might be
> an easier choice.

And the 16.04 can be upgraded to 18.04, with all of the personalizations
intact...

>

--
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                             

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Liam Proven]

On Sun, 14 Feb 2021 at 16:52, Robert Heller <[hidden email]> wrote:

> And the 16.04 can be upgraded to 18.04, with all of the personalizations
> intact...

Also true, yes.

For clarity: 16.04 can be upgraded to 20.04 but not _directly_ to
20.04 -- you always have to go to the next LTS in sequence.

Whereas 16.04 to 18.04 is a direct upgrade with no intermediate stages.

I have to say, though, that in my own experience, 18.04 -> 20.04 was
fairly painless and trouble-free. Everything worked afterwards, I just
had to go through some annoying forced reboots until GNOME stopped
trying to remind me about _every appointment in my Google Calendar in
the last 2 years_.

16.04 -> 18.04 was a pain. The upgrade failed, and I had to reboot,
fix it with `apt install -f` and `dpkg-reconfigure -a` and then it
installed all the rest of the updates. After another reboot, I had
only GNOME Shell -- Unity had been removed. I had to manually
reinstall it.

This is why I have been experimenting with the Unity remix.
Unfortunately, someone somewhere added GNOME-Shell as a dependency for
the ubuntu-unity-desktop metapackage, so currently, all Ubuntu Unity
installs have GNOME Shell _as well_. Rudra is working on it -- he has
removed GNOME Shell from the login screen, for instance, and replaced
GNOME Files with Cinnamon's Nemo file manager.

I do not know why this dependency is there. Obviously when Ubuntu
shipped Unity by default, it was the only desktop present, and Unity
machines did not have GNOME Shell installed. Why it's there now is an
annoying enigma.

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: [phone] – ČR (+ WhatsApp/Telegram/Signal): [phone]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Robert Heller]

At Sun, 14 Feb 2021 17:05:38 +0100 "Ubuntu user technical support, not for general discussions" <[hidden email]> wrote:

>
> Content-Type: text/plain
>
> On Sun, 14 Feb 2021 at 16:52, Robert Heller <[hidden email]> wrote:
>
> > And the 16.04 can be upgraded to 18.04, with all of the personalizations
> > intact...
>
> Also true, yes.
>
> For clarity: 16.04 can be upgraded to 20.04 but not _directly_ to
> 20.04 -- you always have to go to the next LTS in sequence.
>
> Whereas 16.04 to 18.04 is a direct upgrade with no intermediate stages.

I had no problem upgrading from 16.04 *server* to 18.04 -- I wanted to install
18.04 on my old box running CentOS 6.10, but it had raid (2 arrays) and lvm,
which 18.04 desktop could not handle and the 18.04 server installer barfed,
not being able to deal properly with the raid arrays (two of them). 16.04 was
able to deal properly (more or less) with my CentOS 6.10 system it is two raid
arrays.

>
> I have to say, though, that in my own experience, 18.04 -> 20.04 was
> fairly painless and trouble-free. Everything worked afterwards, I just
> had to go through some annoying forced reboots until GNOME stopped
> trying to remind me about _every appointment in my Google Calendar in
> the last 2 years_.
>
> 16.04 -> 18.04 was a pain. The upgrade failed, and I had to reboot,
> fix it with `apt install -f` and `dpkg-reconfigure -a` and then it
> installed all the rest of the updates. After another reboot, I had
> only GNOME Shell -- Unity had been removed. I had to manually
> reinstall it.
>
> This is why I have been experimenting with the Unity remix.
> Unfortunately, someone somewhere added GNOME-Shell as a dependency for
> the ubuntu-unity-desktop metapackage, so currently, all Ubuntu Unity
> installs have GNOME Shell _as well_. Rudra is working on it -- he has
> removed GNOME Shell from the login screen, for instance, and replaced
> GNOME Files with Cinnamon's Nemo file manager.
>
> I do not know why this dependency is there. Obviously when Ubuntu
> shipped Unity by default, it was the only desktop present, and Unity
> machines did not have GNOME Shell installed. Why it's there now is an
> annoying enigma.
>

--
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Tom H-4]

On Sun, Feb 14, 2021 at 4:09 PM Robert Heller <[hidden email]>
wrote:


> For what it is worth:
>
> The default setup for grub-mkconfig is somewhat "broken". It
> poorly handles the case where there is a shared /boot file system
> shared by two or more Linux distros. I have two systems that can
> dual boot Ubuntu 18.04 (4.15.0-* kernels) and CentOS 6.10
> (2.6.32-* kernels). The default behaviour will include the options
> to boot with a 2.6.32 kernel with the Ubuntu root file system (this
> really won't work!)

How's grub supposed to know which kernel belongs to which installation
is "/boot" is shared?! grub-mkconfig's not broken, your setup is. The
only way to deal with your setup would be for grub-mkconfig to check
"/etc/os-release" and use the appropriate tool, dpkg/pacman/rpm/...,
to query the package database and find out which kernels are owned by
which of the installed distros.

> Also I found an interesting passage in the grub manual:
>
> " grub-mkconfig does have some limitations. While adding extra
> custom menu entries to the end of the list can be done by editing
> '/etc/grub.d/40_custom' or creating '/boot/grub/custom.cfg',
> changing the order of menu entries or changing their titles may
> require making complex changes to shell scripts stored in
> '/etc/grub.d/'. This may be improved in the future. In the
> meantime, those who feel that it would be easier to write 'grub.cfg'
> directly are encouraged to do so (see Chapter 5 [Booting], page 15,
> and Section 6.3 [Shell-like scripting], page 25), and to disable
> any system provided by their distribution to automatically run
> grub-mkconfig."
>
> So it seems that even the grub devs don't full trust
> grub-mkconfig...

Your dislike of grub's making you misinterpret the above. The
developers are simply saying that the more that you want to customize
"/boot/grub/grub.cfg", the more complex the changes that you have to
make have to be.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Colin Watson]

On Mon, Feb 15, 2021 at 12:54:52PM +0100, Tom H wrote:

> On Sun, Feb 14, 2021 at 4:09 PM Robert Heller <[hidden email]>
> wrote:
> > Also I found an interesting passage in the grub manual:
> >
> > " grub-mkconfig does have some limitations. While adding extra
> > custom menu entries to the end of the list can be done by editing
> > '/etc/grub.d/40_custom' or creating '/boot/grub/custom.cfg',
> > changing the order of menu entries or changing their titles may
> > require making complex changes to shell scripts stored in
> > '/etc/grub.d/'. This may be improved in the future. In the
> > meantime, those who feel that it would be easier to write 'grub.cfg'
> > directly are encouraged to do so (see Chapter 5 [Booting], page 15,
> > and Section 6.3 [Shell-like scripting], page 25), and to disable
> > any system provided by their distribution to automatically run
> > grub-mkconfig."
> >
> > So it seems that even the grub devs don't full trust
> > grub-mkconfig...
>
> Your dislike of grub's making you misinterpret the above. The
> developers are simply saying that the more that you want to customize
> "/boot/grub/grub.cfg", the more complex the changes that you have to
> make have to be.

Speaking as the author of the passage quoted above (albeit most of ten
years ago), I endorse Tom's interpretation.

More generally, it's OK for tools not to cover all possible cases.
Sometimes it's better to say "if you have unusual requirements, you may
have to do unusual things" rather than contorting tools to handle
absolutely everything.  This isn't about trust, but rather about scope.

--
Colin Watson (he/him)                              [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users