Re: Debian 11 couldn't determine device type, assuming default (plain)
On Sat 29 Jan 2022 at 22:48:23 (-0800), David Christensen wrote:
> On 1/29/22 22:15, David Christensen wrote:
> > debian-user:
> >
> > I have:
> >
> > 2022-01-29 22:09:45 dpchrist@laalaa ~
> > $ cat /etc/debian_version ; uname -a
> > 11.2
> > Linux laalaa 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
> > x86_64 GNU/Linux
> >
> > It has encrypted swap (and root), created by the Debian installer.
> >
> > 2022-01-29 22:14:17 dpchrist@laalaa ~
> > $ grep sdb2 /etc/crypttab
> > sdb2_crypt /dev/disk/by-partuuid/544032f5-02 /dev/urandom
> > cipher=aes-xts-plain64,size=256,swap,discard
> >
> > When I boot and enter the root passphrase, I see the following
> > warning anywhere from two to a dozen or more times:
> >
> > cryptsetup: WARNING: sdb2_crypt: couldn't determine device type,
> > assuming default (plain)
> >
> > What is causing the warning?
> > How do I fix whatever is causing problem(s), so that no warning is
> > displayed?
>
> This appears to be the result of the Debian installer assuming that
> everyone uses suspend/ resume and the suspend image is stored in the
> swap partition.
You said that you created the random-encrypted swap in the d-i,
so I would have thought it should have known that your swap
was unusable for resume.
Or did you make either of those decisions (encryption and
randomisation) after the event? In which case, you'd be expected
to set RESUME=none yourself, in /etc/initramfs-tools/conf.d/resume.
AFAICT there's code in /usr/share/initramfs-tools/hooks/resume
to handle RESUME=none and RESUME=auto, but I don't think it can
override an explicit value. If the d-i knew already that it was
random-encrypted, I think that it's a bug to set it up.
(It's a very long time since I let the d-i itself know anything
about swap availability, so it has always written RESUME=none
while I've been encrypting swap.)
> One work-around is to edit /etc/default/grub to disable resume:
>
> GRUB_CMDLINE_LINUX="noresume"
Would RESUME=none in /etc/initramfs-tools/conf.d/resume work too?
(Remaking the initrd.img afterwards.)
> It also appears that the GRUB settings are stored in two or more
> places -- text configuration files and binary files -- and the binary
> files must be rebuilt whenever the setting change:
>
> # update-grub
> Generating grub configuration file ...
> Found background image: /usr/share/images/desktop-base/desktop-grub.png
> Found linux image: /boot/vmlinuz-5.10.0-11-amd64
> Found initrd image: /boot/initrd.img-5.10.0-11-amd64
> Found linux image: /boot/vmlinuz-5.10.0-10-amd64
> Found initrd image: /boot/initrd.img-5.10.0-10-amd64
> done
I think expressing it like that confuses the issue. /etc/default/grub
affects what grub-mkconfig puts into Grub's configuration files.
Grub never consults it when it boots the computer: it's not even
available, so they're not really "Grub settings".
The Grub configuration is built in /boot/grub/grub.cfg by
grub-mkconfig, and it's a text file, not binary (though you
could be forgiven … :) ).
And, of course, there's a third level of indirection: which
instance of /boot/grub/grub.cfg gets read when several are
available on one or more devices. That depends on the ESP,
or in your case the MBR, set up by grub-install.
The situation is less confusing with the initramfs because
its scheme employs more vocabulary:
mkinitramfs builds initrd.img using /{etc,usr/share}/initramfs-tools/,
the kernel uses the initrd.img as a filesystem. A clear distinction.
Cheers,
David.
Reply to: