Re: What to do with d-i on armel?
Emanuele Rocca wrote... > Any armel users out there? :-) Fairly late, but just to avoid the impression there aren't any left: Yes, here. But that's not an objection against plans in Debian kernel and/or d-i, I'm using my own kernel, and should I ever have the need of a new installation, I know how to debootstrap and the rest. Besides, the hardware is a Seagate DockStar, so Architecture: armv5tel Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Vendor ID: Marvell Model name: Feroceon-88FR131 and 128 Mbytes of RAM. Running Debian stable already requires some hacks to not end up in thrashing, I might do a presentation "Running Debian on small systems" some day about it. In summary, I'm glad Debian keeps supporting this device - but I'm aware the good times are in the past and it will very likely become e-waste before the hardware dies. If not Debian ends the support, the Linux kernel will. Christoph signature.asc Description: PGP signature
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
Ben Hutchings wrote... > As a temporary workaround, disabling the Spectre v2 mitigation with the > kernel parameter "nospectre_v2" should allow this kernel version to run > on older CPUs without SSE2. We'll fix this properly in a later update. Thank you, that did the right thing on my very old Celeron (Coppermine) CPU from around the year 2000, part of my hardware museum. Christoph signature.asc Description: PGP signature
Bug#886049: Further splice() tests with and without libglib2.0-0
Reiny wrote... > About the above mentioned bug I did some more tests: I built a debug version > of the libglib2.0-0 to see what is happening inside where the splice > function is called. In case of a small file with 112 bytes the splice() is > called inside the function do_splice() in gfile.c for three times: (...) At first, thanks a lot for your analysis. Now my question, does this still happen in buster or sid? Since I could not reproduce the problem in buster, but very well in Ubuntu Bionic, I assume it has been healed the the past weeks, possibly by the latest glib2 upstream release - although I didn't find anything obvious in the sources. Christoph signature.asc Description: PGP signature
Bug#829280: initramfs-tools: "cannot stat '/etc/modprobe.d/*'" warning from empty /etc/modprobe.d/
Michael Prokop wrote... > Right (while kmod ignores the non *.conf files - so no harm done - > it might still be confusing for the user). (...) > http://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?h=mika/829280) > and let us know whether this works for you? Looks good. Thanks for your swift reaction. Christoph signature.asc Description: Digital signature
Bug#829280: initramfs-tools: "cannot stat '/etc/modprobe.d/*'" warning from empty /etc/modprobe.d/
Source: initramfs-tools Version: Warning upon empty /etc/modprobe.d/ Severity: minor Dear Maintainer, when /etc/modprobe.d/ exists but is empty, update-initramfs issues a warning: | # update-initramfs -k all -u | update-initramfs: Generating /boot/initrd.img-4.6.0-1-amd64 | cp: cannot stat '/etc/modprobe.d/*': No such file or directory Besides cosmetical issues I wonder what happens if there are files that just are a reminder of dpkg conffile handling, like e.g. /etc/modprobe.d/pptpd.conf.dpkg-remove since appearently update-initramfs happily processes them. Which is probably not the right thing to do. Christoph -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.4.13 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect signature.asc Description: Digital signature
