On Samsung Chromebook Plus (v1) trying to boot from a rootfs on a USB
storage device without these modules in the initramfs, it drops to an
initramfs shell with a non-working display. For the d-i netboot image,
the screen doesn't turn on, but the installer menu works.
A recent change to initramfs-tools includes extcon-usbc-cros-ec, so
include that and a relevant PHY module here as well.
Relevant:
https://salsa.debian.org/kernel-team/initramfs-tools/commit/994d698a
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
On some ChromeOS devices, this is required to connect to a wireless
network via mwifiex_pcie.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The cros_ec multifunction device provides the keyboard services on some
ChromeOS devices, but requires a bus to be enabled to communicate with
it. On Samsung Chromebook Plus (v1), including spi-rockchip and
cros_ec_spi are enough. A recent change in initramfs-tools included all
SPI drivers, so include them here as well.
Relevant:
https://salsa.debian.org/kernel-team/initramfs-tools/commit/797e5fed
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Some important modules like cros_ec_keyb are in input/keyboard. A recent
change in initramfs-tools also includes them, so include them here too.
Relevant:
https://salsa.debian.org/kernel-team/initramfs-tools/commit/40f66474
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Debian policy says the package name must change when the soname
changes. We don't expect the ABI to change in a stable update,
so use only 2 components in both.
It's not necessary to delete the definitions of the variables that
become unused. Nor is it necessary to move the definition of
LIBBPF_VERSION before LIB_FILES, because the latter is defined
as recursively expanded (i.e. its variable references are not
immediately expanded).
This makes the actual change we're making clearer, and should
reduce the future work to maintain this patch.
Import patches from:
https://lore.kernel.org/patchwork/cover/933178/
that allow to also load dbx and MOKX as blacklists for modules.
These patches also disable loading MOK/MOKX when secure boot is
not enabled, as the variables will not be safe, and to check the
variables attributes before accepting them.
Import patches from:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-uefi
that enable a new option that automatically loads keys from db
and MOK into the secondary keyring, so that they can be used to
verify the signature of kernel modules. Enable the required KCONFIGs.
Allows users to self-sign modules (eg: dkms).
With this option enabled, the kernel will be able to retrieve firmware
logs by looking in the coreboot table. This can be accessed from
userspace via the sysfs file /sys/firmware/log.
Requested by John Paul Adrian Glaubitz, with the explanation:
> GRUB doesn't really support compressed kernels with OpenFirmware, at
> least on SPARC. It used to work with 2.02+patches but it doesn't
> work with GRUB 2.04~rc1 and upstream said that it's not really
> supported.
The "recommends" field set in the [image] section for these
configurations overrode the field at the top level. We want
gencontrol.py to concatenate the relations in this section at all
levels.
The ConfigCore.get_merge method supports doing this, but only with
list fields So we need to specify in the config schema that these
fields are comma-separated lists.
We were building the omap-rng driver, because the same block is used
on some recent Marvell chips and HW_RANDOM_OMAP is enabled by default
if ARCH_MVEBU is enabled.
We were also building virtio-rng, but there isn't (so far as I know)
any publicly available emulation of the ARMv5 Marvell chips.
As we're about to include HWRNG drivers to the installer, disable the
whole subsystem for armel/marvell to avoid adding useless drivers.
Closes: #785065
This finally removes the need for the ppc64el compiler to support
32-bit code generation, and removes a useless file from debug
packages on ppc64el.
Since we don't use the Release and Packages files to verify the
packages we download, it's worth using TLS to reduce the risk of
a man-in-the-middle corrupting them.
ftp.ports.debian.org and security.debian.org don't support TLS
in general, so use deb.debian.org for the ports and security
archives.
If the changelog distribution is *-security, fetch from the security
archive. Otherwise, try the main archive, ports, incoming, and
incoming.ports in that order.