[Solved] Has anyone had /etc/default/grub mysteriously disappear?

[Praxis]

Because I've had it happen on two machines. The first one I noticed was originally installed a Neptune OS https://distrowatch.com/?newsid=11892 install from Summer 2023 that I upgraded to Debian testing/trixie & removed the Neptune packages & repos at some point. I'm not concerned about that one, more fool me for installing some Debian-based variant that apparently has abominations like grub-customizer installed on it. Derivative distros are just asking for trouble, especially upgrading.

But the second installation is a pretty bog-standard Debian stable installation, albeit originally installed a longish time ago.

cat /var/log/installer/lsb-release 
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="8 (jessie) - installer build 20150422+deb8u1"
X_INSTALLATION_MEDIUM=cdrom

Old, but it is a trusty install, updated to current stable (bookworm) over the years, & I'm sure I have customized its grub plenty of times by editing /etc/default/grub. (I even have a bash alias to edit that file with vim since it is something I do often enough.) This time I went to edit the file and it was missing!
Grub was working well enough, it keeps booting the luks-encrypted system and updating the kernels. And the install never had the grub-customizer package installed on it. The OS seems to have a fairly normal assortment of grub packages installed:

dpkg -l | grep grub
ii  grub-common                                    2.06-13+deb12u1                         amd64        GRand Unified Bootloader (common files)
ii  grub-efi                                       2.06-13+deb12u1                         amd64        GRand Unified Bootloader, version 2 (dummy package)
ii  grub-efi-amd64                                 2.06-13+deb12u1                         amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin                             2.06-13+deb12u1                         amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed                          1+2.06+13+deb12u1                       amd64        GRand Unified Bootloader, version 2 (amd64 UEFI signed by Debian)
ii  grub2-common                                   2.06-13+deb12u1                         amd64        GRand Unified Bootloader (common files for version 2)
ii  grub2-splashimages                             1.0.1+nmu2                              all          a collection of great GRUB2 splashimages

That is the same assortment that is on my local Debian stable server that does have /etc/default/grub intact.

I copied the /etc/default/grub over from my server and executed "update-grub" and the operating system is now using the new file, I was able to enable & disable os-prober by editing the copied /etc/default/grub.

Warning: os-prober will be executed to detect other bootable partitions.

Warning: os-prober will not be executed to detect other bootable partitions.

Has anyone seen this weirdness before?

[sunrat]

Please use code tags for terminal text and commands etc.

No I have never lost /etc/default/grub

[Aki]

Hello @Praxis

No I have never lost /etc/default/grub

Neither did I.

Searching the Debian source code base, there doesn't seem to be any package with direct shell commands to delete it.

Are you sure you didn't delete it manually ?

Do you use third party packages or programs ? You can check with:

Code: Select all

$ apt list '?narrow(?installed, ?not(?origin(Debian)))'

[Praxis]

Aki, I didn't delete the file.

I seem to have about 248 non-Debian packages on my 9 year-old Debian stable installation, but most of these were actually installed from Debian repositories, e.g.

Code: Select all

apt-cache show hddtemp
Package: hddtemp
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 188
Maintainer: Aurelien Jarno <aurel32@debian.org>
Architecture: amd64
Version: 0.3-beta15-54
Depends: libc6 (>= 2.15), debconf (>= 0.5) | debconf-2.0, lsb-base (>= 3.0-3)
Conffiles:
 /etc/hddtemp.db e0e140cb1c90ccf5dfe847eb34f29260
 /etc/init.d/hddtemp 6db304eba5d7660b71cb9ff3d61a9b69
 /etc/logcheck/ignore.d.server/hddtemp 90bdb8807ba5aea5796629a20f58c9ef
Description: hard drive temperature monitoring utility
 The hddtemp program monitors and reports the temperature of PATA, SATA
 or SCSI hard drives by reading Self-Monitoring Analysis and Reporting
 Technology (S.M.A.R.T.) information on drives that support this feature.
Description-md5: 
Homepage: http://www.guzu.net/linux/hddtemp.php

I have a few non-Debian repositories enabled for program I like, such as signal & ubuntuzilla (for seamonkey, which I use as a simple GUI html editor), but nothing that should mess with core operating system libraries, though I do have the Debian contrib & non-free repositories enabled, so I guess there could be something in there? I had debian-multimedia.org enabled years ago, but I have long since disabled it and purged all of its packages, probably around stretch or buster, certainly before I upgraded to bullseye.

While nosing around I found this on askubuntu https://askubuntu.com/questions/774678/ ... stallation

/etc/default/grub is created by the grub-pc post-installation script. You can probably regenerate in using

dpkg-reconfigure grub-pc

although I haven't tested it.

I'll give that a throw when I get home.

If that doesn't fly I guess I can just copy my /etc/defaults/grub another testing/trixie installation to the right place on my ex-Neptune box, that seemed to work with Debian stable, though I will make sure grub-customizer is purged first, which I've done before using a tutorial I found online, why do some folks seem to think GC is a useful program? I have a buddy who uses it even though I've told him he can more reliably get all the customizations he wants from the command line without introducing a bunch of dangerous complexity, but he isn't quite as comfortable with the CLI as I am, I've been using Linux for 20 years. https://easylinuxtipsproject.blogspot.c ... mizer.html

[Praxis]

Well, FWIW I ran the dpkg-reconfigure grub-pc command and it asked me 3 questions including whether to enable os-prober, to which I answered yes. Then I ran update-grub and got:

Code: Select all

Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings 

