Bug#929667: debian-installer doesn't install Recommends of linux-image-*
Package: debian-installer Version: 20190410 debian-installer doesn't install the Recommends of "linux-image-*". Apparently, this is by design since [1]. The effects are: 1) For "buster", a clean install doesn't include "apparmor" and "firmware-linux-free" (both are Recommends for "linux-image-*"). This is curious, because [2] suggests "apparmor" is enabled by default, while it actually isn't. 2) A future kernel upgrade initiated by "apt" _WILL_ install the "Recommends", causing "apparmor" and "firmware-linux-free" to be installed at that stage. I think these effects are undesired. I'd suggest to use "APT::Install-Recommends true" when installing the linux image. [1] https://salsa.debian.org/installer-team/base-installer/commit/53e3722a1376c401e453d03491b8090fefd2 [2] https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#apparmor
Bug#929667: debian-installer doesn't install Recommends of linux-image-*
Control: tag -1 serious On Tue, 2019-05-28 at 10:16 +0200, Patrick wrote: > Package: debian-installer > Version: 20190410 > > debian-installer doesn't install the Recommends of "linux-image-*". > Apparently, this is by design since [1]. > > The effects are: > 1) For "buster", a clean install doesn't include "apparmor" and > "firmware-linux-free" (both are Recommends for "linux-image-*"). This > is curious, because [2] suggests "apparmor" is enabled by default, > while it actually isn't. > 2) A future kernel upgrade initiated by "apt" _WILL_ install the > "Recommends", causing "apparmor" and "firmware-linux-free" to be > installed at that stage. There has (effectively) been a change in APT's behaviour since that earlier commit. "apt-get upgrade" does not install new packages unless you use the --with-new-pkgs option. However, the newer "apt upgrade" command does install new dependencies and recommendations. Because security upgrades sometimes introduce ABI changes and new binary packages, we now recommend use of either "apt-get upgrade --with-new-pkgs" or "apt upgrade" for all upgrades, and since last year the installer uses the former. > I think these effects are undesired. I'd suggest to use > "APT::Install-Recommends true" when installing the linux image. I agree that it's a serious problem that AppArmor may only be properly enabled later, and I'm upgrading the severity accordingly. I think that for at least the kernel installation, APT::Install-Recommends should be set to the same value it will have in the installed system, i.e. dependent on base-installer/install- recommends. However, I think we should revert this commit entirely. The current default behaviour is that *any* security update or other stable update will cause the installation of its recommendations where they weren't installed before, and that is likely to be quite surprising. Ben. > [1] > https://salsa.debian.org/installer-team/base-installer/commit/53e3722a1376c401e453d03491b8090fefd2 > [2] > https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#apparmor > -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Processed: severity of 929667 is serious
Processing commands for cont...@bugs.debian.org: > severity 929667 serious Bug #929667 [debian-installer] debian-installer doesn't install Recommends of linux-image-* Severity set to 'serious' from 'normal' > thanks Stopping processing here. Please contact me if you need assistance. -- 929667: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929667 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
can't unlock disk on reboot after clean install
Hello: I installed Debian 10 RC1 in a QEMU/KVM virtual machine on my Fedora 29 laptop using 'Virtual Machine Manager' -- I overwrote a previously-working Debian 9 test VM. I installed from debian-buster-DI-rc1-amd64-netinst.iso. I chose the first listed kernel (which had a number defining it, 4.18.something, not the second choice which had no numerical designation). I used the partitioner and accepted defaults to create encrypted LVM setup (boot is not encrypted, only / and swap on the encrypted LVM). After finishing the install I rebooted the newly-installed system which shows grub and boots to the prompt to unlock the disk -- but it will not unlock. If I drop to a shell I can test the keyboard map is correct -- I'm typing the right characters. If I boot gparted-live ISO I am able to unlock the encrypted disk that the Debian 10 RC1 installer created using the expected password! Is there any test you'd like me to try? Or more info I can provide? I am doubting myself because clearly many people would have tested this scenario -- yet it does not seem to be a known issue.
