Re: What to do with d-i on armel?
On Wed, 2024-01-10 at 08:34 +0100, Arnd Bergmann wrote: > On Sun, Jan 7, 2024, at 23:07, Bastian Blank wrote: > > Hi > > > > With Linux 6.6 we dropped the Marvell specific kernel image, as it > > was not known to work on any of the available devices. We still have > > another armel kernel left, the one of the Raspberry Pi 0 and 1, which > > uses an ARMv6 CPU. > > > > This also removed all the udebs from armel, which makes many d-i > > components not longer have fullfiled dependencies and the release stuff > > of course acting up. > > > > Do we have any armel subarch that can be installed via d-i? > > A few ideas from the kernel's point of view: > > The most important ARMv5 platform is now probably at91, as > Microchip still releases new sam9 chips[1] and is going to > keep supporting it for a while. > I would guess that the latest ones are not even that far off > the performance of the kirkwood/mv78xx0 or bcm2835 parts, > but I don't have numbers. > > Qemu versatilepb is probably the most accessible arm926 > platform, though there are a couple of other armv5/v6 (ast2400, > ast2500, pxa27x, raspi1ap) in qemu that one should be able > to get to work as well if anyone found the time. We used to have a configuration for Versatile, but it got broken accidentally; when I found out I removed it because no-one had complained in 9 months. (Maybe that was a bit quick!) We do have a configuration for RPi 0/1, which is supported with images at <https://raspi.debian.net/> rather than through d-i. I don't think anyone has proposed configurations to support the other platforms. > Since armel userland should work fine with any armhf or > arm64 kernel, it might still be useful to repackage > one or both of those for the armel archive and use this > to have an installation method for armel on modern > hardware. [Side note: I would also like to see an arm64 > kernel image added to armhf, it's probably more useful > than the armmp-lpae kernel in terms of enabling users.] We used to do this for amd64 kernels on i386. Then Debian implemented multiarch and it became an unnecessary waste of build resources. Still, we are lacking support for adding a "foreign" architecture and kernel package at installation time. (This specific combination would also be hard to support in the current linux packaging because arm64 and armhf have different kernel architectures and toolchains, unlike amd64 and i386.) > At the moment, it is possible to enable support for > arm1176 (as in bcm2835) in a normal armhf kernel and > have that boot on armv6k, armv7 and armv8 hardware. > I actually want to change that in the kernel though: > Now that we dropped SMP support in armv6, as it now > makes more sense to have armv6k grouped with armv5 > and instead have a generic kernel for armel that > works on bcm2835, versatilepb, at91, kirkwood and > all the others that one might use. If someone wants to make this work in Debian that would be great, but without a specific maintainer it's not going to happen. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: [...] > ## Kernel modules will be signed with an ephemeral key > > The modules will not longer be signed using the Secure Boot CA like the > EFI kernel image itself. Instead a key will be created during the build > and thrown away after. > > Yes, this will make the build unreproducible, but no better solution > currently exists. There are some plans, but no-one is working on them. > If a suitable replacement shows up, we can always switch to that > solution. Builds for the architectures involved are already unreproducible due to inconsistent generation of BTF in both the kernel and modules. Additionally, my "plan" would also get rid of signing modules with the Secure Boot CA, so I'm not going to object to this. [...] > ## Image packages contains more version info > > By renaming the kernel packages we try to make several kernels > installable at the same time. In contrast to rpm, where you can have > the same package installed multiple times in different versions, dpkg > only supports a single one at the same time. So the co-installable > versions needs to have different package names. > > The packages will include the full upstream version. There exists the > exception of devel builds and uploads to experimental, wich will contain > even less of the version, to avoid new names in that cases. > > Example: linux-image-6.5.3-cloud-arm64 > > There are some drawbacks. > > The same upstream version in testing and backports will have the same > package name. This is not OK, because they will be incompatible on architectures supporting SB (and sometimes incompatible on others due to compiler differences or required config changes). If someone upgrades from stable + backports to testing, and has OOT modules: - With DKMS, will a rebuild be triggered if the linux-image package name doesn't change? - With module-assistant, the new linux-image package will satisfy dependencies of the old modules even though they are incompatible. > Multiple uploads of the same upstream version will have > the same package name, but those rarely happens. Those happen fairly often for urgent security updates. > Those packages will > not be compatible and a reboot is necessary to be able to load modules > again. > > It will not longer be possible to reliably derive the package name from > kernel release (see above), as both values are not really related > anymore. Given all the drawbacks, I don't see the benefit of decoupling package names from release strings. In the same way that shared library packages must be renamed for every backward-incompatible ABI changes, I believe we should keep doing this for linux-image packages. > ## Header and tool packages will not longer contain version > > The headers packages will not longer include the version. It won't be > reliably possible to derive the package name anyway from the running > kernel. > > This means that only headers of one single version can be available on > the system at one time. This might be a bit inconvinient for dkms, as > it can't longer build modules for multiple versions. > > But we too often have the problem that image and headers go out of sync > and then you can't find the correct ones anyway. > > Example: linux-headers-cloud-arm64 This is all downside with no justification given. Please explain what the benefit is. > ## Installer packages will not longer contain too much version > > The installer can only ever handle one version of kernel. Also it got > an internal mechanism to detect which packages belong together > (the Kernel-Version control entry). So we have no need to rename them > and force a matching change in d-i itself just because a new kernel > exists. So it will not longer contain the full version in the package > names if not needed. [...] In the installer, netboot images break every time the kernel ABI is bumped. I think there's a specific check and error message for this, but I'm not exactly sure. It should be verified that this detection will work the way you expect, so that the error message doesn't change and create a support burden for the installer team. Currently kernel-wedge generates the udeb package names and would need to add an option to leave out the version part of the names. I'm happy to work on that once we have an agreement for what to do. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#1037261: Bookworm - OOM-killer called before partition hard drives
On Fri, 2023-06-09 at 17:16 +0200, Anael Mobilia wrote: [...] > During the launch of the partition (before the installer provide the > choice on how did I want to partition manually, automatically, ...), > OOM-killer is called, stopping the installation > > Syslog : > Jun 9 14:50:43 syslogd started: BusyBox v1.36.1 > Jun 9 14:50:43 kernel: klogd started: BusyBox v1.36.1 (Debian 1:1.36.1-1) > Jun 9 14:50:43 kernel: [0.00] Linux version 6.1.0-9-amd64 > (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld > (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 > (2023-05-08) > Jun 9 14:50:43 kernel: [0.00] Command line: > BOOT_IMAGE=/install.amd/vmlinuz priority=low vga=788 > initrd=/install.amd/initrd.gz --- > Jun 9 14:50:43 kernel: [0.00] x86/fpu: x87 FPU will use FXSAVE > Jun 9 14:50:43 kernel: [0.00] signal: max sigframe size: 1440 > Jun 9 14:50:43 kernel: [0.00] BIOS-provided physical RAM map: > Jun 9 14:50:43 kernel: [0.00] BIOS-e820: [mem > 0x-0x0009fbff] usable > Jun 9 14:50:43 kernel: [0.00] BIOS-e820: [mem > 0x0009fc00-0x0009] reserved > Jun 9 14:50:43 kernel: [0.00] BIOS-e820: [mem > 0x000f-0x000f] reserved > Jun 9 14:50:43 kernel: [0.00] BIOS-e820: [mem > 0x0010-0x3ffc9fff] usable > Jun 9 14:50:43 kernel: [0.00] BIOS-e820: [mem > 0x3ffca000-0x3fff] reserved > Jun 9 14:50:43 kernel: [0.00] BIOS-e820: [mem > 0xfeffc000-0xfeff] reserved > Jun 9 14:50:43 kernel: [0.00] BIOS-e820: [mem > 0xfffc-0x] reserved That's 1 GiB RAM, not 32 GiB. Still, that should be more than enough for installation. [...] > Jun 9 14:55:00 kernel: [ 260.262259] active_anon:35811 inactive_anon:26906 > isolated_anon:0 > Jun 9 14:55:00 kernel: [ 260.262259] active_file:0 inactive_file:0 > isolated_file:0 > Jun 9 14:55:00 kernel: [ 260.262259] unevictable:0 dirty:0 writeback:0 > Jun 9 14:55:00 kernel: [ 260.262259] slab_reclaimable:4417 > slab_unreclaimable:7292 > Jun 9 14:55:00 kernel: [ 260.262259] mapped:2481 shmem:54494 pagetables:198 > Jun 9 14:55:00 kernel: [ 260.262259] sec_pagetables:0 bounce:0 > Jun 9 14:55:00 kernel: [ 260.262259] kernel_misc_reclaimable:0 > Jun 9 14:55:00 kernel: [ 260.262259] free:11279 free_pcp:2112 free_cma:0 > Jun 9 14:55:00 kernel: [ 260.262273] Node 0 active_anon:53632kB > inactive_anon:60236kB active_file:0kB inactive_file:0kB unevictable:0kB > isolated(anon):0kB isolated(file):0kB mapped:9860kB dirty:0kB writeback:0kB > shmem:90728kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 14336kB > writeback_tmp:0kB kernel_stack:2032kB pagetables:620kB sec_pagetables:0kB > all_unreclaimable? yes > Jun 9 14:55:00 kernel: [ 260.262283] Node 1 active_anon:89612kB > inactive_anon:47388kB active_file:0kB inactive_file:0kB unevictable:0kB > isolated(anon):0kB isolated(file):0kB mapped:64kB dirty:0kB writeback:0kB > shmem:127248kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 4096kB > writeback_tmp:0kB kernel_stack:392kB pagetables:172kB sec_pagetables:0kB > all_unreclaimable? yes [...] So that's approximately: 46 MiB of slab (kernel heap) 213 MiB of shmem (mostly initramfs files) 263 MiB of anon (process heap and stack) 13 MiB of other stuff --- 536 MiB which is well under 1 GiB. It seems like there must be a lot of kernel memory allocations that aren't being accounted here, and might have been leaked. But you will probably succeed in installing if you correct the memory allocation for this VM to the intended 32 GiB. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice - John Levine signature.asc Description: This is a digitally signed message part
Bug#1036446: Please enable udhcpc6
Package: udhcpc Version: 1:1.35.0-4+b2 Severity: wishlist Tags: ipv6 Busybox has a DHCPv6 client (udhcpc6) but this is not included in the Debian packages. Please enable CONFIG_UDHCPC6 and the dependent features. Ben. -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages busybox depends on: ii libc6 2.36-8 busybox recommends no packages. busybox suggests no packages. -- debconf-show failed
Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics
On Sun, 2023-05-14 at 19:40 +0200, Ben Hutchings wrote: [...] > This works for me with all the QEMU graphics devices. But I haven't > tested on real hardware. Now tested successfully on 2 custom desktops: - Asus P8Z68-V LX motherboard, Intel Core i5 2500 CPU, integrated GPU - ASRock B450 PRO4, AMD Ryzen 5 3600 CPU, Radeon RX580 GPU and 2 laptops: - Lenovo ThinkPad T420, Intel Core i5 2nd gen CPU, integrated GPU - Lenovo ThinkPad T460, Intel Core i5 6th gen CPU, integrated GPU Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics
Control: tag -1 patch On Sun, 2023-05-14 at 00:21 +0200, Ben Hutchings wrote: [...] > So I suppose there's a regression in either efifb or fbdev_drv. I'm not spotting any functional changes in fbdev or the submodules it depends on between bullseye and bookworm. So this implicates either efifb or, as you mentioned, GRUB. > > Via QEMU, under BIOS and UEFI, results are: > > > > +-+-+-+-+ > > | Graphics | Bullseye 11.7 | Bookworm RC 2 | Daily builds | > > +-+++++++ > > | | BIOS | UEFI | BIOS | UEFI | BIOS | UEFI | > > +-+++++++ > > | | OK | OK | OK | KO-G | OK | KO-G | > > | -vga std| OK | OK | OK | KO-G | OK | KO-G | > > | -vga cirrus | OK | OK | OK | KO-S | OK | KO-S | > > | -vga qxl| OK | OK | OK | OK | OK | OK | > > | -vga virtio | OK | OK | OK | OK | OK | OK | > > | -vga vmware | OK | OK | OK | OK | OK | OK | > > +-+++++++ > > I started testing with QEMU and OVMF from unstable, and I'm instead > seeing Xorg failing to start in the same cases you see glitches. The > relevant error message seems to be this one: > http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c=504 [...] I tested with QEMU from bullseye and OVMF from unstable, and again I saw Xorg failing to start, rather than glitches. Weird. I also patched the kernel to report the internal screen_info structure and the fb_var_screeninfo structure passed in and out of FBIOPUT_VSCREENINFO. The key difference is: - With -vga qxl, screen_info says 32 bpp, X wants 32 bpp, the kernel agrees with that. - With -vga std or -vga cirrus screen_info says 24 bpp, X wants 32 bpp, and the kernel says 24 bpp. I think the problem is this GRUB has native drivers for Bochs and Cirrus that reprogram the framebuffer bit depth, and the kernel is then confused about what the bit depth is supposed to be. With QXL, GRUB doesn't have a native driver so it doesn't reconfigure the framebuffer. Unfortunately, with Secure Boot we have to use a monolithic GRUB build so I can't easily exclude video_bochs and video_cirrus to see if that improves matters. But what does works for me is: --- a/build/boot/x86/grub/grub-efi.cfg +++ b/build/boot/x86/grub/grub-efi.cfg @@ -5,7 +5,7 @@ else fi if loadfont $font ; then - set gfxmode=800x600 + set gfxmode=800x600x32 set gfxpayload=keep insmod efi_gop insmod efi_uga --- END --- A full patch is attached. This works for me with all the QEMU graphics devices. But I haven't tested on real hardware. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer From 49a5e562850e3ae4f64ed2d61bd582d8adedc393 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Sun, 14 May 2023 19:17:45 +0200 Subject: [PATCH] Always use 32 bpp for GRUB EFI graphical menu (Closes: #1036019) --- build/boot/x86/grub/grub-efi.cfg | 2 +- debian/changelog | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/build/boot/x86/grub/grub-efi.cfg b/build/boot/x86/grub/grub-efi.cfg index 0a9a67d48..14708c7bc 100644 --- a/build/boot/x86/grub/grub-efi.cfg +++ b/build/boot/x86/grub/grub-efi.cfg @@ -5,7 +5,7 @@ else fi if loadfont $font ; then - set gfxmode=800x600 + set gfxmode=800x600x32 set gfxpayload=keep insmod efi_gop insmod efi_uga diff --git a/debian/changelog b/debian/changelog index 4624187fe..6be6864b5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,12 @@ debian-installer (20230428) UNRELEASED; urgency=medium + [ Cyril Brulebois ] * Bump Linux kernel ABI to 6.1.0-9. * Switch source format from 1.0 to 3.0 (native). + [ Ben Hutchings ] + * Always use 32 bpp for GRUB EFI graphical menu (Closes: #1036019) + -- Cyril Brulebois Thu, 27 Apr 2023 22:52:15 +0200 debian-installer (20230427) unstable; urgency=medium signature.asc Description: This is a digitally signed message part
Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics
note, keeping the bundling in src:debian-installer for the > next few weeks makes us autonomous: we can enable and disable those > extra modules without requiring a new linux upload… so it's nasty but I > actually thought about the few advantages we were getting out of this! > > We should also be OK legal-wise, given we already have linux in > Built-Using via its udebs, so copying things around from linux-image > wouldn't change anything there, would it? > > Of course in the long run, if having those modules is desired, it will > be better to have them merged in linux and to drop the nasty code, e.g. > in a point release. [...] Definitely. I will spend some time investigating this, but I doubt I'll come up with a better fix in time. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Ensuring initramfs is compressed with zstd
I did a test installation with d-i bookworm alpha 2, and I noticed a warning message from update-initramfs during base installation that it was falling back from zstd to gzip compression. zstd has been the default compressor in initramfs-tools for a while, but since the compressor is configurable it only Recommends zstd. It looks like later package upgrades lead to a new initramfs being generated with zstd. However, it is possible that in some conditions an installation would not include zstd, or would leave the initramfs compressed with gzip even though zstd is installed. Does the patch below for base-installer seem like a reasonable change? (I haven't tested it yet, but may do so tomorrow.) Ben. diff --git a/library.sh b/library.sh index e7fb8f60..120a39ae 100644 --- a/library.sh +++ b/library.sh @@ -542,12 +542,16 @@ EOF if [ "$do_initrd" = yes ]; then rd_generator=initramfs-tools - # initramfs-tools needs busybox pre-installed (and only - # recommends it) + # initramfs-tools may need busybox, and prefers to use + # zstd over gzip, but only recommends them if ! log-output -t base-installer apt-install busybox; then db_subst base-installer/kernel/failed-package-install PACKAGE busybox exit_error base-installer/kernel/failed-package-install fi + if ! log-output -t base-installer apt-install zstd; then + db_subst base-installer/kernel/failed-package-install PACKAGE zstd + exit_error base-installer/kernel/failed-package-install + fi # Make sure the ramdisk creation tool is installed before we # change its configuration -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Fri, 2022-07-29 at 01:17 +0200, Chris Hofstaedtler wrote: > * Ben Hutchings : > [..] > > Right. So this seems like a botched transition - fuse3 should have > > taken over the fuse binary package but instead each reverse-dependency > > has to be updated. I agree it would make sense in the short term to > > force fuse3 installation. > [..] > > Thank you for pointing out the problem. Even if the exact issue > > doesn't occur in Debian, we should sort out fuse vs fuse3. > > I would imagine #918984 is related. Right. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Wed, 2022-07-27 at 14:25 +0200, Arnaud Rebillout wrote: > On Thu, 14 Jul 2022 20:14:15 +0200 Ben Hutchings > wrote: > > > > You should find out why that is, before proposing to override it. What > > if something in KDE really does need FUSE 2? > > I don't think that it can happen. A package might need FUSE3 (in such > case it depends on fuse3), or it might need FUSE (any implementation) > (in such case it depends on fuse, and it's either fuse or fuse3 that > will be installed, as fuse3 Provides fuse). But it cannot really ask for > FUSE2, as far as I understand (there's no fuse2 package). That makes sense. > In the case I described above, if fuse gets installed, it's not because > a package needs FUSE2, it's because no package needs FUSE3. So apt picks > fuse rather than fuse3. > Right. So this seems like a botched transition - fuse3 should have taken over the fuse binary package but instead each reverse-dependency has to be updated. I agree it would make sense in the short term to force fuse3 installation. > > (Since you found that removing fuse doesn't remove anything else, this > > implies that the relationship is only a Recommends and not a Depends. > > But that doesn't mean that removal won't break anything.) > > I believe that if replacing fuse by fuse3 doesn't remove anything, it's > because fuse3 Provides fuse. > > In any case: in Kali we solved that by recommending fuse3 in > kali-desktop-core, a metapackage that is always installed with every > Kali desktop. Therefore we're sure to have fuse3 (we don't let apt > guess), and we're sure that open-vm-tools will be installed if needed. > It's a better solution than modifying hw-detect as I suggested here. > > Therefore I'll close this bug, as I don't think it affects Debian anyway. > > Thanks for your feedback, and sorry for the noise. Thank you for pointing out the problem. Even if the exact issue doesn't occur in Debian, we should sort out fuse vs fuse3. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
On Thu, 2022-07-14 at 16:56 +0200, Arnaud Rebillout wrote: > Source: hw-detect > Version: 1.147 > Severity: normal > User: de...@kali.org > Usertags: origin-kali > > Dear Maintainer, > > The package open-vm-tools 11.3.5, released in January 2022, depends on > fuse3 rather than fuse [1]. > > As a consequence, hw-detect fails to install open-vm-tools if ever the > package fuse was already installed. This is because installing fuse3 > would cause the removal of fuse, and removals are not allowed. > > This can be seen in the logs of the installer: > > in-target: The following additional packages will be installed: > in-target: ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3 > in-target: libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5 > in-target: libsigc++-2.0-0v5 open-vm-tools zerofree > in-target: Suggested packages: > in-target: cloud-init > in-target: The following packages will be REMOVED: > in-target: fuse > in-target: The following NEW packages will be installed: > in-target: ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3 > in-target: libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5 > in-target: libsigc++-2.0-0v5 open-vm-tools open-vm-tools-desktop zerofree > in-target: 0 upgraded, 13 newly installed, 1 to remove and 0 not upgraded. > in-target: E: Packages need to be removed but remove is disabled. > > In practice, it hits Kali Linux users, as reported in [2]. For some > reasons, fuse gets installed if users install the KDE desktop for Kali. [...] You should find out why that is, before proposing to override it. What if something in KDE really does need FUSE 2? (Since you found that removing fuse doesn't remove anything else, this implies that the relationship is only a Recommends and not a Depends. But that doesn't mean that removal won't break anything.) If we find that it's not really needed, then a better fix may be to remove the recommendation(s) or change them to "fuse3 | fuse". Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Re: Bug#1012707: /etc/network/interfaces: only source configuration files using with '*.conf' / use 'source /etc/network/interfaces.d/*.conf' instead of 'source /etc/network/interfaces.d/*'
On Tue, 2022-06-14 at 22:52 +0200, Santiago Ruano Rincón wrote: > El 12/06/22 a las 14:13, Patrick Schleizer escribió: > > Package: ifupdown > > Severity: normal > > > > Dear maintainer, > > > > in file /etc/network/interfaces ... > > > > Could you please consider instead of setting the default: > > > > source /etc/network/interfaces.d/* > > > > change suggestion: > > > > source /etc/network/interfaces.d/*.conf > > > > Reason: > > > > When > > > > - text editor (such as kate) create backup files (such as > > /etc/network/interfaces.d/50_user~ with the tilde at the end) > > > > - local packages by system administrator or Debian derivatives place > > configuration drop-in snippets in /etc/network/interfaces.d/ folder, > > > > then on upgrades then redundant files might end up in that folder such > > as those with file extensions '.dpkg-old' or '.dpkg-dist'. > > > > When ifupdown is restarted, an interface is likely to be duplicated > > leading to ifupdown failure, resulting in a broken network connection. Is this not what the "source-directory" directive exists for? It is a bit puzzling that this was added and then not used... > > > > By parsing only configuration files such as with the `*.conf` file > > extension issues with parsing unexpected files created by editors > > (backup files) or dpkg are avoided. > > Thanks for your report. I think it makes sens. But for the moment, I am > pushing it to a separate branch. If I am not wrong, the debian-installer > installs some files in /etc/network/interfaces.d/, so there must be some > coordination to avoid issues in future installs. > > Debian Installer Team: it is OK from your side to make the change > described above? I grepped the source repositories of d-i packages and found 2 uses of interfaces.d: - netboot-assistant has an example command that creates "/etc/network/interfaces.d/static": https://salsa.debian.org/installer-team/netboot-assistant/-/blob/master/README.installbox#L62 - netcfg creates /etc/network/interfaces itself, with the wildcard that's being reported as a bug: https://salsa.debian.org/installer-team/netcfg/-/blob/master/write_interface.c#L29 So netcfg would probably also have to be changed, whether you decide to go with *.conf or source-directory. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: ifupdown/dhcp
On Wed, 2022-05-11 at 11:38 +0200, Bjørn Mork wrote: > Michael Hudson-Doyle writes: > > > Well busybox's udhcpc would seem a likely candidate here -- but its IPv6 > > support (iirc the reason we switch to dhclient from klibc's ipconfig in > > Ubuntu's initramfs, at least) is described as incomplete. > > udhcpc is a very good IPv4 candidate indeed. The ability to run over > any IP interface makes it better than the ISC dhclient IMHO. > > As for DHCPv6 - we do have both dibbler and WIDE clients which are both > DHCPv6 only. Unfortunately, the upstream state and future of both aren't > any better than the ISC dhclient. > > Maybe look at the OpenWrt odhcp6c? Needs packaging, but at least it has > an upstream. https://github.com/openwrt/odhcp6c [...] I already packaged this because I wanted prefix delegation, but I never got around to integrating it with ifupdown. For that reason I only uploaded it to experimental. I would be happy to hand over to a more active maintainer, or to co-maintain it. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Bug#995833: busybox: uudecode doesn't recognise the special decode_pathname /dev/stdout
On Wed, 2021-10-06 at 16:00 +0200, Christoph Anton Mitterer wrote: > Package: busybox > Version: 1:1.30.1-7+b1 > Severity: normal > Tags: upstream patch > > > Hey. > > Since it's unclear whether and when upstream will react and how long it then > takes that this actually lands in Debian, could you possibly consider to > cherry pick the patch I provided at: > https://bugs.busybox.net/show_bug.cgi?id=14241 > > for inclusion in the Debian package? > > > The issue is basically, that uudecode is mandated by POSIX to consider > /dev/stdout as a special symbol (and not a file) that causes output written > to standard output (and not to whichever file the uuENcoded data indicates. > > Under normal user space this wouldn't be that much of an issue, since > /dev/stdout exists and is a symlink to /proc/self/fd/1. > > But within the initramfs, this symlink doesn't sem to exist, so any output > that should go to stdout would actually go to that file (or cause error > if that's not writable). [...] This is bug #981302 (which I thought we'd actually fixed already). I don't think busybox needs to change. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On Wed, 2021-08-25 at 12:45 -0400, Chuck Zmudzinski wrote: [...] > > I will try it in my bullseye Xen HVM DomU. > > I am not sure how to rebuild the installation media with a patched > systemd, but I can patch my installed Xen HVM DomU system > with a patched systemd with the increased buffer size and see if the > Coldplug failure early in the boot process goes away. If so, then it > is likely this patch to systemd would also fix the installation media. [...] Sorry for not being clear - this is a patch for the kernel. Instructions for rebuilding the kernel package are at <https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official>. I agree that you should check whether this fixes the coldplug error before we try rebuilding the installer. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Re: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On Tue, 2021-08-24 at 15:19 -0400, Chuck Zmudzinski wrote: > On 8/24/2021 1:12 PM, Ben Hutchings wrote: [...] > > I think a proper fix would be one of: > > > > a. If the Xen virtual keyboard driver is advertising capabilities it > > doesn't have, stop it doing that. > > b. Change the implementation of modalias attributes to allow longer > > values. > > > > It's not clear to me whether the Xen driver is advertising correctly or > > not. If it is, then the solution should be b, but that may be too > > disruptive a change to the kernel. So a reasonable workaround might > > be: > > > > c. Change the input subsystem to limit the length of the > > capabilities part of the modalias. > > > > > > Ben. > > > > So workaround c would not involve disruptions to the kernel or > systemd? Workaround c seems too disruptive for stable to me, > but maybe could go into unstable and eventually into testing. I don't think it would be very disruptive. It might require a kernel ABI bump, but we do those regularly during a stable release. And this bug is severe enough that I think a fix would be suitable for Debian stable. > A problem with the approach of fixing this bug in the Xen > keyboard driver is that the fix must be implemented in the underlying > Dom0 system, which could be almost anything - another Linux distro > or Debian stable or oldstable. Any fix upstream would probably get into > a bullseye Dom0, but not oldstable Dom0, but perhaps it could be > provided as a backport for anyone who is still on oldstable for their > Xen Dom0. [...] I agree that we need to fix this for domU independently of any protocol change to allow discovery of which keys the underlying input device has. So we can't solve this with approach a. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Re: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote: > > Ben Hutchings writes: > > > I think a proper fix would be one of: > > > > a. If the Xen virtual keyboard driver is advertising capabilities it > >doesn't have, stop it doing that. > > b. Change the implementation of modalias attributes to allow longer > >values. > > > > It's not clear to me whether the Xen driver is advertising correctly or > > not. If it is, then the solution should be b, but that may be too > > disruptive a change to the kernel. So a reasonable workaround might > > be: > > > > c. Change the input subsystem to limit the length of the > >capabilities part of the modalias. > > The problem with a) is that the Xen keyboard is not a physical keyboard > and so it has no way of knowing what keys it actually has. It is a fake > input device designed to pass through whatever input the Xen hypervisor > sends down. As such, any key could come in. If it doesn't advertise > that it has all of these keys, then they would not be accepted by > libinput when the hypervisor sends them down. Right, that's what I feared. xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC, KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654 keys and 2362 bytes in the modalias. > This seems to be the heart of the problem: libinput was designed > assuming that all keyboards can and must report what keys are actually > present, and then libinput tries to cram that information into the > modalias rather than some other sysfs attribute as it should ( or not at > all... I still don't see how this information is actually supposed to be > useful to userspace ). I think modaliases aren't intended to be interpreted by user-space, other than processing wildcards when matching to modules. For input devices, the same information is available through other variables in the uevent, in a more compact form. The information *is* useful for user-space; e.g. in initramfs-tools we recognise keyboard devices and add their drivers to the initramfs but ignore other input devices. > As for b), the problem isn't with the modalias attribute itself, but > when the kernel tries to copy it into the environment block for the udev > callout. The environment block is only a single page, and so limited to > 4 KB. And that's for everything else that goes into the environment, > not just the modalias. Text-based sysfs attributes are limited to a page, but udev receives uevents through netlink, not sysfs. The current limit on the environment of a uevent appears to be 2 KB (UEVENT_BUFFER_SIZE defined in ). That seems like it *might* be easier to change, so long as user-space doesn't have a similar limit. I looked into systemd/udev, and it seems to use an 8 KB buffer for receiving uevents: https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 But as a first step I think increasing the kernel buffer size to 4 KB would be enough. Perhaps someone could test whether this patch to the domU kernel makes udev happier: --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -30,7 +30,7 @@ #define UEVENT_HELPER_PATH_LEN 256 #define UEVENT_NUM_ENVP64 /* number of env pointers */ -#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */ +#define UEVENT_BUFFER_SIZE 4096 /* buffer for the variables */ #ifdef CONFIG_UEVENT_HELPER /* path to the userspace helper executed on an event */ --- END --- ? Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: PGP signature
Re: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On Tue, 2021-08-24 at 10:56 -0400, Chuck Zmudzinski wrote: > On 5/24/2021 3:30 AM, Michael Biebl wrote: > > Hi Phillip > > > > Am 24.05.2021 um 06:19 schrieb Cyril Brulebois: > > > > trigger to cold plug all devices. Both scripts are set -e. The Xen > > > > Virtual Keyboard driver and at least one other driver have always > > > > failed > > > > to trigger due to having absurdly long modalias, but the error used to > > > > be ignored. The kernel now returns the error to udevadm > > > > So this is a change in behaviour in the kernel? > > What happens if you boot the installed system? Does udevadm trigger > > fail there as well? > > > > I feel a bit uneasy changing the udev start script this late in the > > release cycle (especially when it appears like covering up an issue > > someplace else). > > > > I'll let Marco make the judgement on this though, as he has the most > > experience with those udev udeb start scripts as the original author. > > > > Michael > > > > After reviewing Philip's message at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43 > > which seems to point to the root cause of this bug, I can add: > > On my Xen HVM DomU I see the absurdly long modalias for the Xen > Virtual keyboard that seems to be causing this crash in sysfs at > > /sys/devices/virtual/input/input2/modalias > > But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would > probably not result in an error in the udev script if this was also > written as the modalias at /sys/devices/virtual/input/input2/modalias > > So the Xen virtual keyboard appears more than once in sysfs, and > modalias is not the same in the different places. This seems > to be a problem. They are two different devices, and they should have different modaliases. Linux has code for discovering devices on each kind of bus, including virtual buses, and that code creates "bus devices" such as vkbd-0. At this point the kernel doesn't know what the device is capable of. The modalias for a bus device carries some identifying information that can be used to select a driver module for it. The driver does know what the device is capable of, and how to use it. It will normally create one or more "class devices" that support a particular set of operations; in this case input device operations. Class devices typically don't have modaliases, since they don't need another layer of drivers on top. However, for input devices the modalias carries information about the device's capabilities. These may trigger loading of the evdev or joydev module. > I understand the correct way to fix this bug is by modifying the > Xxen virtual keyboard (and any other devices that might cause > this crash) and not the start-udev script on the netinst > installation media, which is so far the only available workaround. > Hopefully Xen will accept a fix if we can come up with a fix. [...] I think a proper fix would be one of: a. If the Xen virtual keyboard driver is advertising capabilities it doesn't have, stop it doing that. b. Change the implementation of modalias attributes to allow longer values. It's not clear to me whether the Xen driver is advertising correctly or not. If it is, then the solution should be b, but that may be too disruptive a change to the kernel. So a reasonable workaround might be: c. Change the input subsystem to limit the length of the capabilities part of the modalias. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Re: Should /boot be ext2, instead of ext4?
On Sat, 2021-08-07 at 16:24 +0200, John Paul Adrian Glaubitz wrote: > Hi Hideki! > > > On Aug 7, 2021, at 4:12 PM, Hideki Yamane > wrote: > > > > I've found that d-i creates /boot as ext2 for guided partioning > > with LVM. I think ext4 is better but is there any reason to do so? > > (e.g. some architecture or bootloader cannot recognize ext4 for it) > > It’s normally a bootloader compatibility issue but since we switched > many architectures over to GRUB where possible, it might no longer be > necessary to use ext2 for /boot. > > I will have to go through the list of bootloaders currently in use > and I’ll let you know. [...] This is bug #985463. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#989863: debian-installer: Firmware problems in bullseye
On Sat, 2021-07-24 at 10:27 +0100, Simon McVittie wrote: > On Sat, 24 Jul 2021 at 09:05:59 +0200, Cyril Brulebois wrote: > > If we were to go the “(almost) all in” route, it might make sense to > > either blacklist (some of) those, or to whitelist the known-ok ones, > > which would require some monitoring of new additions over time (which > > dillon, behind d-i.debian.org, could help us with). > > As an 80% solution, would it be feasible to have the officially-unofficial > media with firmware install the firmware-linux metapackage by default, > or at least install it if a desktop task was chosen? > > firmware-linux pulls in firmware-amd-graphics and firmware-misc-nonfree > (which has the Nvidia firmware), and I think its rules for inclusion > imply not needing an EULA or other special license-acceptance by the > user. [...] Yes - nothing requiring a EULA should be accepted into the upstream repository, and if it happens anyway we would put those files in a separate binary package. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Bug#991500: Missing modalias metadata needed for automatic installation
Source: firmware-nonfree Version: 20210315-2 Severity: serious Tags: pending X-Debbugs-Cc: k...@debian.org, debian-boot@lists.debian.org The binary firmware packages built from firmware-nonfree currently include metanfo.xml files with a list of filenames of the firmware in them. These files are indexed and allows firmware packages to be identified and installed based on the files requested. However, during system installation not all kernel drivers are installed and it is not known which files will be requested by the full system. The metainfo.xml files should include a list of Linux modalias strings for the related modules, so that it's possible to identify (possibly) needed firmware packages without the drivers loaded. Ben. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Linux freeze 5.10.0.7
On Sun, 2021-06-06 at 14:50 +0200, Cyril Brulebois wrote: > Hi, > > Михаил Осипов (2021-06-06): > > Hi! Few days ago after updating to the new kernel > > (linux-image-5.10.0.7-amd64) I started having problems loading the > > operating system. Terminal shows "^@^@^@" and freezes. It works well on > > previous version 5.10.0.6. > > For now i have to select 5.10.0.6 every time on boot. I can't install > > previous version because it already does not exists in the repository. > > > > Debian testing > > $ uname -a > > Linux teal 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 > > GNU/Linux > > > > Laptop: Lenovo Ideapad 5 14ARE05 > > You've reached the team responsible for the installer. Please file a > bug report against the Linux kernel, I suppose by running the > following command: > > reportbug linux-image That should be: reportbug kernel Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Re: Use isenkram to get around the firmware problem?
On Fri, 2021-04-30 at 08:42 +0200, Petter Reinholdtsen wrote: > [Ben Hutchings] > > Here's what I came up with: > > https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/19 > > > > The generated files can be seen in: > > https://people.debian.org/~benh/firmware-metainfo/ > > Cool. I'll see what I can get isenkram to do with the tags. > Might take a while, though, as I am not sure these are indexed by > appstream. Testing will tell. These packages have included AppStream files with elements for years (since 20160110-1). The elements are what I'm adding. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Re: [AMD/ATI graphics] Missing firmware not declared / kernel modules not included in initrd
On Sun, 2021-04-25 at 10:13 +, Andrew M.A. Cater wrote: [...] > Adding to this, if I may. > > I've got two machines which both turn out to need firmware-amd-graphics > rather than the more modern firmware-amdgpu. There is no "firmware-amdgpu". firmware-amd-graphics includes firmware for all AMD GPUs, regardless of which kernel driver supports them. > Installing with Bullsye RC1 netinst for amd64 but NOT the unofficial firmware > version. debian-bullseye-DI-rc1-amd64-netinst.iso > > Even on an expert text mode install.the installer does not prompt for the > firmware-amd-graphics package to be installed - it does complain about > Realtek ethernet drivers and a Ralink WiFi card suggesting that you install > the firmware for these. On PCs (and some other architectures) the installer can rely on the system firmware to set up a framebuffer, so we don't waste space by including graphics drivers. However, its current support for device firmware is limited to prompting for firmware requested by loaded drivers. This is why it does not detect that the GPU may need firmware when the installed system is booted. > Booting the install medium does show, in passing, > in text that you need Radeon firmware R600 for modesetting. There are Debian-specific patches to the amdgpu and radeon drivers that has a basic check for missing firmware and aborts initialisation before reaching a point of no return. This is the error message that radeon will print in this case. But this means radeon *is* being loaded. Did you mean to say "booting the installed system"? [...] > This is explicitly NOT amdgpu which is where people are reporting black > screens and no output whatsoever, I think. And I don't understand that... unless firmware-amd-graphics is missing some firmware needed by the latest kernel version. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your signature. signature.asc Description: This is a digitally signed message part
Re: Use isenkram to get around the firmware problem?
On Fri, 2021-04-23 at 23:14 +0200, Cyril Brulebois wrote: > Hi Ben, > > And sorry for the long delay before replying to your offer. > > Ben Hutchings (2021-03-12): > > firmware-amd-graphics, like most (not all) firmware-* packages in non- > > free, is generated from the firmware-nonfree source package. I am one > > of the maintainers but currently maks is doing most of the work on it. > > > > Kernel modules do now mostly contain lists of associated firmware in > > their metadata. So in principle we could generate a list of device IDs > > from a recent kernel build: for each packaged firmware file, find out > > which module(s) refer to it, and add the device IDs the module(s) > > support. > > > > However, we don't generally know which device IDs correspond to which > > files. So this would result in: > > > > * Listing some device IDs that we don't have the firmware for > > * Listing some device IDs that don't need firmware files (e.g. older > > Intel GPUs) > > > > Is that kind of inaccuracy acceptable? > > That would look way better than the status quo, and I'd be happy to get > that kind of information, thanks! Here's what I came up with: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/19 The generated files can be seen in: https://people.debian.org/~benh/firmware-metainfo/ Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your signature. signature.asc Description: This is a digitally signed message part
Bug#985956: Merge request submittted to initramfs-tools
On Thu, 2021-04-15 at 17:28 +0200, Samuel Thibault wrote: > Hello, > > Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit: > > Quite a few people are negatively affected by this bug, and one can expect a > > lot more to be if Debian 11 goes to release without the inclusion of > > mdio-bcm-unimac.ko in the netinst ARM64 ISOs. > > > > I have created an initramfs-tools merge request to attempt to fix the > > problem, which can be found at: > > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46 > > AIUI initramfs-tools rules are not used to build the nic-modules > udeb, it'd rather be happening in the linux package, in > debian/installer/modules/nic-modules, which indeed doesn't include > drivers/net/mdio/. > > Linux maintainers, do you know more on this issue? Yes that's correct. This should be fixed in both initramfs-tools (for normal system boot) and linux (for installation). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: serial console install issues
On Mon, 2021-04-12 at 13:48 +1200, Richard Hector wrote: > On 11/04/21 9:26 pm, Samuel Thibault wrote: > > Richard Hector, le dim. 11 avril 2021 21:18:49 +1200, a ecrit: > > > On 11/04/21 9:10 pm, Samuel Thibault wrote: > > > > $ git grep -i "Boot console" . > > > > en/boot-installer/parameters.xml: Boot console > > > > po/[...] > > > > > > > > That's very most probably it. > > > > > > I think so, yes. But my problems started earlier than booting linux, at > > > the > > > SysLinux menu. > > > > See the section, it talks about kernel arguments, which are passed from > > the syslinux menu. See the section just before, "Boot Parameters". > > Yes. > > It's becoming clear that I asked/commented/complained about too many > things in one email :-) > > I got the hang of the boot parameters, though that section doesn't > mention removing the 'vga=xxx' section from the linux command line. I'm > not sure if that's important; I'll have to retest to confirm. > > But all that's irrelevant if I can't get to the linux commandline, > because Syslinux is misbehaving. > > Does anyone know if it's inherent in Syslinux that it won't work > correctly with a 24-line serial terminal? [...] I think that syslinux is working through a BIOS-emulated display and keyboard controller, and is not aware that a serial terminal is beign used. The code for SeaBIOS's serial console support is here: <https://github.com/pcengines/seabios/blob/apu_support/src/sercon.c>. It presents an 80x25 (or 40x25) text display as there is no VGA BIOS mode number for 80x24. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#985463: debian-installer: kernel complains about /boot partition in LVM install (ext2 filesystem being mounted at /boot supports timestamps until 2038)
On Thu, 2021-03-18 at 20:20 +0100, Laurent Bonnaud wrote:
> On 3/18/21 7:51 PM, Ben Hutchings wrote:
>
> > I think that the installer uses ext2 for /boot because some boot
> > loaders only support(ed) ext2 and not its successor filesystem
> > formats.
> > But I think that's an historical problem for most release
> > architectures.
>
> If that is true, then an even simpler solution would be to get rid of
> the separate /boot partition and have the /boot directory in the root
> filesystem.
We could probably do that for at least the "atomic" ("all files in one
partition") configuration, yes.
There used to be various compatibility constraints on PCs that made it
important to put all files needed by the boot loader near the beginning
of the disk. I don't think those should influence our defaults any
more.
Ben.
> Thanks for looking at this bug !
>
--
Ben Hutchings
73.46% of all statistics are made up.
signature.asc
Description: This is a digitally signed message part
Bug#985463: debian-installer: kernel complains about /boot partition in LVM install (ext2 filesystem being mounted at /boot supports timestamps until 2038)
Control: clone -1 -2 Control: reassign -1 partman-auto Control: retitle -1 partman-auto: Use ext4 filesystem for /boot if boot loader supports it Control: reassign -2 release-notes Control: retitle -2 release-notes: Recommend converting /boot from ext2 to ext4 if possible Control: tag -2 bullseye On Thu, 2021-03-18 at 17:10 +0100, Laurent Bonnaud wrote: > Package: debian-installer > Severity: normal > > > Dear Maintainers, > > I did a test installation using debian-testing-amd64-netinst.iso from > 2021-03-15 (Debian bullseye/11), chose the LVM option, > and noticed that once the system is installed and boots, the kernel > complains with this message: > > ext2 filesystem being mounted at /boot supports timestamps until > 2038 (0x7fff) > > This is not fatal, but is ugly and most people would prefer a system > without this message. > > The problem comes from the fact that the boot partition is created as > ext2 with 128 bytes inodes. I think that the installer uses ext2 for /boot because some boot loaders only support(ed) ext2 and not its successor filesystem formats. But I think that's an historical problem for most release architectures. > One fix would be to create the /boot filesystem as ext4 with 256 > bytes inodes. On architectures where we install GRUB by default, I think this would be a sensible change. > The same problem exists in the Debian buster installer and will show > up when buster systems are upgraded to a 5.10 kernel. Since we don't have a specific upgrade program, I think the best we can do about this is to document it in the release notes. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Re: Use isenkram to get around the firmware problem?
On Sun, 2021-03-07 at 08:13 +0100, Petter Reinholdtsen wrote: [...] > The generic solution is to get the firmware-amd-graphics maintainer to > add appstream metadata mapping to the PCI IDs supported by the package, > http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html > > > and https://wiki.debian.org/AppStream/Guidelines > > provide some clues on how to do this. [...] firmware-amd-graphics, like most (not all) firmware-* packages in non- free, is generated from the firmware-nonfree source package. I am one of the maintainers but currently maks is doing most of the work on it. Kernel modules do now mostly contain lists of associated firmware in their metadata. So in principle we could generate a list of device IDs from a recent kernel build: for each packaged firmware file, find out which module(s) refer to it, and add the device IDs the module(s) support. However, we don't generally know which device IDs correspond to which files. So this would result in: * Listing some device IDs that we don't have the firmware for * Listing some device IDs that don't need firmware files (e.g. older Intel GPUs) Is that kind of inaccuracy acceptable? Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: Color choices for the installer
On Tue, 2021-02-09 at 09:32 -0500, Jeffrey Walton wrote: > On Tue, Feb 9, 2021 at 9:22 AM Peter Ehlert > wrote: > > > > On 2/9/21 5:00 AM, Jeffrey Walton wrote: > > > Hi Everyone, > > > > > > I think the installer's choice of red for the background color can be > > > improved. Red is a color associated with anger and aggression. Red as > > > an accent would probably be OK, but the installer uses a wall of > > > red. > > I am just a common user, lurking. I do lots of installs and never have I > > seen a Red background. > > Please tell us which ISO you are using. > > I am using debian-10.0.0-powerpc-NETINST-1.iso at > https://cdimage.debian.org/cdimage/ports/snapshots/2021-02-02/. I remember there being cases in the past where red and blue components were swapped on some hardware. I think you've just found another one of those cases. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
Re: Naming convention for udebs: -udeb/-installer suffix
On Wed, 2021-01-13 at 17:24 -0500, John Scott wrote: > > We don't ship udebs for firmware. So please discuss first how this > > s[h]ould work > > I presumed a udeb was necessary for it to be usable during installation. If > it's not needed, that's good to hear and I guess I'll hold off. > > If that's because the ordinary .deb is suitable (it conforms to udeb > requirements), I wonder what my next steps are to see it incorporated in the > installation images. Free firmware should be packaged in udebs so we can integrate it into the installer. However, most firmware that may be useful in the installer is non-free and has to be kept separate from the official images. So the installer doesn't currently have any provision for finding and installing firmware from udebs. We recently added a udeb for wireless-regdb, which contains a file that the kernel loads in the same way as firmware. We ended up putting it in the installer initramfs, so that it's always present. We could do the same for free firmware blobs, but we really shouldn't be adding large files to the initramfs unless we have to. Both wireless-regdb and the ath9k free firmware are useless without nic- wireless-modules-di (udeb for wifi drivers), and should be installed along with it. The idea I had a while back was that nic-wireless-modules-di should depend on wireless-regdb-udeb, and I think the same would go for the free ath9k firmware udeb. However, currently all the kernel module udebs are generated by kernel-wedge which doesn't allow defining dependencies on other packages. Perhaps you could have a look at kernel-wedge and think of a good way to support declaring such dependencies? Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso
On Tue, 2021-01-12 at 19:50 +0100, Holger Wansing wrote: > Hi, > > Holger Wansing wrote: > > Yes, that works fine, using a netboot image, I am NOT asked to > > provide > > firmware for regulatory.db file, because it's already included in > > the d-i > > image. > > > > However, that's only true for netboot images! > > > > My wireless card (on an IBM Thinkpad T60) is also usable with > > DVD/CD netinst images > > (so related kernel modules seem to be included in those images; I > > have explicitly > > tested that with said images on that T60), so probably wireless- > > regdb-udeb should just > > be added to all Linux d-i images? > > I prepared a patch for this (includes removing it from the netboot/* files, > since it's now added generally in pkg-lists/base). > Will apply it, if noone objects. Oh, I see. What I did was to add it to every list that includes nic- wireless-modules, forgetting that for "CD" images that's not present in the initramfs and will get installed later. I think the cleanest solution, that I originally intended to implement, is to make it a dependency of nic-wireless-modules, but that was going to require changing kernel-wedge. But I don't have time to do that now, so I'm happy with your change. The size increase will be negligible. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso
On Sun, 2021-01-03 at 14:30 +0100, Holger Wansing wrote: > Hi, > > liangyue wrote: > > My wifi can not connect. The installer told me that I missing > > firmware files are > > regulatory.db, and I solved it by add package named wireless-regdb. > > I think the package > > wireless-regdb should be add to nonfree iso. > > By the way, my amd gpu rx590 also need firmware, because I can't > > enter desktop > > environment until I install the package firmware-amd-graphics. I > > think the two firmware > > should included in nonfree iso for everyone like my haardware. > > Two different issues here: > > 1. regulatory.db from wireless-regdb package is not included in non-free > firmware-including d-i images. [...] regulatory.db is free, and is packaged in wireless-regdb-udeb which should be included in most installer builds since 20201202. So I don't know why it's not being found. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson signature.asc Description: This is a digitally signed message part
Re: [AMD/ATI graphics] Missing firmware not declared / kernel modules not included in initrd
(Re-sending with quoting fixed. Evolution's composer has regressed again.) On Fri, 2020-12-04 at 22:08 +0100, Holger Wansing wrote: [...] > While debugging this, I found that the "radeon" module - responsible > for this graphics card - is not included in the installer environment. > > So, the kernel cannot load it when detecting the graphics card. > And because of that, the "check-missing-firmware" mechanism does not get > notified about missing firmware. > > Is this intended this way? On most architectures, the installer can use generic framebuffer drivers (VGA, EFI, OpenFirware, or simple-framebuffer) as it does not require high performance. Adding hardware-specific graphics drivers would probably increase its size and memory requirements significantly. > (I was stumbling about the radeon module here, but apparently it's the same > for other graphic cards too, like Intel? I don't find any video-output > kernel modules at all in d-i environment ...) > > Would adding such graphics modules to the installer cause any harm? > Or could they be added, and get such problems sorted out? Adding those drivers just to trigger firmware installation seems like a silly thing to do. It wouldn't fix the issue in radeon or amdgpu, because they don't have a working fallback for missing firmware. (Debian carries a patch to make sure they abort probing early if it's not installed. So this wouldn't cause a regression but it wouldn't log the usual "missing firmware" message.) Could this not be done in "discover"? If it can match PCI devices with a specific class and vendor, that should be enough to decide that firmware-amd-graphics (AMD, ATI) or firmware-misc-nonfree (Intel, Nvidia) might be wanted. Ben. > Sorry, if I got something completely wrong here ... -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Re: [AMD/ATI graphics] Missing firmware not declared / kernel modules not included in initrd
On Fri, 2020-12-04 at 22:08 +0100, Holger Wansing wrote: [...] While debugging this, I found that the "radeon" module - responsible for this graphics card - is not included in the installer environment. So, the kernel cannot load it when detecting the graphics card. And because of that, the "check-missing-firmware" mechanism does not get notified about missing firmware. Is this intended this way? On most architectures, the installer can use generic framebuffer drivers (VGA, EFI, OpenFirware, or simple-framebuffer) as it does not require high performance. Adding hardware-specific graphics drivers would probably increase its size and memory requirements significantly. (I was stumbling about the radeon module here, but apparently it's the same for other graphic cards too, like Intel? I don't find any video-output kernel modules at all in d-i environment ...) Would adding such graphics modules to the installer cause any harm? Or could they be added, and get such problems sorted out? Adding those drivers just to trigger firmware installation seems like a silly thing to do. It wouldn't fix the issue in radeon or amdgpu, because they don't have a working fallback for missing firmware. (Debian carries a patch to make sure they abort probing early if it's not installed. So this wouldn't cause a regression but it wouldn't log the usual "missing firmware" message.) Could this not be done in "discover"? If it can match PCI devices with a specific class and vendor, that should be enough to decide that firmware-amd-graphics (AMD, ATI) or firmware-misc-nonfree (Intel, Nvidia) might be wanted. Ben. > Sorry, if I got something completely wrong here ... -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Bug#974206: closed by Ben Hutchings (Re: Bug#974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway)
Control: reopen -1 On Wed, 2020-11-11 at 19:34 +0200, Harald Hannelius wrote: > On Wed, 11 Nov 2020, Debian Bug Tracking System wrote: > > > This is an automatic notification regarding your Bug report > > which was filed against the debian-installer package: > > > > #974206: debian-installer: When entering an IPv6 address, fe80::1 should be > > a valid gateway > > > > It has been closed by Ben Hutchings . > > > No, this is a link-local address so you have to also specify the > > interface name, e.g. "fe80::1%eth0", > > The installer could then give a hint that %eth0 should be added, or any > interface name that was used in the previous step when the interface got > it's IP-address. The user doesn't know the correct name for the interface at > that stage, it might be ens3, eth0, wlan0, eno1, wlp1s3 or something else. > > I can't remember when I have had to add the interface name to the gateway > since this configuration is usually added in the context of the interface > being configured. OK, yes, good point. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded
On Wed, 2020-11-04 at 15:34 +, Ben Hutchings wrote: [...] > I don't know this part of the installer. But I think it would be a > mistake to use a mapping table; instead the installer should look at > metadata provided by the kernel. All drivers in a loaded module should > be listed under /sys/module//drivers, and the installer > could use that to map a driver name to its module name. Alternately: module="$(basename "$(readlink /sys/bus/*/drivers/$driver/module)")" Some error-checking would be needed. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
Re: Setting up /tmp on /tmpfs during installation
On Tue, 2020-10-27 at 10:07 +0100, Christian Kastner wrote: > During installation, is there some way of requesting /tmp to be mounted > as a tmpfs? It might be possible to do this by pre-seeding partman, but I don't think it can be done interactively. > This is the one manual step I always do after an installation, but doing > during would seem more appropriate (and I wouldn't forget to do it half > the time). Some other distros apparently even set this by default. I think this could be done by default when there is a reasonably large swap partition. > Apologies if this is documented somewhere, I didn't find anything (or > rather: there is TMI out there. The solution to /tmp varied over time, > and distros). Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken signature.asc Description: This is a digitally signed message part
Re: Maintainer access to install repo
On Mon, 2020-10-26 at 20:35 +, Eugene Losowski-Gallagher wrote: > Hi Debian-Installer team, > > I wish to submit patches to fix installer issues when they crop up (I use > debian a lot!). > It might progress to better supporting packages I use frequently for > development (win-win) > > I requested access to: > https://salsa.debian.org/sergiodj/rsync/ > To make a pull-request (see below for patch). That's a personal repository for rsync, which has nothing to do with the installer team. If you want to make changes to rsync packaging: 1. Go to <https://salsa.debian.org/debian/rsync> and press the Clone button to create a personal repository on Salsa. 2. Push to a branch in your personal repository. 3. Create a merge request referring to that branch. You don't need any special permission to do this. > There is also another bug on the installer for setting root password in > expert mode > (had to work-around via the rescue cd). Working on identifying that. [...] I think that's in user-setup, so you can use a similar process starting from <https://salsa.debian.org/installer-team/user-setup>. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Bug#972366: debian-installer: It may be illegal not to set wireless regulatory domain
Control: tag -1 moreinfo On Sat, 2020-10-17 at 09:36 +0900, Ryutaroh Matsumoto wrote: > Package: debian-installer > Version: 20200314 > Severity: important > > Dear Maintainer, > > According to > https://wireless.wiki.kernel.org/en/developers/regulatory > > when a wireless interface is used by Linux, wireless regulatory > domain must be set to comply the laws. > But current installer does not seem to set it. [...] In most cases, this should not be necessary. A regulatory domain is defined in the NVRAM of the local wireless interface, and access points will also include this information in their beacons. In case you use wireless hardware that was intended for use in a different regulatory area, and you configure it as an AP, then you should set the regulatory domain. But I don't think it makes sense for the installer to try to set this - it only ever configures wifi interfaces for infrastructure mode. Am I missing something? Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#971943: task-laptop: Add tlp and thermald
On Sat, 2020-10-10 at 11:44 +0200, Frank wrote: > Package: task-laptop > Version: 3.53 > Severity: wishlist > > Dear Maintainer, > > I wish that the package tlp (to save powers) and thermald (to control the > temperature) is included in task-laptop, which are quite useful for laptops. Power-saving modes are (unfortunately) a major source of bugs in hardware, firmware, and drivers. For that reason we should be cautious about enabling them. Currently device power-saving policies are mostly set by kernel drivers, and where they enable a power-saving mode by default they also tend to have long lists of workarounds for buggy devices. I don't think a task should include programs that override our kernel's defaults, as tlp appears to do. If we decide those defaults are bad then I think we should fix them in our kernel. As for thermald, I understand that it is important for some newer laptops. Does it quietly do nothing on other models? Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#971871: installation-reports: bullseye wkly 20201005 - nouveau firmware
Control: severity -1 important Control: reassign -1 src:linux 5.8.10-1 Control: retitle -1 nouveau no longer fails cleanly when firmware is missing Debian does not include non-free software, including firmware. That's not a bug. You will need to install firmware-misc-nonfree to make the nouveau driver fully functional. However, the driver ought to fail cleanly when firmware is missing. At a minimum it should be possible to boot in text mode and then install a firmware package if wanted. > During a hung boot, I am able to SSH into the box to poke around and > send this report. [...] > Oct 8 10:36:52 petrarca kernel: [ 14.118750] nouveau :01:00.0: > firmware: failed to load nvidia/gp107/nvdec/scrubber.bin (-2) > Oct 8 10:36:52 petrarca kernel: [ 14.118753] firmware_class: See > https://wiki.debian.org/Firmware for information about missing firmware > Oct 8 10:36:52 petrarca kernel: [ 14.118760] nouveau :01:00.0: > firmware: failed to load nvidia/gp107/acr/bl.bin (-2) > Oct 8 10:36:52 petrarca kernel: [ 14.118762] nouveau :01:00.0: acr: > failed to load firmware > Oct 8 10:36:52 petrarca kernel: [ 14.118763] nouveau :01:00.0: acr: > failed to load firmware > Oct 8 10:36:52 petrarca kernel: [ 14.118764] nouveau :01:00.0: acr > ctor failed, -2 > Oct 8 10:36:52 petrarca kernel: [ 14.118771] nouveau: probe of > :01:00.0 failed with error -2 I think that boot did complete, but without a working video driver. nouveau may have disabled the basic video driver (probably efifb) before attempting to load firmware and then finding that it can't take over. Unfortunately the kernel doesn't have an API for re-enabling a basic video driver. There have been similar issues with the radeon and amdgpu drivers, which we patch to guard against this failure mode. We might need to apply a similar patch for nouveau. Ben. -- Ben Hutchings [W]e found...that it wasn't as easy to get programs right as we had thought. I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. - Maurice Wilkes, 1949 signature.asc Description: This is a digitally signed message part
Bug#970678: udev: missing /dev/stdin etc.
Control: reopen 967546 Control: block 970678 with 967546 This udev change also affected the installer, which has neither systemd nor sysvinit; see bug #970678. It might also affect some other initramfs environments (but initramfs-tools itself doesn't use these symlinks, and dracut creates them). systemd still includes the dev_setup() function which creates these symlinks, so I don't see why it can't be called by udevd. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#970678: Network preseeding using http is broken
On Mon, 2020-09-21 at 20:42 +0100, Ben Hutchings wrote: > On Mon, 2020-09-21 at 17:43 +0200, Martin Samuelsson wrote: > > Philip Hands @ 2020-09-21 (Monday), 15:30 (+0200) > > > Martin Samuelsson writes: > > > > > > Just to be clear on this point, are you saying [...] > > > > I'm saying there is no /dev/fd/ at all on current daily debian-installer > > images and hasn't been since at least 20200818 (which was the oldest one I > > could try with current kernel modules). > [...] > > Then we should investigate and fix that instead of removing code that > uses it. It's a udev regression, bug #967546. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Re: base-installer upload?
On Mon, 2020-09-21 at 22:14 +0200, Holger Wansing wrote: > Hi Ben, > > any objections against me uploading base-installer with this pending > changings? > There are some pending translation updates, which is why I want to do another > upload ... No objections; please go ahead. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Re: udeb for wireless-regdb?
On Mon, 2020-02-03 at 17:34 +, Ben Hutchings wrote: > On Mon, 2020-02-03 at 01:23 +0100, Cyril Brulebois wrote: > > Hi Ben, > > > > Ben Hutchings (2020-02-02): > > > Starting with Linux 5.5, we'll enable the kernel to directly load > > > wireless regulatory information. I don't think it's that important in > > > the installer - wireless interfaces should be passively scannming for > > > APs and the APs should provide regulatory information. That's why I > > > haven't thought of adding it to the installer previously. > > > > > > However, now it would just be a case of adding two files for the kernel > > > to pick up. So perhaps a udeb would be worthwhile? > > > > Adding such a udeb (and maybe depending on it from kernel-image, or > > adding it to pkg-lists…) looks sane enough to me at first glance. > > I think it would make sense to add it as a dependency of nic-wireless- > modules-di. I came back to this and remembered that kernel-wedge discards any dependencies on packages that it doesn't generate. Rather than changing kernel-wedge to let us avoid that, I've added wireless-regdb-udeb directly to all the package lists that include nic-wireless-modules. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Bug#970678: Network preseeding using http is broken
On Mon, 2020-09-21 at 17:43 +0200, Martin Samuelsson wrote: > Philip Hands @ 2020-09-21 (Monday), 15:30 (+0200) > > Martin Samuelsson writes: > > > > Just to be clear on this point, are you saying [...] > > I'm saying there is no /dev/fd/ at all on current daily debian-installer > images and hasn't been since at least 20200818 (which was the oldest one I > could try with current kernel modules). [...] Then we should investigate and fix that instead of removing code that uses it. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Re:
On Sun, 2020-09-20 at 14:25 +, Robert Grayson wrote: > To : Debian Install System Team and Debian ALSA Maintainers also Guillem Jover > How do I apt-get install the-program(s) name, all seam to say cannot > find the add-ons > for Firefox application, > > for Internal Real Time Clock Module for the Raspberry Pi which > includes Models A,B,A+,B+,Pi Zero,Pi 2 and Pi 3. this one uses > i2c-tools, > > When I just did this today it said > Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main i2c-tools > armhf 3.1.0-2 > 404 Not Found [...] Raspbian is not Debian, and the Debian installer team is responsible only for the software that does initial installation of a Debian system. It looks like Raspbian has removed their release based on Debian wheezy. In that case you will need to upgrade to a newer release. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Re: Firmware testing images broken
On Tue, 2020-09-15 at 10:01 +0100, Steve McIntyre wrote: > On Mon, Sep 14, 2020 at 09:51:57AM +0100, Steve McIntyre wrote: > > Hi Brandon, > > > > On Sun, Sep 13, 2020 at 03:17:11AM -0400, Brandon Werner wrote: > > > Hi, > > > > > > I tried to use one of the Sid DI netinst firmware images and they > > > seem to be broken for about a week or so now. After picking the > > > language and keyboard, the iso is unable to mount. I am using an EFI > > > machine with a usb flash drive and don't have a disk drive to test if > > > the error occurs in that scenario. I tested on three different EFI > > > machines that I have with very different processors and got the same > > > results. One thing that might help is that I saw that linux 5.8 > > > entered Sid at the time things stopped working and wonder if a > > > possible regression could be due to that > > > > ACK, looks like a regression in config somewhere - the isofs > > filesystem is missing compared to the last build with 5.7.0-3. > > And fixed as of today's daily builds. > > Thanks for the report! Thanks Steve. We probably should have thought to update that after changing the dependencies (which was needed because the module dependencies changed). Ben. -- Ben Hutchings One of the nice things about standards is that there are so many of them. signature.asc Description: This is a digitally signed message part
Bug#969450: partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
Control: severity -1 minor On Thu, 2020-09-03 at 08:43 +0200, jurriaan wrote: > Package: partman-auto > Severity: important > Tags: d-i > > Dear Maintainer, > > I was a bit surprised when I did a quick Debian Stable install on my > new workstation (384 Gb RAM, 512 Gb ssd) and ended up with just 80 Gb > usable diskspace, thanks to a 400 Gb swap partition that the Debian > installer created. I think a warning/question when more than 25% of > the disk is used as swap-space would be in order. I would think that > computer-owners who install large amounts of memory carefully install > enough memory to not swap excessively. [...] This is an extremely unusual configuration for a desktop. You always have the opportunity to review and modify the partitioning before going ahead. So reducing the severity. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#769107: debian-installer: grub-installer fails if more than 26 SCSI devices are present
On Sun, 2020-08-23 at 13:38 +0200, Holger Wansing wrote: > > Ben Hutchings wrote (24 Nov 2014 04:09:01): > > device_to_disk already knows how to do the mapping. We have this > > complicated wildcard here which doesn't match the regexp in > > device_to_disk, only because no-one got round to clearing out the devfs > > cruft which is the following '*' case. > > > > So I propose this instead: > > > > Subject: Remove devfs case for mapping partitions to whole disk names > > (Closes: #769107) > > > > Rather than using an unmaintainable wildcard for non-devfs > > partition device names, we should remove the obsolete devfs > > case and use device_to_disk by default. > > > > Also remove one of the many pointless uses of mapdevfs. > > Hi, > > what's the status here? > Should this be committed? > Or should I file this bug as will-not-fix? I think this should be fixed, but I don't know that I ever got as far as testing that patch. So this should probably wait until someone has done that. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Re: Bug#968803: debian-cd : please include base packages from 'unreleased' on debian-ports architectures
On Fri, 2020-08-21 at 13:31 +0200, John Paul Adrian Glaubitz wrote: [...] > Furthermore pressing tasks are: [...] > - re-introduce old xorg drivers needed for PowerMacs (mach64, r128 etc) [...] It might be a better choice in the long term to write kernel (KMS) drivers for these instead. Those would then be usable by both X and Wayland servers and should be able to handle suspend and resume gracefully. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Bug#968441: partman-auto: Default /boot partition size is too small
Control: unarchive 893886 Control: forcemerge 893886 -1 On Sat, 2020-08-15 at 12:56 +0200, Pablo R wrote: > Package: partman-auto > Severity: normal > > Dear Maintainer, > > I recently assisted a friend in her installation of Debian over the > phone. > Going through manual partitionning over the phone would be too > bothersome so I told her to use the automated partitionning option > that uses a whole disk with LVM and encryption. > > Everything went well except that a few weeks later my friend's > computer would not boot: apparently, a kernel update had gone wrong > because the /boot partition was full. > Of course my friend did not see the problem during the update because > she did not know she had to pay attention to that. > > I had the same problem myself a bit more than 10 years ago, and since > then I always do partitioning manually during installs so I did not > know until then that too small /boot partition was still a thing. > > The default should probably be like 1GB or even 2GB to be safe :). [...] This is fixed in the current version of partman-auto, though not (yet) in stable. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#746966: HiDPI support
On Tue, 2020-08-04 at 17:39 -0500, Diego Escalante Urrelo wrote: [...] > MIN_WIDTH_HIDPI=1600 > virtual_size=/sys/class/graphics/fb0/virtual_size > > if [ "$kernel" = linux -a -e "$virtual_size" ]; then > width=`cut -d',' -f2 < "$virtual_size"` > > if [ "$width" -ge "$MIN_WIDTH_HIDPI" ]; then > FONTSIZE="16x32" > fi [...] You have consistently written "width" here where you mean "height". Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Re: debian6
On Thu, 2020-07-30 at 17:43 +0300, Ali Durmaz wrote: > merhabalar notebook üzerinde çalışıp wireless driverinde sorun çıkartmıycak > debian6 iso imagesine ihtiyacım var link gönderebilirmisiniz. Debian 6.0 has many known security issues that will no longer be fixed. If you can accept that, here are the ISO images: https://cdimage.debian.org/cdimage/archive/6.0.10/ Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#886642: fixed? (please default to a larger /boot for guided partitioning)
On Mon, 2020-05-25 at 13:22 +0200, Holger Wansing wrote: > Hi, > > "McIntyre, Vincent (CASS, Marsfield)" wrote: > > Hi > > > > I thought this would have been fixed by this commit > > > > https://salsa.debian.org/installer-team/partman-auto/-/commit/79bea1c75d2fd9fbd6eb01c1bea6de2914d24d22 > > > > which will be available in the 'daily' build of the installer. > > I don't know what the prospects are for having this applied to > > the 'stable' installer. > > This is indeed fixed for bullseye, tracked in #893886 / #951709, leading to > /boot > getting a size between 512 and 768MB (depending on disc size). > > @Tobias: you can try a daily build from > https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/ > to confirm it works for you for installation of bullseye. > > I was not aware of this bug, so did not close it... > > Should this be considered for backporting to stable? I think it should, though there is a small risk of regression if people install on very small storage devices. Ben. -- Ben Hutchings Nothing is ever a complete failure; it can always serve as a bad example. signature.asc Description: This is a digitally signed message part
Bug#954856: Please add option to install signed grub bootloader
On Sat, 2020-03-28 at 22:50 +0100, Cyril Brulebois wrote: > Hallo Bernhard, > > Bernhard (2020-03-28): > > My system don't start in case of Secure Boot is enabled. > > > > In Debian Wiki: https://wiki.debian.org/SecureBoot > > The package grub-efi-amd64-signed is not installed. > > This is a recommended package. > > But this package is necessary for Secure Boot. > > > > If i install a standard Debian installation, my system boot with Secure > > Boot. > > With a standard Debian installation, the recommended packages will be > > installed also. > > Oh, we do install grub-efi-amd64 which Depends: grub-efi-amd64-bin which > itself Recommends: grub-efi-amd64-signed. > > So either stop disabling Recommends (you're working against the default > setting, you're supposed to be dealing with the consequences on your > own), or additionally install grub-efi-amd64-signed through appropriate > parameters in your preseed file. > > This seems to me like a not-a-bug situation. It is definitely a bug that we automatically install shim-signed without grub-efi-amd64-signed. That combination doesn't make any sense. Ben. > Leaving this open for other members of the installer team to comment, > but as far as I can tell, this bug report could likely be closed right > away. > > > Cheers, -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
On Sat, 2020-03-28 at 13:41 +, Steven Chamberlain wrote: [...] > kfreebsd-10 FTBFS, due to probably this change in kernel-wedge: > https://salsa.debian.org/installer-team/kernel-wedge/-/commit/3827f1ee9f53540b104c592a8a2695f78d8629ed [...] On Sat, 2020-03-28 at 18:29 +, Steven Chamberlain wrote: > tags -1 + patch > thanks Sorry about that. I knew this was a relatively risky change, but thought I had test cases covering everything. Would you mind adding a regression test for this case? Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Re: Install the GRUB boot loader on a hard disk
On Wed, 2020-03-18 at 16:03 +0100, John Paul Adrian Glaubitz wrote: > On 3/18/20 3:36 PM, Ben Hutchings wrote: > > > According to that logic you would have to replace the save icon in every > > > desktop application because we're no longer using floppy disks. > > [...] > > > > That has already happened to many (most?) applications. > > I actually just verified that and both Microsoft Office 2019 and > LibreOffice 6.4.x both use the floppy disk icon for "Save As". LibreOffice is an odd one because there are multiple icon styles available. With the "Elementary" style, which appears to be the default, the icon is a downward arrow on a piece of paper. But "Colibre" and "Tango" have the floppy disk. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Bug#954200: DI encrypted LVM, discard option crypttab file
On Wed, 2020-03-18 at 11:27 +0100, john doe wrote: > Package: debian-installer > Version: debian-10.3.0-amd64-netinst.iso > > After installing debian-10.3.0-amd64-netinst.iso with encrypted LVM, the > crypttab file is populated with the discard' option in the fourth field. > > According to (1), the discard option has security implication: > > "discard > Allow discard requests to be passed through the encrypted block device. > This improves performance on SSD storage but has security implications." As I recall, the security implication is a minor information leak - it makes it possible to determine how much, and which parts, of the disk are used. Hardly anyone should care about that, so this is a reasonable defualt. Ben. > I would suggest that the debian-installer populates the first two > mandatory fields of '/etc/crypttab'. > > 1) https://www.freedesktop.org/software/systemd/man/crypttab.html > > -- > John Doe > -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: Install the GRUB boot loader on a hard disk
On Wed, 2020-03-18 at 10:11 +0100, John Paul Adrian Glaubitz wrote: > On 3/18/20 9:58 AM, Holger Wansing wrote: > > while investigating a grub installation failure, I came across the main menu > > entry of grub-installer: > > "Install the GRUB boot loader on a hard disk" > > > > This is no longer optimal, since we have flash/SSD drives, SD cards etc. > > where > > OS'es are installed on. > > > > So this should be changed, similar to the "rename 'CD/CD-ROM' into > > 'installation media' approach". > > According to that logic you would have to replace the save icon in every > desktop application because we're no longer using floppy disks. [...] That has already happened to many (most?) applications. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: Dropping haveged from the installer
On Sat, 2020-03-14 at 08:13 +0100, Cyril Brulebois wrote: [...] > Anyway, to get the ball rolling, I've performed some tests to see how it > would go. I've tried dropping haveged-udeb from pkg-lists and that seems > to be working fine: there are no obvious delays with either the > all-HTTPS scenario or the encrypted LVM one. I'm seeing the “random: > crng init done” message after 23 or 52 seconds respectively, likely when > the first entropy-needing operations are happening. Can you confirm this > is the expected behaviour? [...] Yes, that's what I would expect. However: I've just run a test where the initramfs script reads one byte of /dev/random then reports the time and relevant log messages. On 5.5, with random.trust_cpu=N, it still hangs for many minutes. Eventually I stopped waiting and pressed keys, and that un-stuck it. So I think the in-kernel entropy generator might not be reliable (yet). Ben. -- Ben Hutchings Humour is the best antidote to reality. signature.asc Description: This is a digitally signed message part
Re: boot-time accessibility issues
On Thu, 2020-03-05 at 07:16 -0500, Jude DaShiell wrote: > If dummy was used for monitor type, the screen reader could come up > talking without any monitor attached. Many linux distros including > debian can get a monitor turned on and off during operation and don't > let a screen reader know now we have a working monitor and now we don't > have a working monitor. Most display controllers that are designed to allow hotplugging monitors, can report hotplug events to the driver. Where there is a native kernel mode-setting (KMS) driver for the controller, it should report hotplug events to user-space. So a screen reader could (in principle) react to these. However, the generic drivers for firmware-configured frame buffers or VGA-compatible display controllers don't have this functionality, and the installer usually uses one of those generic drivers. > I'm thinking along these lines to attempt to > make installations bulletproof. On the debian-user list earlier someone > had a monitor that required firmware to run it and debian wouldn't > install without that firmware. I'm not sure with that radeon monitor if > vga normal could have been run on boot to eliminate the firmware > complaint. [...] Linux doesn't have drivers for specific monitors. "radeon" is the kernel driver for older ATI/AMD GPUs and display controllers, and regrettably it does need firmware to set up some of those display controllers. The generic VGA driver should be able to set up these display controllers without firmware, but won't be able to configure high resolutions, hotplug reporting, or other advanced features. GNOME and other desktop environments using Wayland won't work with the generic VGA driver. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#951709: /boot should get a bigger share of disk in default installation
On Thu, 2020-02-20 at 18:50 +0530, Pirate Praveen wrote: > Package: debian-installer > Version: 20190702+deb10u3 > Severity: important > > With initrd around 60+ MBs, 236 MB /boot in a 300 GB hard disk can hold > only 2 versions of the kernels at the same time. When installing a 3rd > kernel /boot gets filled up. I think it should be able to store at > least 3 kernels and ideally 4 or even more. > > The paritions were created automatically with just /home in a separate > partition with lvm by debian buster installer. I agree; the default size of /boot is now too small. I think we should normally allocate at least 500 MB to it. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: udeb for wireless-regdb?
On Mon, 2020-02-03 at 01:23 +0100, Cyril Brulebois wrote: > Hi Ben, > > Ben Hutchings (2020-02-02): > > Starting with Linux 5.5, we'll enable the kernel to directly load > > wireless regulatory information. I don't think it's that important in > > the installer - wireless interfaces should be passively scannming for > > APs and the APs should provide regulatory information. That's why I > > haven't thought of adding it to the installer previously. > > > > However, now it would just be a case of adding two files for the kernel > > to pick up. So perhaps a udeb would be worthwhile? > > Adding such a udeb (and maybe depending on it from kernel-image, or > adding it to pkg-lists…) looks sane enough to me at first glance. I think it would make sense to add it as a dependency of nic-wireless- modules-di. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
udeb for wireless-regdb?
Starting with Linux 5.5, we'll enable the kernel to directly load wireless regulatory information. I don't think it's that important in the installer - wireless interfaces should be passively scannming for APs and the APs should provide regulatory information. That's why I haven't thought of adding it to the installer previously. However, now it would just be a case of adding two files for the kernel to pick up. So perhaps a udeb would be worthwhile? Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Re: [installer] One more template change?
On Thu, 2020-01-30 at 23:21 +0100, Holger Wansing wrote: [...] > I would propose to simplify/improve that like this: I would suggest using consistently "question" instead of "item", and avoiding "reasonable default" as I'm not sure how widely that term is understood: > You can select the priority of question you want to see: > - 'critical': you will only see items that will probably break the system >without user intervention. "only questions that are essential for a successful installation" > - 'high': items are shown, that don't have reasonable defaults, additionally > to those from critical. "also questions for which the default often needs to be changed" > - 'medium': also show normal items that have reasonable defaults. "also questions for which the default sometimes needs to be changed" > - 'low': even show trivial items that have defaults which will work in > the vast majority of cases. [...] "all questions, even if the default only rarely needs to be changed" Ben. > -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Bug#950086: base-installer: please support configuring initramfs compression
On Thu, 2020-01-30 at 20:10 +0300, Alper Nebi Yasak wrote: > 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. Right, thanks for the explanation and sorry for wasting your time with my initial objection. > (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.) That was accidental, so I've now bounced both messages. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. signature.asc Description: This is a digitally signed message part
Bug#950086: base-installer: please support configuring initramfs compression
On Thu, 2020-01-30 at 16:35 +0300, Alper Nebi Yasak wrote: > 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. [...] 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. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. signature.asc Description: This is a digitally signed message part
Bug#950086: base-installer: please support configuring initramfs compression
On Wed, 2020-01-29 at 00:01 +0300, Alper Nebi Yasak wrote: > Source: base-installer > Version: 1.192 > Severity: wishlist > Tags: patch This is definitely a rather niche option, so "wishlist" is appropriate. > 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. Looking at the patch: [...] > --- 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 [...] > --- a/library.sh > +++ b/library.sh [...] > + if [ "$RET" = xz ] || [ "$RET" = lzma ]; then > + log-output -t base-installer apt-install > xz-utils > + else > + log-output -t base-installer apt-install "$RET" > + fi 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. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your signature. signature.asc Description: This is a digitally signed message part
Re: netcfg: proposal for template change
On Fri, 2020-01-10 at 22:01 +0100, Holger Wansing wrote: > Hi, > > I would like to propose a change on a template in netcfg: [...] > _Description: Malformed IP address > The IP address you provided is malformed. It should be in the form > - x.x.x.x where each 'x' is no larger than 255 (an IPv4 address), or a > - sequence of blocks of hexadecimal digits separated by colons (an IPv6 > + x.x.x.x where each 'x' is an integer not larger than 255 (for an IPv4 > address), or > + ::::::: each '' being a block of > hexadecimal digits (for an IPv6 > address). Please try again. [...] But IPv6 addresses do not have to look like that: leading zeroes in each group can be omitted and a run of all-zero groups in the middle can be omitted. And really I think the tiny proportion of users who need to enter static network configuration will already know what an IP address looks like. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#946682: debian-installer: Discard transmission by LVM
On Fri, 2019-12-13 at 17:15 +0100, Frederic MASSOT wrote: > Package: debian-installer > Severity: wishlist > Tags: d-i > > Dear Maintainer, > > Following a discussion on the list of Proxmox users, I understood > that only LVM Thin transmits discard commands to SSD. This seems to be incorrect. LVM normally uses dm-table, which supports discard if the underlying device(s) do. > https://pve.proxmox.com/pipermail/pve-user/2019-December/171187.html > > https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_hard_disk_discard > > When creating logical volumes with the Debian installer, they are not > of the LVM Thin type. > > Can you add to the Debian Installer the ability to create logical > volume with thin provisioning? "Thin provisioning" is a device-mapper layer that allows assigning more logical storage space than the underlying physical storage. Newly written blocks are allocated from the physical storage pool and discarded blocks are returned to the pool. This can be appropriate for disk server / VM host applications where storage can be over-committed to VMs and more physical storage will be added to the pool depending on actual need. It does not seem to be appropriate for the OS installation and therefore should not be offered in the installer. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Re: [cdrom-detect] Change template proposal
I think this template, and the code using it, is obsolete. The only two non-standard CD-ROM drivers left in Linux are pcd and gdrom, neither of which we enable. Maybe FreeBSD has some such drivers, but given that pre-ATAPI CD-ROM drives must be >20 years old now I don't see the point in bothering with them. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Bug#946118: synaptics touchpad does not work in debian installer graphical mode
Control: tag -1 moreinfo On Wed, 2019-12-04 at 01:56 +0300, dinar qurbanov wrote: > Package: debian-installer > Version: 20190702+deb10u2 > severity: minor > > synaptics touchpad does not work in debian installer graphical mode. i > have not checked text mode. This bug report is unlikely to be actionable unless you specify *exactly* which model of computer you are using. There are literally hundreds of different touchpad devices out there. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Re: Dropping haveged from the installer
On Thu, 2019-11-07 at 22:36 +0100, Cyril Brulebois wrote: > Hi Ben, > > Ben Hutchings (2019-11-07): > > Linux 5.4 introduces an in-kernel jitter-entropy implementation for > > systems without a usable hardware RNG, which should remove the need for > > haveged. > > > > We could possibly cherry-pick that change on to 5.3, to avoid the need > > for further changes to haveged packaging. > > Oh, great. > > Feel free to either follow-up on this bug report once you have > backported it to 5.3, or alternatively once 5.4 trunk has reached > experimental, so that the switch away from haveged can be tested. This is included in 5.3.9-1, which is currently building. Ben. -- Ben Hutchings Everything should be made as simple as possible, but not simpler. - Albert Einstein signature.asc Description: This is a digitally signed message part
Re: Request add hibmc_drm into buster aarch64 netboot image
On Thu, 2019-11-07 at 13:39 +0800, She Kairui wrote: > Hello， > > I'm trying to install Debian buster on to the Huawei Kunpeng arm64 server, > found that the installation graphic output not show up via the server BMC > virtual console. > > Because Huawei Kunpeng arm64 server BMC chip is hibmc, the OS need > hibmc_drm.ko to work with it, currently this kernel module is not included > in the netboot initrd ( > http://ftp.debian.org/debian/dists/stable/main/installer-arm64/20190702+deb10u1/images/netboot/netboot.tar.gz) > . This module isn't even enabled in the kernel package for unstable yet! > I have verified the BMC virtual console graphic output works well by adding > hibmc_drm.ko into the netboot initrd. Could you please help evaluating add > the hibmc_drm udeb into the netboot initrd by default? > Thanks The selection of drivers to included in is mostly done through the kernel package, not the installer packages. Please open a bug against "src:linux" requesting that this driver is built and included in the installer. We'll fix it unstable first, and can then possibly fix it in an update to buster. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Dropping haveged from the installer
Linux 5.4 introduces an in-kernel jitter-entropy implementation for systems without a usable hardware RNG, which should remove the need for haveged. We could possibly cherry-pick that change on to 5.3, to avoid the need for further changes to haveged packaging. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package
On Tue, 2019-11-05 at 22:17 +0100, Holger Wansing wrote: [...] > I just noticed that the relevant message currently appears with netinst image, > too (because build badly broken). > > So, maybe we should not restrict the above proposed changing to the "netboot" > installation method? > (means: skipping the "check if you are using an up-to-date netboot image" > part) That seems reasonable. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part
Re: finish-install warning
On Fri, 2019-11-01 at 08:08 +0100, john doe wrote: > Hi, > > Looking in the log after a fresh install of Debian Buster, I'm seeing > the following in /var/log/installer/syslog: > > "... finish-install: dpkg-divert: warning: diverting file > '/sbin/start-stop-daemon' from an Essential package with rename is > dangerous, use --no-rename" > > I tried to look at (1) but couldn't find where to correct the above warning. > > 1) https://salsa.debian.org/installer-team/finish-install I don't think the problem that this warning is about is relevant during installation. So I don't think there's an actual bug to fix here. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Bug#749991: debian-installer: Wrong kernel in debian-installer package
On Fri, 2019-11-01 at 00:09 +0100, Holger Wansing wrote:
> Hi,
>
> Ben Hutchings wrote:
> > On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote:
> > > Bugreport against kernel version mismatch, when using outdated or broken
> > > netboot images:
> > >
> > >
> > > Since it's unlikely that we completely prevent this issue to happen,
> > > maybe we
> > > could at least change the error message, saying that the user should try
> > > another / a newer installation image?
> > > (as already suggested in bug#367515)
> > >
> > > It would be a good time for such template changing now...
> > > Patch attached.
> >
> > I feel that we ought to give a more definite answer, instead of "you
> > can try" and "will probably fail". I don't think that "choosing to
> > install a different version of Debian" is likely to be a useful answer
> > very often, and continuing without kernel modules is definitely going
> > to fail.
> >
> > If I understood correctly, this message can only appear when using a
> > netboot image, and can be caused by either (a) old netboot image or (b)
> > broken mirror. If that's right, we should recommend (a) make sure your
> > netboot image is current (b) if it is, then try another mirror,
> > recommending deb.debian.org.
>
> That looks reasonable.
> I have prepared a proposal for this:
The new text looks good to me.
[...]
> > Also, this should be an error message, not a question.
>
> For this, I would need some help, since I'm lacking the needed skills there.
> The relevant part of anna.c seems to be:
[]
> if (!kernel_packages_present) {
> di_log(DI_LOG_LEVEL_WARNING, "no packages matching running
> kernel %s in archive", running_kernel);
> #ifdef __GNU__
> /* GNU Mach does not have modules */
> #else
> debconf_input(debconf, "critical", "anna/no_kernel_modules");
> if (debconf_go(debconf) == 30)
> return 0;
> debconf_get(debconf, "anna/no_kernel_modules");
> if (strcmp(debconf->value, "false") == 0)
> return 0;
I think that for an error message the above 5 lines (after
debconf_input(...)) can be changed to:
debconf_go(debconf);
return 0;
[...]
> I assume, just turning
>
> = snip
> Template: anna/no_kernel_modules
> Type: boolean
> Default: false
> # :sl2:
> _Description: Continue the install without loading kernel modules?
> = snap
>
> into
>
> = snip
> Template: anna/no_kernel_modules
> Type: error
> # :sl2:
> _Description: No kernel modules found
> = snap
>
> is not enough here?
Right, because there will no longer be any answer for the code to get.
Ben.
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
signature.asc
Description: This is a digitally signed message part
Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package
On Mon, 2019-10-28 at 15:56 +0100, Cyril Brulebois wrote: > Philipp Wollschlegel (2019-10-28): > > On 28.10.19 15:11, Ben Hutchings wrote: > > > On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote: > > > > Bugreport against kernel version mismatch, when using outdated or > > > > broken > > > > netboot images: > > > > This isn't a package / message problem, this is a process problem. > > > > The netboot image is not built at the same time as the rest of the > > distribution. I.e. the kernel in the main distro changes and the netboot > > image still uses the old one. > > > > Even when using a direct url to the netboot image, the netboot image > > will fail, using the same package mirror, the netboot image came from. > > That's not true for stable or oldstable. Also, we ship netboot images in > packages, use that and be happy? > > If users are tracking testing or unstable, well, yes; those > distributions are WIP. I think that's reasonable for unstable, but this really shouldn't happen in testing (and I didn't realise it did). Ben. > But the script you quoted seems to be about buster, so using d-i-n-i > packages should be a no-brainer. > > https://tracker.debian.org/pkg/debian-installer-netboot-images > > > Cheers, -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package
On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote: > Bugreport against kernel version mismatch, when using outdated or broken > netboot images: > > > Since it's unlikely that we completely prevent this issue to happen, maybe we > could at least change the error message, saying that the user should try > another / a newer installation image? > (as already suggested in bug#367515) > > It would be a good time for such template changing now... > Patch attached. I feel that we ought to give a more definite answer, instead of "you can try" and "will probably fail". I don't think that "choosing to install a different version of Debian" is likely to be a useful answer very often, and continuing without kernel modules is definitely going to fail. If I understood correctly, this message can only appear when using a netboot image, and can be caused by either (a) old netboot image or (b) broken mirror. If that's right, we should recommend (a) make sure your netboot image is current (b) if it is, then try another mirror, recommending deb.debian.org. Also, this should be an error message, not a question. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Bug#941300: finish-install: write random seed to correct location for chosen init system
On Sat, 2019-09-28 at 17:20 +0800, Paul Wise wrote: > Package: finish-install > Version: 2.56 > Severity: important > Tags: security > Control: found -1 2.81 > Control: found -1 2.100 > Control: found -1 2.101 > > finish-install creates a random seed in the location used by the > urandom init script from the initscripts package. On systemd based > systems, systemd-random-seed.service overrides the urandom init script > but uses a different location for its random seed file. Consequently on > first boot of systemd based systems there is no random seed file so the > amount of entropy available is lower. [...] This should improve the randomness of /dev/urandom. However, the last time I checked, the systemd service does not change the kernel's entropy accounting. (And there was a small risk of using the seed twice, which would need to be fixed before changing that.) So this does not help with the problem of slow boots due to the kernel not accounting enough entropy. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Re: Debootstrap and package versions
On Tue, 2019-09-24 at 22:06 +, Matt Bearup wrote: [...] > 5. From looking at the official metadata for buster and buster- > updates, it seems like the convention is to *remove* the old package > versions. And indeed, doing this in our repo caused debootstrap to > fetch our new package versions and run successfully. The Packages file for a given Debian suite and architecture usually only has one entry for a given name. I believe this is always the case for stable suites. It is certainly *not* true for unstable or for security suites. As I understand it, the FTP team must invoke a "decruft" process to remove old versions periodically: https://nthykier.wordpress.com/2015/06/22/introducing-dak-auto-decruft/ > So my questions... > 1. Is it intended that debootstrap only grabs the first package > version it finds, then neglects to fetch the newer version if it's > needed for a pre-dependency? Is it worth scraping the rest of the > metadata for newer package versions? This was probably intentional, as it is simple to implement and normally works. Perhaps taking the last package version would be better, but I don't know if it is safe to assume that packages will be sorted in version order. > 2. I'm fairly certain I've installed "old" package versions before > (e.g. apt install foo=n-1). Are the conditions for old packages being > removed or retained described anywhere? Looking at the > PointReleaseChecklist ( > https://wiki.debian.org/Teams/ReleaseTeam/PointReleaseCheckList) and > bullet #5 above it looks like old packages do in fact get removed, > but are there situations where they are retained? If you're referring to "List of packages … that need to be removed", that actually means completely removing packages which are very buggy, not just removing old versions. Old versions may still be available in a different suite that you have as an APT source, or might not have been decrufted yet. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Bug#940801: missing virtio block Kernel Objects
On Fri, 2019-09-20 at 09:06 +0200, Fred Boiteux wrote: > Le 20/09/2019 à 07:21, Bastian Blank a écrit : > > On Thu, Sep 19, 2019 at 10:56:55PM +0200, Geert Stappers wrote: > > > The netboot tarball misses virtio block drivers. > > > This makes it unnessecary tiresome > > > to install Debian VMs on not-Internet-connected server. > > This is intentional. netboot is for booting from _network_. On the > > network you got a distribution mirror, otherwise you have problems > > installing Debian anyway. > > > > Bastian > > > Hello Bastian, > > In fact the VM is actually booting from network, and has access to a > distribution mirror (copy of DVD-1 of Debian Buster 10.1), but the > debian-installer can't detect VM disk to be partitionned… I don't know > very well debian-installer internals, should it downloads a .deb or > .udeb for disk modules to be able to detect them ? I saw in previous > Debian versions some « virtio-modules » like : > virtio-modules-4.9.0-11-amd64-di, containing virtio_blk module, but it > doesn't exist in Buster, how the installer is supposed to get it ? It's in scsi-modules--di now. (I know it's not a SCSI driver, but that's where we currently put miscellaneous storage drivers.) The netboot installer should install that package and then trigger loading of the module. Have you updated the netboot installer since the point release? Ben. -- Ben Hutchings Nothing is ever a complete failure; it can always serve as a bad example. signature.asc Description: This is a digitally signed message part
Re: Change templates: CD -> installation medium - proposal #2
On Thu, 2019-09-12 at 19:08 +, Holger Wansing wrote: [...] > So installation disk would be fine. > > The only alternative I can think of (from Justin's list) > would be installation image. > Additional benefit would be, that this term seems to be the > most used on the Debian website. > So if users know that term from the website or find it there, they can make > the connection to the messages in d-i, > if in doubt what is meant. > > What do you think? An "installation image" is a regular file. It has to be copied onto a physical device, or mapped as a virtual device, to create an "installation disk". Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: Change templates: CD -> installation medium - proposal #2
On Tue, 2019-09-10 at 20:21 +0200, Holger Wansing wrote: [...] > Again another thought: > > When we talk about an "installation disk": > Is it clear enough, that we mean the disk where we install *from* ? > This could likely be mixed up with the disk where we install *to* , right? I think this is a standard computing term and should not be confusing for native English speakers. There may be some risk of confusion for non-native speakers. > Think about these strings: > > > #. Type: text > #. Description > #. :sl1: > #: ../cdrom-detect.templates:2001 > -msgid "Detecting hardware to find CD-ROM drives" > +msgid "Detecting hardware to find installation drives" > msgstr "" > > #. Type: error > #. Description > #. :sl2: > #: ../cdrom-detect.templates:14001 > -msgid "The CD-ROM drive contains a CD which cannot be used for installation." > +msgid "The detected installation drive cannot be used for installation." > msgstr "" [...] I don't know exactly what cdrom-detect does, but it may still be specific to optical drives. In that case you could use more specific terms here, e.g. "The optical disc drive contains a disc which cannot be used for installation." Otherwise a suitable new text could be something like "The detected drive does not contain a usable installation disk". Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#451535: debian-installer: allow to 'reuse' encrypted volumes
On Sat, 2019-09-07 at 13:48 +0300, M Santala wrote: [...] > This bug has persisted for a long time and it bites long-term Debian > users who are upgrading their systems, causing loss of time and > data. This makes upgrade a challenge and encourages to keep obsolete > systems in operation. What makes you think the installer is intended to be used for upgrades? Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Re: Bug#935069: installation-guide: remove mentions of floppies
On Wed, 2019-08-28 at 21:42 +0100, Miguel Figueiredo wrote: > Hello, > > On 18/08/19 23:44, Holger Wansing wrote: > > Package: installation-guide > > Severity: wishlist > > > > > > The installation-guide still mentions floppies as installation-media. > > Remove that. > > > > > > Filing this bugreport as a reminder. > > > > Holger Maybe you should send the patch to the bug address? Also, in all these files: > diff --git a/build/arch-options/hurd-i386 b/build/arch-options/hurd-i386 > index 0b341aeb6..7177cc32e 100644 > --- a/build/arch-options/hurd-i386 > +++ b/build/arch-options/hurd-i386 > @@ -20,7 +20,6 @@ smp_config_option="N/A" > fdisk="fdisk.txt;cfdisk.txt" > network="" > # For Lenny i386 does not have floppy images > -#boot="supports-floppy-boot;bootable-disk" > boot="bootable-disk" > frontend="newt" > other="" > diff --git a/build/arch-options/i386 b/build/arch-options/i386 > index 4cb7d5316..090b1ca5e 100644 > --- a/build/arch-options/i386 > +++ b/build/arch-options/i386 > @@ -20,7 +20,6 @@ smp_config_option="Symmetric multi-processing support" > fdisk="fdisk.txt;cfdisk.txt" > network="supports-tftp;supports-bootp;supports-nfsroot" > # For Lenny i386 does not have floppy images > -#boot="supports-floppy-boot;bootable-disk;bootable-usb" > boot="bootable-disk;bootable-usb;isohybrid-supported" > frontend="newt;gtk" > other="supports-wireless;supports-pcmcia;supports-serial-console" > diff --git a/build/arch-options/kfreebsd-i386 > b/build/arch-options/kfreebsd-i386 > index 46be8b717..8da63c7ed 100644 > --- a/build/arch-options/kfreebsd-i386 > +++ b/build/arch-options/kfreebsd-i386 > @@ -22,7 +22,6 @@ smp_config_option="Symmetric multi-processing support" > fdisk="fdisk.txt;cfdisk.txt" > network="supports-tftp;supports-bootp;supports-nfsroot" > # For Lenny i386 does not have floppy images > -#boot="supports-floppy-boot;bootable-disk;bootable-usb" > boot="bootable-disk;bootable-usb;isohybrid-unsupported" > frontend="newt;not-gtk" > other="supports-wireless;supports-pcmcia;supports-serial-console" the comments above the deleted lines should also be deleted. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: Installer image for HP mv2120 fails to build with Linux 5.2
On Mon, 2019-08-26 at 15:01 +0200, Raphael Hertzog wrote: > Hello, > > FYI in Kali we tried to build the installer images with Linux 5.2 but the > build fails on armel due to the image for HP Media Vault mv2120 going > over some limit: [...] This was mentioned in the changelog: * [armel/marvell] Increase maximum image size (fixes FTBFS): - This removes support for QNAP TS-109, TS-119, TS-209, TS-219, TS-409, and HP Media Vault mv2120 - This may be reverted if we can disable or modularise some features Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: Change templates: CD -> installation medium
On Sun, 2019-08-25 at 22:12 +0200, Holger Wansing wrote: > Hi, > > during the now active development cycle, I would like to make some changes on > templates of the installer (affecting translations as well, of course): > > > Change "CD" into "installation medium" > (such as in "Loading installer components from CD") [...] I absolutely agree with replacing "CD", but I think "installation medium" might be too abstract and technical. In this example, do we need to say "from " at all? The components could be loaded over the network, but wouldn't we use "downloading" in that case? In other instances, like when we ask whether to install packages from another "CD", would a phrase like "disc or drive" work? Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Bug#934383: [Fwd: Re: Bug#934383: debian-install: Package fails attempting to access USB WiFi]
Forwarded Message From: William Melgaard Reply-To: William Melgaard To: Ben Hutchings Subject: Re: Bug#934383: debian-install: Package fails attempting to access USB WiFi Date: Sat, 10 Aug 2019 12:13:49 -0400 (GMT-04:00) Message-Id: <1485212848.2002.1565453629821@wamui- abby.atl.sa.earthlink.net> -Original Message- > From: Ben Hutchings > Sent: Aug 10, 2019 11:22 AM > To: William Melgaard > Cc: 934...@bugs.debian.org > Subject: Re: Bug#934383: debian-install: Package fails attempting to access > USB WiFi > > Control: tag -1 moreinfo > > On Sat, 2019-08-10 at 17:17 +0300, andreimpope...@gmail.com wrote: > > Control: reassign -1 debian-installer > > > > On Sb, 10 aug 19, 09:50:50, William Melgaard wrote: > > > Package: debian-install > > > Version: debian-10.0.0-amd64-netinst.iso > > > Severity: serious > > > Tags: ipv6 > > > Justification: 2 > > > > > > Dear Maintainer, > > > > > > > > > > > >* What led up to the situation? > > > Attemting to install Buster with an USB WiFi dongle > > >* What exactly did you do (or not do) that was effective (or > > > ineffective)? > > >* What was the outcome of this action? > > > When the installer reached the "Detect Network Hardware", it > > > entered a loop of alternating white & black screen > > >* What outcome did you expect instead? The install package never got as far as an installation log. c could not break the loop. The only way out was to pull the plug PS rt2800us should read rt2800usb The black screen is not entirely black. It has the Debian logo and "Debian" at the top. > > > Identify the presence of a Panda PAU06 Wifi dongle, RT5372, > > > requiring Debian package rt2800us > > This requires the *kernel module* rt2800usb, which in turn requires > non-free firmware. My guess is that you used an installation image > that doesn't include the firmware. However the installer is supposed > to detect and report that error. > > Were you able to copy out the installation log (/var/log/syslog)? > > Ben. > > -- > Ben Hutchings > Beware of programmers who carry screwdrivers. - Leonard Brandwein > >
Bug#934383: debian-install: Package fails attempting to access USB WiFi
Control: tag -1 moreinfo On Sat, 2019-08-10 at 17:17 +0300, andreimpope...@gmail.com wrote: > Control: reassign -1 debian-installer > > On Sb, 10 aug 19, 09:50:50, William Melgaard wrote: > > Package: debian-install > > Version: debian-10.0.0-amd64-netinst.iso > > Severity: serious > > Tags: ipv6 > > Justification: 2 > > > > Dear Maintainer, > > > > > > > >* What led up to the situation? > > Attemting to install Buster with an USB WiFi dongle > >* What exactly did you do (or not do) that was effective (or > > ineffective)? > >* What was the outcome of this action? > > When the installer reached the "Detect Network Hardware", it > > entered a loop of alternating white & black screen > >* What outcome did you expect instead? > > Identify the presence of a Panda PAU06 Wifi dongle, RT5372, > > requiring Debian package rt2800us This requires the *kernel module* rt2800usb, which in turn requires non-free firmware. My guess is that you used an installation image that doesn't include the firmware. However the installer is supposed to detect and report that error. Were you able to copy out the installation log (/var/log/syslog)? Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Bug#930228: partman-crypto: cryptsetup's initramfs integration was moved to a separate package
On Thu, 2019-07-25 at 01:02 -0300, Guilhem Moulin wrote: > Control: severity -1 normal > > On Sat, 08 Jun 2019 at 22:05:42 +0200, Guilhem Moulin wrote: > > Our (cryptsetup maintaining team) plan is to rename ‘cryptsetup-run’ to > > ‘cryptsetup’ once Buster is released, hence this bug should be RC at > > this point: with `apt-install cryptsetup` the initramfs integration > > won't be installed anymore. > > Since 2:2.1.0-6 we reclaimed the name ‘cryptsetup’: > > Package: cryptsetup > Recommends: cryptsetup-initramfs, cryptsetup-run > Description: disk encryption support - startup scripts > > Package: cryptsetup-initramfs > Depends: cryptsetup > Description: disk encryption support - initramfs integration > > Package: cryptsetup-run > Depends: cryptsetup > Description: transitional dummy package for cryptsetup > > Thanks to the Recommends: d-i will automatically pull the initramfs > integration, at least on systems where APT::Install-Recommends hasn't > been turned off by preseeding. (The Recommends: cryptsetup-run is there > to improve the upgrade path, cf. #932625.) I'm therefore only raising > the severity to ‘normal’. APT::Install-Recommends is only enabled after the base-installer phase. of installation. I don't know what stage cryptsetup is installed at, but I suggest it's worth checking that this assumption is correct. Ben. -- Ben Hutchings compatible: Gracefully accepts erroneous data from any source signature.asc Description: This is a digitally signed message part
Bug#931852: [armel/marvell] cmdline mtd partition map without effect
On Tue, 2019-07-16 at 09:02 +0200, Chris Laif wrote: > On Tue, Jul 16, 2019 at 1:22 AM Ben Hutchings wrote: > > On Mon, 2019-07-15 at 09:31 +0200, Chris Laif wrote: > > > On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings > > > wrote: > > > > On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote: > > > This seems to break backwards compatibility for a lot of devices > > > (Google shows lots of hits for "mtdparts=" and only a handful for > > > "cmdlinepart.mtdparts", so I think nobody is using the latter). > > > > > > I wonder what's the best way to have a both Stretch and Buster > > > compatible cmdline. A quick test shows that "cmdlinepart.mtdparts" > > > works with Stretch, too (even Stretch does not have a seperate > > > "cmdlinepart" module). Do you have any recommendations? > > > > I think that "cmdlinepart.mtdparts" will work whether or not the driver > > is actually a module. But I accept it would be better if "mtdparts" > > also continued to work when the driver is a module. > > > > Thanks. Do you know if the acceptance of 'mtdparts' with/without > prefix is specific to the Debian kernel or if it is a decision by the > upstream kernel devs? I remember that some months ago one of the beta > Buster kernels accepted the 'mtdparts' variable, I /think/ the > incompatible change has been introduced during finalisation of Buster. > > Kernel docs > (https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html) > refer to the 'mtdparts' variable (without prefix). The difference in behaviour between the built-in and modular builds of the driver, is not specific to Debian. The change to building this driver as a module was our decision, however. That change was made in version 4.16-1~exp1, over a year ago. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part
Bug#931852: [armel/marvell] cmdline mtd partition map without effect
On Mon, 2019-07-15 at 09:31 +0200, Chris Laif wrote:
> On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings wrote:
> > On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote:
> > > Package: debian-installer
> > > Version: 20190702
> > >
> > > I'm using the current Buster kernel/initrd on my Seagate Blackarmor NAS.
> > >
> > > The mtd partition map ('mtdparts' cmdline variable) has no effect
> > > (even with 'cmdline' module loaded):
> > [...]
> >
> > What if you replace "mtdparts=" with "cmdlineparts.mtdparts="?
> >
>
> With "cmdlineparts.mtdparts" it does not work:
[...]
> With "cmdlinepart.mtdparts" (without trailing "s", equal to the name
> of the kernel-module) it works!:
Sorry for the typo.
> ~ # cat /proc/cmdline
> console=ttyS0,115200
> cmdlinepart.mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
> ~ # cat /proc/mtd
> dev:size erasesize name
> mtd0: 000a 4000 "uboot"
> mtd1: 0001 4000 "env"
> mtd2: 0050 4000 "uimage"
> mtd3: 01a4 4000 "rootfs"
> ~ #
>
> This seems to break backwards compatibility for a lot of devices
> (Google shows lots of hits for "mtdparts=" and only a handful for
> "cmdlinepart.mtdparts", so I think nobody is using the latter).
>
> I wonder what's the best way to have a both Stretch and Buster
> compatible cmdline. A quick test shows that "cmdlinepart.mtdparts"
> works with Stretch, too (even Stretch does not have a seperate
> "cmdlinepart" module). Do you have any recommendations?
I think that "cmdlinepart.mtdparts" will work whether or not the driver
is actually a module. But I accept it would be better if "mtdparts"
also continued to work when the driver is a module.
Ben.
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
signature.asc
Description: This is a digitally signed message part
Bug#931852: [armel/marvell] cmdline mtd partition map without effect
Control: tag -1 moreinfo
On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote:
> Package: debian-installer
> Version: 20190702
>
> Hi,
>
> I'm using the current Buster kernel/initrd on my Seagate Blackarmor NAS.
>
> The mtd partition map ('mtdparts' cmdline variable) has no effect
> (even with 'cmdline' module loaded):
[...]
What if you replace "mtdparts=" with "cmdlineparts.mtdparts="?
Ben.
--
Ben Hutchings
One of the nice things about standards is that
there are so many of them.
signature.asc
Description: This is a digitally signed message part
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Control: reassign -1 src:linux 4.19.37-5 On Sun, 2019-07-07 at 00:12 +0200, Samuel Thibault wrote: > Package: kernel-wedge > Version: 2.99 > Severity: serious > Tags: a11y > Justification: prevents blind people from using d-i > > We have had (late, unfortunately) reports that HDA-based audio hardware > does not get detected. Actually it does, but only after 60s of delay, > which is way too long for the espeakup script. > > What happens is in snd_hdac_i915_init, which tries to load the i915 > module, which is not included in d-i, and waits for 60s to get it loaded > and bound to it. The delay was "only" 10s in 4.19.12, but apparently > increased to 60s in 4.19.37. > > So I guess we should just ship the i915 module in d-i, either manually > in the existing sound-modules*-di package, or in a separate package and > make sound-modules*-di depend on it. It's a big 3M module, but it would > be shipped only in the gtk images anyway. i915 belongs in fb-modules. I'm not sure that sound-modules should depend on it, as it's not a hard dependency. Recent Intel sound and graphics hardware also needs non-free firmware which is packaged in firmware-intel-sound and firmware-misc-nonfree respectively. Please check that this is included in the non-free installation images. Ben. > It'd definitely be so much useful to have this change uploaded in time > for 10.1. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#931317: debian-installer: A feature to "secure erase" SSDs would be nice
On Mon, 2019-07-01 at 22:09 +0200, Philip Hands wrote: > "Karl O. Pinc" writes: > > > Package: debian-installer > > Severity: wishlist > > Tags: d-i > > > > Hello, > > > > It would be nice if the debian installer included the option to > > "secure erase" SSDs before creating a partition table during > > installation. > > > > A used SSD may have been "over-filled", especially a consumer grade > > device that is not over-provisioned. By this I mean that it has had > > enough cells written that writing requires erasure, which results in > > write-amplification and poor performance. A "secure erase" operation > > restores the original performance of the drive. > > > > I have not put any thought into whether this feature is feasible. > > I think it's probably rather hard to do safely, as IIRC one often needs > to try hdparm, then in order to cause the drive not to be locked do > something like suspend and resume the system, then set an admin > password, and only then do the secure erase ... which then takes > quite a while. I believe that modern drives (both HD and SSD) often have their own encryption layer, and secure erase is implemented by erasing the encryption key and (on an SSD) marking all blocks free in the flash translation layer. But of course we cannot assume that all drives work that way. > Doing that inside d-i reliably seems likely to be quite a challenge, and > then if someone gets bored and turns off the power, their first and last > experience of Debian might well be us converting their SSD into a brick. > > A suggestion for them to think about doing it before installation, in > the installation manual, might be better. That would certainly be a lot easier for us. Ben. -- Ben Hutchings It's easier to fight for one's principles than to live up to them. signature.asc Description: This is a digitally signed message part