Great. So I copied the /etc/default/grub to the correct location from another testing box and reran update-grub and it seemed to work.

Update: I restarted and grub booted my encrypted system and also gave me the choice to boot my other OS, so copying the file worked despite my not having removed grub-customizer beforehand.

On a side note, I was rather surprised to see that grub-customizer seems to be a standard Debian repository package so maybe it is better vetted than I thought. https://packages.debian.org/bookworm/grub-customizer I didn't install it, it came with Neptune. That said, when I tried to use it to enable os-prober it didn't work, grub didn't detect my other OS. That may have been because for whatever obscure reason my /etc/default/grub had gone missing.

[Aki]

Hello,

[..]
So I copied the /etc/default/grub to the correct location from another testing box and reran update-grub and it seemed to work.
[..]

I'm happy you sorted it out.

Please mark the discussione as "Solved" adding the tag "[Solved]" at the beginning of the subject of the first post.

Happy Debian.

[td211]

The only time it disappeared is when I purged "grub-pc" while keeping "grub-efi". I don't know why exactly I had "grub-pc", maybe because I installed using debootstrap.

Anyways I fixed it by reinstalling grub-efi related packages.

[Aki]

Hello @td211,

The only time it disappeared is when I purged "grub-pc" while keeping "grub-efi". I don't know why exactly I had "grub-pc", maybe because I installed using debootstrap.

Anyways I fixed it by reinstalling grub-efi related packages.

I was able to replicate what you reported above in an EFI Debian Testing installation booting with grub-efi-amd64.

The grub-pc (grub for PC/BIOS) was un-installed, but its configuration files were not purged. When I purged them with the command:

Code: Select all

sudo apt purge grub-pc

the /etc/default/grub file was deleted. But a backup file was stored in /etc/default/grub.ucf-dist. So it was possible to restore it.

Reinstalling the grub-efi-amd64 package will recreate the /etc/default/grub (unless /etc/default/grub was manually deleted).

Hope this helps.

[Alikmiankoli]

Oh sure, I’ve encountered something of the sort in the past. Well, that must be surely puzzling when files simply disappear like that or more so when they disappear from a stable operating system. It could be something like updates or it could be a package which fiddled with the grub config. Well since copying the file from another machine helped it is apparent the system only misplaced the file or an update replaced it in some way. I would also suggest that one should look at logs to determine if there was any silly package deletion or system alteration when it occurred.

[Aki]

Hello @Alikmiankoli,

Oh sure, I’ve encountered something of the sort in the past. Well, that must be surely puzzling when files simply disappear like that or more so when they disappear from a stable operating system.

What you're alleging is rather unusual, in my experience. Debian Stable is very ... stable. :D

[..] I would also suggest that one should look at logs to determine if there was any silly package deletion or system alteration when it occurred.

If you read again my previous post, it's what I have done. :wink:

[td211]

The grub-pc (grub for PC/BIOS)

That's what made it unexpected for me, my system boots from EFI so how exactly I ended up with "grub-pc" alongside "grub-efi"? I don't know (probably debootstrap or incorrect grub install command by me).

[Aki]

The grub-pc (grub for PC/BIOS)

That's what made it unexpected for me, my system boots from EFI so how exactly I ended up with "grub-pc" alongside "grub-efi"? I don't know (probably debootstrap or incorrect grub install command by me).

Probably an incorrect installation of grub-pc.

The grub-pc and grub-efi-amd64 packages cannot be installed at the same time, and there should be no reason to install grub-pc on an EFI-booting machine (unless you have changed the BIOS boot configuration from legacy to EFI). This is the description of the grub-pc package:

Code: Select all

$ apt show grub-pc
Package: grub-pc
Version: 2.06-13+deb12u1
Priority: optional
Section: admin
Source: grub2
Maintainer: GRUB Maintainers <pkg-grub-devel@alioth-lists.debian.net>
Installed-Size: 564 kB
Depends: debconf (>= 0.5) | debconf-2.0, grub-common (= 2.06-13+deb12u1), grub2-common (= 2.06-13+deb12u1), grub-pc-bin (= 2.06-13+deb12u1), ucf
Conflicts: grub (<< 0.97-54), grub-coreboot, grub-efi-amd64, grub-efi-ia32, grub-ieee1275, grub-legacy, grub-xen
Replaces: grub, grub-common (<= 1.97~beta2-1), grub-coreboot, grub-efi-amd64, grub-efi-ia32, grub-ieee1275, grub-legacy, grub2 (<< 2.06-13+deb12u1)
Homepage: https://www.gnu.org/software/grub/
Tag: admin::boot, implemented-in::c, interface::framebuffer,
 interface::shell, interface::text-mode, role::TODO, role::program
Download-Size: 137 kB
APT-Manual-Installed: yes
APT-Sources: http://localhost:3142/debian bookworm/main amd64 Packages
Description: GRand Unified Bootloader, version 2 (PC/BIOS version)
 GRUB is a portable, powerful bootloader.  This version of GRUB is based on a
 cleaner design than its predecessors, and provides the following new features:
 [..]
 This is a dependency package for a version of GRUB that has been built for
 use with the traditional PC/BIOS architecture.  Installing this package
 indicates that this version of GRUB should be the active boot loader.

[LouisR4]

I haven’t encountered this particular problem before, but it does seem like something may have deleted or cleared that file. It might be caused by the update of the system, problem with the certain package or something with grub settings has been changed during upgrade. Oh well at least you were able to copy it over from your server and get things back up and running. If it continues, perhaps looking for any automatic script, or update script that may reset the file, could be useful.