On Wed 03 Feb 2021 at 15:56:58 (-0500), Greg Wooledge wrote:
> On Wed, Feb 03, 2021 at 02:06:04PM -0600, David Wright wrote:
> > >From foo/main/init where foo is
> > $ unmkinitramfs /boot/initrd.img foo/
>
> Interesting.... I used locate --regex to find where this is coming
> from, and it seems there's a copy in /usr/share/initramfs-tools/init
> which I'm guessing is what gets installed as init inside the initrd.
>
> /usr/share/initramfs-tools/init is from the initramfs-tools-core
> package which appears to come from Debian itself (according to
> the copyright file), having been forked from Ubuntu's version.
>
> A google search for "linux fsck.mode=force" led me indirectly to the
> systemd-fsck man page. This one tells me that fsck.mode= is an option
> supported by systemd-fsck with the values auto, force or skip. Debian's
> /usr/share/initramfs-tools/init script appears to be using a superset
> of these values, including your forcefsck alias.
>
> Putting these clues all together is tricky for me because nothing is
> really spelled out clearly. Near as I can manage to guess, Debian's
> initrd init script parses the kernel command line and looks for these
> fsck-ish options, applies them during the initrd stage, and then...
> then, I don't know what happens.
>
> There is still no clear end-user-comprehensible documentation that says
> how to make fsck happen on the next boot.
The first ~43 lines of grub.cfg juggles with the contexts of grubenv.
foo/main/init pulls in foo/main/scripts/{functions,local}. The former
contains _checkfs_once which translates the forcefsck words etc into
options for fsck. The latter mounts local filesystems, calling checkfs.
> > > What is the "normal mechanism"? Where is it documented?
> >
> > https://www.gnu.org/software/grub/manual/grub/grub.html
>
> (I told you guys how my email is being mangled....)
>
> > I'm guessing the comment is a signature. §15.2 outlines the grubenv
> > method. As Stefan mentioned, grubenv is designed to remain static,
> > and grub-editenv carefully alters its contents. Configuring Grub
> > uses /etc/grub.d/00_header and the variables in /etc/default/grub to
> > write the code at the top of /boot/grub/grub.cfg for juggling the
> > boot selection.
> >
> > You start all this off by editing /etc/default/grub: GRUB_DEFAULT=0 →
> > GRUB_DEFAULT=saved and running grub-set-default 0. Then:
> >
> > $ head -c 72 /boot/grub/grubenv ; echo
> > # GRUB Environment Block
> > saved_entry=0
> > #################################
> > $
> >
> > # grub-reboot 'fsck>fsck'
>
> At this point I give up. I don't know where this "fsck>fsck" argument
> comes from or how you use it. It's definitely not in the grub-reboot
> man page.
That's my implementation, my choice. My grub.cfg postprocessing script
turns:
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-f3bf6eef-3c26-4070-b180-fd1914377253' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-14-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-4.19.0-14-amd64-advanced-f3bf6eef-3c26-4070-b180-fd1914377253' {
[…]
linux /boot/vmlinuz-4.19.0-14-amd64
root=UUID=f3bf6eef-3c26-4070-b180-fd1914377253 ro systemd.show_status=true
quiet
into:
submenu 'Advanced options' $menuentry_id_option 'fsck' {
menuentry 'FSCK Debian 4.19.0-14-amd64 FSCK' --class debian --class
gnu-linux --class gnu --class os $menuentry_id_option 'fsck' {
[…]
linux /boot/vmlinuz-4.19.0-14-amd64 root=LABEL=toto04 ro
systemd.show_status=true quiet forcefsck
The 'FSCK … FSCK' labelling is for visibility when using Grub
interactively; the two 'fsck' labels match the invocation
grub-reboot 'fsck>fsck' when using the grubenv mechanism.
1024 characters in grubenv is ample to hold two or three of
the tediously long default labels, but I choose to use
shorter, more meaningful ones.
BTW there was some dispute over whether the > operator worked
in handling these nested menuentries. I've seen no actual
evidence presented, having regularly used them in grub-reboot,
and tested them with grub-set-default. No follow-ups to
https://lists.debian.org/debian-user/2020/12/msg00641.html
Cheers,
David.
