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.
It appears to be technically possible to use PCMCIA cards on POWER8/9
systems through a PCI Express to PCI adapter and a PCI to
PCMCIA/CardBus adapter. But I can't believe anyone would want to.
So rather than adding a pcmcia-modules package or excluding the
drivers from udebs, disable PCMCIA altogether.
Module loading needs the issuer certificate to validate the signature,
and that certificate is not embedded in the signature itself.
For now embed both the signing certificate and the root CA.
This workaround is no longer needed for Debian's OpenJDK packages:
* OpenJDK 7 is unfixed (bug #876068) but is not present in stretch or
later suites
* OpenJDK 8 was fixed in unstable (bug #876051) and the fix was then
included in a stretch security update
* OpenJDK 9 and later were fixed (bug #876069)
The workaround was never applied upstream and it also doesn't seem
like a good idea to have a Debian-specific VM quirk that weakens the
defence against Stack Clash. Therefore drop it now rather than
including it in another release.
With this option set, module text and rodata memory areas will be made
read-only. Moreover, non-text memory will be made non-executable. This
provides protection against certain security exploits. Currently, this
option is implicitly enabled in Kconfig for most configurations where it
is possible to enable it. This commit enables the option by default
explictly for all supported targets (except marvell to keep it small)
When set, this generates crash dump after being started by kexec. Useful
for debugging purpose on ARM. As this is already enabled for other arch,
enable it for ARM, as well (except marvell to keep it small).
Nowadays, Raspberry Pi 2 and Rasberry Pi 3 works perfectly fine with
Debian (including the official kernel package or the userland). RPi 1
and RPi Zero have an SoC that contains an armv6-based CPU, this means
that it cannot work with an hardfloat ABI, that is armv7 based. So we
have to use the Debian armel userland for this reason. Both boards are
supported in the mainline linux kernel and not being supported in the
debian-kernel package is the only blocking point that prevent RPI 1 and
RPI Zero from being well supported in an official Debian distribution.
This commit add a new kernel flavour for enabling support for the both
platforms.
It is no longer possible to run the "setup" rules without a compiler,
because Kconfig symbols can depend on compiler properties. Add a way
to invoke just the first step of setup, which merges the kconfig files
and overrides together.
Ben Hutchings
Romain Perier
Alper Nebi Yasak
Aurelien Jarno
Salvatore Bonaccorso
Romain Perier
John Paul Adrian Glaubitz
Vagrant Cascadian
Luca Boccassi
Uwe Kleine-König
Bastian Blank
YunQiang Su
Stefan Fritsch
Yves-Alexis Perez
Marcin Juszkiewicz