Bug#1051208: linux-headers-amd64 6.1.27-1~bpo11+1 depends on a package that is not in the repos
Package: linux-headers-amd64 Version: 6.1.27-1~bpo11+1 Severity: important Dear Maintainer, When installing linux-headers-amd64 from the Backports repo, it depends on the linux-headers-6.1.0-0.deb11.9-amd64 (= 6.1.27-1~bpo11+1) package, which is not found in the mirrors, thus fails. Please update the linux-headers-amd64 package in the backports repository to depend on other kenel, or upload the kernel headers package to the mirrors (the linux-image package for that version is available, just the headers are missing). -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.2.16-3-pve (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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) Versions of packages linux-headers-amd64 depends on: pn linux-headers-5.10.0-22-amd64 pn linux-headers-5.10.0-25-amd64 pn linux-headers-6.1.0-0.deb11.9-amd64 linux-headers-amd64 recommends no packages. linux-headers-amd64 suggests no packages.
Bug#996018: Acknowledgement (linux-image-5.10.0-9-amd64: linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type)
This is not the reason for the absence of kernels 5.10 at startup After the migration to bullseye it was missing update-grub.
Bug#996018: linux-image-5.10.0-9-amd64: linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type
Package: src:linux Version: 5.10.70-1 Severity: important Dear Maintainer, I can't use kernel 5.10 cat I have a building module error === $ sudo dpkg-reconfigure linux-image-5.10.0-9-amd64 /etc/kernel/postinst.d/dkms: dkms: running auto installation service for kernel 5.10.0-9-amd64: Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area... make -j8 KERNELRELEASE=5.10.0-9-amd64 -C /lib/modules/5.10.0-9-amd64/build M=/var/lib/dkms/asus/1.0/build/src modules...(bad exit status: 2) Error! Bad return status for module build on kernel: 5.10.0-9-amd64 (x86_64) Consult /var/lib/dkms/asus/1.0/build/make.log for more information. . /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-5.10.0-9-amd64 $ cat /var/lib/dkms/asus/1.0/build/make.log DKMS make.log for asus-1.0 for kernel 5.10.0-9-amd64 (x86_64) dim. 10 oct. 2021 12:17:37 CEST make : on entre dans le répertoire « /usr/src/linux-headers-5.10.0-9-amd64 » CC [M] /var/lib/dkms/asus/1.0/build/src/hid-asus.o CC [M] /var/lib/dkms/asus/1.0/build/src/i2c-hid.o /var/lib/dkms/asus/1.0/build/src/i2c-hid.c:42:10: fatal error: linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type 42 | #include | ^ compilation terminated. make[2]: *** [/usr/src/linux-headers-5.10.0-9-common/scripts/Makefile.build:285 : /var/lib/dkms/asus/1.0/build/src/i2c-hid.o] Erreur 1 make[2]: *** Attente des tâches non terminées make[1]: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:1846 : /var/lib/dkms/asus/1.0/build/src] Erreur 2 make: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:185 : __sub-make] Erreur 2 make : on quitte le répertoire « /usr/src/linux-headers-5.10.0-9-amd64 » -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: ASUSTeK COMPUTER INC. product_name: N501VW product_version: 1.0 chassis_vendor: ASUSTeK COMPUTER INC. chassis_version: 1.0 bios_vendor: American Megatrends Inc. bios_version: N501VW.300 board_vendor: ASUSTeK COMPUTER INC. board_name: N501VW board_version: 1.0 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:1910] (rev 07) Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [1043:1080] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore 00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:1080] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 07) Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [1043:1080] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: proc_thermal Kernel modules: processor_thermal_device 00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI]) Subsystem: ASUSTeK Computer Inc. 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [1043:201f] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 Signal processing controller [1180]: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem [8086:a131] (rev 31) Subsystem: ASUSTeK Computer Inc. 100 Series/C230 Series Chipset Family Thermal Subsystem
Bug#968099: ethtool: please upgrade to v5.8 to support forcing master or slave mode
Package: ethtool Version: 1:5.4-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Linux 5.7 introduced support for forcing master or slave mode for ethernet devices. This is helpful for debugging issues like Bug#911560, #845128, #927397 suspectedly involving badly calibrated ethernet PHYs. Interacting with theese new features require ethtool 5.8 or newer. Therefore, please upgrade ethtool to 5.8. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8uqhYACgkQLHwxRsGg ASGSyg//cpQFH7EhWMLig8tFxmPI1FPjb7eQS1H60re19zC5lP+3Mru866WwkGmd EGxWRddS4Q/Tr2LB819QE1THIm5iM9AKK8ieSF/dh/wSjllZjAywJIo7B5h+0SX1 +0MzYLZtTYG7VpHXDZwUbZKB/Ii8ikluq6Uu3PiEGNJwQyypGxY+OfnGjaDId/qh VakUHzY5ec54iFiVTzJJx81DCA8j344Ly/UZ2q3BWTRct3Gc2oIllrayKuOI0htH hYVIn4Q+tdB6LeatVD1nozKavp9I6jx2d2dlGV9rUWIO+lgCh4RIBjJZtW9CQyyp mmvJw75bzS0l13UWc1jW38+KbRoFjLpU49iuFyRkt3zmK0BMl2dmyTrGvv6Iju98 9f+HffekycgQw27DA2UohpQhuC4QpD46Phxcx46C9xV71WaDF9Qoxm14veRGU6xA mX+A6B02Uexfgnn8mZEuqJBFClsDUILAnBFRmRudPvjoa6voHEBm8Ex2XhsnJJfo dZseAU4vADhRXc6/S4+eNw1szz9EoXwKTLsLerL+PBwwrSrzJeB45RQz7IEzbM5L 8bi/HDT6XIm63xWt/vOtMNVU51E/C5ftETo8uPq+FKPWbYRrBLm7qu9Gw5bRsCz/ 6c3BCOT3TX78ZzlDkQBfPsnxUlm3QFoT0b1MXSuP/6cBjKsenuw= =/Wc+ -END PGP SIGNATURE-
Bug#960355: Invalid serial console blocks system boot
Package: initramfs-tools-core Version: 0.137 Putting a serial console on a non-existent/broken serial port via the last "console=" argument of the kernel command line causes the initrd to hang without completing the boot process. If the problematic serial console argument comes first in the kernel command line, the system boots without issues. ***To reproduce:*** 1. Check for a non-connected/disabled serial port. On the problematic system running [$] stty -a -F /dev/ttyS1 stty: /dev/ttyS1: Input/output error The serial ports are registered by the "serial8250" driver but are probably not wired to anything. 2. Boot with a kernel command line that puts serial console on a non-existent/broken serial port via last "console=" argument: console=tty0 console=ttyS1,115200n8 3. Check if system boots successfully I am using Debian GNU/Linux 11 (bullseye/testing), vanilla kernel 5.7-rc5. This issue was initially reported multiple times for Debian and Ubuntu to the systemd maintainers as: https://github.com/systemd/systemd/issues/15656 (for Ubuntu) https://github.com/systemd/systemd/issues/15783 (for Debian, duplicate) I am not sure if the _exact_ cause of both issues is the same, because I observed the problem on a very minimal system without console-setup or kbd.
Bug#941660: linux-image-5.2: please enable CONFIG_i2C_AMD_MP2 to make peripherals bound to AMD's platform bus work.
Package: linux-source Version: 5.2+106~bpo10+1 Severity: wishlist Dear maintainers, on AMD Ryzen based laptops several peripherals (such as the touchpad) are connected by the i2c-amd-mp2 bus. The drivers for this bus system were merged into the upstream kernel release 5.2. While Debian Buster only supports the kernel 4.19, its backport repository contains kernel 5.2 which could allow to use the AMD bus. Unfortunately the configuration flag CONFIG_I2C_AMD_MP2 has not been set yet. Therefore I suggest to enable it for kernel 5.2 and above in buster-backports and any newer release. Thank you Best regards Jonas -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-source depends on: ii linux-source-5.2 5.2.9-2~bpo10+1 linux-source recommends no packages. linux-source suggests no packages. -- no debconf information
Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook
Quoting Ben Hutchings (2019-02-27 19:37:41) > Control: severity -1 wishlist > Control: retitle -1 Add option to override filesystem type detection > > On Wed, 2019-02-27 at 18:38 +0100, Jonas Smedegaard wrote: > > Quoting Jonas Smedegaard (2019-02-27 17:45:33) > > > Building a system image using multistrap, > > > including generating an initial ramdisk, > > > worked fine recently. > > > > > > Now it fails with this error message: > > > > > > W: Couldn't identify type of root file system for fsck hook > > > > > > It seems to me that git commit a8ed874 intended to extend the code > > > operating on "auto" mounted filesystems to cover all _except_ root > > > disk, but that the logic is flipped around so that now it _only_ > > > extends that to include root disk: > > This commit went into version 0.123, before stretch, so if your use > case "worked fine recently" then this is not the change that broke it. Heh. I even looked briefly at the date thinking "hmm, committed in January, not February when released was made, but oh well...", and noticed that corresponding bug#767471 had a quite low number... :-) > > Please ignore my guess above: I think I understand now that it was > > intentional to check root disk (I got confused by the comment > > talking about ignoring root and then processing root not skipping > > it). > > > > Let me clarify my use case: I generate a system image on a fast > > amd64 system targeted a slower real device (that's the reason having > > initramfs generated is important). > > > > fstab now unconditionally being distrusted for root disk makes it > > more difficult to build on a different host than intended for target > > boot. > > > > Would it perhaps make sense to support passing pre-resolved root > > filesystem fstype as an environment variable, taking precedence over > > probing? > > I don't think this should be an environment variable but it does seem > like a useful option. Thanks for considering. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook
Quoting Jonas Smedegaard (2019-02-27 17:45:33) > Building a system image using multistrap, > including generating an initial ramdisk, > worked fine recently. > > Now it fails with this error message: > > W: Couldn't identify type of root file system for fsck hook > > It seems to me that git commit a8ed874 intended to extend the code > operating on "auto" mounted filesystems to cover all _except_ root disk, > but that the logic is flipped around so that now it _only_ extends that > to include root disk: Please ignore my guess above: I think I understand now that it was intentional to check root disk (I got confused by the comment talking about ignoring root and then processing root not skipping it). Let me clarify my use case: I generate a system image on a fast amd64 system targeted a slower real device (that's the reason having initramfs generated is important). fstab now unconditionally being distrusted for root disk makes it more difficult to build on a different host than intended for target boot. Would it perhaps make sense to support passing pre-resolved root filesystem fstype as an environment variable, taking precedence over probing? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook
Package: initramfs-tools
Version: 0.133
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Building a system image using multistrap,
including generating an initial ramdisk,
worked fine recently.
Now it fails with this error message:
W: Couldn't identify type of root file system for fsck hook
It seems to me that git commit a8ed874 intended to extend the code
operating on "auto" mounted filesystems to cover all _except_ root disk,
but that the logic is flipped around so that now it _only_ extends that
to include root disk:
- - case "$MNT_TYPE" in
- - auto)
[...]
+ # Ignore filesystem type for /, as it is not available and
+ # therefore never used at boot time
+ if [ "${MNT_DIR}" = "/" ] || [ "${MNT_TYPE}" = "auto" ]; then
- Jonas
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlx2vqoACgkQLHwxRsGg
ASF8ohAAjuJLFgguQyXi0Xp+v2YhFWxqiZxnSBav7/f85S3UjaqUNU3DjXdFv/FJ
7SkzZShmdqGIkpjxGyajRBGbFZzDJkR2Xn7p1T+CcYHvOcUNPfcWzHumc120l9mW
f74frkEC6J/IZX3tFRRXsEZaZ9ZasA16mvoQyL6lXR6ys22gQa3fEVRpGS95jxm2
hH4OorJSLeaGNYiXUMDmav29Aom1We7sojs/fdkQXiSE7Q0nc9jeuOOsSXLkFgKI
EvK88J3YpjuzXGNtwYbVn1QyVAYSAqrDyLyTtjtFwUjQbQc3jy/rYW/DeoTQ8lD2
syKc7e2N0xz02Y3JOQWxMdA+SdlQqeiGkQI7AHL23D0MXLcVkCp9WfWfOAlulpKd
tNrf7+Bc+tSBz4uNy04xP5UzhLcOKOPy1Rxz2ItSd6vZF0BL/4fptMZBMlvqxWsX
f3soeauNDC9F0584K0Fkuhta8jI3KYAJkNOw1omBzjunf8TpnAEKIvr7IfEk9RJp
FnE7TF9fUurxxnZx8crBCzNqFRkwj0oCjno/0HMvNKYbucPaXCD/Oco7aU4/KnbP
YVj5i9V/sfS7f68N3q6tZF09Tcd0IKPkItm7i796GtQRcVwvLpa7CPPMz4WK33bE
P6lP1/ldcx2+THYbL1i4xGhA3S24g4Nn1DSqNZRaZA90cLtZGKU=
=0zMd
-END PGP SIGNATURE-
Re: linux: please enable module sch_cake
Control: found -1 4.19~rc6-1~exp1 Hi kernel team, Quoting Jonas Smedegaard (2018-09-12 23:32:22) > Linux 4.19 introduces an exciting new network queueing algorithm, > sch_cake. > > More about Cake at <https://lwn.net/Articles/758353/> and upstream at > <https://www.bufferbloat.net/projects/codel/wiki/Cake/>. > > Corresponding config option is CONFIG_NET_SCH_CAKE. > > Please enable CONFIG_NET_SCH_CAKE for all architectures: Cake is > useful also on tiny systems used for routing traffic for home > networks. Just a friendly nudge - I am super excited about this feature and would really love to see it enabled soon. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#908709: linux: please enable module sch_cake
Source: linux Version: 4.19~rc2-1~exp1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Linux 4.19 introduces an exciting new network queueing algorithm, sch_cake. More about Cake at <https://lwn.net/Articles/758353/> and upstream at <https://www.bufferbloat.net/projects/codel/wiki/Cake/>. Corresponding config option is CONFIG_NET_SCH_CAKE. Please enable CONFIG_NET_SCH_CAKE for all architectures: Cake is useful also on tiny systems used for routing traffic for home networks. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAluZheMACgkQLHwxRsGg ASEGgBAAkSnMKM6WDN0aDRkuZPG7mf+AbzkyscJ3Ei7Z0695DMVYSITsWfcf/OdK UN1GPaWbM4Id+wrk+PhsvBDDfzZMWneyCem+qT2kvDhiQV1zQ+H2bpMCJLSMOidS 8Efe4y2T8DAeO/Eu7p93VVM/2MDhDwrXQ909fPdd12UCAgInTMhL5IKe2Vb6tEll eOZ5EnIjnNPO2F970Cw3NwL7tX4QDnd3C4khfpdGu6fdWiOrps+hKPRwGSOHk1Ul ryJXVgddrQ03PGgM8C/f5Or35It1rtq7zndMLG/fCfNY97q5QvP50dTjvmuPLJoh IM8Y6Zng1o8LcyKDxqxt3r2GUHSjrMSYbSrPLAoauKel2mMwz0acZOXwz4JzyLVv KFNsXrY3MVVft9shzrvKKSSNeMHT9eloaSIJb1El9HLkd2K0sD1UxfPZNrTA9SCd g2x47Qzzd7GAVo9PkF1JMoFVKnzYcEE62HzuNzh958l1tfCat4AfsLGTboDg82pw iN8mzO2VcfFaZ3QU83t575AR5XSiVKCJ0ueaxyPab9N939YrSSsIxRY2HkPTNiPT UBFajxDZFWzfkkolvuCsrb5W7Q7JeK9vXsSC4OSwrglWkzGPBVqSvE2MhOIaeWrN d1IbdzaN5Gy8NUGG1xdyjcsSF7JJMdtS3Rz8vACj+KMsw+2CA7s= =Txb8 -END PGP SIGNATURE-
Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype
Am 23.08.2018 um 12:43 schrieb Guilhem Moulin:
> On Thu, 23 Aug 2018 at 12:16:35 +0200, Jonas Meurer wrote:
>> Mh. When using LUKS, the cryptsetup scripts should not do any post
>> checks by default. Can you send a detailed log of the script execution?
>> Maybe indeed our initramfs rewrite introduced a regression here.
>> Guildhem, could you look into this?
>
> That's not a regression AFAIK, see https://bugs.debian.org/906283#10 :-)
> But I'll remove the check for LUKS, then.
Agreed. Thanks for looking into it :)
>>>> Why not returning `pttable` too, indicating that it is not a garbage
>>>> inside of it?
>>>> Or do you suggest that cryptsetup integration needs to be adjusted
>>>> instead?
>>>
>>> I think cryptsetup should be adjusted.
>>>
>>> Looking at the local-top script from cryptsetup-initramfs, it seems to
>>> depend rather too closely on details of both initramfs-tools and lvm2.
>>>
>>> - Why does it try to activate a volume group directly? lvm2's scripts
>>> should do that.
>>
>> The problem is that we support both setups with dm-crypt on top of lvm
>> and lvm on top of dm-crypt. That's why we mess around with lvm directly,
>> since the lvm2 local-top script is executed after cryptroot.
>
> I guess you mean the other way around, as the /script/local-top/cryptroot
> has been running last since forever :-P As I just wrote, if
> /script/local-{top,block}/lvm2 were to depend on cryptroot, we wouldn't
> have to manually activate the device for LVM in dm-crypt setups.
Upps, you're right. I'm to busy these days and didn't check properly.
Cheers
jonas
signature.asc
Description: OpenPGP digital signature
Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype
Hello, Am 22.08.2018 um 22:22 schrieb Ben Hutchings: > On Tue, 2018-08-21 at 08:38 +0300, Nazar Mokrynskyi wrote: >> 21.08.18 02:57, Ben Hutchings пише: > [...] >>> LVM inside LUKS (I don't know why you call it multi-layer LVM) is well >>> supported in Debian, so I find this statement surprising. >> >> I know it is supported and expressed this awareness initially. >> I call it multi-layer because it has concepts of VGs, PVs and LVs, >> which are not straightforward to use, I know this is not technically >> correct, sorry about that. >> For instance, I was recently moving my fully encrypted Ubuntu (LVM on >> top of LUKS) from 500GB HDD to 256GB SSD. >> It was a painful and risky operation with no support from graphical >> utilities. I did it successfully, but I'd like to not doing this ever >> again. >> Which is why I found regular partition table much easier to use - I >> can just open it with GParted, shrink partitions, move them to the >> beginning of the disk and `dd` as much of it as I need. Easy. > > Yes, shrinking is easy to get wrong with the command line tools. > > On the other hand, moving to new physical media is generally easier and > safer with LVM: you add the new PV to the group, use pvmove to move all > volumes, and then remove the old PV. This can be interrupted without > losing data. > >>> What's more, Linux block drivers have to opt in to supporting >>> partitions, and dm-crypt doesn't do that. So the kernel doesn't look >>> for a partition table on a dm-crypt device. >> >> The primary issue for me is that LUKS container can contain a valid >> partition table and I can add a hook for initramfs to recornize it, >> but because cryptsetup integration checks for known partitions an >> doesn't find any, it closes LUKS container immediately with "unknown >> fstype, bad password or options?". >> This is extemely inconvenient and requires me to edit initramfs's >> files, wich will be reverted on upgrades, and I'd like to avoid it by >> having native support so this use case. > > So this should be dealt with in cryptsetup-initramfs. Mh. When using LUKS, the cryptsetup scripts should not do any post checks by default. Can you send a detailed log of the script execution? Maybe indeed our initramfs rewrite introduced a regression here. Guildhem, could you look into this? >> Why not returning `pttable` too, indicating that it is not a garbage >> inside of it? >> Or do you suggest that cryptsetup integration needs to be adjusted >> instead? > > I think cryptsetup should be adjusted. > > Looking at the local-top script from cryptsetup-initramfs, it seems to > depend rather too closely on details of both initramfs-tools and lvm2. > > - Why does it try to activate a volume group directly? lvm2's scripts > should do that. The problem is that we support both setups with dm-crypt on top of lvm and lvm on top of dm-crypt. That's why we mess around with lvm directly, since the lvm2 local-top script is executed after cryptroot. > - I don't think it should probe the contents of the encrypted volume at > all. That would mean that a wrong password for a non-LUKS device won't > be specifically detected and reported. But LUKS is strongly > recommended, and I don't think this makes the non-LUKS user experience > significantly worse. For non-LUKS devices, the post checks are the only possibility to detect whether you successfully entered the correct passphrase (or provided the correct key). Besides, it provides a security measure against accidently overriding the wrong partitions when setting up encrypted tmpfs or swap partitions. Cheers, jonas signature.asc Description: OpenPGP digital signature
Bug#903587: src:linux: FTBFS on arm64: of_mdio module in two packages
Package: src:linux Version: 4.18~rc3-1~exp1 Severity: serious Justification: fails to build from source (but built successfully in the past) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 of_mdio module in two packages on amd64 Hi, buildlogs for experimental¹ hints that amd64 package failed to build: > some modules are in more than one package > debian/nic-usb-modules-4.18.0-rc3-arm64-di > lib/modules/4.18.0-rc3-arm64/kernel/drivers/of/of_mdio.ko > debian/nic-modules-4.18.0-rc3-arm64-di > lib/modules/4.18.0-rc3-arm64/kernel/drivers/of/of_mdio.ko https://buildd.debian.org/status/package.php?p=linux=experimental - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAltGHeEACgkQLHwxRsGg ASEi4hAAmSyghQBrvT1OM08YR91h1YQitcBuQj4uOX8CW0lEwkYvrcjU5zYfzDja e5TUAxfilyrjaaUFLS63xbKZC9hCU+y8/hW7unxqlJpLd2DkENzUGi/H/e/nG1PY cdpGnayOhWErQqiiuvdBAMPM3HhrJZhheAvI9SkDDyPFDjXwKFnT8faB8Cldr7Al i0yHTmkaZphjNvhb+OOLkesfntctPMDMk8chZVCpRrDGRWeQvri1vEuDo36rWl5r /S1eoKq/6mwEwwtGQmDjga2rmo+4f5i2M9v+eBJwN1irYyh8sa3GFeEMnV2Ka4KB ubFtfHXiChjra5vGEG7fO+YokugPs8gIjPBKK7m0YlJY4EMiPZGQpMh0Kq5S50bg +Pz4V8fkv6zL5kDS9NeEIJJ+2NA4jaTR7/NZd0bJHPjR/QmQABaetSKKt9BWHskI tc8dinjIXifnEVG09cHxyrSp9LHfinzS17wXK3Ujq5P3oo1LaI8TfzvFqrUIyW4b U1fDH96AyzjyUghITn3eUoeVI6Ra7PKexqmIYTVH+sMQEMCViHOut2cnLycBlpT5 uhRygYl3RdgtnIFtiU0kVtAYp3kbkeLzZXGZFBvt5btrC8p1VITsamo/K4UB9XhG kno5N65tqeCyGg6MnRUZ4IqOaVsXZQXIN/ac7oF1PRcI6J5Ou7c= =E0Ql -END PGP SIGNATURE-
Bug#901702: Add locale and gettext support to initramfs
Am 17.06.2018 um 02:53 schrieb Jonas Meurer:
> I've prepared a patch that optionally adds locale and gettext support to
> initramfs (depending on a initramfs.conf variable). You can find the
> patch attached to this bugreport or as a merge request on Salsa[2].
> Whatever you prefer ;)
I just discovered a bug in the patch. The dummy eval_{n,}gettext()
functions provided if no gettext support is installed have to eval the
provided input as well in order to behave similar to the ones provided
by gettext.sh.
The updated patch is attached and can be found in the merge request[1].
Cheers
jonas
[1] https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/4
From c3a3e94a87946d0eb782b3147409ac37123febdf Mon Sep 17 00:00:00 2001
From: Jonas Meurer
Date: Sun, 17 Jun 2018 01:37:03 +0200
Subject: [PATCH] Add support for locales and gettext to initramfs
---
conf/initramfs.conf | 8
hooks/locales | 47 +++
initramfs-tools.8 | 11 +++
initramfs.conf.5| 5 +
mkinitramfs | 1 +
scripts/functions | 16
6 files changed, 88 insertions(+)
create mode 100755 hooks/locales
diff --git a/conf/initramfs.conf b/conf/initramfs.conf
index 1319536..12a361c 100644
--- a/conf/initramfs.conf
+++ b/conf/initramfs.conf
@@ -38,6 +38,14 @@ BUSYBOX=auto
KEYMAP=n
#
+# LOCALES: [ y | n ]
+#
+# Add locales and gettext to the initramfs.
+#
+
+LOCALES=n
+
+#
# COMPRESS: [ gzip | bzip2 | lzma | lzop | xz ]
#
diff --git a/hooks/locales b/hooks/locales
new file mode 100755
index 000..8320f67
--- /dev/null
+++ b/hooks/locales
@@ -0,0 +1,47 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+ echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+# Hook to load locales and gettext into initramfs if requested by LOCALES=y
+if [ "$LOCALES" != "y" ] && [ "$LOCALES" != "Y" ]; then
+ exit 0
+fi
+
+if [ ! -x /usr/bin/locale ]; then
+ echo "locale is missing. Please install the 'locales' package."
+ exit 0
+fi
+
+. /usr/share/initramfs-tools/hook-functions
+
+# Copy binaries required for gettext support
+copy_exec /usr/bin/envsubst
+copy_exec /usr/bin/gettext
+copy_exec /usr/bin/gettext.sh
+copy_exec /usr/bin/ngettext
+
+# Copy locale files except LC_COLLATE. It's not needed for localized string
+# support and usually is by far the biggest locale file.
+for file in $(find /usr/lib/locale -type f \! -name LC_COLLATE 2>/dev/null); do
+ copy_file locale_file $file
+done
+
+# Write locale variables to initramfs conf.d
+for line in $(locale); do
+ if [ "${line#LC_COLLATE}" = "$line" ]; then
+ echo "export $line" >>${DESTDIR}/conf/conf.d/locales
+ fi
+done
diff --git a/initramfs-tools.8 b/initramfs-tools.8
index 32cce2d..0481131 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -424,6 +424,17 @@ user to investigate the situation.
panic "Frobnication failed"
.RE
+.TP
+\fB\fI
+gettext_support
+Either loads /usr/bin/gettext.sh (if available) or provides dummy functions
+eval_gettext() and eval_ngettext() functions otherwise.
+.RS
+.PP
+.B Example:
+gettext_support
+.RE
+
.SS Subdirectories
Both /usr/share/initramfs-tools/scripts and /etc/initramfs-tools/scripts
contains the following subdirectories.
diff --git a/initramfs.conf.5 b/initramfs.conf.5
index 569834c..4587e2f 100644
--- a/initramfs.conf.5
+++ b/initramfs.conf.5
@@ -57,6 +57,11 @@ that might need input will normally set this variable automatically, so there
should normally be no need to set this.
.TP
+\fB LOCALES
+If set to 'y', locales and gettext will be installed into the initramfs and
+locale environment variables will be set.
+
+.TP
\fB COMPRESS
Specifies the compression method used for the initramfs image.
.B mkinitramfs
diff --git a/mkinitramfs b/mkinitramfs
index 24715d5..ab9ede5 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -203,6 +203,7 @@ export DESTDIR
export DPKG_ARCH
export verbose
export KEYMAP
+export LOCALES
export MODULES
export BUSYBOX
export RESUME
diff --git a/scripts/functions b/scripts/functions
index 0b7ca10..d6d18ae 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -463,3 +463,19 @@ mount_bottom()
{
:
}
+
+# Load /usr/bin/gettext.sh if available, provide dummy functions eval_gettext()
+# and eval_ngettext() otherwise.
+gettext_support()
+{
+ if [ -f "/usr/bin/gettext.sh" ]; then
+ . /usr/bin/gettext.sh
+ else
+ eval_gettext() {
+ eval echo "$1"
+ }
+ eval_ngettext() {
+ eval echo "$1"
+ }
+ fi
+}
--
2.11.0
signature.asc
Description: OpenPGP digital signature
Bug#901702: Add locale and gettext support to initramfs
Package: initramfs-tools
Version: 0.130
Severity: normal
Tags: l10n patch
Hello,
when trying to add l10n support to the cryptsetup initramfs script I was
surprised to realize that apparently no initramfs component has l10n
support yet.
Probably that's because most messages from initramfs are more targeted
at developers. Unfortunately, that's not true for the initramfs scripts
of cryptsetup. Here, we need to ask users for input (passphrase) and
therefore the messages we print are targeted at normal users. There's
also an open bugreport that requests support for translated strings[1].
I first thought about adding all the required locale and gettext stuff
to initramfs in the cryptroot hook, but after thinking about it again,
I think it should be done in initramfs itself instead. Other initramfs
components might want to use it as well.
That's why I'd like to add locale and gettext support to initramfs but
make it optional. Without any prompts targeted at endusers, there's no
real need to bloat the initramfs with locales and gettext files. But
e.g. in the cryptsetup package, we would enable it.
I've prepared a patch that optionally adds locale and gettext support to
initramfs (depending on a initramfs.conf variable). You can find the
patch attached to this bugreport or as a merge request on Salsa[2].
Whatever you prefer ;)
Would be awesome if you could consider to merge it. It's a prerequisite
for adding l10n support to the cryptsetup initramfs scripts.
Cheers,
jonas
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688735
[2] https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/4
>From c3a3e94a87946d0eb782b3147409ac37123febdf Mon Sep 17 00:00:00 2001
From: Jonas Meurer
Date: Sun, 17 Jun 2018 01:37:03 +0200
Subject: [PATCH] Add support for locales and gettext to initramfs
---
conf/initramfs.conf | 8
hooks/locales | 47 +++
initramfs-tools.8 | 11 +++
initramfs.conf.5| 5 +
mkinitramfs | 1 +
scripts/functions | 16
6 files changed, 88 insertions(+)
create mode 100755 hooks/locales
diff --git a/conf/initramfs.conf b/conf/initramfs.conf
index 1319536..12a361c 100644
--- a/conf/initramfs.conf
+++ b/conf/initramfs.conf
@@ -38,6 +38,14 @@ BUSYBOX=auto
KEYMAP=n
#
+# LOCALES: [ y | n ]
+#
+# Add locales and gettext to the initramfs.
+#
+
+LOCALES=n
+
+#
# COMPRESS: [ gzip | bzip2 | lzma | lzop | xz ]
#
diff --git a/hooks/locales b/hooks/locales
new file mode 100755
index 000..8320f67
--- /dev/null
+++ b/hooks/locales
@@ -0,0 +1,47 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+ echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+# Hook to load locales and gettext into initramfs if requested by LOCALES=y
+if [ "$LOCALES" != "y" ] && [ "$LOCALES" != "Y" ]; then
+ exit 0
+fi
+
+if [ ! -x /usr/bin/locale ]; then
+ echo "locale is missing. Please install the 'locales' package."
+ exit 0
+fi
+
+. /usr/share/initramfs-tools/hook-functions
+
+# Copy binaries required for gettext support
+copy_exec /usr/bin/envsubst
+copy_exec /usr/bin/gettext
+copy_exec /usr/bin/gettext.sh
+copy_exec /usr/bin/ngettext
+
+# Copy locale files except LC_COLLATE. It's not needed for localized string
+# support and usually is by far the biggest locale file.
+for file in $(find /usr/lib/locale -type f \! -name LC_COLLATE 2>/dev/null); do
+ copy_file locale_file $file
+done
+
+# Write locale variables to initramfs conf.d
+for line in $(locale); do
+ if [ "${line#LC_COLLATE}" = "$line" ]; then
+ echo "export $line" >>${DESTDIR}/conf/conf.d/locales
+ fi
+done
diff --git a/initramfs-tools.8 b/initramfs-tools.8
index 32cce2d..0481131 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -424,6 +424,17 @@ user to investigate the situation.
panic "Frobnication failed"
.RE
+.TP
+\fB\fI
+gettext_support
+Either loads /usr/bin/gettext.sh (if available) or provides dummy functions
+eval_gettext() and eval_ngettext() functions otherwise.
+.RS
+.PP
+.B Example:
+gettext_support
+.RE
+
.SS Subdirectories
Both /usr/share/initramfs-tools/scripts and /etc/initramfs-tools/scripts
contains the following subdirectories.
diff --git a/initramfs.conf.5 b/initramfs.conf.5
index 569834c..4587e2f 100644
--- a/initramfs.conf.5
+++ b/initramfs.conf.5
@@ -57,6 +57,11 @@ that might need input will normally set this variable
automatically, so there
should normally be no need to set this.
.TP
+\fB LOCALES
+If set to 'y', locales and gettext will be installed into the initramfs and
+locale environment variables will be set.
+
+.TP
\fB COMPRESS
Specifies the compression method used for the initramfs image.
.B mkinitramfs
diff --git a/mkinitramfs b/mkinitramfs
inde
Bug#881570: linux-image-4.14.0-rc7-armmp-lpae: please enable DRM_SUN4I_HDMI_CEC
Package: src:linux Version: 4.14~rc7-1~exp1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Kernel 4.14 introduces support for HDMI CEC support for Allwinner A10/A20 SoC. Please enable that - it should be DRM_SUN4I_HDMI_CEC (which I guess need DRM_SUN4I enabled too). - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloJEzcACgkQLHwxRsGg ASErsQ/9FrlJikZTdHkZvMVnTLxGSPgEsUulz3BjbBrE7SnqjQTEH9yp+t4YVt2n qQKg8/T52CEp+rp0fW66hef90owE31ptfZE/hzQeP3h44utCmbFX5b2msrItVkZR TRqEyCER7oSG59EQF8RoCiJ6/qeqLWsh6pVBxBCmud7oskh1j1NWCbKBRkwZnB4/ J1newkLSVhNFMyLCqZkdZMCPzZlOEPkZyBS7+H6Pj3EmwEusTIXNhoQKnYLpzDjM 2jGDFxh+YbnY+F9ggYMO2B1KvPBYwcSebm+PGgq4rgNoMlobuVYOG0X8y3C1E8st ZZFMFJgdNrVjHDFgQNLw80sGRpzIG8ZjoZa94dDhItgzxRpmWG3cuGbIfaIc6Dl6 CPdxOSyEp7dife2udxlD+jzHKl6UoQ72xaKWyIWlZ85v39KaR/08Eq3kny8dOQcS smHMEYIH6lAte3VYxpxbAve++mianhQ3WRwpIE6AGghpCryBwJCpL2XJajFmIZru VXeQX6iLvVNd9jcHizIlZ4Mo+oSgTTGdgaq0q3pjIHHZtOCuWcd3xu9NuIGqJIbI 0tkffloNLOrJGXr7PlgeGLVohii4NjLanlYp0rVT/AcXjaUxR1Fpt7KbOlpohBO+ /u/k1s4tutaEtgjq9c3TJQTs6pKU4XNj1Hp+FW5aSycGLuzCRw8= =RKr3 -END PGP SIGNATURE-
Bug#881568: src:linux: please enable CONFIG_RTL8723BS (staging driver for wifi used in TERES-I laptop)
Package: src:linux Version: 4.14~rc7-1~exp1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please enable CONFIG_RTL8723BS, for building the staging driver for the Realtek 8723bs wifi+bluetooth chip used in at least the Olimex TERES-I DIY laptop. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloI/EcACgkQLHwxRsGg ASEcOA//WgXyEORnEX4hmbiEQQjfVXu1i/qnCy/ADIbDFmcc3rjqNmju95yIjQCe 8QhvbfR5febUowwAyqkoIT+u2iIHdss4N+Fl0n1VEdgJSf8Mjo8yDRf9INzBF2BU 7FnK0E1oHDWgjwCHA/xrVqY2kP8j46X3rtPErBEOSUgAN/XP1qXyPTOasq4/Mh49 wxQLoHMp8O6qFoB6wuy/YN0zzslYU2lo6T5aflJ7rnyZH6LuBi0YMJgHf7oTVHfQ lw/vFw9+jxTflQc9SbBt6tmfikrCHaVmiRp56ze1mWsNExbGBVfnpjyW0AUtJcUg D1gvHSuRofepWxivEcbt6yQ44Y82Q++IXGUHpCX1P+8Of4pesp2idhIhl6BQNKET Z0siYEU7WxuVuo9544I2LTJH6IeG/Z0TF2iiFTTv5iIxK6GsYGXW1uZSCvkZXdSZ 6XRPRdD6iC8Veb/Ex1KB94MjI0KTCfb4yDPBQhVbTe+59VOk5YWQ98E7SAOoi16p rjiflvyHLjODQIsQGJTlvO9ypqBafy5EOi/EfVhIPO2pyp6DZrBMa4+0MJjQQcfO /udWWuyr7d3/6NeMdiMs0cWDNaZOKQbQ7N5vYAs6Z2lAoQqjmYuXviKNKuIVi7Qn CB6XfIrzIIjx6gQZW3uhKKkc84g2p/I9HCgB36DX40LyUTSX5A0= =KBr/ -END PGP SIGNATURE-
Bug#881567: linux-image-4.14.0-rc7-arm64: Consider enabling CONFIG_NVMEM_SUNXI_SID
Package: src:linux Version: 4.14~rc7-1~exp1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 In checking what my exciting new Olimex TERES-I laptop is capable of, I notice that CONFIG_NVMEM_SUNXI_SID is disabled in its config. The feature is available on all Allwinner SoC apparently, and documented at <http://linux-sunxi.org/SID_Register_Guide>, so probably relevant to enable both on arm64 and armmp kernels. I don't have a crucial need for this personally, but wonder if harmless to enable in case someone finds it useful. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloI+csACgkQLHwxRsGg ASErpA//SBRc+UWtVap6ECUPPYGs496DGtvzP2dR/y2+FzjzBbVGQM3wB2U8nnNY lqskyRRJzGrQH0YlvqfGEBMmZngGFFputPXOZHRe5gzjFMn+H2jj0YoIAuwP8eu6 FHLwhAqiPnLhOuew0aFMjUQr5xdy5dvM5uv0CiZve/53oaYogVmyeb26L1GC4Gdf Nq1wrboqr7vAlXGtUAqJID9pblRBJrZ+ZAaEkKxn9smH+1k3l/LZkdCQbXAsY2SO dH6CxTQNTapbvC8wfZVhJLeTj7EEgP+Y4SS4SGi4GZ4rXnu449gdPumTiRDXV2zN uwWGoZMnCeVJW0lia31FTr63Vcv1y25qYq9xstUJsoi9+1UIbdVqyfeBo33kHPkb nKkiJkPfCGlNQI6RMEofqsubUak+VV5BULxYcIyc3AwwHxbPQJCkF5m0Aijk55x9 adN+7mIUhmwFd8wlcaOXagoyPPHxFv83ep3stxpDILvSlgdfRlCFKvAhMIYffP8B KxzfENto7el6wpshROTxrbPACrpArorEJhG4dGt2QjA9gvLsDmNY5DxTJ8u22RF1 hoE+UUNLcj7yehEH/xZryOKk1SvzFi6VIC+S4kT9SY5HalkRRSCbbRz42+TDv4XS 3mKcPrl3FqMh5thsJv5gzLwiLy+4DOwjdiyy8zphMTOsiYKa0AQ= =9oPJ -END PGP SIGNATURE-
☢yay some interesting facts
Hello, I've found that interesting article with a whole lot of surprising reality, simply take a look http://songynghia.com/principal.php?0e0f Thanks for your consideration, Jonas Meurer
Bug#855094: [pkg-cryptsetup-devel] Bug#855094: initramfs-tools-core: Error on upgrade if cryptsetup is installed, but a current busybox isn't
Hi intigeri, hi Guilhem, Am 02.04.2017 um 10:10 schrieb Guilhem Moulin: > On Sun, 02 Apr 2017 at 09:50:55 +0200, intrigeri wrote: >> So at this point, I suggest this bug is reassigned to cryptsetup, and >> option 3 is implemented there. But downgrading to non-RC and leaving >> things as-is seems acceptable to me as well. >> >> Thoughts? > > I think the proper fix would be to split cryptsetup's initramfs bits to > a separate package (depending on busybox), cf. #783297. It's > unfortunate that we didn't implement that in time for Stretch, but > considering the impact of this, I'd favor downgrading the severity and > merging the bugs for the time being. I fully agree with Guilhem here. We should split out cryptsetup-initramfs as soon as Stretch is released and make it depend on initramfs-tools and busybox. Cheers, jonas signature.asc Description: OpenPGP digital signature
Bug#815480: cryptsetup: versions before 1.7.1 incompatible with latest batch of Linux kernels (mainline and stable)
Hi Ben, On Mon, 07 Mar 2016 03:45:17 + Ben Hutchings <b...@decadent.org.uk> wrote: > Control: retitle -1 Linux kernel crypto 'no key'Â patches break cryptsetup if > not carefully backported > > Linux 3.2.78 and 3.16.7-ckt25 have this problem, but I have fixed it > (at least, the result works on my machine!) before uploading stable > updates based on those versions. > > If you use any other stable kernel branch, you'll need to either > upgrade to 4.4 or request the appropriate stable maintainer fixes their > backport of the 'no key' patches. Probably this bugreport should be closed, no? To my understanding, the Linux kernels in Debian are all patched to fix this problem and besides, cryptsetup packages in Unstable and Stretch are fixed to work with the backwards-incompatible changes anyway since quite some time. Cheers, jonas signature.asc Description: OpenPGP digital signature
Bug#841512: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#841512: (no subject))
Quoting Debian Bug Tracking System (2016-10-21 16:39:13) > > Purging the package fails if its directory below /lib/modules is > > already removed: [...] > > P.S. I actually cheated a bit for the subject line: I copied the > > seemingly identical but english string from bug#841453 > > You deliberately opened a duplicate bug? What was the point of that? Not deliberately - I got confused by linux → linux-signed naming: Checking for existing bugs I saw bug#841453 and checked it out, but stopped at its getting reassigned to another package. Only now thanks to your terse remark did I read again in full, realizing that the other package was the very one I had problem with myself :-P Sorry for the noise! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#841512: (no subject)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Subject: linux-image-4.7.0-1-amd64: cannot purge: rmdir: failed to remove '/lib/modules/4.7.0-1-amd64': Directory not empty Package: src:linux Version: 4.7.6-1 Severity: normal Purging the package fails if its directory below /lib/modules is already removed: (Læser database ... 287580 filer og kataloger installeret i øjeblikket.) Afinstallerer linux-image-4.7.0-1-amd64 (4.7.6-1) ... Renser ud i konfigurationsfilerne for linux-image-4.7.0-1-amd64 (4.7.6-1)... rmdir: kunne ikke fjerne '/lib/modules/4.7.0-1-amd64': Ingen sådan fil eller filkatalog dpkg: fejl under behandling af pakken linux-image-4.7.0-1-amd64 (--purge): underproces installerede post-removal-script returnerede afslutningsstatus 1 Above is in danish, but I guess keywords are similar enough to english to recognize what is happening. Workaround was to add an empty directory. - Jonas P.S. I actually cheated a bit for the subject line: I copied the seemingly identical but english string from bug#841453 -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYCeS3AAoJECx8MUbBoAEh9g8QAJIDfPv3451JkOs3XXS26Sdm s2VksAlm2AqHNhtZ7KzrhFyTun70OJshN24LUXAtC+8sUawssjgBecKIairEIO5O IK9tDVLphOrDptjJBTT/YYcEZxqIAXq/YKvnxq5enp3QKSpqwcMB38ZB/uPWNkyW iRHaE+rOzKyBjcAukAZHC3n69IXPuraKs6dawEOctDYK+jTyQILRuYt+WT3+lgnS kZOrVPvPPEQ8R+KHSDVua8K6EnvCX+k4LSwlFwZ+BSkbH5ILyvyskjWjKtDEND3P biI9PqvvReufgd2uPtl/TTXF5x032NHTq9dq2HH8OlYoyOhAkVkR9HdwJnVyfbwd ri23Vl/373l7fglTeXfAa6ewHgWtteL6oBBbiCsdoOs/+YCbHr1sODBcNxh3PLHz VmFx5YCxIKC47ws64/RJFJmSu89V8VkS1Dx31u8nKPHmrhWK+fvz0Hn4ZsCb/J8Q eKMBKyPvSXsexwHtqoV3eIjjYzx2Vtzv4M4YULnVxFTpJ33pZANaYrYt4GpqBt3b 0YE/LRhf6rgnnvq27lx0DROmxzZNPE2f2VsiAlRfkmlLRp4CjEUsq0hoiDE64APQ IHnaYJ/IzXCCOG/ZZfqtA4pRury9+MvB0Bblthv7iew3VTSujREhKIkTEnSzDox6 UnuXS4vLIhbSmrxjnuYJ =olj0 -END PGP SIGNATURE-
Bug#841289: [drm/i915] GPU HANG: ecode 9:0:0xfffffffe, in Xorg [2507], reason: Engine(s) hung, action: reset
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=98332 Am 19.10.2016 um 14:35 schrieb Ben Hutchings: > On Wed, 2016-10-19 at 13:53 +0200, Jonas Meurer wrote: >> Package: src:linux >> Version: 4.7.6-1 >> Severity: grave >> Justification: renders package unusable >> >> Hello, >> >> recently, something on my system related to drm/i915 broke. Since no >> xserver/drm packages have been upgraded, I strongly suspect the >> latest >> linux kernel upgrade to be the culprit. > > Please open a bug upstream as recommended: Thanks for the prompt reply. > Then let us know the bug number or URL. It can be found here: https://bugs.freedesktop.org/show_bug.cgi?id=98332 Cheers, jonas signature.asc Description: OpenPGP digital signature
Bug#841289: [drm/i915] GPU HANG: ecode 9:0:0xfffffffe, in Xorg [2507], reason: Engine(s) hung, action: reset
Package: src:linux Version: 4.7.6-1 Severity: grave Justification: renders package unusable Hello, recently, something on my system related to drm/i915 broke. Since no xserver/drm packages have been upgraded, I strongly suspect the latest linux kernel upgrade to be the culprit. Since several days, the X server on my Lenovo Thinkpad T460 sometimes freezes, apparently when gnome locks and turns of the screen after some time of inactivity. This renders the system completely unusable, it seems to not react at all anymore. Also changing to a text consoly (tty) doesn't work. Below you find a copy of the relevant syslog entries. Unfortunately, since the system is rendered unusable, I'm not able to save the crash details from /sys/class/drm/card0/error. After reboot, it obviously is empty again. Please tell me if I can do anything more to debug this bug. It's very annoying as it sometimes implies loosing things that you just worked on. Unfortunately, I don't know another way to reproduce the bug apart from waiting for the automatic screen lock. Then you have to be (un)lucky because it doesn't freeze every time. Cheers, jonas (Assumed) relevant logs from /var/log/syslog: [...] Oct 12 21:43:01 calvin2 kernel: [11219.762878] [drm] RC6 on Oct 12 21:43:25 calvin2 kernel: [11243.760753] [drm] RC6 on Oct 12 21:43:54 calvin2 kernel: [11272.758240] [drm] RC6 on Oct 12 21:44:23 calvin2 kernel: [11301.754923] [drm] RC6 on Oct 12 21:44:40 calvin2 kernel: [11318.753426] [drm] stuck on render ring Oct 12 21:44:40 calvin2 kernel: [11318.754593] [drm] GPU HANG: ecode 9:0:0xfffe, in Xorg [2507], reas on: Engine(s) hung, action: reset Oct 12 21:44:40 calvin2 kernel: [11318.754599] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. Oct 12 21:44:40 calvin2 kernel: [11318.754603] [drm] Please file a _new_ bug report on bugs.freedesktop.o rg against DRI -> DRM/Intel Oct 12 21:44:40 calvin2 kernel: [11318.754607] [drm] drm/i915 developers can then reassign to the right c omponent if it's not a kernel issue. Oct 12 21:44:40 calvin2 kernel: [11318.754610] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. Oct 12 21:44:40 calvin2 kernel: [11318.754614] [drm] GPU crash dump saved to /sys/class/drm/card0/error Oct 12 21:44:40 calvin2 kernel: [11318.756979] drm/i915: Resetting chip after gpu hang Oct 12 21:44:41 calvin2 kernel: [11319.761430] [drm] RC6 on Oct 12 21:44:50 calvin2 kernel: [11328.752757] [drm] stuck on render ring Oct 12 21:44:50 calvin2 kernel: [11328.753891] [drm] GPU HANG: ecode 9:0:0xfffe, in Xorg [2507], reason: Engine(s) hung, action: reset Oct 12 21:44:50 calvin2 kernel: [11328.756633] drm/i915: Resetting chip after gpu hang Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): EDID vendor "LGD", prod id 1188 Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): Printing DDC gathered Modelines: Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): Modeline "1920x1080"x0.0 138.70 1920 1968 2000 2080 1080 1083 1088 +hsync -vsync (66.7 kHz eP) Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): EDID vendor "LGD", prod id 1188 Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): Printing DDC gathered Modelines: Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): Modeline "1920x1080"x0.0 138.70 1920 1968 2000 2080 1080 1083 1088 +hsync -vsync (66.7 kHz eP) Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): EDID vendor "LGD", prod id 1188 Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): Printing DDC gathered Modelines: Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): Modeline "1920x1080"x0.0 138.70 1920 1968 2000 2080 1080 1083 1088 +hsync -vsync (66.7 kHz eP) Oct 12 21:44:51 calvin2 kernel: [11329.760399] [drm] RC6 on Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: intel_do_flush_locked failed: Input/output error Oct 12 21:44:51 calvin2 firefox-esr.desktop[3113]: firefox-esr: Fatal IO error 11 (Die Ressource ist zur Zeit nicht verfügbar) on X server :0. Oct 12 21:44:51 calvin2 pidgin.desktop[2749]: Pidgin: Fatal IO error 11 (Die Ressource ist zur Zeit nicht verfügbar) on X server :0. [...] Oct 12 21:44:51 calvin2 kernel: [11329.834184] Qt bearer threa[2850]: segfault at 0 ip 7fd4d6fbe9e5 sp 7fd4b7b8e560 error 4 in libQt5DBus.so.5.6.1[7fd4d6f5c000+87000] Oct 12 21:44:51 calvin2 nautilus-autostart.desktop[2779]: Server response: STATUS:OK:/home/user Oct 12 21:44:51 calvin2 org.a11y.atspi.Registry[2589]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" Oct 12 21:44:51 calvin2 org.a11y.atspi.Registry[2589]: after 17393 requests
Bug#825403: linux: [regression from 4.5.0-1] power consumption increased significantly on T460p
It appears to me that the problem is fixed with 4.7.0-1. best regards, jwi
Bug#833355: Please package new upstream version with ucode files for Intel Wireless 8260
Package: firmware-iwlwifi Version: 20160110-1 Severity: important Hello, for the Intel Wireless 8260 controller, several ucode files are missing, that are published upstream: # lspci -v -s 04:00.0 04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a) Subsystem: Intel Corporation Wireless 8260 Flags: bus master, fast devsel, latency 0, IRQ 126 Memory at f100 (64-bit, non-prefetchable) [size=8K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 44-85-00-ff-ff-12-53-bd Capabilities: [14c] Latency Tolerance Reporting Capabilities: [154] L1 PM Substates Kernel driver in use: iwlwifi Kernel modules: iwlwifi # dmesg |grep iwlwifi [ 21.639144] iwlwifi :04:00.0: firmware: failed to load iwlwifi-8000C-21.ucode (-2) [ 21.639149] iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-21.ucode failed with error -2 [ 21.639159] iwlwifi :04:00.0: firmware: failed to load iwlwifi-8000C-20.ucode (-2) [ 21.639162] iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-20.ucode failed with error -2 [ 21.639169] iwlwifi :04:00.0: firmware: failed to load iwlwifi-8000C-19.ucode (-2) [ 21.639176] iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-19.ucode failed with error -2 [ 21.639184] iwlwifi :04:00.0: firmware: failed to load iwlwifi-8000C-18.ucode (-2) [ 21.639190] iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-18.ucode failed with error -2 [ 21.639197] iwlwifi :04:00.0: firmware: failed to load iwlwifi-8000C-17.ucode (-2) [ 21.639203] iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-17.ucode failed with error -2 [ 21.639458] iwlwifi :04:00.0: Unsupported splx structure [ 21.645714] iwlwifi :04:00.0: firmware: direct-loading firmware iwlwifi-8000C-16.ucode [ 21.646255] iwlwifi :04:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm # cat /proc/version Linux version 4.6.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18) The missing ucode files are distributed upstream at https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/tree/ Greetings, jonas -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.125 -- no debconf information
Bug#825403: linux: [regression from 4.5.0-1] power consumption increased significantly on T460p
Source: linux Version: 4.5.0-2 Severity: normal Dear Maintainer, Since the dist-upgrade this weekend, I noticed massively increased power consuption on my T460p. I measure this by battery lifetime and the wattage reported by ACPI. The wattage has increased from the range of 7W -- 10W with my usage pattern to 10W -- 12W. These increased metrics are not due to a change in measurement. The battery life has reduced alongside. I have tested with 4.5.0-1 and the problem does not occur there. I was unable to find a possible cause using powertop. What I noticed is that the fan runs even though it would normally not under the load I am putting on the machine. I cannot tell whether this is the cause of the problem, or whether the fan merely runs because something else is putting load on some system component which needs cooling. Please let me know whether there is anything I can do to provide more meaningful data. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#814965: initramfs-tools: Creates corrupt initrd when /etc/initramfs-tools is versioned by SVN (.svn subdirs)
Package: initramfs-tools Version: 0.120 Severity: critical Justification: breaks the whole system Dear Maintainer, this happened after running an 'update-initramfs -u -k all'. The system became unbootable with the following message: Begin: Running /scripts/init-premount ... /init: .: line 210: can't open '/scripts/init-premount/ORDER' I found the 'problem' or what solved it in this forum post: http://forums.debian.net/viewtopic.php?f=5=125545 I also had the directory versioned by SVN, and after removing the .svn subdirectories and creating a new initramfs yet again, the system booted normally again. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 17M Feb 17 08:07 /boot/initrd.img-3.16.0-4-amd64 -rw-r--r-- 1 root root 15M Feb 17 08:07 /boot/initrd.img-3.2.0-4-amd64 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=afb7333e-cba2-4b36-8c51-be882475df55 ro quiet ipmi_si.load=0 ipmi_msghandler.load=0 -- /proc/filesystems xfs fuseblk -- lsmod Module Size Used by nf_conntrack_netlink35433 0 nfnetlink 12989 1 nf_conntrack_netlink xt_tcpmss 12425 1 xt_mark12453 3 sch_sfq21269 3 cls_fw 12762 3 sch_htb21832 1 xt_TCPMSS 12588 2 ipt_MASQUERADE 12594 24 xt_nat 12601 23 xt_conntrack 12681 91 xt_tcpudp 12527 3465 ipt_REJECT 12465 4 xt_LOG 17171 24 xt_limit 12601 26 nf_conntrack_ftp 16783 0 iptable_raw12524 0 iptable_nat12646 1 nf_conntrack_ipv4 18448 92 nf_defrag_ipv4 12483 1 nf_conntrack_ipv4 nf_nat_ipv412912 1 iptable_nat nf_nat 18241 4 ipt_MASQUERADE,nf_nat_ipv4,xt_nat,iptable_nat nf_conntrack 87424 8 ipt_MASQUERADE,nf_nat,nf_nat_ipv4,xt_conntrack,nf_conntrack_netlink,nf_conntrack_ftp,iptable_nat,nf_conntrack_ipv4 iptable_mangle 12536 1 iptable_filter 12536 1 ip_tables 26011 4 iptable_filter,iptable_mangle,iptable_nat,iptable_raw x_tables 27111 14 xt_mark,ip_tables,xt_tcpmss,xt_tcpudp,ipt_MASQUERADE,xt_limit,xt_conntrack,xt_LOG,xt_nat,iptable_filter,xt_TCPMSS,ipt_REJECT,iptable_mangle,iptable_raw binfmt_misc16949 1 capi 22136 0 kernelcapi 35710 1 capi tun26385 4 nfsd 263032 13 auth_rpcgss51211 1 nfsd oid_registry 12419 1 auth_rpcgss nfs_acl12511 1 nfsd nfs 188136 0 lockd 83389 2 nfs,nfsd fscache45542 1 nfs sunrpc237402 19 nfs,nfsd,auth_rpcgss,lockd,nfs_acl pppoe 17364 2 pppox 12594 1 pppoe ppp_generic30387 6 pppoe,pppox slhc 12531 1 ppp_generic 8021q 27844 0 garp 13117 1 8021q stp12437 1 garp mrp17343 1 8021q llc12745 2 stp,garp ppdev 16782 0 joydev 17063 0 evdev 17445 6 psmouse99249 0 powernow_k825433 1 serio_raw 12849 0 pcspkr 12595 0 k8temp 12538 0 amd64_edac_mod 30284 0 edac_mce_amd 21166 1 amd64_edac_mod edac_core 51465 2 amd64_edac_mod parport_pc 26300 0 parport35749 2 ppdev,parport_pc shpchp 31121 0 i2c_amd756 12544 0 amd_rng12549 0 rng_core 12733 1 amd_rng i2c_amd811112671 0 button 12944 0 i2c_core 46012 2 i2c_amd8111,i2c_amd756 processor 28221 1 powernow_k8 thermal_sys27642 1 processor hwmon_vid 12388 0 loop 26605 0 ipmi_watchdog 21915 0 ipmi_poweroff 13197 0 ipmi_devintf 17053 0 ipmi_msghandler39917 3 ipmi_devintf,ipmi_poweroff,ipmi_watchdog fuse 83350 1 autofs435529 2 xfs 779874 1 crc32c_generic 12656 1 libcrc32c 12426 1 xfs raid1 34596 1 hid_generic12393 0 usbhid 44460 0 hid 102264 2 hid_generic,usbhid sd_mod 44356 4 crc_t10dif 12431 1 sd_mod crct10dif_generic 12581 1 crct10dif_common 12356 2 crct10dif_generic,crc_t10dif sg 29973 0 sr_mod 21903 0 cdrom 47424 1 sr_mod dm_mod 89405 0 md_mod107672 2 raid1 ata_generic12490 0 tg3 164481 0 ptp17692 1
Re: [pkg-cryptsetup-devel] Bug#783297: breaks initramfs if BUSYBOX=n
clone 783297 -1 -2 reassign -1 busybox retitle -1 don't source initramfs.conf in busybox initramfs hook reassign -2 initramfs-tools retitle -2 remove busybox hook, leave responsibility to busybox package severity -2 important retitle 783297 split initramfs integration into a separate package severity 783297 wishlist thanks This mail clones the original bugreport two times and reassigns the clones to the busybox and initramfs-tools packages with appropriate titles. See below for details. Am 27.12.2015 um 07:35 schrieb Ben Hutchings: > On Fri, 2015-12-25 at 14:46 +0100, Jonas Meurer wrote: > [...] >> >>> /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting >>> and copy the busybox binary. >>> >>> /usr/share/initramfs-tools/hooks/zz-busybox sources >>> /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set >>> again, and the symlinks are not created. >> >> Honestly, this looks like a bug in busybox to me. What's the reason for >> the two busybox initramfs hook scripts at all? >> >> *) /usr/share/initramfs-tools/hooks/busybox copies bin/busybox to the >>initramfs and links /bin/sh to it without sourcing initramfs.conf. > > This is part of initramfs-tools. So this busybox initramfs hook should be dropped from initramfs-tools and responsibility for installing busybox into initramfs be handed over to the busybox package. >> *) /usr/share/initramfs-tools/hooks/zz-busybox-initramfs sources >>initramfs.conf, removes busybox binary from initramfs if existent, >>and copies bin/busybox to initramfs and links all aliases provided >>by busybox to it. > > This is actually called zz-busybox, and is part of busybox. Somehow I > failed to notice this exists. :-/ > >> I don't understand the following: >> >> What's the purpose of /usr/share/initramfs-tools/hooks/busybox at all, >> if changes are reverted by >> /usr/share/initramfs-tools/hooks/zz-busybox-initramfs later on anyway >> and redone in a slightly different fashion? > > Yes, this is stupid. We should arrange to properly hand over > responsibility for installing busybox, and adjust package dependencies > accordingly. Ack. > >> Why does /usr/share/initramfs-tools/hooks/zz-busybox-initramfs source >> initramfs.conf? The BUSYBOY variable is exported by mkinitramfs anyway. >> >> The simplest fix to this bug would be to stop sourcing initramfs.conf in >> hooks/zz-busybox-initramfs. > > It should certainly stop doing that. This is about the bug in busybox: stop sourcing initramfs.conf from the zz-busybox initramfs hook. > [...] >>> b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the >>> BUSYBOX=y line. And if this is not an option, because cryptsetup >>> requires busybox, then this should be reflected in the package >>> dependencies accordingly by making the Recommends a Depends. >> >> Do you think that the cryptsetup packages should depend on >> initramfs-tools and busybox despite the fact that they're usable without? > > No, they should only recommend them. The busybox hook script is > changed in initramfs-tools 0.121~rc2 to hard fail if busybox is wanted > but not installed. If it's dropped in favour of the zz-busybox hook > script, then I can move that check into mkinitramfs. So indeed the check needs to be moved to mkinitramfs as soon as responsibility for installing busybox is handed over to the busybox package itself. Am 27.12.2015 um 14:21 schrieb Michael Biebl: > Am 25.12.2015 um 14:46 schrieb Jonas Meurer: >> Yes, cryptsetup initramfs scripts do depend on busybox. At least this >> was the case some years ago. >> >> As cryptsetup can be used without initramfs (e.g. only home >> partition or removable storage encrypted), the cryptsetup package >> doesn't depend on "initramfs-tools, busybox" but merely recommends >> them. > > If you want to cleanly support those two different use cases, it looks > like the cleanest solution would be, to ship the initramfs integration > in a separate binary package, say cryptsetup-initramfs-tools. > > This subpackage would have a strict dependency on initramfs-tools and > busybox. The main cryptsetup package could have a recommends on that > subpackage. This part is about the cryptsetup package itself: it is suggested to split the initramfs stuff out into a seperate binary package (I prefer the name 'cryptsetup-initramfs'). This is a wishlist bug. Cheers, jonas signature.asc Description: OpenPGP digital signature
Re: [pkg-cryptsetup-devel] Bug#783297: breaks initramfs if BUSYBOX=n
Hi Michael, hi Ben, Am 26.04.2015 um 01:35 schrieb Michael Biebl: > On Sat, 25 Apr 2015 16:22:13 +0200 Michael Biebl <bi...@debian.org> wrote: >> if the cryptsetup package is installed, it also installed a >> initramfs-tools hook. >> >> I use BUSYBOX=no in initramfs.conf, but the cryptroot hook copies >> /bin/busybox to the initramfs nonetheless. >> >> As a result, the initramfs is unable to boot the system > > I looked into this in more detail, and the culprit seems to be > /usr/share/initramfs-tools/conf-hooks.d/cryptsetup > which forcefully set's > BUSYBOX=y. Yes, cryptsetup initramfs scripts do depend on busybox. At least this was the case some years ago. As cryptsetup can be used without initramfs (e.g. only home partition or removable storage encrypted), the cryptsetup package doesn't depend on "initramfs-tools, busybox" but merely recommends them. > /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting > and copy the busybox binary. > > /usr/share/initramfs-tools/hooks/zz-busybox sources > /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set > again, and the symlinks are not created. Honestly, this looks like a bug in busybox to me. What's the reason for the two busybox initramfs hook scripts at all? *) /usr/share/initramfs-tools/hooks/busybox copies bin/busybox to the initramfs and links /bin/sh to it without sourcing initramfs.conf. *) /usr/share/initramfs-tools/hooks/zz-busybox-initramfs sources initramfs.conf, removes busybox binary from initramfs if existent, and copies bin/busybox to initramfs and links all aliases provided by busybox to it. I don't understand the following: What's the purpose of /usr/share/initramfs-tools/hooks/busybox at all, if changes are reverted by /usr/share/initramfs-tools/hooks/zz-busybox-initramfs later on anyway and redone in a slightly different fashion? Why does /usr/share/initramfs-tools/hooks/zz-busybox-initramfs source initramfs.conf? The BUSYBOY variable is exported by mkinitramfs anyway. The simplest fix to this bug would be to stop sourcing initramfs.conf in hooks/zz-busybox-initramfs. > The result is a broken initramfs. > > I'm not sure, what is supposed to take precedence in such a case: The > configuration in /etc/initramfs-tools/initramfs.conf or > /usr/share/initramfs-tools/conf-hooks.d/cryptsetup and if it's a bug in > cryptsetup which forcefully overrides BUSYBOX= or if it's a bug in > busybox, which sources /etc/initramfs-tools/initramfs.conf in > /usr/share/initramfs-tools/hooks/zz-busybox and therefor doesn't respect > the settings which are set via conf-hooks.d. To my understanding, the purpose of /usr/share/initramfs-tools/hooks-conf.d is to provide a place where packages that include an initramfs hook script can overwrite settings to initramfs.conf without altering the config file itself. In other words, this directory is like an include directory for initramfs.conf. This implies, that every script which explicitly uses/sources initramfs.conf, needs to honour this include directory as well. In fact, we (Guilhem Moulin and me) discuss a related topic with the initramfs-tools maintainers in bugreport #807527[1] at the moment. In our eyes, initramfs-tools should provide a clear API or best practice for custom initramfs hook configuration. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807527 > If cryptsetup really requires busybox and forcefully sets BUSYBOX=y, why > does the cryptsetup package not depend on busybox? See above. > I see several possible fixes here > > a/ /usr/share/initramfs-tools/hooks/zz-busybox doesn't source > /etc/initramfs-tools/initramfs.conf directly and as a result respects > settings from hooks directories. If there's no reason for sourcing initramfs.conf in hooks/zz-busybox, then this definitely is the way to go. > b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the > BUSYBOX=y line. And if this is not an option, because cryptsetup > requires busybox, then this should be reflected in the package > dependencies accordingly by making the Recommends a Depends. Do you think that the cryptsetup packages should depend on initramfs-tools and busybox despite the fact that they're usable without? Cheers jonas signature.asc Description: OpenPGP digital signature
Re: [pkg-cryptsetup-devel] initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration
Am 23.12.2015 um 23:15 schrieb Jonas Meurer: > Am 17.12.2015 um 09:57 schrieb Jonas Meurer: >> Am 11.12.2015 um 15:35 schrieb Guilhem Moulin: >>> On Fri, 11 Dec 2015 at 00:54:03 +, Ben Hutchings wrote: >> I guess that Guilhem meant "... something that's only documented in the >> changelog". And I agree with him, that the purpose and limitations of >> conf-hooks.d directory should be properly documented somewhere in the >> mkinitramfs(8) manpage. > > Do you agree? > >>>> No, I am not going to add any more half-baked shell script parsing. >>>> >>>> Also, it doesn't make any sense to me, to put hook-specific >>>> configuration into a namespace shared across all hooks. You can >>>> always add a configuration file to your own package and source it in >>>> your hook script. >>> >>> Using /etc/$package/initramfs adds a useless directory level for >>> packages that only ship initramfs hook and script. The directory >>> /etc/default is shared, also. >> >> I understand that Ben will not add the solution that we prefer and >> suggest. But I still believe that some "standardized" way to make a >> initramfs hook script configurable would be a benefit. >> >> Especially I don't like the idea to add yet another new config file for >> the hook scripts. Thus I suggest the following: in cryptsetup, we use >> the conf-hook.d/cryptroot file for both the main mkinitramfs and the >> hook script configuration. Variables for the hook script will use a >> special namespace (like CRYPTROOT_*) and will be exported. Moulin could >> use the same scheme for dropbear (with DROPBEAR_* namespace). >> >> Ben, would you be ok with adding the /etc/initramfs-tools/conf-hooks.d >> equivalent directory in addition to >> /usr/share/initramfs-tools/conf-hooks.d? That way, at least custom >> changes of the hook script config would be supported in a proper way. >> >> If we can agree on that, then the following changes would be needed in >> initramfs-tools: >> >> 1/ add support for /etc/initramfs-tools/conf-hooks.d (already >>implemented in the patch I submitted) >> 2/ properly document purpose and limitations of conf-hooks.d directories > > Ben, what's your opinion on this suggestion? Is it an acceptable > solution for you? Or do you prefer to not change anything regarding > conf-hooks.d directory handing in mkinitramfs? After taking bugreport #783297[1] into consideration, the suggested solution doesn't look sufficient any more. Instead, the initramfs-tools documentation should make clear that hook scripts *must not* source initramfs.conf without sourcing all files from hook-conf.d/* as well. Probably a separate configuration file is the cleanest solution for hook scripts that need to be configurable. But in that case, I do think that initramfs-tools should provide a place for hook configuration files. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783297 Cheers jonas signature.asc Description: OpenPGP digital signature
/usr/share/initramfs-tools/bin directory in cryptsetup package? (was: [pkg-cryptsetup-devel] Bug#782024: cryptsetup: [patch] fix remote unlock of encrypted root when plymouth is installed)
Hi Ben, a quick question to you as initramfs-tools maintainer: are you ok with us adding a directory '/usr/share/initramfs-tools/bin' to the cryptsetup package? We would like to place a script 'cryptroot-unlock' there which is installed into /bin/ in initramfs. Thus the directory '/usr/share/initramfs-tools/bin' seems most appropriate for us. See the buglog[1] and below for further details. Cheers jonas [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782024 Am 23.12.2015 um 23:11 schrieb Jonas Meurer: > Am 19.12.2015 um 18:50 schrieb Guilhem Moulin: >> On Fri, 18 Dec 2015 at 19:16:56 -0500, Richard Hansen wrote: >>> * why SIGKILL instead of SIGTERM? seems too aggressive >>> * perhaps add a waitpid() after the kill() to ensure that a second >>>plymouth won't be run before the first one exits >> >> Agreed, but unfortunately plymouth doesn't terminate on SIGTERM. >> >>> * why does cryptroot-unlock use /bin/ash instead of /bin/sh? >>> * there are lots of BusyBox ashisms in the cryptroot-unlock script, >>>many of which can be easily replaced with POSIX conformant code >> >> POSIX's read builtin doesn't support the -s flag. Sure we can replace >> with stty with a trap to restore echo, but since busybox is a dependency >> anyway I don't think it's worth it :-P >> >> I've addressed the rest in the updated patch. Thanks for your input! > > I've incorporated the patch into SVN now, with some minor tweaks: > > * bin/unlock in the initramfs is renamed to bin/cryptroot-unlock. > * some minor coding style changes. > > Also I don't really like that we create the directory > '/usr/share/initramfs-tools/bin'. This place belongs to initramfs-tools > package in my eyes and we should at least ask the maintainers before > introducing it. I'll ask Ben in another ping mail to bug #807527 about > his option. > > Guilhem, can you test the latest SVN version and verify that it works fo > you? > > Cheers > jonas > > > signature.asc Description: OpenPGP digital signature
Re: [pkg-cryptsetup-devel] initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration
Hi Ben, Am 17.12.2015 um 09:57 schrieb Jonas Meurer: > Am 11.12.2015 um 15:35 schrieb Guilhem Moulin: >> On Fri, 11 Dec 2015 at 00:54:03 +, Ben Hutchings wrote: > I guess that Guilhem meant "... something that's only documented in the > changelog". And I agree with him, that the purpose and limitations of > conf-hooks.d directory should be properly documented somewhere in the > mkinitramfs(8) manpage. Do you agree? >>> No, I am not going to add any more half-baked shell script parsing. >>> >>> Also, it doesn't make any sense to me, to put hook-specific >>> configuration into a namespace shared across all hooks. You can >>> always add a configuration file to your own package and source it in >>> your hook script. >> >> Using /etc/$package/initramfs adds a useless directory level for >> packages that only ship initramfs hook and script. The directory >> /etc/default is shared, also. > > I understand that Ben will not add the solution that we prefer and > suggest. But I still believe that some "standardized" way to make a > initramfs hook script configurable would be a benefit. > > Especially I don't like the idea to add yet another new config file for > the hook scripts. Thus I suggest the following: in cryptsetup, we use > the conf-hook.d/cryptroot file for both the main mkinitramfs and the > hook script configuration. Variables for the hook script will use a > special namespace (like CRYPTROOT_*) and will be exported. Moulin could > use the same scheme for dropbear (with DROPBEAR_* namespace). > > Ben, would you be ok with adding the /etc/initramfs-tools/conf-hooks.d > equivalent directory in addition to > /usr/share/initramfs-tools/conf-hooks.d? That way, at least custom > changes of the hook script config would be supported in a proper way. > > If we can agree on that, then the following changes would be needed in > initramfs-tools: > > 1/ add support for /etc/initramfs-tools/conf-hooks.d (already >implemented in the patch I submitted) > 2/ properly document purpose and limitations of conf-hooks.d directories Ben, what's your opinion on this suggestion? Is it an acceptable solution for you? Or do you prefer to not change anything regarding conf-hooks.d directory handing in mkinitramfs? Cheers jonas signature.asc Description: OpenPGP digital signature
Re: /usr/share/initramfs-tools/bin directory in cryptsetup package?
Hi Ben, Am 24.12.2015 um 00:18 schrieb Ben Hutchings: > On Wed, 2015-12-23 at 23:19 +0100, Jonas Meurer wrote: >> Hi Ben, >> >> a quick question to you as initramfs-tools maintainer: are you ok with >> us adding a directory '/usr/share/initramfs-tools/bin' to the cryptsetup >> package? We would like to place a script 'cryptroot-unlock' there which >> is installed into /bin/ in initramfs. Thus the directory >> '/usr/share/initramfs-tools/bin' seems most appropriate for us. >> >> See the buglog[1] and below for further details. > [...] > > Please don't create anything outside of the documented hook/script > directories under /usr/share/initramfs-tools. Make your own directory > e.g. /usr/share/cryptsetup instead. Acknowledged and changed. Thanks for your reply. Cheers jonas signature.asc Description: OpenPGP digital signature
Re: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration
Am 11.12.2015 um 15:35 schrieb Guilhem Moulin: > On Fri, 11 Dec 2015 at 00:54:03 +, Ben Hutchings wrote: >> On Thu, 2015-12-10 at 12:15 +0100, Jonas Meurer wrote: >>> Hi there, >>> >>> On Thu, 10 Dec 2015 02:52:11 +0100 Guilhem Moulin >>> wrote: >>>> AFAIK there is no documentation for where users should set variables to >>>> configure an initramfs hook. There are a couple of workaround, all >>>> hacky and/or relying on undocumented properties of initramfs-tools(8): >>>> >>>> 1/ Setting said variable in initramfs.conf(5). (Since hook scripts >>>> are executed is sub-shells the variable need to be exported.) This >>>> is somewhat ugly since initramfs.conf(5) is the configuration file >>>> *for mkinitramfs*, not for the hook files. >>>> >>>> 2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook. This is an >>>> undocumented (short of an entry in the changelog) hack. Also >>>> unless that file is marked as a conffile (which violates the >>>> policy) user modifications are wiped upon upgrade. >>> >>> If I got it right (didn't find documentation about it), the current >>> purpose of conf-hooks.d seems to be to configure *mkinitramfs* in a >>> proper way required by the hook scripts, not to set configuration >>> variables for the hook scripts themselves, no? >> >> The only documentation I'm aware of is in the changelog: >> >> * mkinitramfs: Export MODULES, allows hook scripts to act accordingly. >> (closes: #421658) Add /usr/share/initramfs-tools/conf-hooks.d for hooks >> options on mkinitramfs run. Do not land in initramfs. > > Please consider adding it to the mkinitramfs manpage, too. Package > maintainers can't rely on something that's only documented in the > manpage, IMHO. I guess that Guilhem meant "... something that's only documented in the changelog". And I agree with him, that the purpose and limitations of conf-hooks.d directory should be properly documented somewhere in the mkinitramfs(8) manpage. >> No, I am not going to add any more half-baked shell script parsing. >> >> Also, it doesn't make any sense to me, to put hook-specific >> configuration into a namespace shared across all hooks. You can >> always add a configuration file to your own package and source it in >> your hook script. > > Using /etc/$package/initramfs adds a useless directory level for > packages that only ship initramfs hook and script. The directory > /etc/default is shared, also. I understand that Ben will not add the solution that we prefer and suggest. But I still believe that some "standardized" way to make a initramfs hook script configurable would be a benefit. Especially I don't like the idea to add yet another new config file for the hook scripts. Thus I suggest the following: in cryptsetup, we use the conf-hook.d/cryptroot file for both the main mkinitramfs and the hook script configuration. Variables for the hook script will use a special namespace (like CRYPTROOT_*) and will be exported. Moulin could use the same scheme for dropbear (with DROPBEAR_* namespace). Ben, would you be ok with adding the /etc/initramfs-tools/conf-hooks.d equivalent directory in addition to /usr/share/initramfs-tools/conf-hooks.d? That way, at least custom changes of the hook script config would be supported in a proper way. If we can agree on that, then the following changes would be needed in initramfs-tools: 1/ add support for /etc/initramfs-tools/conf-hooks.d (already implemented in the patch I submitted) 2/ properly document purpose and limitations of conf-hooks.d directories Cheers jonas signature.asc Description: OpenPGP digital signature
Re: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration
Hi there,
On Thu, 10 Dec 2015 02:52:11 +0100 Guilhem Moulin <guil...@guilhem.org>
wrote:
> AFAIK there is no documentation for where users should set variables to
> configure an initramfs hook. There are a couple of workaround, all
> hacky and/or relying on undocumented properties of initramfs-tools(8):
>
> 1/ Setting said variable in initramfs.conf(5). (Since hook scripts
> are executed is sub-shells the variable need to be exported.) This
> is somewhat ugly since initramfs.conf(5) is the configuration file
> *for mkinitramfs*, not for the hook files.
>
> 2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook. This is an
> undocumented (short of an entry in the changelog) hack. Also
> unless that file is marked as a conffile (which violates the
> policy) user modifications are wiped upon upgrade.
If I got it right (didn't find documentation about it), the current
purpose of conf-hooks.d seems to be to configure *mkinitramfs* in a
proper way required by the hook scripts, not to set configuration
variables for the hook scripts themselves, no? At least, all that
mkinitramfs does for now, is to source the files from conf-hooks.d. No
export of variables, so the configured variables aren't available to the
hook scripts for now.
> 3/ Make /usr/share/initramfs-tools/conf-hooks.d/$hook a symlink to
> /etc/initramfs-tools/conf-hooks.d/$hook. But again, this uses an
> undocumented property of mkinitramfs(8), and it might hijack your
> /etc/initramfs-tools namespace.
>
> There are packages that ship user configurable initramfs hooks
> (cryptsetup and dropbear-initramfs come to mind). These package need
> documented instructions for where to drop user configuration
> (/etc/initramfs-tools/conf-hooks.d/$package comes to mind).
>
> Alternatively, in a private discussion with Jonas Meurer of the Debian
> Cryptsetup Team (X-Debug-CC), I've been suggested that mkinitramfs(8)
> could instead source files in /etc/initramfs-tools/conf-hooks.d/ after
> sourcing /usr/share/initramfs-tools/conf-hooks.d/. This way package
> maintainers would ship variables with their default in /usr while users
> would write their custom configuration in /etc.
Following up on that I think that a proper solution would be the following:
- redefine the purpose of files in conf-hooks.d to set variables that
are made available to mkinitramfs *and* the hook scripts. In other
words, parse the configure includes from conf-hooks.d in mkinitramfs
and export all variables instead of just sourcing the files.
- add the change proposed by Guilhem and support user-defined configs
from /etc/initramfs-tools/conf-hooks.d/, overwriting the configs from
packages at /usr/share/initramfs-tools/conf-hooks.d/.
See attached patch which implements this.
Cheers,
jonas
> -8<->8-
> --- a/mkinitramfs
> +++ b/mkinitramfs
> @@ -87,6 +87,7 @@
> echo "Warning: ${i} is a directory instead of file, ignoring."
> elif [ -e "${i}" ]; then
> . "${i}"
> + . [ ! -f "/etc/${i#/usr/share/}" ] || . "/etc/${i#/usr/share/}"
> fi
> done
>
> -8<->8-
>
> Either way, IMHO initramfs-tools(8) should include some instructions for
> custom initramfs hook configuration.
>
> Cheers,
> --
> Guilhem.
>
> PS. In fact I've implemented 3/ in dropbear-initramfs a couple of weeks
> ago. Oopsâ¦
From fd3af859880f727088a3fd21fbccef9949bb02ed Mon Sep 17 00:00:00 2001
From: Jonas Meurer <jo...@freesources.org>
Date: Thu, 10 Dec 2015 12:09:06 +0100
Subject: [PATCH] mkinitramfs: export variables from conf-hooks.d directories
Up to now, there was no clear api in initramfs-tools to make initramfs
hook scripts configurable. Variables from conf-hooks.d include files were
not available to the hook scripts due to the hooks beeing executed in
sub-shells. This lead to ugly workarounds in packages that tried (and
most of them: failed) to make their hook scripts configurable to the user.
Now, mkinitramfs exports all variables from conf-hooks.d configuration
includes additionally to sourcing the files. This leads to the variables
being available to hooks, thus providing a clear api to configure initramfs
hook scripts.
Additionally, the directory /etc/initramfs-tools/conf-hooks.d is introduced,
meant as a place to overwrite package-provided hook configuration by local
settings.
Close: #807527
---
debian/changelog | 11 ++-
debian/initramfs-tools-core.dirs | 1 +
mkinitramfs | 6 +-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 16e4e5f..
Re: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration
Am 10.12.2015 um 15:18 schrieb Guilhem Moulin:
> On Thu, 10 Dec 2015 at 12:15:33 +0100, Jonas Meurer wrote:
>> - redefine the purpose of files in conf-hooks.d to set variables that
>> are made available to mkinitramfs *and* the hook scripts.
>
> On second thought it might not be ideal to use the same file for both,
> as exporting all variable to the hooks can have unexpected side effects.
>
> For instance the dropbear hook changes the default UMASK value to 0077
> in order to protect the private key material (the SSH host keys). But
> this variable is also used by other software to override the process's
> umask(2); if it were to be set in the hooks, files within the initramfs
> image might be created with the wrong permissions, which is certainly
> not intended and might have unexpected side effects.
Agreed. I updated the patch to do the following:
- source all files from conf-hooks.d/* at the beginning of mkinitramfs
just as before (but adding the files from ${CONFDIR}/conf-hooks.d/*).
- export variables from conf-hooks.d/ just before the hook script
hooks/ is executed.
This should mitigate the described side-effects.
See the updated patch attached to this mail.
>> # source package confs
>> -for i in /usr/share/initramfs-tools/conf-hooks.d/*; do
>> +for i in /usr/share/initramfs-tools/conf-hooks.d/*
>> /etc/initramfs-tools/conf-hooks.d/*; do
>> if [ -d "${i}" ]; then
>> echo "Warning: ${i} is a directory instead of file, ignoring."
>> elif [ -e "${i}" ]; then
>> . "${i}"
>> + hookvars="$(sed -e '/#.*$/d' -e '/^$/d' ${i} | cut -d= -f1)"
>> + if [ -n "${hookvars}" ]; then
>> + export ${hookvars}
>> + fi
>> fi
>> done
>
> If *all* variables are accessible in *all* hooks there must be some kind
> of policy to prevents collisions. For instance packages a and b
> shouldn't make use the same variable OPTIONS, since the assignment in
> conf-hooks.d/b would override that in conf-hooks.d/a.
>
>
> I should also add that Jonas and I would both like to avoid the easy &
> dirty solution consisting of making the package ship a configuration
> file for its hook in /etc/$package/initramfs-hook and source that file
> in the hook. Some cleaner organization in the fashion of /etc/default
> seems like the way to go.
Yep :)
Cheers
jonas
From af1881f4f93de499e99f37a566a79f1dee973269 Mon Sep 17 00:00:00 2001
From: Jonas Meurer <jo...@freesources.org>
Date: Thu, 10 Dec 2015 16:09:54 +0100
Subject: [PATCH] mkinitramfs: export variables from conf-hooks.d includes
Up to now, there was no clear api in initramfs-tools to make initramfs
hook scripts configurable. Variables from conf-hooks.d include files were
not available to the hook scripts due to the hooks beeing executed in
sub-shells. This lead to ugly workarounds in packages that tried (and
most of them: failed) to make their hook scripts configurable to the user.
Now, additionally to sourcing the conf-hooks.d configuration includes,
mkinitramfs exports all variables from conf-hooks.d/ just before
invoking the respective script. This leads to the variables from
conf-hooks.d/ being available to the respective script,
thus providing a clear api to configure initramfs hook scripts.
Additionally, the directory /etc/initramfs-tools/conf-hooks.d is introduced,
meant as a place to overwrite package-provided hook configuration by local
settings.
Close: #807527
Signed-off-by: Jonas Meurer <jo...@freesources.org>
---
debian/changelog | 13 -
debian/initramfs-tools-core.dirs | 1 +
hook-functions | 11 +++
mkinitramfs | 2 +-
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 16e4e5f..d8adccb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
initramfs-tools (0.120) unstable; urgency=medium
+ [ Ben Hutchings ]
* [23ee5f9] Add '.log' to fsck log output file, and document its existence
(Closes: #780352)
* [b87e34b] Remove old comment about running shell on failure of fsck
@@ -10,7 +11,17 @@ initramfs-tools (0.120) unstable; urgency=medium
* [25ab961] NEWS: Add entries about other ways of mounting /usr that won't
work
- -- Ben Hutchings <b...@decadent.org.uk> Mon, 13 Apr 2015 01:18:06 +0100
+ [ Jonas Meurer ]
+ * Redefine the purpose of conf-hooks.d include files (closes: #807527):
+- Additional to these files beeing sourced, variables from
+ conf-hooks.d/ are now exported before is invoked. As a
+ result, variables from conf-hooks.d/ are now available to the
+ hook script hooks/.
+- Add /etc/initramfs-tools/conf-hooks.d as user-configurable place
+ for conf-hooks.d, potentially overwr
Re: auto-mount NFS shares on boot
Hi, Am 2015-06-28 12:54, schrieb Michael Biebl: I suggest to add this simple fix to Jessie by uploading it to stable-proposed-updates. What do you think? Also, do you think that /etc/systemd/system/remote-fs-pre.target.d/nfs.conf belongs to systemd package or to nfs-common? I would say it belongs to nfs-common as that one provides the required tools and services to mount NFS shares on a client. For Jessie: - nfs-common is still an init script, so one cannot simply add Before=remote-fs-pre.target to that. But there are two other options: - just for Jessie: update systemd to change the original unit file remote-fs-pre.target to include After=nfs-common.service - or alternatively, package a drop-in in /lib in the nfs-common package, i.e. /lib/systemd/system/nfs-common.service.d/systemd-ordering.conf: [Unit] Before=remote-fs-pre.target (IMHO at least, I'll defer to the maintainers of the respective packages as to what they think is appropriate.) Certainly, the preferred fix is, that packages ship native service files which override/replace the sysv init scripts. In case of nfs-common/rpcbind, Ubuntu has done some extensive work to properly integrate nfs-common/rpcbind with systemd. This hasn't landed in Debian (yet) and is not something which can be backported for jessie. The drop-in snippet for nfs-common to augment the dependency information when being run under systemd is something which seems to be suitable for jessie and could be added to the package in sid to give it some testing first. Ideally, that drop-in is shipped by the package itself. This would mean a stable upload for nfs-common. I prepared a patch for nfs-utils 1.2.8-9 that adds a systemd drop-in for nfs-common at /lib/systemd/system/nfs-common.service.d/remote-fs-pre.conf. It places the nfs-common service before the remote-fs-pre target. This results in the rpc.gssd service beeing started before NFS shares are mounted during the boot process. The patch is tested on my system and works for me. I suggest to upload nfs packages with this patch to Jessie (through stable-proposed-updates) in order to fix auto-mounting Kerberos-secured NFS mounts at boot in Jessie. Do nfs-utils maintainers take care of this upload? Otherwise I can do the upload (and ask RMs for approval first) myself. A short comment would be helpful. Cheers, jonas diff -Nru nfs-utils-1.2.8/debian/changelog nfs-utils-1.2.8/debian/changelog --- nfs-utils-1.2.8/debian/changelog 2014-08-13 02:12:43.0 +0200 +++ nfs-utils-1.2.8/debian/changelog 2015-07-07 12:11:02.0 +0200 @@ -1,3 +1,13 @@ +nfs-utils (1:1.2.8-9+deb8u1) jessie; urgency=medium + + * NMU by Jonas Meurer. + * Add a systemd drop-in to fix boot order for NFSv4+Kerberos setups. +rpc.gssd needs to be started before mounting Kerberos-secured NFS +mounts. The drop-in takes care that NFS common services are started +before systemd target remote-fs-pre is reached. Closes: #775542. + + -- Jonas Meurer jo...@freesources.org Tue, 07 Jul 2015 12:04:45 +0200 + nfs-utils (1:1.2.8-9) unstable; urgency=medium * debian/patches/22-mountd-fix-segfault-in-add_name-with-newer-gcc- diff -Nru nfs-utils-1.2.8/debian/nfs-common.dirs nfs-utils-1.2.8/debian/nfs-common.dirs --- nfs-utils-1.2.8/debian/nfs-common.dirs 2014-08-13 02:12:43.0 +0200 +++ nfs-utils-1.2.8/debian/nfs-common.dirs 2015-07-07 12:04:37.0 +0200 @@ -7,3 +7,4 @@ usr/share/nfs-common/conffiles usr/share/bug/nfs-common usr/share/bug/nfs-utils +lib/systemd/system/nfs-common.service.d diff -Nru nfs-utils-1.2.8/debian/nfs-common.install nfs-utils-1.2.8/debian/nfs-common.install --- nfs-utils-1.2.8/debian/nfs-common.install 2014-08-13 02:12:43.0 +0200 +++ nfs-utils-1.2.8/debian/nfs-common.install 2015-07-07 12:04:24.0 +0200 @@ -22,3 +22,4 @@ debian/idmapd.conf usr/share/nfs-common/conffiles/ debian/nfs-common.default usr/share/nfs-common/conffiles/ debian/id_resolver.conf etc/request-key.d/ +debian/systemd-remote-fs-pre.conf lib/systemd/system/nfs-common.service.d/remote-fs-pre.conf diff -Nru nfs-utils-1.2.8/debian/systemd-remote-fs-pre.conf nfs-utils-1.2.8/debian/systemd-remote-fs-pre.conf --- nfs-utils-1.2.8/debian/systemd-remote-fs-pre.conf 1970-01-01 01:00:00.0 +0100 +++ nfs-utils-1.2.8/debian/systemd-remote-fs-pre.conf 2015-07-07 12:37:40.0 +0200 @@ -0,0 +1,2 @@ +[Unit] +Before=remote-fs-pre.target
Re: Bug#775542: auto-mount NFS shares on boot
Am 2015-07-07 13:15, schrieb Christian Seiler: Thanks for taking care of this! Thanks for proof-reading the patch! Am 2015-07-07 13:03, schrieb Jonas Meurer: Am 2015-06-28 12:54, schrieb Michael Biebl: I suggest to add this simple fix to Jessie by uploading it to stable-proposed-updates. What do you think? Also, do you think that /etc/systemd/system/remote-fs-pre.target.d/nfs.conf belongs to systemd package or to nfs-common? I would say it belongs to nfs-common as that one provides the required tools and services to mount NFS shares on a client. For Jessie: - nfs-common is still an init script, so one cannot simply add Before=remote-fs-pre.target to that. But there are two other options: - just for Jessie: update systemd to change the original unit file remote-fs-pre.target to include After=nfs-common.service - or alternatively, package a drop-in in /lib in the nfs-common package, i.e. /lib/systemd/system/nfs-common.service.d/systemd-ordering.conf: [Unit] Before=remote-fs-pre.target (IMHO at least, I'll defer to the maintainers of the respective packages as to what they think is appropriate.) Certainly, the preferred fix is, that packages ship native service files which override/replace the sysv init scripts. In case of nfs-common/rpcbind, Ubuntu has done some extensive work to properly integrate nfs-common/rpcbind with systemd. This hasn't landed in Debian (yet) and is not something which can be backported for jessie. The drop-in snippet for nfs-common to augment the dependency information when being run under systemd is something which seems to be suitable for jessie and could be added to the package in sid to give it some testing first. Ideally, that drop-in is shipped by the package itself. This would mean a stable upload for nfs-common. I prepared a patch for nfs-utils 1.2.8-9 that adds a systemd drop-in for nfs-common at /lib/systemd/system/nfs-common.service.d/remote-fs-pre.conf. It places the nfs-common service before the remote-fs-pre target. This results in the rpc.gssd service beeing started before NFS shares are mounted during the boot process. The patch is tested on my system and works for me. Not having built the package with your diff myself: are you sure that it works as expected and installs the file in the right place? Just from reading the debdiff, the following seems to be wrong: The second argument for lines in .install files should be a directory (see dh_install manpage), dh_install alone doesn't support renaming files. (There is dh_exec for that if you need that functionality, but that requires an additional build-dep.) OTOH, you don't really need to rename the file, the name you have is already fine, so why not just put the following line in nfs-common.install: debian/systemd-remote-fs-pre.conf lib/systemd/system/nfs-common.service.d/ Indeed, you're correct. Slipped through my fingers for some reason. Fixed in the updated version of the patch. I suggest to upload nfs packages with this patch to Jessie (through stable-proposed-updates) in order to fix auto-mounting Kerberos-secured NFS mounts at boot in Jessie. Note that the release team wants bugs fixed in unstable first, before they accept uploads to s-p-u. You're correct. I'll wait for the nfs-utils maintainers to comment and prepare an NMU for unstable if they don't take care of it themselves. Cheers, jonas diff -Nru nfs-utils-1.2.8/debian/changelog nfs-utils-1.2.8/debian/changelog --- nfs-utils-1.2.8/debian/changelog 2014-08-13 02:12:43.0 +0200 +++ nfs-utils-1.2.8/debian/changelog 2015-07-07 12:11:02.0 +0200 @@ -1,3 +1,13 @@ +nfs-utils (1:1.2.8-9+deb8u1) jessie; urgency=medium + + * NMU by Jonas Meurer. + * Add a systemd drop-in to fix boot order for NFSv4+Kerberos setups. +rpc.gssd needs to be started before mounting Kerberos-secured NFS +mounts. The drop-in takes care that NFS common services are started +before systemd target remote-fs-pre is reached. Closes: #775542. + + -- Jonas Meurer jo...@freesources.org Tue, 07 Jul 2015 12:04:45 +0200 + nfs-utils (1:1.2.8-9) unstable; urgency=medium * debian/patches/22-mountd-fix-segfault-in-add_name-with-newer-gcc- diff -Nru nfs-utils-1.2.8/debian/nfs-common.dirs nfs-utils-1.2.8/debian/nfs-common.dirs --- nfs-utils-1.2.8/debian/nfs-common.dirs 2014-08-13 02:12:43.0 +0200 +++ nfs-utils-1.2.8/debian/nfs-common.dirs 2015-07-07 12:04:37.0 +0200 @@ -7,3 +7,4 @@ usr/share/nfs-common/conffiles usr/share/bug/nfs-common usr/share/bug/nfs-utils +lib/systemd/system/nfs-common.service.d diff -Nru nfs-utils-1.2.8/debian/nfs-common.install nfs-utils-1.2.8/debian/nfs-common.install --- nfs-utils-1.2.8/debian/nfs-common.install 2014-08-13 02:12:43.0 +0200 +++ nfs-utils-1.2.8/debian/nfs-common.install 2015-07-07 13:30:40.0 +0200 @@ -22,3 +22,4 @@ debian/idmapd.conf usr/share/nfs-common/conffiles/ debian/nfs-common.default usr/share/nfs-common/conffiles/ debian
Bug#775542: auto-mount NFS shares on boot
Hi Christian, Am 27.06.2015 um 16:07 schrieb Christian Seiler: (Ccing the bugtracker because it appears you've stumbled upon a bug that also a few other people had, see below. Please don't reply to the bugtracker yourself unless you feel it's relevant for the bug report.) Link to thread on debian-user for people reading the bug report: https://lists.debian.org/debian-user/2015/06/msg01508.html Thanks for linking this thread to bugreport #775542. I wasn't aware of that bugreport yet. On 06/27/2015 03:39 PM, Jonas Meurer wrote: Could you run the following? systemd-analyze plot bootup.svg Ok, so the following is going on: - local-fs.target is reached, this leads to networking.service being started - networking.service sets up network configuration (takes 172ms) - after networking.service is done, network.target is reached - after network.target is reached, network-online.target is reached (since you don't have any services that wait for the network connection like NetworkManager-wait-online.service, but you also don't need it here, since networking.service with a static configuration and 'auto eth0' will make sure the network is up properly before even network.target is reached, so that's not a problem) - but then immediately after that systemd tries to mount the NFS filesystem - in parallel, first rpcbind and then nfs-common is started Thanks a lot for disassembling and explaining the boot procedure. I see that the problem here is that systemd doesn't wait for rpcbind.service and nfs-common.service to finish before it mounts the NFS shares. This is a bug, that shouldn't happen. Rationale: The problem here is that you are using sec=krb5i type mounts, where rpc.gssd needs to have been started (by nfs-common) BEFORE mounting can take place. Unfortunately, there's no ordering relating nfs-common to remote filesystems, so systemd will start them in parallel and the mount will fail. I myself have never seen this because I've only used sec=sys NFSv4 mounts with Jessie, and those don't require any service to be started when trying to mount them - and while the idmapper may be required to have proper permissions, that can be started later (or not at all if you use the new nfsidmap + request-key logic instead of idmapd). But with sec=krb5i mounts, this is bad, because you need rpc.gssd to mount the filesystems. What's missing here is an ordering dependency between remote-fs-pre.target and nfs-common.service. Searching through the bugtracker, this appears to be the same bug as #775542 [1], that's why I've copied this message to that bug report. Could you try to do the following: 1. create a directory /etc/systemd/system/remote-fs-pre.target.d 2. create a file /etc/systemd/system/remote-fs-pre.target.d/nfs.conf with the following contents: [Unit] After=nfs-common.service And then reboot your system? I would bet it should work then. Perfect, that solution works like a charm. nfs-common is started before remote-fs, thus rpc.gssd runs already when the NFS share is mounted. I suggest to add this simple fix to Jessie by uploading it to stable-proposed-updates. What do you think? Also, do you think that /etc/systemd/system/remote-fs-pre.target.d/nfs.conf belongs to systemd package or to nfs-common? I would say it belongs to nfs-common as that one provides the required tools and services to mount NFS shares on a client. What do the maintainers think? I'm happy to prepare a patch for either package and eventually make an upload to stable-proposed-updates if the maintainers don't have time to do so themselves. Just tell me if I should go ahead. Cheers, jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558ee51e.4040...@freesources.org
Re: Perl embedding pain
Quoting Niko Tyni (2015-05-24 12:10:12) On Tue, Aug 26, 2014 at 01:35:50AM -0700, Ben Hutchings wrote: On Mon, 2014-08-25 at 16:20 -0700, Niko Tyni wrote: On Thu, Aug 21, 2014 at 01:07:16PM -0700, Ben Hutchings wrote: As libperl5.* packages currently depend on an exact version of perl-base, coinstallation of multiple library versions is impossible. Transitions are not only a pain for developers, but users must upgrade all Perl extensions and embedding applications at the same time as the perl package. Why don't all the Perl package names include the ABI version, leaving perl as a metapackage? With linux-tools-* packages, this is particularly problematic as the older packages will never be rebuilt for the new Perl version. My inclination is to 'fix' this by removing Perl integration from perf. Please let us know whether it will be possible to fix this properly. For my part, I'm sort of interested in leaving old libperl versions installable after upgrades, but I wouldn't want to be supporting /usr/bin/perl5.18 and /usr/bin/perl5.20 simultaneously or even having separate source packages for different Perl versions in the archive at the same time. Hi, getting back to this old thread (and #495394, which is a similar request): it looks like we'll be reorganizing the package setup for Perl 5.22 so that in the future libperl5.xx and libperl5.yy will stay coinstallable, along with the full standard library. There are still no provisions for keeping old builds of binary (XS) module packages around, but it should be possible to install those modules manually from CPAN if needed. New major Perl releases are made yearly in May or thereabouts, and 5.22 is currently at the release candidate phase upstream. We expect to get it in experimental soon, and in sid this summer. By the time stretch is frozen I suppose we'll be at 5.24. As jessie was released with the old setup, this won't help jessie-stretch upgrades, but at least things are getting better now. Ohh - this is great news! I look forward to being able to do major Debian upgrades in smaller chunks rather than being forced to upgrade all packages related to XS modules in lockstep. Enjoy Spain! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#782611: linux-image-3.16.0-4-amd64: backlight on, white screen during text mode powersave on Acer Aspire One 725
Quoting Simon Richter (2015-04-14 21:04:54) I've recently installed an Acer Aspire One 725 with Debian jessie, and found that the text mode console goes into powersave mode correctly the first time, but shows a white screen with full backlight power the second and subsequent time. CPU is model name: AMD C-70 APU with Radeon(tm) HD Graphics Graphics adapter is 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Device [1002:980a] As I've already passed the device back to the owner, further testing is difficult for me. This sounds similar (but not identical) to bug#766922. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#782610: linux-image-3.16.0-4-amd64, xserver-xorg-video-radeon: Acer Aspire One 725: black screen in X after resume
Quoting Simon Richter (2015-04-14 20:58:25) I've recently installed an Acer Aspire One 725 with Debian jessie, and found that after resuming from sleep, the display remains black (but backlight is on) with X. Text mode consoles work fine with and without console-setup. This system uses an AMD CPU with integrated graphics: model name: AMD C-70 APU with Radeon(tm) HD Graphics 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Device [1002:980a] As I've already passed that machine back to the owner (with sleep mode disabled in systemd config), it is difficult for me to do further testing. This seems identical to bug#766922. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#766922: failing also on 3.16.7-ckt9-1
reassign 766922 src:linux notfound 766922 3.14.15-2 found 766922 3.16.7-ckt4-3 found 766922 3.16.7-ckt7-1 found 766922 3.16.7-ckt9-1 notfound 766922 3.19.3-1~exp1 thanks Reassigning to source package (noticing how Ben does it like that) - perhaps that is crucial for optimal processing... - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
failing also on 3.16.7-ckt9-1
found 766922 3.16.7-ckt9-1 thanks Again, some changelog entries looked promising, but still the graphics card on my Acer laptop fails to wake up with newest 3.16.7-ckt9-1. As already tracked in this bugreport, wakeup works fine with linux-image-3.14-2-amd64 3.14.15-2 so this is a regression. It also work fine with linux-image-3.19.0-trunk-amd64 3.19.3-1~exp1. A few members of the European Parliament now use Debian on 1 year old Lenovo Edge 145 laptops (a model still sold in shops) that will fail to wake from sleep if upgraded to Jessie. Yes, they can use a custom kernel, but then they no longer run purely stable Debian, which ruins a core point¹ of that pilot project :-( - Jonas ¹ Debian as trustworthy ally for security-concious parliamentary workers (politicians and staffers): https://wiki.debian.org/DebianParl/GreensEFA -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#766922: failing also on 3.16.7-ckt7-1
found 766922 3.16.7-ckt7-1 thanks Some of the changelog entries for 3.16.7-ckt7-1 looked promising, but unfortunately that kernel release still fails to wake up previously mentioned Radeon chips :-( - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: xserver-xorg-video-radeon: resume from suspend/hibernate results in blank screen kernel 3.16
Hi, Should this perhaps be reassigned to the linux kernel, since it seems tied to changes in kernel rather than in Xorg code? I experience what seems to be this same bug, on two quite similar laptops: Acer Aspire One 725 C6Ckk: lspci: [AMD/ATI] Wrestler [Radeon HD 6290] Xorg: AMD Radeon HD 6200 Series Graphics (ChipID = 0x9807) Acer Aspire One 725 C7Xkk: lspci: [AMD/ATI] Wrestler [Radeon HD 7290] Xorg: PALM (ChipID = 0x980a) Most recent working unstable/testing kernel is linux-image-3.14-2-amd64 3.14.15-2 - and problem goes away with the experimental linux-image-3.19.0-trunk-amd64 3.19-1~exp1. Here's a diff of Xorg logs from boot till after a sleep and wakeup comparing working and broken kernels, trimmed to leave out seemingly irrelevant info: --- 3.14.2/post-sleep/dmesg. +++ 3.18.0/post-sleep/dmesg. @@ -1,8 +1,9 @@ -Linux version 3.14-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-7) ) #1 SMP Debian 3.14.15-2 (2014-08-09) +Linux version 3.18.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 3.18.5-1~exp1 (2015-01-31) +ACPI: Early table checksum verification disabled -ACPI: IRQ2 used by override. -nr_irqs_gsi: 40 -NR_IRQS:33024 nr_irqs:712 16 +NR_IRQS:33024 nr_irqs:456 0 +Initializing cgroup subsys net_prio -tlb_flushall_shift: 6 +ftrace: allocating 21993 entries in 86 pages -bio: create slab bio-0 at 0 -ACPI: No dock devices found. +vgaarb: setting as boot device: PCI::00:01.0 -ACPI: bus type PNP registered -pnp 00:01: Plug and Play ACPI device, IDs PNP0103 (active) -pnp 00:02: [dma 4] -pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active) -pnp 00:03: Plug and Play ACPI device, IDs PNP0c04 (active) -pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active) -pnp: PnP ACPI: found 10 devices +pnp: PnP ACPI: found 6 devices -ACPI: bus type PNP unregistered -pci :00:01.0: Boot video device +pci :00:01.0: Video device with shadowed ROM +zpool: loaded +ledtrig-cpu: registered to indicate activity on CPUs +radeon :00:01.0: radeon: MSI limited to 32-bit -bio: create slab bio-1 at 1 +Process accounting resumed +rtc_cmos 00:01: System wakeup disabled by ACPI Tell me if useful that I produce similar against working 3.19 kernel, or if some other info is helpful. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150220205307.2648.5...@bastian.jones.dk
Re: kernel crashes after soft lockups in xen domU
reassign 758622 linux-image-3.16.0-4-amd64 thanks Hi Ben, thanks for your response. Am 2014-11-05 21:40, schrieb Ben Hutchings: On Wed, 2014-11-05 at 17:56 +0100, Jonas Meurer wrote: [...] So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ [...] Sorry you haven't had a response from us so far. This seems to be fairly clearly a Linux/Xen interaction and I don't know enough about Xen to suggest how to debug it. As it involves a relatively old kernel version, I don't think Linux upstream developers will want to hear about this unless you can also reproduce it with a more recent version. Linux 3.16 is available (in testing and wheezy-backports) if you would like to try that. I tried linux-image-3.16 from wheezy-backports as VM kernel in the meantime. Sorry to report back that the bug is still reproducible with this kernel. I'm reassigning it to the jessie kernel for that reason. The kernel backtrace was slightly different, but the behaviour was the same: After putting the webserver on test VM under heavy load with siege and pylot, the load exploded until the machine crashed. Now I replaced the hardware again with a Supermicro S8 board and a Intel Xeon L5639 CPU - and you know what: the bug disappeared. I'll have to put the system back into production mode now, so further debugging will be complicated. To sum up the situation: - a setup with Debian Wheezy Dom0 and Debian Wheezy or Jessie VM - the VM runs an apache webserver with mysql backend, nothing more - the VM crashes under load if Dom0 CPU is Intel Xeon E5-2609 - the VM doesn't crash under load if Dom0 CPU is Intel Xeon 5639 - tested on four completely different hardware setups, all components except harddisks replaced several times Kind regards, jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0c5360de19b1627cd9d7448973e7e...@imap.steindlberger.de
Re: kernel crashes after soft lockups in xen domU
And some more information ... Am 2014-10-13 12:04, schrieb Jonas Meurer: Am 2014-08-19 12:26, schrieb Jonas Meurer: I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware setup. I'm unable to reproduce the crash on another Xen system with same kernel an Xen versions but different CPU and motherboard. The VM runs in production mode on the second Xen system since several weeks without one single crash. I've got a test system now where I'm able to reproduce the bug by putting the VM (a webserver) under heavy load with the help of siege and pylot. The VM crashes every time I put the webserver under heavy load, everytime with the same backtrace. I replaced the full system (all hardware components except the harddisks) with a new one in the meantime - and still the bug is repoducible. I'll try to describe the setup: Two Xen virtualization servers (xen1 and xen2), mirroring one block device with DRBD using a primary/secondary setup. The DRBD device holds LVM with the LVs for one single virtual machine (the webserver). This webserver runs an Apache2 daemon. The first virtualization server (xen1, the one that's live) runs rock stable, same for the webserver VM on top. No crashes, no exploding load. The second virtualization server (xen2) runs well as long as it's only secondary (i.e. no virtual machine started). As soon as I switch the DRBD primary to xen2 and start the webserver VM there, load on the webserver is unusual high, it becomes laggy and after some hours (sometimes minutes) it crashes like described in earlier mails. Now I created a test-VM on xen2 that is not on top of the DRBD device in order to factor out DRBD as reason. As already written, if I fire some HTTP requests against the Apache daemon on the test-VM, the VM crashes the same way. I first replaced memory modules and CPU by similar ones without results. Now I replaced the whole hardware (except harddisks) by another one - still the same crashes. So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ Cheers, jonas Regarding the hardware: the RAM was checked with memtest86+ and no errors found and the CPU has been replaced by a new one (same model). Still, the VM crash is reproducible. The hardware on the crashing system is: CPU: Intel Xeon E5-2609v2/4x2,5GHz Motherboard: Supermicro X9SRI-F For information, the hardware on non-crashing system is: CPU: Intel XEON L5639/6x2,13 GHz Motherboard: Supermicro X8STi It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated This is still valid, even though I no longer think that it's related to a RT process at all, as no sched_fifo/rr processes are started. Usually, a few minutes later, soft lockups start to happen, and then the system crashes: The backtrace is slightly different now due to kernel and Xen updates: [353013.384931] sched: RT throttling activated [354008.100835] BUG: soft lockup - CPU#5 stuck for 22s! [apache2:24848] [354008.100846] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100872] CPU 5 [354008.100874] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100894] [354008.100898] Pid: 24848, comm: apache2 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [354008.100904] RIP: e030:[8100122a] [8100122a] hypercall_page+0x22a/0x1000 [354008.100914] RSP: e02b:8802f0b41c00 EFLAGS: 0246 [354008.100918] RAX: 00040001 RBX: 88020200 RCX: 8100122a [354008.100922] RDX
Bug#758622: kernel crashes after soft lockups in xen domU
Hey again, Am 2014-08-19 12:26, schrieb Jonas Meurer: I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware setup. I'm unable to reproduce the crash on another Xen system with same kernel an Xen versions but different CPU and motherboard. The VM runs in production mode on the second Xen system since several weeks without one single crash. I've got a test system now where I'm able to reproduce the bug by putting the VM (a webserver) under heavy load with the help of siege and pylot. The VM crashes every time I put the webserver under heavy load, everytime with the same backtrace. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Regarding the hardware: the RAM was checked with memtest86+ and no errors found and the CPU has been replaced by a new one (same model). Still, the VM crash is reproducible. The hardware on the crashing system is: CPU: Intel Xeon E5-2609v2/4x2,5GHz Motherboard: Supermicro X9SRI-F For information, the hardware on non-crashing system is: CPU: Intel XEON L5639/6x2,13 GHz Motherboard: Supermicro X8STi It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated This is still valid, even though I no longer think that it's related to a RT process at all, as no sched_fifo/rr processes are started. Usually, a few minutes later, soft lockups start to happen, and then the system crashes: The backtrace is slightly different now due to kernel and Xen updates: [353013.384931] sched: RT throttling activated [354008.100835] BUG: soft lockup - CPU#5 stuck for 22s! [apache2:24848] [354008.100846] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100872] CPU 5 [354008.100874] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100894] [354008.100898] Pid: 24848, comm: apache2 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [354008.100904] RIP: e030:[8100122a] [8100122a] hypercall_page+0x22a/0x1000 [354008.100914] RSP: e02b:8802f0b41c00 EFLAGS: 0246 [354008.100918] RAX: 00040001 RBX: 88020200 RCX: 8100122a [354008.100922] RDX: ffc8 RSI: RDI: [354008.100927] RBP: 000e R08: 0200 R09: dead00100100 [354008.100931] R10: dead00200200 R11: 0246 R12: 88028e261da0 [354008.100935] R13: 8802be00 R14: ea00099905e8 R15: 000d [354008.100944] FS: 7f7b66cd2740() GS:8802ffd4() knlGS: [354008.100949] CS: e033 DS: ES: CR0: 8005003b [354008.100953] CR2: 7f7b68c2b000 CR3: 0002855b7000 CR4: 2660 [354008.100958] DR0: DR1: DR2: [354008.100962] DR3: DR6: 0ff0 DR7: 0400 [354008.100967] Process apache2 (pid: 24848, threadinfo 8802f0b4, task 8802ef49c8c0) [354008.100972] Stack: [354008.100974] 0200 81006790 81006d22 [354008.100981] dead00200200 dead00100100 0200 [354008.100988] 88020200 88020200 ffc8 0200 [354008.100995] Call Trace: [354008.101000] [81006790] ? xen_force_evtchn_callback+0x9/0xa [354008.101006] [81006d22] ? check_events+0x12/0x20 [354008.101011] [81006d0f] ? xen_restore_fl_direct_reloc+0x4/0x4 [354008.101017] [81071153] ? arch_local_irq_restore+0x7/0x8 [354008.101024] [8135049f] ? _raw_spin_unlock_irqrestore+0xe/0xf [354008.101031] [810be895] ? release_pages+0xf4/0x14d [354008.101038] [810de78b] ? free_pages_and_swap_cache+0x48/0x60 [354008.101045] [810cf527] ? tlb_flush_mmu+0x37/0x50 [354008.101049] [810cf54c] ? tlb_finish_mmu+0xc/0x31 [354008.101054] [810d5e79] ? exit_mmap+0xc4/0xe9 [354008.101060] [81044b82] ? mmput+0x56/0xf8 [354008.101064] [81049d07] ? exit_mm+0x117/0x122 [354008.101069] [8107115b] ? arch_local_irq_disable+0x7/0x8 [354008.101074] [81350487
Bug#758622: kernel crashes after soft lockups in xen domU
] [8104b780] ? __local_bh_enable+0x40/0x77 [75.760695] [813576ac] ? call_softirq+0x1c/0x30 [75.760695] [81095239] ? arch_local_irq_save+0x11/0x15 [75.760695] [8121dd98] ? xen_evtchn_do_upcall+0x22/0x32 [75.760695] [813576fe] ? xen_do_hypervisor_callback+0x1e/0x30 [75.760695] EOI [8100122a] ? hypercall_page+0x22a/0x1000 [75.760695] [8100122a] ? hypercall_page+0x22a/0x1000 [75.760695] [81006790] ? xen_force_evtchn_callback+0x9/0xa [75.760695] [81006d22] ? check_events+0x12/0x20 [75.760695] [81006cc9] ? xen_irq_enable_direct_reloc+0x4/0x4 [75.760695] [810bf93f] ? spin_unlock_irq+0xa/0xb [75.760695] [810c1959] ? move_active_pages_to_lru+0x95/0x104 [75.760695] [810c3fd8] ? shrink_active_list.isra.51+0x2b5/0x2e2 [75.760695] [810c3c5f] ? shrink_inactive_list+0x32c/0x3f0 [75.760695] [810c4451] ? shrink_zone+0x44c/0x4e6 [75.760695] [810c48e3] ? do_try_to_free_pages+0x1cc/0x41c [75.760695] [810b84e7] ? arch_local_irq_restore+0x7/0x8 [75.760695] [810bb742] ? get_page_from_freelist+0x61f/0x665 [75.760695] [810c4d9e] ? try_to_free_pages+0xa9/0xe9 [75.760695] [810bbc75] ? __alloc_pages_nodemask+0x4ed/0x7aa [75.760695] [810be219] ? add_page_to_lru_list+0x64/0x64 [75.760695] [810e6969] ? alloc_pages_vma+0x12d/0x136 [75.760695] [810d1478] ? handle_pte_fault+0x165/0x79f [75.760695] [810ceacb] ? pmd_val+0x7/0x8 [75.760695] [810ceb49] ? pte_offset_kernel+0x16/0x35 [75.760695] [813533ee] ? do_page_fault+0x320/0x345 [75.760695] [81003223] ? xen_end_context_switch+0xe/0x1c [75.760695] [81003ba5] ? xen_mc_issue.constprop.23+0x31/0x49 [75.760695] [8100d750] ? __switch_to+0x1e5/0x258 [75.760695] [81035bd7] ? arch_local_irq_enable+0x7/0x8 [75.760695] [81039a92] ? finish_task_switch+0x4e/0xb9 [75.760695] [8134f0e9] ? __schedule+0x5f9/0x610 [75.760695] [813509f5] ? page_fault+0x25/0x30 Kind regards, jonas -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.60-1+deb7u3 ** Command line: root=/dev/xvda2 ro ** Not tainted ** Kernel log: [0.045534] NMI watchdog disabled (cpu7): hardware events not enabled [0.045554] Brought up 8 CPUs [0.045681] devtmpfs: initialized [0.048768] Grant table initialized [0.048768] print_constraints: dummy: [0.048768] NET: Registered protocol family 16 [0.048768] PCI: setting up Xen PCI frontend stub [0.048768] PCI: pci_cache_line_size set to 64 bytes [0.049493] bio: create slab bio-0 at 0 [0.049493] ACPI: Interpreter disabled. [0.049493] xen/balloon: Initialising balloon driver. [0.052066] xen-balloon: Initialising balloon driver. [0.052085] vgaarb: loaded [0.052085] PCI: System does not support PCI [0.052085] PCI: System does not support PCI [0.052137] Switching to clocksource xen [0.117785] pnp: PnP ACPI: disabled [0.120183] PCI: max bus depth: 0 pci_try_num: 1 [0.120324] NET: Registered protocol family 2 [0.121371] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) [0.123760] TCP established hash table entries: 524288 (order: 11, 8388608 bytes) [0.125130] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [0.125279] TCP: Hash tables configured (established 524288 bind 65536) [0.125285] TCP reno registered [0.125348] UDP hash table entries: 8192 (order: 6, 262144 bytes) [0.125449] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes) [0.125631] NET: Registered protocol family 1 [0.125642] PCI: CLS 0 bytes, default 64 [0.125682] Unpacking initramfs... [0.154337] Freeing initrd memory: 31668k freed [0.160765] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [0.160777] Placing 64MB software IO TLB between 8800faff2000 - 8800feff2000 [0.160782] software IO TLB at phys 0xfaff2000 - 0xfeff2000 [0.160883] platform rtc_cmos: registered platform RTC device (no PNP device found) [0.161373] audit: initializing netlink socket (disabled) [0.161390] type=2000 audit(1408391570.959:1): initialized [0.175642] HugeTLB registered 2 MB page size, pre-allocated 0 pages [0.176088] VFS: Disk quotas dquot_6.5.2 [0.176135] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [0.176214] msgmni has been set to 23991 [0.176418] alg: No test for stdrng (krng) [0.176469] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [0.176477] io scheduler noop registered [0.176480] io scheduler deadline registered [0.176531] io scheduler cfq registered (default
Bug#708344: [Xen-users] Serial Passthrough broken in Debian Wheezy?
Am 2013-06-04 19:45, schrieb Ian Campbell: On Tue, 2013-06-04 at 17:32 +0200, Jonas Meurer wrote: Just gave Linux 3.9-1-amd64 from Debian/sid a try. The issue is reproducible with this DomU kernel. Could you post dmesg, /proc/ioports and /proc/interrupts from this kernel please? Sure, here we go. All attached as textfiles. Additionally, I attached the (adjusted) domU config. Kind regards, jonas nitializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.9-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.9.4-1 [0.00] Command line: root=/dev/xvda2 ro root=/dev/xvda2 ro [0.00] ACPI in unprivileged domain disabled [0.00] e820: BIOS-provided physical RAM map: [0.00] Xen: [mem 0x-0x0009] usable [0.00] Xen: [mem 0x000a-0x000f] reserved [0.00] Xen: [mem 0x0010-0x0003007f] usable [0.00] NX (Execute Disable) protection: active [0.00] DMI not present or invalid. [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x300800 max_arch_pfn = 0x4 [0.00] e820: last_pfn = 0x10 max_arch_pfn = 0x4 [0.00] Base memory trampoline at [8809a000] 9a000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] init_memory_mapping: [mem 0x2ffe0-0x2] [0.00] [mem 0x2ffe0-0x2] page 4k [0.00] BRK [0x0187c000, 0x0187cfff] PGTABLE [0.00] BRK [0x0187d000, 0x0187dfff] PGTABLE [0.00] init_memory_mapping: [mem 0x2fc00-0x2ffdf] [0.00] [mem 0x2fc00-0x2ffdf] page 4k [0.00] BRK [0x0187e000, 0x0187efff] PGTABLE [0.00] BRK [0x0187f000, 0x0187] PGTABLE [0.00] BRK [0x0188, 0x01880fff] PGTABLE [0.00] init_memory_mapping: [mem 0x28000-0x2fbff] [0.00] [mem 0x28000-0x2fbff] page 4k [0.00] init_memory_mapping: [mem 0x0010-0x27fff] [0.00] [mem 0x0010-0x27fff] page 4k [0.00] init_memory_mapping: [mem 0x3-0x3007f] [0.00] [mem 0x3-0x3007f] page 4k [0.00] RAMDISK: [mem 0x01c7b000-0x03c13fff] [0.00] NUMA turned off [0.00] Faking a node at [mem 0x-0x0003007f] [0.00] Initmem setup node 0 [mem 0x-0x3007f] [0.00] NODE_DATA [mem 0x2fe81d000-0x2fe820fff] [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x3007f] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009] [0.00] node 0: [mem 0x0010-0x3007f] [0.00] On node 0 totalpages: 3147679 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 21 pages reserved [0.00] DMA zone: 3999 pages, LIFO batch:0 [0.00] DMA32 zone: 14280 pages used for memmap [0.00] DMA32 zone: 1044480 pages, LIFO batch:31 [0.00] Normal zone: 28700 pages used for memmap [0.00] Normal zone: 2099200 pages, LIFO batch:31 [0.00] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org [0.00] smpboot: Allowing 8 CPUs, 0 hotplug CPUs [0.00] No local APIC present [0.00] APIC: disable apic facility [0.00] APIC: switched to apic NOOP [0.00] nr_irqs_gsi: 16 [0.00] PM: Registered nosave memory: 000a - 0010 [0.00] e820: cannot find a gap in the 32bit address range [0.00] e820: PCI devices with unassigned 32bit BARs may break! [0.00] e820: [mem 0x30090-0x300cf] available for PCI devices [0.00] Booting paravirtualized kernel on Xen [0.00] Xen version: 4.1.4 (preserve-AD) [0.00] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:8 nr_node_ids:1 [0.00] PERCPU: Embedded 28 pages/cpu @8802fe20 s84800 r8192 d21696 u262144 [0.00] pcpu-alloc: s84800 r8192 d21696 u262144 alloc=1*2097152 [0.00] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 3104622 [0.00] Policy zone: Normal [0.00] Kernel command line: root=/dev/xvda2 ro root=/dev/xvda2 ro [0.00] PID hash table entries: 4096 (order: 3, 32768 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Checking aperture... [0.00] No AGP bridge found [0.00] Memory: 12316732k/12591104k
Bug#708344: [Xen-users] Serial Passthrough broken in Debian Wheezy?
Hey, Am 2013-06-03 18:17, schrieb Ian Campbell: On Mon, 2013-06-03 at 17:25 +0200, Jonas Meurer wrote: Hello, did anybody else discover issue with serial passthrough on Linux 3.2.0 from Debbian Wheezy? I haven't, but Squeeze was based on the out of tree xen.git kernel while Wheezy uses the mainline pvops support, so this is probably an issue with the mainline kernel. I can't quite imagine what it would be though. Are you able to try an newer upstream kernel in your domU? Either a newer version from Debian Sid or wheezy-backports or a self compiled one. Just gave Linux 3.9-1-amd64 from Debian/sid a try. The issue is reproducible with this DomU kernel. Kind regards, jonas Am 2013-05-14 14:56, schrieb Jonas Meurer: Hey again, Am 13.05.2013 17:58, schrieb Jonas Meurer: I just discovered a strange bug with serial passthrough in xen 4.1 on Debian Wheezy. The Dom0 has a GSM modem connected to serial port. The serial port is passed through to a DomU with options 'irq = [ 4 ]' and 'ioports = [ '3f8-3ff ]'. While searching the list archives I found out, that latest Xen 4.1 has several issues with passthrough. But so far it seems to me like nobody else described my exact issue before. Apparently, the other passthrough issues have been introduced by a hypervisor update. My problem appeared after a kernel upgrade. And for me, DomU creation still works. As described, the passed through serial even exists in DomU. Only it doesn't behave as expected. Just wanted to share those additional observations. Kind regards, jonas This worked as expected on Debian Squeeze with Xen 4.0 and Linux kernel 2.6.32 (both for Dom0 and DomU). On Debian Wheezy with Xen 4.1 and Linux kernel 3.2.0 the passthrough seems to work as well (/dev/ttyS0 appears in dmesg of DomU), but something is wrong. The GSM modem doesn't behave as expected. The smstools daemon errors out with 'Cannot open serial port /dev/ttyS0, error: Function not implemented'. It took me hours to find the difference, but it seems like the guest (domU) kernel is the problem. The setup keeps working when Dom0 is upgraded to Debian Wheezy with Xen 4.1 and linux kernel 3.2.0. It even keeps working if the DomU userland is upgraded to Debian Wheezy. Only if I upgrade the DomU linux kernel to 3.2.0 from Wheezy as well, smstools stops working. I don't expect this to be a smstools bug. More likely, something regarding serial pass through functions of xen is broken in 3.2.0 kernel from Debian Wheezy. Did anybody else discover similar issues yet? Kind regards, jonas PS: I'm not subscribed to pkg-xen-de...@lists.alioth.debian.org, please cc me on that list. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bae7da3caf73d0af7ed49b27be3b6...@imap.freesources.org
Bug#708344: xen: serial passthrough broken in Debian Wheezy
Package: src:linux Version: 3.2.41-2 Severity: important Hello, I just discovered a strange bug with serial passthrough in xen 4.1 on Debian Wheezy. The Dom0 has a GSM modem connected to serial port. The serial port is passed through to a DomU with options 'irq = [ 4 ]' and 'ioports = [ '3f8-3ff ]'. This worked as expected on Debian Squeeze with Xen 4.0 and Linux kernel 2.6.32 (both for Dom0 and DomU). On Debian Wheezy with Xen 4.1 and Linux kernel 3.2.0 the passthrough seems to work as well (/dev/ttyS0 appears in dmesg of DomU), but something is wrong. The GSM modem doesn't behave as expected. The smstools daemon errors out with 'Cannot open serial port /dev/ttyS0, error: Function not implemented'. It took me hours to find the difference, but it seems like the guest (domU) kernel is the problem. The setup keeps working when Dom0 is upgraded to Debian Wheezy with Xen 4.1 and linux kernel 3.2.0. It even keeps working if the DomU userland is upgraded to Debian Wheezy. Only if I upgrade the DomU linux kernel to 3.2.0 from Wheezy as well, smstools stops working. I don't expect this to be a smstools bug. More likely, something regarding serial pass through functions of xen is broken in 3.2.0 kernel from Debian Wheezy. Please give me advice on how to provide additional information. Kind regards, jonas -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2 -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130515080054.16881.77426.report...@host100.mejo.inet.de
Re: Linux kernel hardening - link restrictions
On 12-03-02 at 05:11am, Ben Hutchings wrote: The longstanding link restriction patches were recently accepted by Andrew Morton and are likely to end up in Linux 3.4. I've applied these to src:linux-2.6 in svn and they should end up in the upcoming version 3.2.9-1. We know that these are going to break some programs, most notably 'at' (#597130, fixed in wheezy/sid). But of course it's possible to work around that by disabling the restriction, so I don't think this should result in a 'Breaks' relation. I'm therefore intending to warn about this with the following NEWS entry in the linux-image metapackages: Index: debian/linux-image.NEWS === --- debian/linux-image.NEWS (revision 18757) +++ debian/linux-image.NEWS (working copy) @@ -1,3 +1,18 @@ +linux-latest (44) unstable; urgency=low + + * The new kernel version includes security restrictions on links, which +are enabled by default. These are specified in +Documentation/sysctl/fs.txt in the linux-doc-3.2 and linux-source-3.2 +packages. + +These restrictions may cause some legitimate programs to fail. +In particular, if the 'at' package is installed, you should either: +- Upgrade it to at least version 3.1.13-1 (or a backport of that) +or: +- Set sysctl fs.protected_hardlinks=0 (see /etc/sysctl.conf) + + -- Ben Hutchings b...@decadent.org.uk Fri, 02 Mar 2012 04:58:24 + + linux-latest-2.6 (26) unstable; urgency=low * The old IDE (PATA) drivers are no longer developed. Most PATA --- END --- (Why in the metapackages, you ask? Because apt-listchanges shows NEWS from upgraded packages, not new packages.) Does anyone have a better idea how to do this? Know about other packages that are affected? I suggest to add it to *both* metapackages and real packages: Some may not use the metapackages and may inspect the NEWS file by other means than via apt-listchanges (which I guess is what you are talking about). Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Bug#644850: linux-image-2.6.32-5-kirkwood: 2.6.32-38 does not recognise USB harddisks any longer
On 11-10-09 at 08:07pm, Joerg Morbitzer wrote: On the other hand: if the previous kernel was still in place why would it suddenly fail? I believe the answer to above is that the new kernel did not change ABI and therefore modules got installed instead of the old ones (not aside them) - causing the old kernel to try load new modules and failing. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#642066: linux-image-loongson-2f: Please include gnewsense patches
Hi Panayiotis, On 11-09-19 at 10:36am, Panayiotis Karabassis wrote: Currently the kernel is missing various bits of functionality, such as webcam operation and battery monitoring. Googling, I found this functionality is enabled if a Linux Libre kernel is used. However I have not been able to verify this, since the kernel does not install on my machine. I kindly request that the patches available at the following URL be included in the Debian package: http://www.fsfla.org/download/linux-libre/lemote/gnewsense/pool/ I suggest to contact gnewsense and kindly request them to pass their improvement upstream to the main Linux kernel development. Perhaps they already did. If so, they can then provide you some reference on where it is in the process of getting into the mainline tree. And you can forward that info here, to help track the process. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#613536: firmware-realtek: Please include the binary firmware for Realtek
Perhaps it is easier or better to grab the rtlwifi/rtl8192cfw.bin firmware from the linux-firmware repository: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=summary The corresponding license is included there as LICENCE.rtlwifi_firmware.txt . I've been happily using it for weeks with compat-wireless and linux-image-2.6.32-5-amd64 on my Thinkpad with Linux Mint Debian Edition. Further details at: http://www.thinkwiki.org/wiki/ThinkPad_11b/g/n_Wireless_LAN_Mini-PCI_Express_Adapter_III Recent Dell Minis feature this wifi adapter, too, so I guess it is or will become quite common. I'm just about to switch to the 2.6.38 kernel which includes the corresponding rtl8192ce driver, but unfortunately it is not enabled in the Debian unstable package, yet. However, my manual rebuild of that package with the module enabled works well so far, so maybe I just need to send a request for it. Cheers, Jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikr2=azrjN6=zb1teb7zpbdqfvzt4s8vsp3r...@mail.gmail.com
Bug#619051: linux-2.6: Missing Realtek 8188CE pcie wifi support (rtlwifi/rtl8192ce module not built)
Package: linux-2.6 Version: 2.6.38-1 Severity: wishlist Summary: Please enable the new rtlwifi/rtl8192ce drivers in the kernel build config. Full version: I'm sending this email from my wireless Thinkpad Edge using my own rebuild of the linux-image-2.6.38-1-amd64 package with just those two additional modules enabled and the firmware from the linux-firmware git repository in /lib/firmware/rtlwifi/rtl8192cfw.bin. My system runs Linux Mint Debian Edition, but it should apply to all Testing/Unstable systems with the Realtek 8188CE pcie wifi adapter and this kernel. I added the following lines to debian/config/config before building: ~/build diff -Naur config-default config-rtl8192ce --- config-default 2011-03-20 12:26:00.576309324 +0100 +++ config-rtl8192ce2011-03-20 12:40:51.117677926 +0100 @@ -1997,6 +1997,12 @@ CONFIG_RTL8187=m ## +## file: drivers/net/wireless/rtlwifi/Kconfig +## +CONFIG_RTL8192CE=m +CONFIG_RTLWIFI=m + +## ## file: drivers/net/wireless/wl1251/Kconfig ## CONFIG_WL1251=m Please also refer to #613536 for information about the corresponding firmware missing from the firmware-realtek package. Feel free to contact me for further information. Thanks in advance! Cheers, Jonas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110320153807.6488.70249.reportbug@edge
Bug#617639: [linux-2.6] linux-image-2.6.32-5-amd64: After connecting a USB stick, the screen becomes black or blinking sometimes
:48:52 EIFRWSE00160 kernel: [19086.372875] SysRq : This sysrq operation is disabled. Mar 8 13:48:53 EIFRWSE00160 kernel: [19087.187472] SysRq : Emergency Remount R/O regards Jonas --- System information. --- Architecture: amd64 Kernel: Linux 2.6.32-5-amd64 Debian Release: 6.0 900 stable security.debian.org 900 stable ftp.ch.debian.org 800 unstableftp.ch.debian.org 700 experimentalftp.ch.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299742705.2812.12.ca...@eifrwse00160.sofr.hefr.lan
Bug#515294: cryptsetup: Configurable passphrase prompt
Hey, On 12/02/2011 Rodolfo kix Garcia wrote: In the other bug, the user wants a different prompt: PROMPT=Hello boy, What's your passwd: Probably, this options should be in a config file. Any ideas? I'm unsure what to do about that bug. Maybe the initramfs maintainers have a suggestion? either the cryptroot-hook modifies the prompt in cryptroot-script according to an environment variable at mkinitramfs time. or a configuration file is added to the initramfs, which the cryptroot-script includes in order to set the prompt. question to the initramfs maintainers: are the environment variables from /usr/share/initramfs-tools/conf-hooks.d/* available to the initramfs hook scripts? It seems to me that this is not the case. and the second question: initramfs doesn't have support for translated strings yet, does it? greetings, jonas signature.asc Description: Digital signature
Re: [pkg-cryptsetup-devel] Bug#604814: upgrade-reports: Upgrade lenny to squeeze mostly successful
hey,
On 24/11/2010 Julien Cristau wrote:
On Wed, Nov 24, 2010 at 14:53:59 +0100, David Kuehling wrote:
Some warnings were printed during upgrade:
***
update-initramfs: Generating /boot/initrd.img-2.6.26-2-686
cryptsetup: WARNING: target sda2_crypt has a random key, skipped
/tmp/mkinitramfs_vkMxi2/scripts/local-top/cryptroot: line 11: [: too many
arguments
***
No problems so far, my crypto-root is booting without problems.
1 #!/bin/sh
2
3 #
4 # Standard initramfs preamble
5 #
6 prereqs()
7 {
8 # Make sure that cryptroot is run last in local-top
9 for req in $(dirname $0)/*; do
10 script=${req##*/}
11 if [ $script != cryptroot ]; then
12 echo $script
13 fi
14 done
15 }
16
17 case $1 in
18 prereqs)
19 prereqs
20 exit 0
Weird. Maybe the cryptsetup or initramfs-tools maintainer will have an
idea.
for some reason, $script seems to contain a space.
David, please apply attached patch to
/usr/share/initramfs-tools/scripts/local-top/cryptroot and see, whether
that fixes the bug for you. you can try this by invoking
'update-initramfs -u' after applying the patch.
greetings,
jonas
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot
@@ -8,8 +8,8 @@
# Make sure that cryptroot is run last in local-top
for req in $(dirname $0)/*; do
script=${req##*/}
- if [ $script != cryptroot ]; then
- echo $script
+ if [ $script != cryptroot ]; then
+ echo $script
fi
done
}
@@ -90,9 +90,9 @@
;;
source=*)
cryptsource=${x#source=}
- if [ ${cryptsource#UUID=} != $cryptsource ]; then
+ if [ ${cryptsource#UUID=} != $cryptsource ]; then
cryptsource=/dev/disk/by-uuid/${cryptsource#UUID=}
- elif [ ${cryptsource#LABEL=} != $cryptsource ]; then
+ elif [ ${cryptsource#LABEL=} != $cryptsource ]; then
cryptsource=/dev/disk/by-label/${cryptsource#LABEL=}
fi
export CRYPTTAB_SOURCE=$cryptsource
@@ -198,7 +198,7 @@
modprobe -q dm_crypt
# Make sure the cryptsource device is available
- if [ ! -e $cryptsource ]; then
+ if [ ! -e $cryptsource ]; then
activate_vg
activate_evms
fi
@@ -226,10 +226,10 @@
while [ ! -e $cryptsource ]; do
/bin/sleep 0.1
slumber=$(( ${slumber} - 1 ))
- [ ${slumber} -gt 0 ] || break
+ [ ${slumber} -gt 0 ] || break
done
- if [ ${slumber} -gt 0 ]; then
+ if [ ${slumber} -gt 0 ]; then
log_end_msg 0
else
log_end_msg 1 || true
@@ -258,14 +258,14 @@
# Try to get a satisfactory password $crypttries times
count=0
- while [ $crypttries -le 0 ] || [ $count -lt $crypttries ]; do
+ while [ $crypttries -le 0 ] || [ $count -lt $crypttries ]; do
count=$(( $count + 1 ))
- if [ $count -gt 1 ]; then
+ if [ $count -gt 1 ]; then
/bin/sleep 3
fi
- if [ $crypttries -gt 0 ] [ $count -gt $crypttries ]; then
+ if [ $crypttries -gt 0 ] [ $count -gt $crypttries ]; then
message cryptsetup: maximum number of tries exceeded for $crypttarget
return 1
fi
signature.asc
Description: Digital signature
Bug#598866: [linux-image-2.6-amd64] BUG: unable to handle kernel NULL pointer dereference at (null) when X starts with xorg.conf
Package: linux-image-2.6-amd64 Version: 2.6.32+28 Severity: important --- Please enter the report below this line. --- Hello I have installed debian testing AMD64 yesterday from a CD and after the first reboot, I had a black screen when gdm tried to start. Uninstalling xserver-xorg-video-ati fixed the problem for me. Then I needed to create a xorg.conf in order to be able to be able to use dual screens and I wanted to test the xorg.conf generated by Xorg -configure with gdm, but I also had a black screen and can't use the keyboard anymore except with the magic keys. I was then able to enter raw mode and get the following messages from dmesg : [ 14.561465] Bridge firewalling registered [ 14.577850] Bluetooth: SCO (Voice Link) ver 0.6 [ 14.577852] Bluetooth: SCO socket layer initialized [ 14.765427] BUG: unable to handle kernel NULL pointer dereference at (null) [ 14.765434] IP: [a0344933] r600_ioctl_wait_idle+0x49/0x89 [radeon] [ 14.765458] PGD 12e1d3067 PUD 12cd46067 PMD 0 [ 14.765464] Oops: [#1] SMP [ 14.765468] last sysfs file: /sys/devices/virtual/net/lo/operstate [ 14.765472] CPU 5 [ 14.765475] Modules linked in: sco bridge stp bnep rfcomm l2cap bluetooth rfkill acpi_cpufreq cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats fuse radeon ttm drm_kms_helper drm i2c_algo_bit loop snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device i2c_i801 snd soundcore snd_page_alloc i2c_core parport_pc video output pcspkr button evdev parport psmouse processor serio_raw ext4 mbcache jbd2 crc16 sg sr_mod cdrom sd_mod crc_t10dif usbhid hid ata_piix ata_generic libata ehci_hcd e1000e scsi_mod usbcore nls_base thermal thermal_sys [last unloaded: scsi_wait_scan] [ 14.765549] Pid: 1792, comm: Xorg Not tainted 2.6.32-5-amd64 #1 [ 14.765553] RIP: 0010:[a0344933] [a0344933] r600_ioctl_wait_idle+0x49/0x89 [radeon] [ 14.765573] RSP: 0018:88012e34dd70 EFLAGS: 00010246 [ 14.765577] RAX: RBX: 88012e30ce00 RCX: [ 14.765581] RDX: c90005702f34 RSI: 88012e30ce00 RDI: 88012c3be000 [ 14.765585] RBP: 88012dc106c0 R08: 88012e30ce80 R09: c0086464 [ 14.765588] R10: 0001 R11: 00032e34dd7c R12: [ 14.765592] R13: 88012c0ae000 R14: 88012e296600 R15: 88012c0ae000 [ 14.765597] FS: 7fed4a32e700() GS:8800054a() knlGS: [ 14.765601] CS: 0010 DS: ES: CR0: 80050033 [ 14.765605] CR2: CR3: 00012c502000 CR4: 06e0 [ 14.765609] DR0: DR1: DR2: [ 14.765613] DR3: DR6: 0ff0 DR7: 0400 [ 14.765617] Process Xorg (pid: 1792, threadinfo 88012e34c000, task 88012dc1f810) [ 14.765620] Stack: [ 14.765622] a032ab0c 88012dc106c0 88012e34dde8 7fff865100a0 [ 14.765628] 0 a0375d90 c0086464 a02c6f5c 88010064 [ 14.765634] 0 e200 0001 810ca3c2 7fff86510190 [ 14.765641] Call Trace: [ 14.765662] [a032ab0c] ? radeon_gem_wait_idle_ioctl+0x5d/0x8b [radeon] [ 14.765674] [a02c6f5c] ? drm_ioctl+0x259/0x30d [drm] [ 14.765683] [810ca3c2] ? __do_fault+0x38c/0x3c3 [ 14.765704] [a032aaaf] ? radeon_gem_wait_idle_ioctl+0x0/0x8b [radeon] [ 14.765710] [810c338a] ? vma_prio_tree_insert+0x20/0x3a [ 14.765716] [810d035e] ? vma_link+0x74/0x9a [ 14.765722] [810fa032] ? vfs_ioctl+0x21/0x6c [ 14.765727] [810fa580] ? do_vfs_ioctl+0x48d/0x4cb [ 14.765732] [810fa60f] ? sys_ioctl+0x51/0x70 [ 14.765738] [81010b42] ? system_call_fastpath+0x16/0x1b [ 14.765741] Code: 8b 97 c8 00 00 00 76 0d 48 81 c2 34 2f 00 00 31 c0 89 02 eb 16 b8 34 2f 00 00 89 02 48 8b 87 c8 00 00 00 31 d2 48 83 c0 04 89 10 8b 01 c3 48 81 bf c0 00 00 00 80 54 00 00 48 8b 97 c8 00 00 00 [ 14.765784] RIP [a0344933] r600_ioctl_wait_idle+0x49/0x89 [radeon] [ 14.765802] RSP 88012e34dd70 [ 14.765805] CR2: [ 14.765808] ---[ end trace b4246ebb442c59dc ]--- [ 14.766216] [drm:drm_release] *ERROR* Device busy: 1 [ 15.016268] lp0: using parport0 (interrupt-driven). [ 15.018101] ppdev: user-space parallel port driver [ 15.074150] BUG: unable to handle kernel NULL pointer dereference at (null) [ 15.074153] IP: [a0344933] r600_ioctl_wait_idle+0x49/0x89 [radeon] [ 15.074163] PGD 12e3d4067 PUD 12e1fb067 PMD 0 [ 15.074165] Oops: [#2] SMP [ 15.074167] last sysfs file: /sys/module/parport_pc/initstate [ 15.074168] CPU 0 [ 15.074169] Modules linked in: ppdev lp sco bridge stp bnep rfcomm l2cap bluetooth rfkill acpi_cpufreq
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, Jun 30, 2010 at 09:29:42AM -0400, Stephen Powell wrote: Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. Beware that multiple boot loaders might be installed concurrently. If each of them provide a zz- hook script implemented independently, they might handle symlinks differently, leading to surprises. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, Jun 30, 2010 at 10:31:32AM -0400, Stephen Powell wrote: On Wed, 30 Jun 2010 10:00:10 -0400 (EDT), Jonas Smedegaard wrote: On Wed, Jun 30, 2010 at 09:29:42AM -0400, Stephen Powell wrote: ... Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. Beware that multiple boot loaders might be installed concurrently. If each of them provide a zz- hook script implemented independently, they might handle symlinks differently, leading to surprises. dpkg does not prevent multiple boot loaders from being installed concurrently; but this environment is not supported by the various system maintainer scripts of Debian, even today. For example, update-initramfs -u currently checks to see if lilo is installed, and if it is, it runs lilo. But if grub (either version 1 or version 2) is installed also, it issues the following messages: WARNING: grub and lilo installed. Please de-install unused bootloader. It could also test for other boot loaders as well, such as extlinux, but it doesn't. The point is that Debian's maintainer scripts do not support multiple concurrently-installed boot loaders even today. I read above as initramfs-tools in particular not supporting multiple bootloaders. Could you perhaps elaborate more on why this is a general problem? Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: [RFC] Updating boot loaders in lenny and squeeze
On Sat, Jun 26, 2010 at 08:50:27PM +0100, Ben Hutchings wrote: On Wed, 2010-06-23 at 23:31 +0200, Jonas Smedegaard wrote: On Wed, Jun 23, 2010 at 10:12:42AM -0400, Stephen Powell wrote: That does seem like a more general-purpose solution, rather than having lilo and zipl treated as special cases. But please keep the appropriate parties informed of any future design changes to update-initramfs. I myself have never used yaird, but I assume that to be consistent it should have a similar hook system. A great while back initramfs-tools and kernel packages broke the ABI coordinated across initramfs-tools, linux-2.6, yaird and kernel-package. Sure would be nice with a stable ABI again, and getting informed if it changes. That is a separate issue. What we need here is an interface for the initramfs builder to update the boot loader if necessary. No such interface exists yet, AFAIK. Agreed, this is a different ABI. The wish for such ABI being treated as a cross-package ABI still exist. One approach would be to create a page at wiki.debian.org which all interested parties could then subscribe to. I would dislike if (as in the past) we simply rely on whatever internal routines implemented by the most popular packages (initramfs-tools and minux-2.6) which others then need to track sources of. I suggest something like the following: 1. Boot loaders that maintain block lists install a script under /etc/mkinitramfs/post-update.d which takes two arguments: the kernel ABI version (uname -r) and the absolute path to an initramfs. 2. Initramfs builders call the scripts in this directory after creating, updating or deleting an initramfs by running: run-parts --verbose --exit-on-error --arg=$version --arg=$path /etc/mkinitramfs/post-update.d or similar. We could alternately use multiple directories or an argument to distinguish creation, update and deletion. However, I suspect that these scripts will need to invoke the same command in all cases. Seems reasonable to me. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: [RFC] Updating boot loaders in lenny and squeeze
On Wed, Jun 23, 2010 at 10:12:42AM -0400, Stephen Powell wrote: That does seem like a more general-purpose solution, rather than having lilo and zipl treated as special cases. But please keep the appropriate parties informed of any future design changes to update-initramfs. I myself have never used yaird, but I assume that to be consistent it should have a similar hook system. A great while back initramfs-tools and kernel packages broke the ABI coordinated across initramfs-tools, linux-2.6, yaird and kernel-package. Sure would be nice with a stable ABI again, and getting informed if it changes. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#582481: [pkg-cryptsetup-devel] Bug#582481: initramfs-tools: System won't boot anymore if it was encrypted by debian squeeze setup
hey andre, On 25/05/2010 Andre Pawlowski wrote: Today I could copy all the output the error does. thanks, let's see ... Here is what the system shows when I boot with the new initrd.img-2.6.32-trunk-amd64: Loading, please wait... Volume group laptop-vg not found Skipping volume group laptop-vg Unable to find LVM volume laptop-vg/root Unlocking the disk /dev/disk/by-uuid/e7bf2609-7a87-447c-9827-694bc164debb (sda2_crypt) Enter passphrase: udevd-work[422]: kernel-provided name 'dm-0' and NAME= 'mapper/temporary-cryptsetup-414' disagree, please use SYMLINK+= or change the kernel to provide the proper name udevd-work[422]: kernel-provided name 'dm-0' and NAME= 'mapper/temporary-cryptsetup-414' disagree, please use SYMLINK+= or change the kernel to provide the proper name No key available with this passphrase cryptsetup: cryptsetup failed, bad password or options? Unlocking the disk /dev/disk/by-uuid/e7bf2609-7a87-447c-9827-694bc164debb (sda2_crypt) Enter passphrase: did you try to submit the correct passphrase at all? as already written, these udevd-work messages are just warnings, they shouldn't have any impact on the functionality after all. in fact, they appear on my system as well since last udev upgrade. but unlocking the disk still works. Ok, now the output when I use the initrd.img-2.6.32-trunk-amd64.bak: Loading, please wait... Volume group laptop-vg not found Skipping volume group hantuch-vg Unable to find LVM volume laptop-vg/root Unlocking the disk /dev/disk/by-uuid/e7bf2609-7a87-447c-9827-694bc164debb (sda2_crypt) Enter passphrase: Key slot 0 unlocked [normal booting output follows] The system is up to date with the newest squeeze packets. so unlocking the disk works with old initramfs, while it fails with the new initramfs (ignoring the udev warnings)? or does it work with the new initramfs as well, despite cluttering the passphrase prompt with udev warnings? in the former case you most probably spotted another bug (or misconfigured your system), in the latter case this bugreport should be reassigned to package dmsetup, where the respective udev rules need to be updated. greetings, jonas signature.asc Description: Digital signature
Bug#582481: [pkg-cryptsetup-devel] Bug#582481: initramfs-tools: System won't boot anymore if it was encrypted by debian squeeze setup
reassign 582481 dmsetup severity 582481 minor tags 582481 -moreinfo thanks hey marco, On 25/05/2010 Marco d'Itri wrote: On May 25, Jonas Meurer jo...@freesources.org wrote: in the former case you most probably spotted another bug (or misconfigured your system), in the latter case this bugreport should be reassigned to package dmsetup, where the respective udev rules need to be updated. The warning is harmless and does not cause any problems (with the existing kernels). this is known and has been mentioned several times in the buglog already. still the rules need to be updated in order to stop the appearance of these harmless but annoying warning messages. thus reassigning with severity minor. greetings, jonas signature.asc Description: Digital signature
Bug#582481: [pkg-cryptsetup-devel] Bug#582481: initramfs-tools: System won't boot anymore if it was encrypted by debian squeeze setup
hey, On 21/05/2010 maximilian attems wrote: On Fri, 21 May 2010, Andre Pawlowski wrote: This bugreport was written with the initrd.img-2.6.32-trunk-amd64.bak before updating yesterday to initramfs-tools 0.94.4. I have an encrytped lvm which contains every partition except /boot. It was created by the Debian squeeze setup when I installed the system. Today I tried to boot the system with the new initramfs-tools and after I entered the password I get this message: kernel-provided name 'dm-0' and NAME='/mapper/sda2_crypt' disagree, please use SYMLINK+= or change the kernel to provide the proper name This bug appears after I upgraded libudev0 udev insserv groff-base initramfs-tools libglib2.0-0 libglib2.0-dev libglib2.0-data libgps19 libgudev-1.0-0 libjack0 libschroedinger-1.0-0 libwebkit-1.0-common libwebkit-1.0-2 xserver-xorg-video-intel xterm because I only changed the initrd.img and after that I could boot the system again I think it is a bug in initramfs-tools. no we dont set udev symlinks, so it is either a crytsetup or an udev bug. i strongly believe it's a udev bug. the same warnings appear on my system since last udev upgrade. the apear both at cryptdisks and lvm initscript invokation. didn't have time to further investigate it though. greetings, jonas signature.asc Description: Digital signature
Re: Maintenance of nfs-kernel-server
Hi Ben, Aníbal and others, On Mon, Apr 05, 2010 at 11:20:42PM +0100, Ben Hutchings wrote: On Mon, 2010-04-05 at 13:32 +1000, Aníbal Monsalve Salazar wrote: On Sun, Apr 04, 2010 at 08:38:28PM +0100, Ben Hutchings wrote: nfs-kernel-server is closely related to the Linux kernel and most of the bugs reported on it appear to actually be kernel bugs. Therefore it seems to me that it would make more sense for the kernel team to maintain it. Sure. Would you be willing to hand over or share maintainership? I would like to share maintainership. Here's the debdiff for the changes I'd like to make now. We should probably import nfs-utils into a VCS somewhere, but I'm not sure how best to do that with a v3.0 package. One approach is git-buildpackage + the following in debian/rules: clean:: [ ! -d .pc ] || [ ! -f .pc/applied-patches ] || QUILT_PATCHES=debian/patches quilt pop -a [ ! -d .pc ] || [ -f .pc/* ] || rm -rf .pc Above (slightly more convoluted) is what was applied to the JACK[1] packaging yesterday, after discussion[2] in the Multimedia list. Off course it depends highly on your preferred VCS habits, but I guess as kernel hackers you would want to use Git so I suspect it won't be far off from your wants. Regards, - Jonas [1] debcheckout jack-audio-connection-kit [2] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-April/008671.html -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#561764: Bug#561229: Bug#561764: some warnings fly off screen and are not saved in any file
On Mon, Dec 21, 2009 at 09:46:57AM +0100, Bernd Zeimetz wrote:
jida...@jidanni.org wrote:
OK, via
$ zcat /boot/initrd.img-2.6.32-trunk-686|strings|less
I think I found one of the messages I saw:
SYSFS{}= will be removed in a future udev version
which is in /sbin/udevadm ... bug #561229 perhaps.
What the hell does a bug in gpsd udev rules have to do with this
problem?
The bugreport concerns warning messages early in the bootup process not
getting saved.
By now it has been established that those messages are generated by
udev, which is invoked by the initial ramdisk.
Cursing won't make this bug go away.
Demanding the original reporter of the bug to be more clueful is a lousy
approach to solve it, IMHO.
Regards,
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
Bug#559035: linux-image-2.6.26-2-amd64: Random segfaults with lenny amd64 kernel
Package: linux-image-2.6.26-2-amd64 Version: 2.6.26-19lenny2 Followup-For: Bug #559035 Just a 'me too' on the plain kernel version. Some way along the upgrade path [UPGRADE] linux-image-2.6.26-2-amd64 2.6.26-17 - 2.6.26-17lenny2 [UPGRADE] linux-image-2.6.26-2-amd64 2.6.26-17lenny2 - 2.6.26-19 [UPGRADE] linux-image-2.6.26-2-amd64 2.6.26-19 - 2.6.26-19lenny1 [UPGRADE] linux-image-2.6.26-2-amd64 2.6.26-19lenny1 - 2.6.26-19lenny2 I started getting random python segfaults in the log (see log below). There are no additional trace lines in my log, though. All of them are from 5 different python cgi scripts out of a bigger set, and apparently they succeed without segfault most of the time. Actually the segfaults seem to happen only once in every 1 or more tries. All the scripts do file I/O, but do not use any exotic python modules. The simplest one I've seen fail is available from: http://code.google.com/p/migrid/source/browse/trunk/mig/cgi-sid/isjobactive.py It is a production server, but please inform me if there is anything I can test without too much down-time. -- Package-specific info: ** Version: Linux version 2.6.26-2-amd64 (Debian 2.6.26-19lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 5 02:23:12 UTC 2009 ** Command line: root=/dev/md0 ro quiet ** Not tainted ** Kernel log: Dec 12 05:20:54 distlab4 kernel: [411461.235540] statusexe.py[30663]: segfault at 7fff26345a68 ip 4d0e33 sp 7fff26345a70 error 6 in python2.5[40+125000] Dec 12 07:58:00 distlab4 kernel: [420908.288898] jobstatus.py[27020]: segfault at 7fff83701fc8 ip 4a256b sp 7fff83701fb0 error 6 in python2.5[40+125000] Dec 12 09:18:26 distlab4 kernel: [425739.243068] statusexe.py[24938]: segfault at 765a9b98 ip 4ae07b sp 765a9ba0 error 6 in python2.5[40+125000] Dec 12 10:17:39 distlab4 kernel: [429296.675477] put[16603]: segfault at 7fff420cde68 ip 4ae07b sp 7fff420cde70 error 6 in python2.5[40+125000] Dec 12 11:44:45 distlab4 kernel: [434530.111503] put[19119]: segfault at 7fff04847e78 ip 4abd33 sp 7fff04847e80 error 6 in python2.5[40+125000] -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-2-amd64 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-2-amd64 recommends no packages. Versions of packages linux-image-2.6.26-2-amd64 suggests: ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 none(no description available) Cheers, Jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555671: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#555671: linux-image-2.6.26-2-686: Conflicts: yaird ( 0.0.13) but 0.0.12-25 is to be installed)
On Thu, Nov 12, 2009 at 01:45:05AM +, Ben Hutchings wrote: On Thu, 2009-11-12 at 00:12 +0100, matthieu castet wrote: On Wed, 2009-11-11 at 00:14 +0100, matthieu castet wrote: Package: linux-image-2.6.26-2-686 Severity: normal Hi, in lenny linux-image-2.6.26-2-686 failed because it want a version of yaird that doesn't exist. No, it *conflicts* with the old version of yaird that you have installed. yaird is not included in 'lenny'; you should use initramfs-tools instead. Ben. yaird was present on etch, why it is not present on lenny. I don't know; it was not my decision. No, it was the decision of a release manager, based on judgement of Max, described by same release manager as long-term kernel team member which was judging with his kernel arch maintainer hat on. [1] So waving off as not my problem by the kernel team seems a little odd to me. If you speak with your kernel team hat on, that is. I don't want to install initramfs-tools because it depends on udev. And my system which is a video recorder doesn't want/need it. Then you should stick with etch or build your own kernel without an initramfs. Do not ask us to support systems without udev. I do agree: despite my disagreement with max on bug#457177 and (many) other issues of yaird, that does not change that Debian as a project has decided to only in its current stable release have decided to only ship with a single ramdisk generator - the one maintained by the Debian kernel team (or a member therof), and that ramdisk generator depends on udev. So I agree that this bugreport as filed is inappropriate and should stay closed. Kind regards, - Jonas Maintainer of yaird [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457177#78 -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#529164: RE : [linux-image-2.6.29-2-686] unable to handle kernel NULL pointer dereference at ... bug
I updated my laptop yesterday and I did some suspend to disk, but I wasn't able to reproduce the bug anymore Bye Jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533760: linux-headers-2.6.30-1-amd64: Depends on non existing package
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Sat, Jun 20, 2009 at 11:39:05AM +, Debian Bug Tracking System wrote: Not again. This is in NEW. Why not? Because it occurs repeatedly? Or because it will fix itself soon? Please acknowledge the bug and tag as pending instead of closing. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAko81KwACgkQn7DbMsAkQLhAxQCeOfYF5FhCIUejFPMWxhxTnI7U Ww4Anj3SOBdLblSfg/bIe4x9dZlFkGEb =uBho -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hint cryptsetup/2:1.0.6+20090405.svn49-1 for debian/squeeze
On 08/06/2009 Jonas Meurer wrote: hey again, On 02/06/2009 Jonas Meurer wrote: cryptsetup/2:1.0.6+20090405.svn49-1 has been in unstable for 59 days now without migrating to testing. I guess that this is due to the udeb it creates. It would be great if you could hint it for migration to testing/squeeze. here's the relevant changelog: is there a reason why this request has been ignored so far? can I do anything about it? i've cc'ed debian-kernel now, as cryptsetup creates a udeb, and their option might be relevant. shit, that should have been debian-boot instead of debian-kernel. sorry for the noise. greetings, jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hint cryptsetup/2:1.0.6+20090405.svn49-1 for debian/squeeze
hey again, On 02/06/2009 Jonas Meurer wrote: cryptsetup/2:1.0.6+20090405.svn49-1 has been in unstable for 59 days now without migrating to testing. I guess that this is due to the udeb it creates. It would be great if you could hint it for migration to testing/squeeze. here's the relevant changelog: is there a reason why this request has been ignored so far? can I do anything about it? i've cc'ed debian-kernel now, as cryptsetup creates a udeb, and their option might be relevant. greetings, jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Raising minimum CPU requirement for i386 kernel
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Sun, May 24, 2009 at 01:18:39PM -0600, dann frazier wrote: On Sun, May 24, 2009 at 09:07:49PM +0200, Bastian Blank wrote: Hi folks I would like to raise the minimum CPU requirement for the shipped Linux kernels in the i386 port to i686 (with cmov). For now I will not propose a change of the default machine type setting used by the compiler. This means that Debian will get uninstallable on the following CPUs: - Intel i486, - Intel Pentium (MMX), - AMD K5, - AMD K6(-2, -3), - Cyrix 6x86, - VIA C3 before Nehemiah and - National Semiconductor Geode (GXm, GXLV, GX1 and GX2). Except for the C3 and the Geodes, all of them were released in the last Millenium and the successors will be available for at least 10 years at the release of Squeeze. I actively use a VIA C3 (no-cmov) for a number of services, so would prefer not to lose that support. Same here. Me, clients and friends use 10-12 non-cmov boards. non-cmov EPIA and Eden boards are still available in northern european shops and quite cheap. (The new Intel boards are much better, but even if cheaper, they have special PSU requirements so might still end up being more expensive all in all.) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkoZq5sACgkQn7DbMsAkQLiaRACfbhKGOabImgoHtlFXk05jlen1 02kAn0zh936g0j5aYDzBdYLKbffHyO7p =oh2j -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529164: [linux-image-2.6.29-2-686] unable to handle kernel NULL pointer dereference at ... bug
Package: linux-image-2.6.29-2-686 Version: 2.6.29-4 Severity: important --- Please enter the report below this line. --- Hello I am using a Dell Latitude D630 and once I was shutting down my computer when I got a unable to handle kernel NULL pointer dereference at 0018 bug followed by some messages which I typed the most below : [sda] Synchronizing SCSI cache [sda] Stopping disk BUG: unable to handle kernel NULL pointer dereference at 0018 IP: [c01c316c] sysfs_remove_one+0x13/0x59 *pde = Oops : [#1] SMP last sysfs file: /sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/removable It tells me that the last unloaded module was fuse Pid: 12981, comm: halt Not tainted (2.6.29-2-686 #1) Latitude D630 EIP : 0060:[c01c316c] EFLAGS: 00010246 CPU: 0 EIP is at sysfs_remove_one+0x13/0x59 EAX: EBX: 0018 ECX: f53d3e58 EDX: f6b13b90 ESI: f7022350 EDI: f7022368 EBP: f53d2000 ESP: f53d3e50 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process halt (pid: 12981, ti=f53d2000 task=f6af37f0 task.ti=f53d2000) Stack: f732c900 c01c387e f7022350 f6b0ecf0 002f f732c900 c03aee7c f7001c20 c01f9c81 f732c900 c01f9ccc f732c91c c01f9c9d 28121969 c01fa749 ef592800 4321fedc c025b2df c0131fb0 c01321e1 c17f9820 c02ee9b8 Call trace : [c01c387e] sysfs_remove_dir+0x46/0x66 [c01f9c81] kobject_del+0xc/0x28 [c01f9ccc] kobject_release+0x2f/0x4f [c01f9c9d] kobject_release+0x0/0x4f [c01fa749] kref_put+0x39/0x43 [c025b2df] device_shutdown+0x54/0x69 [c0131fb0] kernel_power_off+0xa/0x2f [c01321e1] sys_reboot+0xf6/0x16c [c0120e8c] try_to_wake_up+0x14e/0x157 [c0139b45] sched_clock_cpu+0x136/0x147 [c010212e] __switch_to+0xcd/0x14e [c011cecb] pick_next_task_fair+0x80/0x87 [c012267b] finish_task_switch+0x22/0xa5 [c02e61c3] schedule+0x6dd/0x754 [c0198841] mntput_no_expire+0x1a/0xfe [c0185c71] filp_close+0x4e/0x54 [c0185cdb] sys_close+0x64/0x9f [c010341b] sysenter_do_call+0x12/0x2f Code: e8 b0 26 12 00 58 5a c3 90 90 90 8b 40 20 0f 94 c0 0f b6 c0 c3 f6 42 1d 02 89 c1 53 74 04 0f 0b eb fe 8b 42 08 8d 58 18 8b 40 18 eb 18 39 d0 75 0e 8b 42 0c 00 00 00 00 EIP: [c01c316c] sysfs_remove_one+0x13/0x59 SS:ESP 0068:f53d3e50 /etc/rc0.d/S90halt: line 19: 12981 Segmentation fault halt -d -f $netdown $poweroff $hddown sda is my hard disk and I have kernel modesetting enabled. I don't know how to reproduce this bug again, I think that is because I made some suspend to disk, suspend to RAM and resuming before. It is new that I have linux-image-2.6.29-2-686 installed and kernel modesetting enabled. So I will see later if this bug comes with suspending. I found almost the same bug once I was resuming from suspend to disk and removed a USB Stick during the same time (I can't reproduce this one either) and I notice that with this one it was said : BUG: unable to handle kernel NULL pointer dereference at 001c and it has a different call trace. additional informations : coreutils/testing uptodate 7.3-1 initscripts/stable uptodate 2.86.ds1-61 xserver-xorg-video-intel/sid uptodate 2:2.7.1-1 Bye Jonas --- System information. --- Architecture: i386 Kernel: Linux 2.6.29-2-686 Debian Release: squeeze/sid 450 testing ftp.de.debian.org 400 stable ftp.de.debian.org 300 unstableftp.de.debian.org 200 experimentalftp.ch.debian.org --- Package information. --- Depends (Version) | Installed =-+-= module-init-tools | 3.7-pre9-1 initramfs-tools(= 0.55) | 0.93.2 OR yaird(= 0.0.13) | OR linux-initramfs-tool | Recommends (Version) | Installed =-+-=== libc6-i686| 2.9-4 Suggests (Version) | Installed ===-+-=== linux-doc-2.6.29| grub| OR lilo| --- Output from package bug script --- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523828: linux-image-2.6.26-2-486: fails to find modules.pcimap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 12, 2009 at 03:40:33PM -0600, dann frazier wrote: On Sun, Apr 12, 2009 at 09:37:51PM +0200, Beat Bolli wrote: Package: linux-image-2.6.26-2-486 Version: 2.6.26-15 Severity: grave Justification: renders package unusable During installation of the latest 2.6 kernel I get the following: Setting up linux-image-2.6.26-2-486 (2.6.26-15) ... Running depmod. Running mkinitrd.yaird. yaird error: can't open pci module list /lib/modules/2.6.26-2-486/modules.pcimap (fatal) mkinitrd.yaird failed to create initrd image. Failed to create initrd image. dpkg: error processing linux-image-2.6.26-2-486 (--configure): subprocess post-installation script returned error exit status 9 A second aptitude full-upgrade produces the same messages. The root issue here is that module-init-tools version in squeeze has stopped generating the .map files by default. From the upstream changelog: 3.6 Version: o depmod: make building map files optional (does anyone use them anyway?) So either yaird needs to be updated to no longer require the modules.pcimap file, or make sure the map files still get generated either by calling depmod -m itself, or working with the kernel team to have the image postinst modified to include -m. Note that 2.6.26 kernels are only being updated for use in lenny. The reason this update appeared in squeeze is because a newer release has not yet migrated from sid into squeeze, but we need squeeze versions of package to be greater than or equal to the versions in lenny. Changing maintainer scripts in the lenny packages will unlikely be done unless its shown to break upgrades to lenny. As a workaround, you might consider trying initramfs-tools instead of yaird, or manually running: # depmod -a -m -F /boot/System.map-2.6.26-2-686 2.6.26-2-686 # dpkg --configure -a Thanks for the detailed info, Dann! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknjRNcACgkQn7DbMsAkQLhVIwCfdj1lgXvpIYiqgXnCvxtHNsrj 7KMAmgLUNl2wuVuJvzhWFiEsF66MqnA/ =ZH1+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522909: linux-image-2.6.29-1-amd64: Package cannot be configured due to invalid mkinitrd options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 07, 2009 at 01:54:05PM +0200, Frank Blendinger wrote: Hi. On Tue 2009-04-07 13:31, maximilian attems m...@stro.at proclaimed: On Tue, Apr 07, 2009 at 01:27:45PM +0200, Frank Blendinger wrote: post the output of cat /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = no ramdisk=mkinitrd.yaird mkinitramfs well that is wrong, easiest way is to just scratch that last line. Indeed. It works fine without that line. What Max suggests above is to stop favoring yaird, and instead use the default one (initramfs-tools). If you have no interest in using a specific ramdisk tool, then I agree that you can *avoid* this bug by not explicitly using a ramdisk generator that triggers the bug. Above config file of yours is not wrong, however. ...or more precisely it is not wrong to have yaird in that line - it might be wrong to use mkinitramfs (use mkinitramfs-kpkg instead) but that is a different issue which does not relate to the currently discussed bug. longer explanation * yaird doesn't fully implement update-initramfs compat syntax so can no longer install any linux image since 2.6.28 #518315 If you read that bugreport you will notice the lack of response from the kernel team on the questions raised there. (beside beeing not recommended, not distributed in Lenny, buggy in many ways, not developed anymore and thus deprecated) The package maintainer of initramfs-tools (Max) do not recommend the use of the alternative ramdisk tool yaird. Yaird is bugy in *different* ways than initramfs-tools. Yaird is still developed. Please do not spread FUD! * mkinitramfs was never the direct wrapper to call previously in lenny you could have had mkinitramfs-kpkg in aboves line. now you want update-initramfs that is the upper layer and the recommended command to generat an initramfs since at least etch. Thanks for the explanation. Would you recommend purging yaird completely then? I maintain yaird, and I do not recommend purging it. I depend on it for server installations that need a different degree of reliability than the default ramdisk generator, initramfs-tools, can provide. I am not the only user of yaird. Max obviously has a different opinion, as indicated by his filing http://bugs.debian.org/457177 blocking it from being released with Lenny. After all, I am wondering how the line ended up in kernel-img.conf at all. I never touched it myself (etckeeper helps my unreliable brain here), so it has to be generated by some package, but I could not find which one it is. Do you happen to know that? Should a bug against that package be filed? Again, it is not a bug to have that line. Debian-installer at some point favored yaird over initramfs-tools. Hope that helps, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknbUvEACgkQn7DbMsAkQLhVWACfWZB91ZwP3rHGbIZ41eD3QpuF sIoAnRHixJkNqyiTynSbwSMArdOUpdyZ =DV9B -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522909: closed by maximilian attems m...@stro.at (Re: Bug#522909: linux-image-2.6.29-1-amd64: Package cannot be configured due to invalid mkinitrd options)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 07, 2009 at 05:28:03PM +0200, Frank Blendinger wrote: Hi. On Tue 2009-04-07 12:15, Debian Bug Tracking System ow...@bugs.debian.org proclaimed: On Tue 2009-04-07 13:31, maximilian attems m...@stro.at proclaimed: On Tue, Apr 07, 2009 at 01:27:45PM +0200, Frank Blendinger wrote: ramdisk=mkinitrd.yaird mkinitramfs well that is wrong, easiest way is to just scratch that last line. Indeed. It works fine without that line. this line was added in a special debian installer beta for Etch. it was quickly repaired to not been added. the trouble is that /etc/kernel-img.conf is not owned by any package so we are not allowed to modify it. As aboves failure never slipped in a real realease it is a bit unfortunate for the users of that specific debian installer release. Ah, then it is clear where it came from - I installed the system in question with an RC of the Lenny installer. Hmm. I disagree that it was repaired. Instead it was at some point changed to favor initramfs-tools over yaird - while still supporting both. If, as Max wrote, debian-installer was changed shortly after some beta for Etch, it seems odd to me that you experience this issue in a RC for Lenny: Etch was released some years before Lenny. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknbduAACgkQn7DbMsAkQLhmeQCdEGuHnzmT8GqxmDfWgovO2uf0 IOAAniEeCEujRQ5/MQYqmrBdT22v5bPG =MyBx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522909: linux-image-2.6.29-1-amd64: Package cannot be configured due to invalid mkinitrd options)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear maximilian, On Tue, Apr 07, 2009 at 06:46:15PM +0200, maximilian attems wrote: won't comment any further on your personal opinons. [further comments on my opinions snipped] I have commented on your personal opinions presented as fact. Have a nice day. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknbrTAACgkQn7DbMsAkQLi2FACgnB8moZrIPhEe5K5XqesWN4C/ Yp0An1Cw1BCG7bnmf3TnvTM2va696mu4 =o6VV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520535: linux-image-2.6.28-1-686: Installer fails using mkinitrd.yaird
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Mar 20, 2009 at 06:19:42PM +, tom schorpp wrote: Package: linux-image-2.6.28-1-686 Version: 2.6.28-1 Severity: minor Setting up linux-image-2.6.28-1-686 (2.6.28-1) ... Running depmod. Running /usr/sbin/mkinitrd.yaird. mkinitrd.yaird: invalid option -- t Terminating... /usr/sbin/mkinitrd.yaird failed to create initrd image. Failed to create initrd image. dpkg: error processing linux-image-2.6.28-1-686 (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: linux-image-2.6.28-1-686 but doing manual mkinitrd.yaird and initramfs-tools 0.93 works. 1) linux 2.4 kernel packages optionally use initrd-tools 2) linux 2.6 kernel packages optionally use initrd-tools 3) initramfs-tools comes along, including an initrd-tools wrapper 4) yaird comes along, including an initrd-tools wrapper 5) initramfs-tools adds non-initrd-tools options to its wrapper 6) yaird mimics (or ignores, really) some of those options 7) linux 2.6 kernel packages drop support for initrd-tools 8) kernel team promises yaird support is not affected (hinting that I am insane to even ask) 9) Breakage reported as bug#518315 is rerouted to yaird by the kernel team, considering yaird broken to not fully mimic initramfs-tools. The kernel team has not responded to my latest questions targeted both bug#518315 and the kernel team mailinglist. Might be because I am silly to even ask. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknEKawACgkQn7DbMsAkQLg+/gCfYw1/mxxFuZjzngLD+58SU8fI 91sAnjOdO4KH3SPXS1cCrxYHod/FEYow =+gxX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519800: Acknowledgement (FSTYPE=ext3 but only ext2 in ramdisk possible with MODULES=dep)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Mar 15, 2009 at 11:35:55AM +0100, Martin Michlmayr wrote: Actually, how about running fstype when generating the ramdisk to find out which modules you need (either in addition or instead of looking at the output of mount/fstab). I dislike the idea of a ramdisk generator deliberately ignoring something I've explicitly expressed in /etc/fstab. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAknCHCsACgkQn7DbMsAkQLiMPACUCS87zevdyT0Y8iIPMNnc6LXB VwCfdzBU9RBPepw6wB7WZ90DpQQAWVo= =RA4P -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519800: Acknowledgement (FSTYPE=ext3 but only ext2 in ramdisk possible with MODULES=dep)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Mar 19, 2009 at 11:30:40AM +0100, Martin Michlmayr wrote: * Jonas Smedegaard d...@jones.dk [2009-03-19 11:19]: Actually, how about running fstype when generating the ramdisk to find out which modules you need (either in addition or instead of looking at the output of mount/fstab). I dislike the idea of a ramdisk generator deliberately ignoring something I've explicitly expressed in /etc/fstab. Well, then look at fstype in addition to the output of mount/fstab. The point is that the system won't boot if you only look at the output of mount/fstab. Fine with me. My comment was driven by your or instead of alone :-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknCJ7oACgkQn7DbMsAkQLiX+ACcCiDTvGNXVQ/Lspd6yojhMT7Z CbAAnRDDw7u51JhDH2b00hKWW3f8AC41 =L0v5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518802:
I can confirm this bug -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecation notice of mkinitramfs-kpkg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 16, 2009 at 03:06:05PM +0100, maximilian attems wrote: On Mon, Feb 16, 2009 at 02:45:51PM +0100, Jonas Smedegaard wrote: On Mon, Feb 16, 2009 at 01:16:55PM +0100, maximilian attems wrote: this command is a kludge. it was added for kernel-package as some guy wanted still to use initrd-tools. next initramfs-tools upload will emit a warning when it is used. i'll change linux-2.6 trunk to properly call update-initramfs. as it already does for xen images. Do I understand you correctly that you want to drop support not only for initrd-tools but generally for alternative ramdisk generators? no please reread. also latest yaird understands update-initramfs call syntax. No, that is incorrect. It is true that yaird silently ignore some of the newer initramfs-tools extensions to the mkinitrd interface, but not the -t option which is now expected by linux-2.6 (see bug#518315). mkinitrd provided a limited set of commands needed by kernels to automate generating ramdisks. This interface is what both initramfs-tools and yaird implemented and still used by kernel-package. I believe that option caused problems in the past for initramfs-tools to have that option enabled by default, leading to the change in 0.53 (or really 0.53c). Why do recent linux-2.6 need to introduce the use of the -t option? - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1IU0ACgkQn7DbMsAkQLgfBQCfYindlEK1kt+GjGkhm8qHyIym JKsAnAtw6QQsRYTBdRTQXi7f88h7ZWnD =vTXn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Yaird-devel] Bug#518315: deprecation notice of mkinitramfs-kpkg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Mar 09, 2009 at 03:26:50PM +0100, maximilian attems wrote: On Mon, Mar 09, 2009 at 03:01:49PM +0100, Jonas Smedegaard wrote: [snipp] It is true that yaird silently ignore some of the newer initramfs-tools extensions to the mkinitrd interface, but not the -t option which is now expected by linux-2.6 (see bug#518315). right so it is time to add it! Time? What has time to do with it? Please provide reason! ubuntu doesn't use -t as they have takeover set in initramfs-tools by default, thus probably it went unnoticed there. So why don't you drop that option instead, if it is always forced? mkinitrd provided a limited set of commands needed by kernels to automate generating ramdisks. This interface is what both initramfs-tools and yaird implemented and still used by kernel-package. I believe that option caused problems in the past for initramfs-tools to have that option enabled by default, leading to the change in 0.53 (or really 0.53c). Why do recent linux-2.6 need to introduce the use of the -t option? read man update-initramfs -t section. I did. It describes a feature of a generic tool, not about special needs of official Debian kernels. we want to be sure to really ship the latest modules, it has to be reentrant. Is that a different need for official kernels than other kernels? - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1OHAACgkQn7DbMsAkQLhCSACeNQjQ9LoAk8dTkD2uDYxRFmLB QzwAn32y9tmr5Jv6aIO1tage4OFAlsxU =4dT+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517260: Do Debian Policy 3.5 not apply to unstable?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please reopen this bug. Debian Policy 3.5 mandates correct package dependencies. Debian Policy also applies to Debian unstable too. The unstable refer to the collection of packages - each individual package released to unstable should itself be non-broken. Use experimental for possibly-broken packages. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmnBkIACgkQn7DbMsAkQLiw0gCggoc76YFGKk2tgiiHVGPwLmmv 5J0AnieeukQso1j1Rd0jDcShSoRhnSbo =Wb/J -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517260: Do Debian Policy 3.5 not apply to unstable?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 26, 2009 at 10:26:26PM +0100, Luk Claes wrote: Jonas Smedegaard wrote: Please reopen this bug. Debian Policy 3.5 mandates correct package dependencies. Debian Policy also applies to Debian unstable too. The unstable refer to the collection of packages - each individual package released to unstable should itself be non-broken. It's not broken, it's common to have some things that are out of sync in unstable... Thanks, Luk. I see the point now. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmnFvYACgkQn7DbMsAkQLivDwCbBZggY0wrsuPF9vKjlLDAn9BV LQAAoKext1Yd60oWsyNGXC5iQdViJwH7 =qMcn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517260: Do Debian Policy 3.5 not apply to unstable?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 26, 2009 at 10:39:17PM +0100, maximilian attems wrote: On Thu, Feb 26, 2009 at 10:14:42PM +0100, Jonas Smedegaard wrote: Please reopen this bug. Debian Policy 3.5 mandates correct package dependencies. Debian Policy also applies to Debian unstable too. The unstable refer to the collection of packages - each individual package released to unstable should itself be non-broken. Use experimental for possibly-broken packages. you don't get anything, please stop nagging around on d-kernel. You get everything: Naturally my interest is not the quality of Debian, but only to bother you the most I can. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmnF54ACgkQn7DbMsAkQLhLEgCeOuNkrdTucBQrj9ISo9Puhfy5 YQsAn0uoxwdfug79LTvWnkLSnUA8whHd =84fI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515826: your mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 19, 2009 at 06:31:27PM +0100, Bjørn Mork wrote: Steve Langasek vor...@debian.org writes: Comments/Problems: Trying to boot the Debian 5.0 netboot install image fails to detect CD and/or network card (DE422). It boots up to the install screen just fine, but without CD/network card support unable to install base system. (scsi controller- aha1742 (eisa), network card - de422 (eisa) Do you know what kernel drivers are supposed to be used for these devices? possibly aha1740 for the SCSI card, but I don't have a guess as to which driver should be used for the network card. depca. Don't think that's included in Debian kernels. Not sure, but I believe the tulip driver works too. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdp5YACgkQn7DbMsAkQLhl/gCfSKuhKcBkVLhlMMFSjYmwHds6 KiAAn2BoD+IdGhGg4aOZkWTRVnBkBqP2 =quJa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecation notice of mkinitramfs-kpkg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 16, 2009 at 01:16:55PM +0100, maximilian attems wrote: this command is a kludge. it was added for kernel-package as some guy wanted still to use initrd-tools. next initramfs-tools upload will emit a warning when it is used. i'll change linux-2.6 trunk to properly call update-initramfs. as it already does for xen images. Do I understand you correctly that you want to drop support not only for initrd-tools but generally for alternative ramdisk generators? - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmZbg8ACgkQn7DbMsAkQLia1ACghbVoeMyODTLTZFE8iwTq8h3v 13EAn17ilatkm7ohATpf2bI3U2yYwciD =zRc6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514292: linux-image-2.6.28-1-amd64: Bad page state in process 'emacs'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Feb 15, 2009 at 07:12:22PM +0100, Luca Capello wrote: Hi there! On Tue, 10 Feb 2009 17:26:41 +0100, maximilian attems wrote: how easily can you reproduce!? if easily please consider to tell bugzilla.kernel.org and let us know the bug number. It is not easy at all: it was the first time I experienced such an error and unfortunately I have not seen it again. I reported it because the machine was completely frozen. However, I am experiencing various issues with the latest 2.6.28 kernels, including a thermal error thought to have been solved [1]: either my X60 is dying or 2.6.28 has some problems. Shoulw I report every trace I get? FYI, I have s2disk/kmmc traces now :-( [1] http://thread.gmane.org/gmane.linux.acpi.devel/37230 also please upgrade to latest snapshot it features all stable releases up to 2.6.28.4 I usually upgrade my sid every morning, but I do not reboot every day, since I use a lot s2disk. I will try to keep an eye on my syslog and reboot as soon as I spot an error. Beware that if you upgrade the running kernel, then things like hibernation (which unloads and reloads drivers) won't work until next reboot. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmYZTsACgkQn7DbMsAkQLj3VgCfTq+/RMR+AjcXeptf+qoBr2Hj cDQAn3dVKgkwlOCBk9VJz/wHDOT3/rPn =DmQ0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [FIX]: ultra45 boot failing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Feb 07, 2009 at 02:51:05AM -0800, David Miller wrote: From: Jurij Smakov ju...@wooyd.org Date: Sat, 7 Feb 2009 10:45:31 + Thanks for pointing it out, David. Please contact me in the future if you guys want to add non-trivial sparc specific changes. That's how you can keep stuff like this from getting broken. You can't even install on these boxes because of this bug. It sounds very Ubuntu-esque that you can't get a fix like this into the tree due to timing issues. This is Debian for crying out loud :-) Didn't you hear? Debian is getting into the release on time business too these days :-P That said, the technical next step (if not done already) is to tag that bug as severe enough to be an RC bug. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmNdjIACgkQn7DbMsAkQLjVLwCcD197YrgdP2Lit8L2UNWwKe0p Fw0An3jaS8p8XWGc8fF0B8Ky2kFcGV6Q =ehV8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507676: initramfs-tools: does not wait for usb disks in
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 03, 2008 at 05:30:40PM +0100, Bernhard Kleine wrote: Am Wed, 03 Dec 2008 16:30:30 +0100 schrieb hugo vanwoerkom: Package: initramfs-tools Version: 0.92l Severity: normal Booting linux-image-2.6.26-1-686 initramfs does not wait for the 2 USB disks that are in /etc/fstab to show up, causing the boot to fail. I had a similar problem 2 days ago, one usb partition as /dev/sda1, boot stopped with an error, I do not remember but related to a missing device. Rebooting solved the problem. Using the alternative ramdisk-generator yaird also solves issues like this - but really: Both rebooting and yaird is merely _workarounds_, not real bugfixes. Regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkk2v1EACgkQn7DbMsAkQLiD7wCghLJT+g5mnf8UAq8NUXOEOqS9 r/gAnRdUrX2eSJ1Twf/v7qTo+n8RQgAL =EmNs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
