Bug#1034159: Kernel support for more ChromeOS devices
Hi, I'd hope "during a mini-DebCamp at ARM" is the perfect time to poke you about kernel support for more ARM platforms? On 2023-10-15 16:30 +03:00, Alper Nebi Yasak wrote: > I'll also look into configs needed for ARM Chromebooks in more detail, > but that'll take more time because more things were already-enabled on > the x86 side compared to the ARM side. I've got things mostly working on some MediaTek Chromebooks and filed some merge requests for linux and initramfs-tools, more details at [3]. Please take a look. I have also written up a "dts2config" script inspired by another script Diederik used to analyze RK3588 platforms' dts files for related config options. The script and short / long results for all dts files are available at [3] attached to a comment. I hope they will be useful in enabling support for more hardware. With that, I generated some short lists of config options per SoC, based on device-tree "compatible" strings in ChromeOS boards' dts' for that SoC. Attaching those as a tarball here. It would be nice if you enabled those that aren't enabled yet, but I don't expect that will happen before I can get those tested on actual hardware... [3] [arm64] Enable configs for MediaTek MT8173 and MT8183 Chromebooks https://salsa.debian.org/kernel-team/linux/-/merge_requests/906 P.S.: I'd also appreciate you looking at my x86 ChromeOS configs MR: https://salsa.debian.org/kernel-team/linux/-/merge_requests/768 cros-configs-per-soc.tar.xz Description: application/xz
Bug#1034159: Kernel support for more ChromeOS devices
Control: severity -1 important On 2023-04-10 15:52 +03:00, Alper Nebi Yasak wrote: > Source: linux > Version: 6.1.20-2 > Severity: wishlist I had this as wishlist because I didn't have that much time to work on it until the release. But hardware support is "severity: important". > I've been going through ChromiumOS kernel configs [1] in hope that I > could reach a reasonable list of things to enable for hardware support > for more chromebooks. What I did is roughly: > > - Prepend base.config, /common.config to /*.flavour.config > - Run "make olddefconfig" then "make savedefconfig" for each flavour > - Run "scripts/diffconfig" vs Debian's _none configs > - Filter to only have new non-n values, and n->[ym] changes > - Merge per-flavour changes into one file per arch > - Filter out configs that I guess aren't hardware-related > - Convert them into CONFIG=[ym] form, as many into =m as I could > > I'm attaching what I got so far, but they are still huge (66/112/258 > configs for arm/x86/arm64). I didn't have time to drill down into how > much of this is really useful or which devices need which configs. I'll > try to file per-chromebook MRs as I figure things out. > > Not sure what I can get done in time for bookworm (fearing that it's > probably already too late). It would be nice if you could have a look > and pick whatever ones make sense to include at this stage. > > [1] ChromiumOS kernel configuration sources > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-6.1/chromeos/config/chromeos/ I have a merge request on salsa for x86 Chromebooks that has been open for a while [2]. Please have a look. If you feel it'd be less work to just do the changes yourself better than my attempt at it, please go ahead. As I just commented on that MR: Chromebook user groups are distributing ad-hoc custom kernel builds just because these aren't enabled in Debian proper. I'd also like to get these enabled in stable after this, so people can stop doing FrankenDebians for essential hardware support like audio drivers. I'll also look into configs needed for ARM Chromebooks in more detail, but that'll take more time because more things were already-enabled on the x86 side compared to the ARM side. [2] [x86] Various drivers for ChromeOS devices https://salsa.debian.org/kernel-team/linux/-/merge_requests/768
Bug#1052374: gdm3: Shows only an error screen when gnome.session is missing
On 2023-09-21 13:39 +03:00, Simon McVittie wrote: > On Thu, 21 Sep 2023 at 11:17:51 +0100, Simon McVittie wrote: >> On Thu, 21 Sep 2023 at 09:41:25 +0300, Alper Nebi Yasak wrote: >>> I've been using gdm3 without GNOME, and after recently upgrading gdm3 to >>> 45~beta-1 I started getting the gray "Oh no!" error message instead of >>> the login screen. >> >> Please look in the system log (systemd Journal) for the error messages >> that occur at this time, and send it to the bug address. Knowing only >> "it crashed" does not give us much information, and in particular, if we >> can reproduce a crash with gdm but not GNOME, it does not give us enough >> information to know that we have really reproduced the same crash you see. > > I can reproduce something similar in a test VM after > `apt install --no-install-recommends xorg openbox gdm3`, does the attached > match what you see? I had tried `journalctl -u gdm3` and `dmesg` but those were not very informative... Didn't think of `journalctl -b`, sorry. It's similar to your logs, attached for the record. More specifically, I do have "gsettings[1650]: unable to open named profile (Debian-gdm): using the null configuration." which seems to match what you fixed (per the changelog). Anyway, I built 45.0.1-1 locally and can confirm it fixes this error screen, thanks! journalctl-xb.log.gz Description: application/gzip
Bug#1052374: gdm3: Shows only an error screen when gnome.session is missing
Package: gdm3 Version: 45~beta-1 Severity: serious Justification: missing dependency to function properly Control: -1 notfound 44.1-2 Dear Maintainer, I've been using gdm3 without GNOME, and after recently upgrading gdm3 to 45~beta-1 I started getting the gray "Oh no!" error message instead of the login screen. Tried a few things and found installing the gnome-session package fixes it. Copying /usr/share/gnome-session/sessions/gnome-login.session to .../gnome.session also fixes it. Looks like #850291, but that is archived and I don't know the Control invocations I need to continue on top of that. Setting severity same as that, though. Thanks for all the work on GNOME. My system is a bit of a mess, so don't hesitate to ask specifics if you can't reproduce the error. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf, armel, i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 23.13.9-4 ii adduser 3.137 ii dbus [default-dbus-system-bus]1.14.10-1 ii dbus-bin 1.14.10-1 ii dbus-daemon 1.14.10-1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii gir1.2-gdm-1.045~beta-1 ii gnome-session [x-session-manager] 45.0-1 ii gnome-session-bin 45.0-1 ii gnome-session-common 45.0-1 ii gnome-settings-daemon 45.0-1 ii gnome-shell 44.5-1 ii gnome-terminal [x-terminal-emulator] 3.50.0-1 ii gsettings-desktop-schemas 45.0-1 ii kwin-x11 [x-window-manager] 4:5.27.8-1 ii libaccountsservice0 23.13.9-4 ii libaudit1 1:3.1.1-1 ii libc6 2.37-10 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 45~beta-1 ii libglib2.0-0 2.78.0-2 ii libglib2.0-bin2.78.0-2 ii libgtk-3-03.24.38-5 ii libgudev-1.0-0238-2 ii libkeyutils1 1.6.3-2 ii libpam-modules1.5.2-7 ii libpam-runtime1.5.2-7 ii libpam-systemd [logind] 254.3-1 ii libpam0g 1.5.2-7 ii librsvg2-common 2.54.7+dfsg-2 ii libselinux1 3.5-1 ii libsystemd0 254.3-1 ii libx11-6 2:1.8.6-1 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii lxterminal [x-terminal-emulator] 0.4.0-2 ii metacity [x-window-manager] 1:3.49.1-1 ii polkitd 123-1 ii procps2:4.0.3-1 ii qterminal [x-terminal-emulator] 1.3.0-1 ii rxvt-unicode [x-terminal-emulator]9.31-1 ii systemd-sysv 254.3-1 ii ucf 3.0043+nmu1 ii x11-common1:7.7+23 ii x11-xserver-utils 7.7+9+b1 ii xfce4-session [x-session-manager] 4.18.3-1 ii xfce4-terminal [x-terminal-emulator] 1.1.0-1 ii xfwm4 [x-window-manager] 4.18.0-1 ii xterm [x-terminal-emulator] 384-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.50.0-1 ii desktop-base 12.0.6+nmu1 ii gnome-session [x-session-manager] 45.0-1 ii x11-xkb-utils 7.7+7 ii xfce4-session [x-session-manager] 4.18.3-1 ii xserver-xephyr 2:21.1.8-1 ii xserver-xorg 1:7.7+23 ii zenity 3.44.2-1 Versions of packages gdm3 suggests: pn libpam-fprintd ii libpam-gnome-keyring 42.1-1+b2 pn libpam-pkcs11 pn libpam-sss ii orca 45.0-1 -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3
Bug#1041859: qemu-user-static: Segfault when running armhf python3 in chroot
Package: qemu-user-static Version: 1:8.0.3+dfsg-3 Severity: normal Control: found -1 1:8.0.3+dfsg-2 Dear QEMU maintainers, I've recently noticed my armhf development chroot fails to upgrade python3-minimal. I've tracked it down to a segmentation fault when running python3 (for py3compile) as part of the package postinst. Should be possible to reproduce with something like: $ sudo sbuild-createchroot \ --include=gnupg --arch=armhf --chroot-suffix="-test" \ unstable /srv/chroot/unstable-armhf-test \ http://deb.debian.org/debian $ sudo schroot -c unstable-armhf-test -u root -d /root -- \ apt install -y python3-minimal [...] Setting up python3.11-minimal (3.11.4-1) ... qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault dpkg: error processing package python3.11-minimal (--configure): installed python3.11-minimal package post-installation script subprocess returned error exit status 139 Errors were encountered while processing: python3.11-minimal E: Sub-process /usr/bin/dpkg returned an error code (1) Downgrading qemu-user and qemu-user-static to 1:8.0.3+dfsg-1 makes things work again. It also fails with 1:8.0.3+dfsg-2. I see a bug #1040981 about segfaults in klibc-utils which might be related, but I don't understand much of the discussion at first glance. Apparently version 1:8.0.3+dfsg-2 fixes that but breaks this. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf, armel, i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii systemd 254~rc2-3 qemu-user-static suggests no packages. Versions of packages qemu-user depends on: ii libc6 2.37-6 ii libcapstone4 4.0.2-5 ii libgcc-s1 13.1.0-9 ii libglib2.0-0 2.76.4-4 ii libgnutls30 3.7.9-2 ii libnuma1 2.0.16-1 ii liburing2 2.4-1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages qemu-user recommends: ii qemu-user-static [qemu-user-binfmt] 1:8.0.3+dfsg-3 qemu-user suggests no packages. -- no debconf information
Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive
Package: thunderbird Version: 1:115.0-1 Severity: important X-Debbugs-CC: d...@fifthhorseman.net Dear Maintainer, I decided to upgrade Thunderbird to the version in experimental, and noticed that its OpenPGP functionality is completely broken: the Key Manager is empty, and it doesn't even attempt to decrypt/verify encrypted/signed messages (at least over external gnupg). The "Troubleshooting Information" page says the expected minimum version for the RNP library is 0.17.0, where I had 0.16.3-1 installed as currently in unstable. Seeing a 0.17.0~git20220428-1 version for librnp0 in experimental, I tried installing that. But that doesn't work either, apparently its source is older than 0.16.1? (Also see bug #1031363). So I think Thunderbird needs to depend on librnp0 >= 0.17.0 (currently unversioned), but no such version is in Debian yet. I got it to work by sloppily packaging the newer source. (The proper package may take a bit, has a new dependency apparently in NEW -- I'm CC-ing the maintainer.) Thanks! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf, armel, i386 Kernel: Linux 6.4.0-0-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 5.8-1 ii fontconfig 2.14.1-4 ii libasound2 1.2.9-1 ii libatk1.0-0 2.48.3-1 ii libc62.37-6 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libdbus-1-3 1.14.8-2 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.13.0+dfsg-1 ii libgcc-s113.1.0-8 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.91-1 ii libotr5 4.1.1-5 ii libpango-1.0-0 1.50.14+ds-1 ii librnp0 0.17.0-1~1.gbp1d03e6 ii libstdc++6 13.1.0-8 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.6-1 ii libx11-xcb1 2:1.8.6-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxext6 2:1.3.4-1+b1 ii libxrandr2 2:1.5.2-2+b1 ii psmisc 23.6-1 ii x11-utils7.7+5 ii zenity 3.44.0-3 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-en-gb [hunspell-dictionary] 1:7.5.0-1 ii hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2 Versions of packages thunderbird suggests: ii apparmor 3.0.8-3 ii fonts-lyx 2.3.7-1 ii libgssapi-krb5-2 1.20.1-2 -- no debconf information
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
On 01/06/2023 16:27, Emanuele Rocca wrote: > Hi again, > > On 2023-05-31 05:46, Samuel Thibault wrote: >> The problem is that both are frown-prone. I guess there is a reason why >> on arm the default console is set to the serial port, e.g. for simpler >> debugging or something like that. > > Also worth mentioning: there is no bug on real hardware (eg: RPi 3B+). > > So far I think we've only heard about people getting this issue with > qemu. I've had this problem on my chromebook (rk3399-gru-kevin) since forever. I don't know what's best here, but wanted to provide more context in case it helps. Thank you all for working on it. There's actually two different things that can make Linux set a serial port as the preferred console on arm64 systems: - An SPCR table on devices using ACPI - A /chosen stdout-path property on devices using device-tree I had once tried to change it on the kernel side, going through that email thread [1] might make the how-and-why clearer. (I've silently given up on that series) Furthermore, the same thing happens in the installed system as well, which will ask for your encryption password over a serial console that you have no access to [2] unless you have ended up installing plymouth transitively through a desktop environment. Adding console=tty0 would persist into the installed system and fix that, so I'm used to doing that as a workaround on my own systems. But that disables the serial console on device-tree systems, so doing it by default is a problem for SBCs etc. where people might genuinely be trying to install over serial. (I'd still like it for "Graphical Install" entries [3], but that's orthogonal to this). [1] Prefer working VT console over SPCR and device-tree stdout-path https://lore.kernel.org/lkml/20200513143755.GM17734@linux-b0ei/ [2] initramfs-tools: prefers serial console over framebuffer console https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952452 [3] arm64 graphical installer fixes merge request https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/17
Bug#1035375: mtools: interprets SOURCE_DATE_EPOCH in system timezone instead of UTC
Package: mtools
Version: 4.0.33-1+really4.0.32-1
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
I came across timestamp differences in FAT filesystem images while
trying to build debian-installer with debrepro (among many other
things), and tracked it down to mmd/mcopy calls. Here's a short reproducer:
export SOURCE_DATE_EPOCH="$(date "+%s")"
imgprep() {
[ -f "$1" ] && rm "$1"
mkfs.msdos --invariant -v -i deb1 -C "$1" 512
mmd -i "$1" ::foo
mcopy -i "$1" "$2" ::bar
}
dd if=/dev/random of=rand.img bs=512 count=200
TZ=UTC imgprep first.img rand.img
TZ=UTC-3 imgprep second.img rand.img
diffoscope first.img second.img
which shows an exact 3-hour difference in timestamps for me. AFAICT,
SOURCE_DATE_EPOCH is meant to be in UTC, so embedded timestamps and the
two files should be the same regardless of TZ or system timezone.
Bug#1034159: Kernel support for more ChromeOS devices
Source: linux Version: 6.1.20-2 Severity: wishlist Hi, I've been going through ChromiumOS kernel configs [1] in hope that I could reach a reasonable list of things to enable for hardware support for more chromebooks. What I did is roughly: - Prepend base.config, /common.config to /*.flavour.config - Run "make olddefconfig" then "make savedefconfig" for each flavour - Run "scripts/diffconfig" vs Debian's _none configs - Filter to only have new non-n values, and n->[ym] changes - Merge per-flavour changes into one file per arch - Filter out configs that I guess aren't hardware-related - Convert them into CONFIG=[ym] form, as many into =m as I could I'm attaching what I got so far, but they are still huge (66/112/258 configs for arm/x86/arm64). I didn't have time to drill down into how much of this is really useful or which devices need which configs. I'll try to file per-chromebook MRs as I figure things out. Not sure what I can get done in time for bookworm (fearing that it's probably already too late). It would be nice if you could have a look and pick whatever ones make sense to include at this stage. [1] ChromiumOS kernel configuration sources https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-6.1/chromeos/config/chromeos/CONFIG_ARCH_TEGRA_114_SOC=y CONFIG_ARCH_TEGRA_2x_SOC=y CONFIG_ARCH_TEGRA_3x_SOC=y CONFIG_ARM_ERRATA_818325_852422=y CONFIG_ARM_ERRATA_821420=y CONFIG_ARM_ERRATA_825619=y CONFIG_ARM_ERRATA_857271=y CONFIG_BATTERY_BQ27XXX_I2C=m CONFIG_BT_AOSPEXT=y CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m CONFIG_BT_MSFTEXT=y CONFIG_CHARGER_BQ24735=m CONFIG_CHARGER_CROS_PCHG=m CONFIG_CHARGER_TPS65090=m CONFIG_CROS_EC_CHARDEV=m CONFIG_CROS_EC_LIGHTBAR=m CONFIG_CROS_EC_SENSORHUB=m CONFIG_CROS_EC_SYSFS=m CONFIG_CROS_USBPD_NOTIFY=m CONFIG_DAX=m CONFIG_GPIO_TPS6586X=y CONFIG_HW_RANDOM_TPM=y CONFIG_I2C_HID_OF=m CONFIG_I2C_STUB=m CONFIG_IIO_CONFIGFS=m CONFIG_IIO_CROS_EC_ACCEL_LEGACY=m CONFIG_IIO_CROS_EC_SENSORS_CORE=m CONFIG_IIO_HRTIMER_TRIGGER=m CONFIG_IIO_SW_TRIGGER=m CONFIG_IIO_SYSFS_TRIGGER=m CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=m CONFIG_JOYSTICK_XPAD_FF=y CONFIG_JOYSTICK_XPAD_LEDS=y CONFIG_JOYSTICK_XPAD=m CONFIG_KEYBOARD_GPIO_POLLED=m CONFIG_KEYBOARD_NVEC=m CONFIG_MFD_CROS_EC_DEV=m CONFIG_MFD_NVEC=m CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS6586X=y CONFIG_MOUSE_CYAPA=m CONFIG_MWIFIEX=m CONFIG_MWIFIEX_SDIO=m CONFIG_NET_VENDOR_ARC=y CONFIG_NET_VENDOR_SEEQ=y CONFIG_NVEC_PAZ00=m CONFIG_NVEC_POWER=m CONFIG_REGULATOR_PWM=m CONFIG_REGULATOR_TPS51632=m CONFIG_REGULATOR_TPS62360=m CONFIG_REGULATOR_TPS65090=m CONFIG_REGULATOR_TPS6586X=m CONFIG_ROCKCHIP_INNO_HDMI=y CONFIG_RT2800USB_UNKNOWN=y CONFIG_SENSORS_LM90=m CONFIG_SOC_TEGRA20_VOLTAGE_COUPLER=y CONFIG_SOC_TEGRA30_VOLTAGE_COUPLER=y CONFIG_TCG_TIS_I2C_INFINEON=m CONFIG_TEGRA20_EMC=m CONFIG_TEGRA30_EMC=m CONFIG_TEGRA_IOMMU_GART=y CONFIG_TOUCHSCREEN_ELAN=m CONFIG_USB_MASS_STORAGE=m CONFIG_ARCH_MEDIATEK=y CONFIG_ARM_MEDIATEK_CCI_DEVFREQ=m CONFIG_ARM_MEDIATEK_CPUFREQ=m CONFIG_ARM_MEDIATEK_CPUFREQ_HW=m CONFIG_ARM_SMC_WATCHDOG=m CONFIG_ATH10K_SDIO=m CONFIG_ATH10K_SNOC=m CONFIG_ATH11K_AHB=m CONFIG_BT_AOSPEXT=y CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m CONFIG_BT_MSFTEXT=y CONFIG_BT_MTKSDIO=m CONFIG_COMMON_CLK_MT6765=y CONFIG_COMMON_CLK_MT6779=m CONFIG_COMMON_CLK_MT6795=m CONFIG_COMMON_CLK_MT6795_MFGCFG=m CONFIG_COMMON_CLK_MT6795_MMSYS=m CONFIG_COMMON_CLK_MT6795_VDECSYS=m CONFIG_COMMON_CLK_MT6795_VENCSYS=m CONFIG_COMMON_CLK_MT7622=y CONFIG_COMMON_CLK_MT7986=y CONFIG_COMMON_CLK_MT7986_ETHSYS=y CONFIG_COMMON_CLK_MT8167=y CONFIG_COMMON_CLK_MT8167_AUDSYS=y CONFIG_COMMON_CLK_MT8167_IMGSYS=y CONFIG_COMMON_CLK_MT8167_MFGCFG=y CONFIG_COMMON_CLK_MT8167_MMSYS=y CONFIG_COMMON_CLK_MT8167_VDECSYS=y CONFIG_COMMON_CLK_MT8173=y CONFIG_COMMON_CLK_MT8173_MMSYS=y CONFIG_COMMON_CLK_MT8183=y CONFIG_COMMON_CLK_MT8183_AUDIOSYS=y CONFIG_COMMON_CLK_MT8183_CAMSYS=y CONFIG_COMMON_CLK_MT8183_IMGSYS=y CONFIG_COMMON_CLK_MT8183_IPU_ADL=y CONFIG_COMMON_CLK_MT8183_IPU_CONN=y CONFIG_COMMON_CLK_MT8183_IPU_CORE0=y CONFIG_COMMON_CLK_MT8183_IPU_CORE1=y CONFIG_COMMON_CLK_MT8183_MFGCFG=y CONFIG_COMMON_CLK_MT8183_MMSYS=y CONFIG_COMMON_CLK_MT8183_VDECSYS=y CONFIG_COMMON_CLK_MT8183_VENCSYS=y CONFIG_COMMON_CLK_MT8186=y CONFIG_COMMON_CLK_MT8192=y CONFIG_COMMON_CLK_MT8195=y CONFIG_COMMON_CLK_MT8365=m CONFIG_COMMON_CLK_MT8365_APU=m CONFIG_COMMON_CLK_MT8365_CAM=m CONFIG_COMMON_CLK_MT8365_MFG=m CONFIG_COMMON_CLK_MT8365_MMSYS=m CONFIG_COMMON_CLK_MT8365_VDEC=m CONFIG_COMMON_CLK_MT8365_VENC=m CONFIG_COMMON_CLK_MT8516=y CONFIG_COMMON_CLK_PALMAS=m CONFIG_CROS_EC_MKBP_PROXIMITY=m CONFIG_CROS_EC_RPMSG=m CONFIG_DRM_ANALOGIX_ANX7625=m CONFIG_DRM_ANALOGIX_ANX78XX=m CONFIG_DRM_ITE_IT6505=m CONFIG_DRM_MEDIATEK=m CONFIG_DRM_MEDIATEK_HDMI=m CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m CONFIG_DRM_PANEL_INNOLUX_P079ZCA=m CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04=m CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=m CONFIG_DRM_PANEL_VISIONOX_RM69299=m CONFIG_DRM_PARADE_PS8640=m
Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
On 31/10/2022 00:52, Jérémy Lal wrote: > Le dim. 30 oct. 2022 à 22:42, Jérémy Lal a écrit : >> Everything seems to be fine with your package. >> It builds fine, is lintian-clean, copyright is ok, and best practices are >> observed. >> >> Since it's a python program, it would make more sense to team-maintain it >> in the python-team group. >> I cloned your repo to >> https://salsa.debian.org/python-team/packages/depthcharge-tools >> >> Now you need to request write access (developer role) to that repository. >> Please have a look at https://wiki.debian.org/Teams/PythonTeam/HowToJoin >> >> After that, debian/control should be modified to be: >> Maintainer: Alper Nebi Yasak >> , Debian Python Team >> Vcs-Browser: >> https://salsa.debian.org/python-team/packages/depthcharge-tools >> Vcs-Git: >> https://salsa.debian.org/python-team/packages/depthcharge-tools.git >> > > Also since python-team admins are busy, I've took the liberty to make the > changes, > slightly differently (see > https://salsa.debian.org/python-team/packages/depthcharge-tools), > and I uploaded your package to NEW. Thanks! I sent an email to the debian-python list just now about joining the Python team. I agree with your changes and points above, but didn't want to put the team as Maintainer before getting an OK from them.
Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: Jérémy Lal X-Debbugs-Cc: Hans-Cristoph Steiner X-Debbugs-Cc: debian-pyt...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "depthcharge-tools": * Package name : depthcharge-tools Version : 0.6.0-1 Upstream contact : Alper Nebi Yasak * URL : https://github.com/alpernebbi/depthcharge-tools * License : GPL-2+ * Vcs : https://salsa.debian.org/alpernebbi/depthcharge-tools Section : admin The source builds the following binary packages: depthcharge-tools - Tools for ChromeOS firmware/bootloader integration To access further information about this package, please visit the following URL: https://mentors.debian.net/package/depthcharge-tools/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/depthcharge-tools/depthcharge-tools_0.6.0-1.dsc Changes for the initial release: depthcharge-tools (0.6.0-1) unstable; urgency=medium . * Initial release. (Closes: #950687) Regards, -- Alper Nebi Yasak
Bug#950687: ITP: depthcharge-tools -- Tools to manage the Chrome OS bootloader
On 29/08/2022 16:35, Jérémy Lal wrote: > Hi, > now that I have three c201 chromebooks running debian/bookworm > thanks to depthcharge-tools, I might be a good candidate to sponsor that > package. > > Do you still care for it ? Yes, and I actually had a talk on this at DebConf22 [1]! But first let me work on it for a few days to undo some decisions I realized was wrong in retrospect, update the boards database, test that it'll play nice with the d-i integration, tag a minor release... Then, I'll send a RFS. My current packaging attempt is on salsa [2] by the way. [1] Solving "How Can I Run Debian on My Chromebook?" For Good https://debconf22.debconf.org/talks/87-solving-how-can-i-run-debian-on-my-chromebook-for-good/ [2] alpernebbi/depthcharge-tools repository on salsa.d.o https://salsa.debian.org/alpernebbi/depthcharge-tools
Bug#1007730: plymouth: should not add panfrost kernel module to initramfs
Package: plymouth Version: 0.9.5+git20211018-1 Severity: normal Tags: patch Hello, The Plymouth initramfs-tools hook adds the Panfrost kernel module to the initramfs, but that fails to probe without a devfreq governor and makes hardware-accelerated graphics unavailable until the module is removed and re-probed. Plymouth actually runs fine without Panfrost in the initramfs, so it should not add it. I've filed a merge request on salsa [1] to fix it, wanted to ping here as well in case you missed it. [1] debian/local/plymouth.hook: Avoid adding Panfrost to the initramfs https://salsa.debian.org/debian/plymouth/-/merge_requests/5
Bug#1007729: Firefox 98 fails to draw a window on aarch64
Package: firefox Version: 98.0-2 Severity: important Tags: upstream patch Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1757571 X-Debbugs-Cc: debian-...@lists.debian.org Hello, I'm running Debian unstable with XFCE on an arm64 chromebook (rk3399-gru-kevin). Firefox could no longer draw a browser window when I upgraded it to version 98. Process manager programs show Firefox and its child processes are running, but nothing user-visible happens. Downgrading to 96.0.3-1 works, but since there's a downgrade protection on profiles I also had to run 'firefox --allow-downgrade' to get it to use my profile. That's discouraged that as it might cause data loss (bookmarks, history etc.), and it's hard to discover when your browser isn't working. Seems to be an already-reported upstream bug [1]. An Ubuntu maintainer tracked it down to a crossbeam upgrade and has a workaround patch in a “PPA for Ubuntu Mozilla Security Team” [2], hope that's helpful here as well (so I tagged as 'patch'). [1] 1757571 - Firefox 98 fails to draw a window on Linux aarch64 https://bugzilla.mozilla.org/show_bug.cgi?id=1757571 [2] firefox (98.0.1+build2-0ubuntu0.21.10.1) impish; urgency=medium https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+sourcepub/13309056/+listing-archive-extra
Bug#973323: Boot failure triggered by USB on rockpro64-rk3399 and pinebook-pro-rk3399
On 21/01/2021 03:08, Vagrant Cascadian wrote: > It seems rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot when usb > is started. It hangs indefinitely at: > > ## Flattened Device Tree blob at 01f0 > Booting using the fdt blob at 0x1f0 > > I have observed this also using 2020.10 on rockpro64-rk3399, though on > pinebook-pro-rk3399 usb does not work and so it basically avoids > triggering the issue. > > Setting CONFIG_USE_PREBOOT=n in the config works around the problem, > though obviously by breaking usb keyboard support or booting from USB > devices. This might be the same as [1] where running "usb stop" would hang, but disabling CONFIG_USB_OHCI_HCD and CONFIG_USB_OHCI_GENERIC gets the board to boot (still breaks the keyboard). Might help narrow things down. [1] https://lists.denx.de/pipermail/u-boot/2020-November/432931.html On 21/01/2021 06:37, Kever Yang wrote: > Do you know which version is the last version that works in this case? The email I linked above has some versions they've tested, in case this is the same issue.
Bug#976808: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0
On 13/12/2020 12:05, Ryutaroh Matsumoto wrote: > I verified that the reported symptom does NOT occur with > qemu-system-x86_64 and ttyS0 serial console running on an amd64 host. > This symptom seems unique to arm(64). I had misunderstood you and was trying with -nographic earlier :) . Found an easier way to reproduce: qemu-system-aarch64 \ -display gtk -enable-kvm -machine virt -cpu host -m 1G -smp 2 \ -kernel /boot/vmlinuz -initrd /boot/initrd.img \ -append "break console=ttyAMA0" Then, run cat on the initramfs shell and see arrow keys result in ^[ . For x86_64, it's console=ttyS0 and ^[[A etc. as you also found out.
Bug#977466: rootskel: bterm cannot start when requesting graphical console and serial console at the same time
On 15/12/2020 20:17, Samuel Thibault wrote: > Wang Shanker, le mer. 16 déc. 2020 01:05:58 +0800, a ecrit: >> I carried out a simple test by limiting memory of my qemu machine >> and appending `lowmem=2` to the kernel command line. I can confirm >> that btrem and its font file get deleted. > > Ok, good! > > Thanks for testing, I have uploaded the fix to lowmem. > > Samuel > I've tested with this and the patch for rootskel, and in the text-based installer on the framebuffer the black boxes are replaced with actual characters (arm64 QEMU, with console=ttyAMA0 console=tty0). Can you apply that and do a release for rootskel if that's fine? (also see: a small fix for the changelog [1]) [1] https://salsa.debian.org/installer-team/rootskel/-/merge_requests/4
Bug#976808: Bullseye arm64 d-i Alpha 3: Items cannot be selected by space
On 09/12/2020 02:15, Ryutaroh Matsumoto wrote: > Hi Alper, thank you for paying attention. > >> On that specific question, you use the arrow keys to navigate between > > Neither the space bar nor arrow keys worked for me with Alpha 3... I tried running it under different terminals (tmux, xfce4-terminal, gnome-terminal, xterm, rxvt-unicode) in case that was the problem, but couldn't reproduce this. Other than that I have no idea why it wouldn't work. (Just in case, try running "cat -v" and pressing the arrow keys -- it prints ^[[A upto ^[[D or ^[0A upto ^[0D for me.) > When I tried a weekly build of d-i on November or October, > at least "v" and "^" worked, d-i failed on "tasksel", and > the installation cannot be completed > > But Alpha 3 does not seem to recognize "v" or "^" as subtitutes of arrow keys, > and the situation got worse. Ryutaroh For me, "v" and "^" work on the GRUB menu but not on the d-i menus (both in Alpha 3 and Alpha 2), but I didn't test that on any weekly builds.
Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64
On 08/12/2020 13:30, Marcin Juszkiewicz wrote: > W dniu 08.12.2020 o 11:13, Alper Nebi Yasak pisze: >> On 08/12/2020 12:26, Marcin Juszkiewicz wrote: > >>> Both standard and graphical installer contain kernel modules for virtio >>> framebuffer. And both ignore video output forcing user to use serial >>> console. Also while 'standard' installer gives "d-i in screen", >>> graphical one gave just d-i on serial console. >>> >>> /proc/consoles has only ttyAMA0 >> >> This only happens on arm64 ACPI systems with SPCR (QEMU VM is one) now. >> The arm64 graphical installer should be working fine in this release >> with device-tree systems, which do have tty0 in /proc/consoles. > > So maybe there should be message "Debian is for SBC, please use > $OTHER_DISTRO for servers/etc" on d-i website? I didn't mean that. On the contrary, I'm someone trying to fix it. >> You can still work around it with "console=tty0". Even more, the ACPI >> case is fixed on git (by explicitly checking /dev/tty0), but that didn't >> make into this alpha release. > > D-I has issues with AArch64/ACPI systems since probably forever. No idea about those.
Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64
On 08/12/2020 12:26, Marcin Juszkiewicz wrote: > W dniu 08.12.2020 o 09:06, Ryutaroh Matsumoto pisze: >> Hi Debian Arm users, >> >> I tried Bullseye d-i Alpha3 released on December 6 for >> building a qemu disk image usable by qemu-system-aarch64. >> To me, Alpha 3 d-i seems almost unusable for that purpose. >> I filed a report at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 >> >> If you have interest, please have a look. Ryutaroh > > You have started machine in QEMU without any graphics support and got > surprised by lack of graphics? (Also bug #976807 where Ryutaroh did try with graphics support) > But even with "-device virtio-gpu-pci" added Bullseye alpha3 installer > follows the path of Buster :( > > Both standard and graphical installer contain kernel modules for virtio > framebuffer. And both ignore video output forcing user to use serial > console. Also while 'standard' installer gives "d-i in screen", > graphical one gave just d-i on serial console. > > /proc/consoles has only ttyAMA0 This only happens on arm64 ACPI systems with SPCR (QEMU VM is one) now. The arm64 graphical installer should be working fine in this release with device-tree systems, which do have tty0 in /proc/consoles. You can still work around it with "console=tty0". Even more, the ACPI case is fixed on git (by explicitly checking /dev/tty0), but that didn't make into this alpha release.
Bug#976808: Bullseye arm64 d-i Alpha 3: Items cannot be selected by space
Control: severity -1 normal On 08/12/2020 10:59, Ryutaroh Matsumoto wrote: > Dear Maintainer, > As I reported at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976807 > Bullseye arm64 d-i does not provide graphical installation > to QEMU VMs. So I tried text-based installation. The > installer says: > moves; selects; activates buttons > > But is not recognized. When I type an alphabet letter, > the selection moves to an item starting with that letter, > but when there are multiple items starting with the same latter > (e.g. Africa and Asia), I cannot choose the second item (e.g. Asia). > This really prevents me from installation... On that specific question, you use the arrow keys to navigate between options and to choose the option you want. But, there are some questions where you mark which options you want with and continue to the next question with , you can identify those by the brackets before given the options which look like: [*] Selected option [ ] Unselected option For those questions does work on my machine with your command. It might be a small misunderstanding, so lowering severity. But I'd expect to answer the first kind of question as well.
Bug#976807: debian-installer: Bullseye d-i Alpha3: qemu ramfb and virtio-gpu are unusable for graphical installation
On 08/12/2020 10:33, Ryutaroh Matsumoto wrote: > I tried to use Debian Bullseye arm64 d-i Alpha 3 to install Bullseye > to a QEMU disk. I tried -device ramfb and -device virtio-gpu-pic > for graphical installation by d-i Alpha 3. But neither of them were > used by the Alpha 3 installer and text-based installation begun. > The full commands for starting qemu-system-aarch64 is as follows. > Host Debian Linux is ARM64 Bullseye, so I used -enable-kvm. When I run your command, I get a new QEMU window showing the TianoCore logo and then GRUB menu on the ramfb. I can select "Graphical Install" and it goes on to show a blinking cursor on the ramfb, and a text-mode installer on the serial0 (can switch from the "View" menu). Is that the same as what you're seeing? To actually get the installer to launch on the framebuffer, I have to add console=tty0 to the GRUB menu entries manually (press E, add it next to "quiet"). Can you try that?
Bug#967963: installation failure: rockpro64
On 06/08/2020 03:04, Forest wrote: I used the installer image from over a week ago, because d-i.debian.org has no newer daily images. That happens frequently, as when the kernel is updated in the archive the installer sources have to be manually updated to build for/with the new kernel. The old images are looking for the old kernel which no longer exists, so you get the installer-archive kernel mismatch error. It's updated now, so the current daily builds should work. Booting with my serial adapter set for 150 bps showed nothing but garbage. Using 115200 bps instead showed several bootloader messages clearly, and then nothing but garbage. Editing extlinux.conf to append console=ttyS2,115200n8 to the kernel command line and then setting my serial port to that speed made kernel boot messages visible and allowed me operate the debian installer. Can you check /sys/firmware/devicetree/base/chosen/stdout-path to see if it gives a reasonable serial configuration? AFAICT it should be "serial2:150n8", which should match what you'd normally set your serial adapter to. Otherwise I don't really know what would be causing the garbled output. Maybe try pressing Ctrl-A then 0 (or 1, 2, etc) (screen key bindings to switch windows) to see if it refreshes into something usable?
Bug#961590: Include drm modules in non-gtk arm64 cdrom initrds
Control: reassign -1 debian-installer
Control: severity -1 normal
Control: retitle -1 Include drm modules in non-gtk arm64 cdrom initrds
Control: tag -1 patch
On 26/05/2020 20:40, Marcin Juszkiewicz wrote:
There are two initrds in that iso, 'install.a64/initrd.gz' doesn't
have drm modules, but the 'install.a64/gtk/initrd.gz' one has them.
Can you try booting the gtk one? If you boot to GRUB, 'Graphical
Install' should be using that.
And that's plain wrong.
I want to run D-I on my monitor. Nevermind is it text mode one or gtk
one. My board does not require serial console to boot as I have
graphical output in U-Boot and can control it using USB keyboard.
I agree they should be included, so I'm changing bug metadata to that
(hopefully correctly).
And I prefer text mode D-I over gtk one.
You can also add DEBIAN_FRONTEND=newt to the kernel cmdline to force
that in the gtk builds.
--
Haven't really tested, but this change should be enough:
diff --git a/build/pkg-lists/cdrom/arm64.cfg
b/build/pkg-lists/cdrom/arm64.cfg
index bb5b3a6ff..672d00a64 100644
--- a/build/pkg-lists/cdrom/arm64.cfg
+++ b/build/pkg-lists/cdrom/arm64.cfg
@@ -1,6 +1,7 @@
fat-modules-${kernel:Version}
cdrom-core-modules-${kernel:Version}
input-modules-${kernel:Version}
+fb-modules-${kernel:Version}
console-setup-udeb
kbd-udeb
usb-modules-${kernel:Version}
Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used
On 26/05/2020 20:09, Marcin Juszkiewicz wrote: > RockPro64 does not enable screen at all. And there are no DRM modules in netinstall image [1]: ~ # cd /lib/modules/5.6.0-1-arm64/ /lib/modules/5.6.0-1-arm64 # find . -name *drm* /lib/modules/5.6.0-1-arm64 # 1. https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso There are two initrds in that iso, 'install.a64/initrd.gz' doesn't have drm modules, but the 'install.a64/gtk/initrd.gz' one has them. Can you try booting the gtk one? If you boot to GRUB, 'Graphical Install' should be using that. However, that image is currently broken due to a kernel version mismatch and won't actually install, try the weekly build instead: https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso
Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used
On 26/05/2020 15:03, Marcin Juszkiewicz wrote: Devices with Mali gpu can use 'panfrost' driver to provide working framebuffer. And then Debian installer can be run on screen instead of serial console. But 'panfrost' module is not available when d-i starts ;( So please include 'panfrost' in 'fb-modules' udeb. Panfrost shouldn't be necessary for a working framebuffer. On my rk3399-gru-kevin, rockchipdrmfb handles that and d-i runs on the screen just fine. Which device are you having this issue with?
Bug#960390: x86_64: No serial port output
On 13/05/2020 03:43, Punit Agrawal wrote: Incidentally, this does not work if '-m 1024' is missing. Kernel boot fails to find 'init'. I suspect that the Qemu default RAM configuration is not sufficient to unpack the initrd. Thanks, that's it. I haven't noticed it the first time around because I normally run virtual machines with virt-manager... The default RAM is 128MiB and the messages also say "Initramfs unpacking failed: write error". Based on this, updated version of Alper's instructions now launch the DI without the need to extract the kernel / initrd. $ qemu-system-x86_64 -cdrom *.iso -nographic -vga none -m 1024 Edit the 'Install' option (by removing 'quiet' and 'vga=788') into: /install.amd/vmlinuz initrd=/install.amd/initrd.gz --- console=ttyS0 (BTW, we need console=ttyS0 here because /proc/consoles only has tty0. The exact opposite happens on arm64 VMs: there /proc/consoles only has ttyAMA0 so debian-installer only launches on the serial console and not on the graphics window.)
Bug#960390: x86_64: No serial port output
On 12/05/2020 13:02, Punit Agrawal wrote: The above parameters do not launch the installer from the iso here. I am not quite sure what the right arguments are. I wonder if "root=" to the kernel will do the trick. Will give that a try. When I try: $ qemu-system-x86_64 -cdrom *.iso -nographic -vga none My terminal turns into a GRUB boot menu, where I can edit the 'Install' option (by removing 'quiet' and 'vga=788') into: /install.amd/vmlinuz initrd=/install.amd/initrd.gz --- console=ttyS0 Which gets me booting kernel messages, can you try that? (Booting still fails with a "Failed to execute /init (error -2)" in my case, but that'd be a separate bug if it's not a problem with my setup.)
Bug#950718: RFS: depthcharge-tools/0.3.1-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
On 03/03/2020 18:51, Cyril Brulebois wrote:
partman-* is of course fine for udebs shipping partman stuff, but
depthcharge-support-installer strikes me as something that could be
named depthcharge-support-udeb, or maybe just depthcharge-udeb?
I mimicked the flash-kernel & flash-kernel-installer naming for the
latter two, and *-installer seems to be the way bootloader-related udeb
packages are usually named (e.g. {grub,lilo,zipl}-installer currently in
the archive). But I will change it if you're not convinced -- I think
depthcharge-support-udeb is OK, but depthcharge-udeb feels weird as this
is definitely not depthcharge itself (see below).
Maybe I can merge depthcharge-support into depthcharge-tools, it's just
the easiest way I had thought of indicating "use this bootloader" like
grub-* packages do (vs. grub-*-bin packages); then we could just have a
depthcharge-tools and depthcharge-tools-installer/depthcharge-tools-udeb
whichever is better.
(Unfortunately I don't have any time to review this more thoroughly to
figure out exactly which part does what etc., but I thought sending
this quick note wouldn't hurt.)
Thanks for the reply. I tried to write up a somewhat short overview of
what my prospective packages do, to hopefully make things easier to
understand:
Depthcharge is a coreboot payload from Google which is shipped as part
of ChromeOS devices' firmware. It boots from images of a special format
written to partitions of a special type.
partman-cros:
- enables partman to create these partitions
- checks and alerts if these partitions are necessary but don't exist
depthcharge-tools provides scripts/commands that automate e.g.:
- building images for a known current machine or an arbitrary config
- writing images to partitions and setting boot priority
- blessing the currently booted partition
depthcharge-support only consists of:
- initramfs & kernel hooks to build and write an up-to-date image
- init.d script & systemd service to bless only successful boots
depthcharge-support-installer is an installer step that:
- installs depthcharge-tools to target
- makes target build and write an image for itself
- reconfigure initramfs if it's too big (machine-specific size limit)
- installs depthcharge-support if all is fine
Bug#950718: RFS: depthcharge-tools/0.3.1-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
I've uploaded a new version of depthcharge-tools to mentors.debian.net.
General changes:
- New upstream release v0.3.1, set version to 0.3.1-1
- Use *.{service,init} symlinks to install systemd/init.d files
- Export build-configuration variables in debian/rules
- Change GPL-2.0+ to GPL-2+ in debian/copyright
Installer changes:
- Temporarily disable our initramfs hook if it already exists
- Fix warning on nonexistent /proc/device-tree/model file
- Add a template to override machine detection
- Clarify initramfs compression template (to match my patch at #950086)
Also, it's now possible to test debian-installer integration in a QEMU
virtual machine with a kernel cmdline like [0], by generating a d-i
image with localudebs including depthcharge-support-installer and
partman-cros, and installing both deb packages from this to the target
before the installer step is run.
[0] console=tty0 priority=low live-installer/enable=false
partman-cros/enable=true
depthcharge-support-installer/machine="Google Kevin"
Bug#952452: initramfs-tools: prefers serial console over framebuffer console
On 27/02/2020 02:10, Ben Hutchings wrote: A device that is intended to be used with keyboard and video display should not have this in the device tree for production units. If we ship the device tree then we can correct that. If not, then the boot loader should be configured to override it, and the installer could do that by default. I'm using rk3399-gru-kevin.dtb from the Debian package. The stdout-path property comes from arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi in the kernel tree. Setting a serial console this way seems to be ordinary, a lot of other devices have it too. For the bootloader (part of the firmware), I don't know if there is a way to make it change that property in the device-tree file. Meanwhile I've added "console=tty0" to the default cmdline my bootloader-handler project uses, so everything should be fine for now. I don't think it makes sense for initramfs-tools to do this, as the wrong default console will still affect other software. I intended to say that maybe initramfs-tools should correct the default console to the virtual console not just for itself but for the entire userspace. (I don't even know if that's possible.)
Bug#952452: initramfs-tools: prefers serial console over framebuffer console
On 24/02/2020 19:50, Alper Nebi Yasak wrote:
I'm using Debian on an arm64 chromebook, and not setting "console=tty1"
in the kernel command line results in a number of weird behaviours
related to the initramfs.
Turns out my device-tree has (for debugging purposes?):
chosen {
stdout-path = "serial2:115200n8";
};
Removing that makes everything work on the screen again, but that's a
worse way to solve it compared to adding a kernel cmdline arg.
QEMU on aarch64 does a similar thing according to [0]:
$ sudo dmesg | grep -i console
[0.00] ACPI: SPCR: console: pl011,mmio,0x900,9600
...
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1661288#c35
Those seem to be the root cause.
Bug#952452: initramfs-tools: prefers serial console over framebuffer console
Package: initramfs-tools Version: 0.136 Severity: minor Dear kernel team, I'm using Debian on an arm64 chromebook, and not setting "console=tty1" in the kernel command line results in a number of weird behaviours related to the initramfs. During an ordinary boot, plymouth doesn't show the futureprototype boot splash. Instead, it shows the init log; but pressing ESC does switch to plymouth (but with what I'm assuming is the text theme instead). If I use "break" (even "break=init") in the kernel command line, I don't see an initramfs shell prompt and the keyboard does nothing. If plymouth is installed, I see the "Spawning shell within the initramfs" message but rest is the same (plymouth quits in it's panic hook). When I'm trying to boot from an encrypted root (different installation), I don't see the "Please unlock disk" cryptsetup prompt and can't type a passphrase; unless plymouth is installed. I'm able to boot the encrypted system as a QEMU virtual machine and I get similar behaviour there, no messages or prompts are printed to the graphical console and instead all go to the serial console. However having plymouth doesn't make the cryptsetup prompt ask in the graphical console in the virtual machine. All these are fixed by simply adding "console=tty1" to the command line, is that something a user is supposed to do manually (e.g. GRUB configs)? Should the initramfs (or maybe the kernel itself) be detecting when graphics are working and automatically switch outputs/prompts to that? I want to work on this, what would be the best way to proceed? -- Might be relevant: -- /proc/consoles: ttyS2-W- (EC p a)4:66 tty0 -WU (E p )4:7 -- Some dmesg lines that might be useful: [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] [0.00] Linux version 5.4.0-4-arm64 (...) [0.00] Machine model: Google Kevin [0.001029] Console: colour dummy device 80x25 [0.001038] printk: console [tty0] enabled [0.044788] Serial: AMBA PL011 UART driver [1.853700] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [1.855861] ff1a.serial: ttyS2 at MMIO 0xff1a (irq = 39, base_baud = 150) is a 16550A [1.856046] printk: console [ttyS2] enabled [1.857318] Serial: AMBA driver [1.857898] msm_serial: driver initialized [2.103745] ttyS2 - failed to request DMA [2.159994] Run /init as init process [2.785121] rockchip-drm display-subsystem: bound ff8f.vop (ops rockchip_drm_fini [rockchipdrm]) [2.787381] rockchip-drm display-subsystem: bound ff90.vop (ops rockchip_drm_fini [rockchipdrm]) [2.794270] rockchip-drm display-subsystem: bound ff97.edp (ops rockchip_drm_fini [rockchipdrm]) [2.794439] rockchip-drm display-subsystem: bound fec0.dp (ops rockchip_drm_fini [rockchipdrm]) [2.794446] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.794449] [drm] No driver support for vblank timestamp query. [2.824898] cdn-dp fec0.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn [3.076232] Console: switching to colour frame buffer device 300x100 [3.132091] rockchip-drm display-subsystem: fb0: rockchipdrmfb frame buffer device [3.144856] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0 [4.972935] systemd[1]: systemd 244.3-1 running in system mode. (...) -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 12M Jan 19 11:20 /boot/initrd.img-5.4.0-2-arm64 -rw-r--r-- 1 root root 16M Feb 8 12:52 /boot/initrd.img-5.4.0-3-arm64 -rw-r--r-- 1 root root 16M Feb 19 14:25 /boot/initrd.img-5.4.0-4-arm64 -- /proc/cmdline cros_secure kern_guid=7849fbba-1fb3-4f0b-9989-952567ef5a3c root=PARTUUID=3518689e-a82c-4448-9ec2-c79b13f88d8e rootwait quiet splash -- resume RESUME=UUID=490bfb86-ee41-4944-8bcf-4f4b2211026d -- /proc/filesystems ext3 ext2 ext4 fuseblk -- lsmod Module Size Used by vhost_net 32768 0 vhost 49152 1 vhost_net tap32768 1 vhost_net uhid 24576 1 algif_hash 20480 1 algif_skcipher 16384 1 af_alg 28672 6 algif_hash,algif_skcipher rfcomm 81920 16 fuse 139264 5 xt_CHECKSUM16384 1 xt_MASQUERADE 20480 3 xt_conntrack 16384 1 ipt_REJECT 16384 2 nf_reject_ipv4 16384 1 ipt_REJECT xt_tcpudp 20480 6 nft_compat 20480 13 nft_counter16384 30 nft_chain_nat 16384 8 nf_nat 45056 2 nft_chain_nat,xt_MASQUERADE nf_conntrack 159744 3 xt_conntrack,nf_nat,xt_MASQUERADE nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack libcrc32c 16384 2 nf_conntrack,nf_nat nf_tables 151552 102
Bug#950718: RFS: depthcharge-tools/0.3.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
On 07/02/2020 17:31, Andrej Shadura wrote: Same here as with #950717: how about talking to the DI team and team-maintaining it and hosting it under https://salsa.debian.org/installer-team? That would be great. I'm not part of the installer team, but I'm willing to join. (Any formal process to do so?) P.S. I had a look at the package and apart from the fact I call the GPL "GPL-2+" not "GPL-2.0+", I don’t have any nitpicks, but then I don’t know anything about how the d-i integration should work. I don't really have a preference for the zero. Is it OK if I change that only if other changes are also requested?
Bug#950717: RFS: partman-cros/1 [ITP] -- Add partman support for ChromeOS kernel partitions
On 07/02/2020 17:23, Andrej Shadura wrote: How about talking to the DI team and team-maintaining it and hosting it under https://salsa.debian.org/installer-team? I think that's the best way to do it, especially for this package (as other partman-* packages are).
Bug#950718: RFS: depthcharge-tools/0.3.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-b...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "depthcharge-tools": * Package name: depthcharge-tools Version : 0.3.0-1 Upstream Author : Alper Nebi Yasak * URL : https://github.com/alpernebbi/depthcharge-tools * License : GPL-2.0+ * Vcs : https://salsa.debian.org/alpernebbi-guest/depthcharge-tools Section : admin It builds those binary packages: depthcharge-tools - Tools for ChromeOS firmware/bootloader integration depthcharge-support - ChromeOS firmware/bootloader integration depthcharge-support-installer - Make this ChromeOS machine bootable (udeb) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/depthcharge-tools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/depthcharge-tools/depthcharge-tools_0.3.0-1.dsc Changes since the last upload: * Initial release. (Closes: #950687) Regards, Alper Nebi Yasak
Bug#950717: RFS: partman-cros/1 [ITP] -- Add partman support for ChromeOS kernel partitions
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-b...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "partman-cros": * Package name: partman-cros Version : 1 Upstream Author : Alper Nebi Yasak * URL : https://salsa.debian.org/alpernebbi-guest/partman-cros * License : GPL-2.0+ * Vcs : https://salsa.debian.org/alpernebbi-guest/partman-cros Section : debian-installer It builds those binary packages: partman-cros - Add partman support for ChromeOS kernel partitions (udeb) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/partman-cros Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/partman-cros/partman-cros_1.dsc Changes since the last upload: * Initial release. (Closes: #950686) Regards, Alper Nebi Yasak
Bug#950687: ITP: depthcharge-tools -- Tools to manage the Chrome OS bootloader
Package: wnpp Severity: wishlist Owner: Alper Nebi Yasak X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: depthcharge-tools Version : 0.3.0 Upstream Author : Alper Nebi Yasak * URL : http://github.com/alpernebbi/depthcharge-tools * License : GPL-2.0+ Programming Lang: sh Description : Tools to manage the Chrome OS bootloader This project is a collection of tools that ease and automate interacting with depthcharge, the ChromeOS bootloader. Depthcharge is built into the firmware of ChromeOS machines, uses a custom verified boot flow and usually cannot boot other operating systems as is. This means someone who wants to use e.g. Debian on these machines need to either replace the firmware or work their system into the format depthcharge expects. These tools are about the latter. This is the main part of my attempt to get Debian and Debian installer to work on ChromeOS devices with stock firmware. What I'm aiming for is a fully automated solution that makes installing and using Debian on these systems as easy as doing so on ordinary x86 laptops. Right now it only supports the one arm64 chromebook I own, but I hope this project can evolve to be the go-to solution for running Linux on these devices in the future. For most x86 models people usually flash third-party firmware, but such an option is not readily available for ARM ones. Other than that, users have to jump through a lot of hoops just to get a bootable system, and still have to do device-specific work on every kernel/initramfs change. Although not included in that specific repo, I've also implemented a Debian installer step and Debian-specific integration to fully automate ChromeOS bootloader management from the installed system. These are available on salsa [0]. I have been using my system with these over the course of multiple kernel upgrades already. It's similar to flash-kernel in its purpose, so I'm OK with maintaining this under the installer team (though I don't want to cause them too much work, so I'm also OK with maintaining it myself). I need a sponsor and will file an RFS soon. [0] https://salsa.debian.org/alpernebbi-guest/depthcharge-tools
Bug#950686: ITP: partman-cros -- Add partman support for ChromeOS kernel partitions
Package: wnpp Severity: wishlist Owner: Alper Nebi Yasak X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: partman-cros Version : 1 Upstream Author : Alper Nebi Yasak * URL : http://salsa.debian.org/alpernebbi-guest/partman-cros * License : GPL-2.0+ Programming Lang: sh Description : Add partman support for ChromeOS kernel partitions This package provides a 'cros' partition method for partman. The firmware and bootloader used on ChromeOS systems require a special ChromeOS kernel partition created by this method. Creating partitions of this ChromeOS kernel type is one part of what's necessary for Debian installer to install a successfully bootable system on ChromeOS machines. This package is essentially a partman-prep fork for this partition type. It's probably already possible to create these partitions manually using e.g. parted-udeb and fdisk-udeb. But, this package does some checks to ensure the partition is in the right disk and offers a warning if the partition is not created (when that could lead to an unbootable system). It makes most sense to maintain this package under the installer team if they accept. I need a sponsor and will file an RFS soon.
Bug#950086: base-installer: please support configuring initramfs compression
On 30/01/2020 16:43, Ben Hutchings wrote: Oh, right, then I misunderstood what you were doing. I don't understand how the two templates work together, so it may well be that the first version was OK. I don't really grok debconf, but from what I can tell: 1. at build-time, x may be set differently per-arch 2. either x or y may be preseeded with a value by the user 3. if y is empty, it's set to the value of x at install-time 4. installer asks about y (based on priority) 5. value of y is used to configure initramfs-tools where: x is base-installer/kernel/linux/initramfs-tools/* (string) y is base-installer/initramfs-tools/* (select) If either is set to a wrong value, y is somehow reset to it's first choice. I searched a bit and came across bug #192889 which says it's the frontend that does sanitization, so step 4. The first version is probably good enough, except in contrived situations designed to break it. (You didn't reply to the bts, so I'm not doing either. Just pointing it out in case it was by accident. If you resend to bts, feel free to forward this mail as well.)
Bug#950086: base-installer: please support configuring initramfs compression
On 29/01/2020 21:31, Ben Hutchings wrote: This is definitely a rather niche option, so "wishlist" is appropriate. Thanks! (My reasoning was that it's a new feature.) So it's possible to set any arbitrary string, but if you set it to anything other than "gzip", "xz", or "lzma" then the required compressor might not be installed. (And it's possible to set a string that mkinitramfs doesn't install either.) I think this needs to be a "select" type question, so that only the supported compression types can be selected. Allowing arbitrary strings wasn't the intention. I had mimicked the driver-policy implementation. The template you quoted is only used to set a "select" type question, and I assumed doing that with an invalid value would cause an error. While testing I noticed that it would use the first choice when given invalid values (e.g. with kernel cmdline [0]), so I reordered the compression choices to match initramfs.conf, with "gzip" as the first choice. Anyway, I don't think checking the values would hurt, so I did that for my patch and for the driver-policy question too (as patch 1/2). I'm just running "exit 1" in the invalid cases, I'm not sure that's entirely right. Also I'm now calling apt-install before writing the configuration, and made it fail the installation step with (hopefully the appropriate error) if it can't install the compressor package. Attaching a series of two patch files to replace the previous one. Hope they resolve your concerns. [0] quiet console=tty0 priority=critical \ base-installer/initramfs-tools/compression=git \ base-installer/kernel/linux/initramfs-tools/compression=git >From e6949630a32e4930561e5fa9d9f443ab8ac044bc Mon Sep 17 00:00:00 2001 From: Alper Nebi Yasak Date: Thu, 30 Jan 2020 14:21:30 +0300 Subject: [PATCH 1/2] Verify answers to initramfs-tools driver-policy questions Also set "base-installer/kernel/linux/initramfs-tools/driver-policy" to type "select" with choices "most" and "dep". Signed-off-by: Alper Nebi Yasak --- debian/templates-arch | 3 ++- library.sh| 9 +++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/debian/templates-arch b/debian/templates-arch index 30e8f7a8..fbb18372 100644 --- a/debian/templates-arch +++ b/debian/templates-arch @@ -6,7 +6,8 @@ Description: for internal use only Use an (initramfs) initrd (linux 2.6 and later only) Template: base-installer/kernel/linux/initramfs-tools/driver-policy -Type: string +Type: select +Choices: most, dep Default: most Default[armel]: dep Description: for internal use diff --git a/library.sh b/library.sh index d7f05024..890f7087 100644 --- a/library.sh +++ b/library.sh @@ -583,12 +583,17 @@ EOF fi db_get base-installer/initramfs-tools/driver-policy - if [ "$RET" != most ]; then + IT_MODULES="$RET" + if [ "$IT_MODULES" != most ] && [ "$IT_MODULES" != dep ]; then + exit 1 + fi + + if [ "$IT_MODULES" != most ]; then cat > $IT_CONFDIR/driver-policy <>From f0dad1298cfb8f0e32616243f44ba776b647dc75 Mon Sep 17 00:00:00 2001 From: Alper Nebi Yasak Date: Thu, 30 Jan 2020 14:42:26 +0300 Subject: [PATCH 2/2] Support configuring initramfs compression Some machines/bootloaders do not support initramfs images larger than a certain size. Setting MODULES=dep in initramfs-tools config is usually enough to satisfy these size limits, and base-installer already asks a question for this (driver-policy, with priority medium). This patch implements a similar question for initramfs-tools' COMPRESS setting which can further reduce the initramfs size for these machines. Signed-off-by: Alper Nebi Yasak --- debian/bootstrap-base.templates | 11 +++ debian/templates-arch | 7 +++ library.sh | 34 + 3 files changed, 52 insertions(+) diff --git a/debian/bootstrap-base.templates b/debian/bootstrap-base.templates index 78a6f29a..8529fbf7 100644 --- a/debian/bootstrap-base.templates +++ b/debian/bootstrap-base.templates @@ -88,6 +88,17 @@ _Description: Drivers to include in the initrd: smaller targeted initrd there is a very small chance that not all needed drivers are included. +Template: base-installer/initramfs-tools/compression +Type: select +Choices: gzip, bzip2, lz4, lzma, lzop, xz +# :sl3: +_Description: Compression method for the initramfs image: + Compressing the initramfs is usually a trade-off between initramfs + size, memory use, compression speed, and the time your system takes to + boot (decompression speed). Gzip is reasonably balanced, xz and lzma + makes the initramfs significantly smaller, but lz4 has the highest + decompression speed. + Template: base-installer/kernel/failed-install Type: error # :sl2: diff --git a/debian/templates-arch b
Bug#950086: base-installer: please support configuring initramfs compression
Source: base-installer Version: 1.192 Severity: wishlist Tags: patch Dear Maintainers, Debian-installer can already configure initramfs-tools' MODULES setting to get a smaller initramfs. I've written a patch for configuring its COMPRESS setting as well, please consider applying it. I've tested it using an arm64 virtual machine with a custom built netboot image. I'm doing something like flash-kernel & flash-kernel-installer for chromebooks, which have size limits on kernel + initramfs + etc. If the installer step fails due to initramfs size I'll be asking these two questions to the user with a higher priority, regenerate the initramfs, and retry the step. Such a flow could be implemented for flash-kernel as well, and I think having at least the question template here would be great. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.4.0-3-arm64 (SMP w/6 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled >From 2864137a59bcfbc957a7e8960b65e3e39977106a Mon Sep 17 00:00:00 2001 From: Alper Nebi Yasak Date: Mon, 27 Jan 2020 21:16:10 +0300 Subject: [PATCH] Support configuring initramfs compression Some machines/bootloaders do not support initramfs images larger than a certain size. Setting MODULES=dep in initramfs-tools config is usually enough to satisfy these size limits, and base-installer already asks a question for this (driver-policy, with priority medium). This patch implements a similar question for initramfs-tools' COMPRESS setting which can further reduce the initramfs size for these machines. Signed-off-by: Alper Nebi Yasak --- debian/bootstrap-base.templates | 11 +++ debian/templates-arch | 6 ++ library.sh | 22 ++ 3 files changed, 39 insertions(+) diff --git a/debian/bootstrap-base.templates b/debian/bootstrap-base.templates index 78a6f29a..7a53cad3 100644 --- a/debian/bootstrap-base.templates +++ b/debian/bootstrap-base.templates @@ -88,6 +88,17 @@ _Description: Drivers to include in the initrd: smaller targeted initrd there is a very small chance that not all needed drivers are included. +Template: base-installer/initramfs-tools/compression +Type: select +Choices: lzop, lz4, gzip, bzip2, xz, lzma +# :sl3: +_Description: Compression method for the initramfs image: + Compressing the initramfs is usually a trade-off between initramfs + size, memory use, compression speed, and the time your system takes to + boot (decompression speed). Gzip is reasonably balanced, xz and lzma + makes the initramfs significantly smaller, but lz4 has the highest + decompression speed. + Template: base-installer/kernel/failed-install Type: error # :sl2: diff --git a/debian/templates-arch b/debian/templates-arch index 30e8f7a8..873dc001 100644 --- a/debian/templates-arch +++ b/debian/templates-arch @@ -12,6 +12,12 @@ Default[armel]: dep Description: for internal use Default driver inclusion policy for initramfs-tools +Template: base-installer/kernel/linux/initramfs-tools/compression +Type: string +Default: gzip +Description: for internal use + Default compression method for initramfs-tools + Template: base-installer/kernel/linux/extra-packages Type: string Default: diff --git a/library.sh b/library.sh index d7f05024..d2859566 100644 --- a/library.sh +++ b/library.sh @@ -575,8 +575,15 @@ EOF db_get base-installer/kernel/linux/initramfs-tools/driver-policy db_set base-installer/initramfs-tools/driver-policy "$RET" fi + if db_get base-installer/initramfs-tools/compression && \ + [ -z "$RET" ]; then + # Get default for architecture + db_get base-installer/kernel/linux/initramfs-tools/compression + db_set base-installer/initramfs-tools/compression "$RET" + fi db_settitle debian-installer/bootstrap-base/title db_input medium base-installer/initramfs-tools/driver-policy || true + db_input medium base-installer/initramfs-tools/compression || true if ! db_go; then db_progress stop exit 10 @@ -591,6 +598,21 @@ EOF MODULES=$RET EOF fi + + db_get base-installer/initramfs-tools/compression + if [ "$RET" != gzip ]; then + cat > $IT_CONFDIR/compression <
Bug#949316: parted: please cherry-pick ChromeOS Kernel partition flag
Source: parted Version: 3.3-1 Severity: wishlist Tags: fixed-upstream d-i Dear Maintainer, The firmware/bootloader in ChromeOS machines only attempts to boot from partitions of a certain GPT partition type. Please cherry-pick my commit 08256913c307e0313ee014e0f292fa335cc18f1d from upstream [1], which adds support for it. I've managed to get debian-installer working on my chromebook and I'm trying to upstream my changes. Part of that work is enabling partman to create these partitions (see my partman-cros [2]), which requires libparted2-udeb to understand this flag, so I've added the 'd-i' tag. [1] https://git.savannah.gnu.org/cgit/parted.git/commit/?id=08256913c307e0313ee014e0f292fa335cc18f1d [2] https://salsa.debian.org/alpernebbi-guest/partman-cros -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.4.0-2-arm64 (SMP w/6 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#940014: plymouth: Include only device-specific modules in initramfs if MODULES=dep
Source: plymouth Version: 0.9.4-1.1 Severity: important Tags: patch Plymouth includes most drm modules in the initramfs and makes it too big for some machines which only support a limited-size image. These devices are supportable by setting MODULES=dep in initramfs-tools configuration, but the plymouth hook doesn't obey it. I've implemented support for including less modules in this case, in the same way initramfs-tools does internally. Please see my merge request on salsa: https://salsa.debian.org/debian/plymouth/merge_requests/2/
Bug#831003: support gzip'd kernel image
On Thu, 23 May 2019 10:36:15 -0700 Vagrant Cascadian wrote:
Untested and refreshed patch against current git attached.
I wanted to extend this, but I ended up almost completely rewriting it:
https://salsa.debian.org/installer-team/flash-kernel/merge_requests/15/
Instead of only using a compressed kernel as-is, my implementation can
also decompress/recompress into a preferred format, with many more
compression types.
Regardless of my MR,
+compress_type() {
+local file="$1"
+magic="$(od -x -N2 $file | head -1 | cut -d' ' -f2)"
If compress_type is called without an argument, od reads from stdin
which might cause flash-kernel to 'hang' unexpectedly. Quoting "$file"
instead exits in error.
Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD
On Tue, 13 Feb 2018 01:03:43 + Ben Hutchings wrote: Now that I think about it, initramfs-tools does allow other packages to override the configuration for mkinitramfs through shell scripts in /usr/share/initramfs-tools/conf-hooks.d. This seems like a good reason to do that. I've recently implemented doing this: https://salsa.debian.org/installer-team/flash-kernel/merge_requests/16/ (But I didn't add the relevant machine db entries for this device).
