I did a regular softrware update on my boot drive -- the SSD at /dev/sdc1 -- and got this:
Configuration file '/etc/grub.d/10_linux' ==> Deleted (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** 10_linux (Y/I/N/O/D/Z) [default=N] ?
I did "D" but have no clue as to what is right here. After looking at it for a few minutes and ending up no more enlightened than I was when I started, I kept the default. The first line of the thing is
+# grub-mkconfig helper script.
It contains things such as
+# Default to disabling partition uuid support to maintian compatibility with +# older kernels. +GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
Ought I have let it install? It seems a bad idea, but that is totally a guess. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
10_linux is complex and smart and unlikely to be changed by a user.
I can only guess: You probably accidentally touched 10_linux. You're probably MUCH better off with the new package maintainer's version.
On Thu August 19 2021 17:55:47 dep wrote:
I did a regular softrware update on my boot drive -- the SSD at /dev/sdc1 -- and got this:
Configuration file '/etc/grub.d/10_linux' ==> Deleted (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** 10_linux (Y/I/N/O/D/Z) [default=N] ?
I did "D" but have no clue as to what is right here. After looking at it for a few minutes and ending up no more enlightened than I was when I started, I kept the default. The first line of the thing is
+# grub-mkconfig helper script.
It contains things such as
+# Default to disabling partition uuid support to maintian compatibility with +# older kernels. +GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
Ought I have let it install? It seems a bad idea, but that is totally a guess. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/ ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt op.org
said Mike Bird:
| 10_linux is complex and smart and unlikely to be changed by a user. | | I can only guess: You probably accidentally touched 10_linux. | You're probably MUCH better off with the new package maintainer's | version.
In that I did the same update on the other drive, running the same version of Ubuntu, without getting the question, could I then simply copy the 10_linux from there into /etc/grub/10_linux on this drive? Or would that break things? -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Thu August 19 2021 19:58:49 dep wrote:
In that I did the same update on the other drive, running the same version of Ubuntu, without getting the question, could I then simply copy the 10_linux from there into /etc/grub/10_linux on this drive? Or would that break things?
I just did "md5sum /etc/grub.d/10_linux" on a dozen or so very different systems and they were all identical leading me to believe it is not customized per system and therefore copying it should work fine.
--Mike
said Mike Bird:
| On Thu August 19 2021 19:58:49 dep wrote: | > In that I did the same update on the other drive, running the same | > version of Ubuntu, without getting the question, could I then simply | > copy the 10_linux from there into /etc/grub/10_linux on this drive? Or | > would that break things? | | I just did "md5sum /etc/grub.d/10_linux" on a dozen or so very | different systems and they were all identical leading me to | believe it is not customized per system and therefore copying | it should work fine.
And the file doesn't exist *at all* on the drive I have booted now.
Would there be a need to rerun update-grub after copying it over, do you suppose? -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Thu August 19 2021 20:24:09 dep wrote:
And the file doesn't exist *at all* on the drive I have booted now.
Odd. I have it on laptops, desktops, servers, and virtual machines.
It's identical across i386, amd64, and multi-arch. They are all currently Debian Buster - I had been testing Bullseye but my test boxes are back to Buster until the next TDE stable ships.
Would there be a need to rerun update-grub after copying it over, do you suppose?
Good idea.
--Mike
said Mike Bird:
| I just did "md5sum /etc/grub.d/10_linux" on a dozen or so very | different systems and they were all identical leading me to | believe it is not customized per system and therefore copying | it should work fine.
The plot thickens: there *is* a file on this booted drive, /etc/grub.d/10_linux.dpkg-dist, that has the same size -- 18151 -- and timestamp as /etc/grub.d/10_linux on the other drive. Might dpkg have left it there in case I clutched my pearls, said, "What a fool I've been!" and wished to install it after all? Is this normal dpkg behavior when one decides under such circumstances to stick with the original version of something? -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Thu August 19 2021 20:34:16 dep wrote:
The plot thickens: there *is* a file on this booted drive, /etc/grub.d/10_linux.dpkg-dist, that has the same size -- 18151 -- and timestamp as /etc/grub.d/10_linux on the other drive. Might dpkg have left it there in case I clutched my pearls, said, "What a fool I've been!" and wished to install it after all? Is this normal dpkg behavior when one decides under such circumstances to stick with the original version of something?
Yep. That's exactly what happens for "config files" you choose not to accept. This is not really a config file but you can edit it so it is treated as a config file.
--Mike