Bug#956226: linux: dh-thin-pool module missing in md-modules udeb, d-i unable to remove thinly provisioned logical volume
Source: linux Version: 4.19.67-2+deb10u2 Severity: normal Tags: d-i patch The dm-thin-pool module is required when you want to run d-i on a machine which contains thinly provisioned logical volumes. Otherwise d-i is unable to remove them and you see messages like this from partman-lvm: > modprobe: FATAL: Module dm-thin-pool not found in directory > /lib/modules/4.9.0-9-amd64 [...] > Can't process LV vg_system/lv_system: thin-pool target support missing from > kernel? Thus I attach a patch to add the missing module in md-modules. I have also included the dependencies (dm-persistent-data and dm-bio-prison), I'm not sure if it's required... Cheers, Raphaël. -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS >From 3b91afe0e9bc9626d81ae6695a7072e4bd792ef3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= Date: Wed, 8 Apr 2020 17:51:54 +0200 Subject: [PATCH] udeb: add dm-thin-pool in md-modules udeb That module is required when you want to run d-i on a machine which contains thinly provisioned logical volumes. Otherwise d-i is unable to remove them and you see messages like this from partman-lvm: modprobe: FATAL: Module dm-thin-pool not found in directory /lib/modules/4.9.0-9-amd64 Can't process LV vg_system/lv_system: thin-pool target support missing from kernel? --- debian/installer/modules/md-modules | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/installer/modules/md-modules b/debian/installer/modules/md-modules index d4f710406d46..d2da3b835d4f 100644 --- a/debian/installer/modules/md-modules +++ b/debian/installer/modules/md-modules @@ -6,9 +6,12 @@ raid0 raid1 raid456 raid10 +dm-bio-prison dm-mirror +dm-persistent-data dm-raid dm-snapshot +dm-thin-pool bcache # RAID-related libraries, also used by btrfs -- 2.26.0
Bug#948257: Bug#948350: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '[...]/lib/modules/[kernelversion]/modules.builtin.bin'
Hello, On Tue, 07 Jan 2020, Marco d'Itri wrote: > #948257 In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#105, Ben is wondering whether the fix should not be done in kmod since the ERROR displayed is due to a Debian-specific patch that you applied (debian/patches/verbose_missing_bin): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#95 Can you please take position and explain why you think this should be fixed in initramfs-tools when the message is not even displayed in upstream's kmod ? The message also seems to appear during a manual kernel build and install: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#110 Given all this, it seems cleaner to drop the patch debian/patches/verbose_missing_bin that you applied. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Bug#943953: linux: DKMS module builds are failing on arm64 due to lack of armhf cross-compiler
Control: tags -1 - moreinfo Hi, On Sat, 02 Nov 2019, Ben Hutchings wrote: > I already communicated this via IRC, but I thought it should be logged > in the BTS too: I have a tentative fix for this in < > https://salsa.debian.org/benh/linux.git> branch bug943953. I don't > have an arm64 system to test it on though. Steev tested it and replied to you on IRC: 03:09 bwh: buxy: tested on two different arm64 machines, seems to be working Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
Bug#919452: firmware-misc-nonfree: Please include the mediatek folder for mt7622u usb wifi devices
Control: tag -1 + patch On mer., 16 janv. 2019, Steev Klimaszewski wrote: > As of the 4.19 kernel, support is available for mediatek mt7622u based > wireless devices like the Alfa AWUS036ACM usb wireless device via the > mt76x2u driver in the mainline kernel, however the firmware-misc-nonfree > does not contain the mediatek folder from the upstream linux-firmware tree > which was added on 2018-07-30. I've tested these files locally to work with > the mentioned device on a debian 4.19 based kernel. FYI I have submitted a merge request for this: https://salsa.debian.org/kernel-team/firmware-nonfree/merge_requests/7 Cheers, -- Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer
Re: linux backport in jessie LTS
On Sun, 22 Apr 2018, Ben Hutchings wrote: > Therefore, would it make sense to add a Linux 4.9 backport to the > regular jessie and jessie-security suites? Yes, I think so. It's also interesting to keep a security-supported kernel once we are past the usual 5 years of LTS (aka Extended LTS). Since the bakcported kernel is still supported in the next release, it's possible to continue to maintain the backport while the original kernel version clearly went out of support. > (Maintaining kernel backports is generally quite easy once the suite > they are backported from is stable.) The only downside is that you can't have a linux-latest backport in the main suite while it was possible in the jessie-backports suite. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#886506: busybox sh broken on i386 with glibc 2.26, leads to kernel panic
Control: reassign -1 src:glibc 2.26-1 Control: retitle -1 busybox sh broken on i386 with glibc 2.26, leads to kernel panic Control: severity -1 serious Control: affects -1 + busybox src:linux Hello, on i386 with glibc 2.26-4, busybox sh is broken: $ busybox sh [...] BusyBox v1.27.2 (Debian 1:1.27.2-2) built-in shell (ash) Enter 'help' for a list of built-in commands. Segmentation fault In the kernel messages, you see this: [1097712.640730] traps: busybox[3288] general protection ip:f7e9a51d sp:ff8da68c error:0 in libc-2.26.so[f7d48000+1cd000] There's a work-around (the same as the one described in #887169): $ GLIBC_TUNABLES=glibc.tune.hwcaps=-SSE4_2 busybox sh [...] BusyBox v1.27.2 (Debian 1:1.27.2-2) built-in shell (ash) Enter 'help' for a list of built-in commands. ~ $ Given that busybox's sh is used in the initrd and that the init command is a shell script, this will lead to the kernel panic shown earlier in this bug report. Possible work-arounds in the mean time: - disable busybox in the initrd by setting BUSYBOX=n in /etc/initramfs-tools/initramfs.conf (but this is not possible if you use cryptsetup) - you can add the "GLIBC_TUNABLES=glibc.tune.hwcaps=-SSE4_2" to the kernel command line so that it's set in the environment of the init script (this will at least let you boot once to fix it permanently) - install busybox-static instead of busybox (since it was built with an earlier version of glibc) and rebuild your initrd. Aurélien Jaron commented on IRC that this was strange that busybox was affected by this bug since the analysis made in #887169 lead to believe that only binaries compiled with -mstack-align=4 would be affected. I see that busybox uses things like this: include/platform.h:# define ALIGN1 __attribute__((aligned(1))) include/platform.h:# define ALIGN2 __attribute__((aligned(2))) include/platform.h:# define ALIGN4 __attribute__((aligned(4))) Could those attributes have a similar effect than -mstack-align=4 ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Tue, 12 Sep 2017, Ben Hutchings wrote: > > This is strange because schroot does bind-mount /dev in the default > > profile that I used: > > Then I don't know what's going wrong in your chroot environment. Me neither. > > Assuming your analysis is right, what would be the right course of action? > > > > Calling "udevadm trigger " after the mkfs call? > > I think that's right... except now I wonder whether it's reasonable to > assume udevadm in a chroot can talk to udev on the outside. It looks > like they would have to share /run/udev/control. I would have expected something like this too... but that does not seem to be the case. At least it's not the reason why that call works here because /run is not shared: $ grep /run /etc/schroot/default/fstab # It may be desirable to have access to /run, especially if you wish #/run /runnonerw,bind 0 0 #/run/lock /run/lock nonerw,bind 0 0 #/run/shm /run/shmnonerw,bind 0 0 So maybe "udevadm trigger" is re-opening and re-closing the device in write mode and this leads the kernel to emit a new uevent and udev outside the chroot then reprocesses the device? > It seems like maybe vmdebootstrap shouldn't be used in a chroot. Or maybe update-grub should have a FORCE_USE_OF_UUID flag or something like that. vmdebootstrap does not really care about the by-uuid symlink, only grub insists on seeing it before accepting to use the UUID as "root" kernel parameter. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
Hi Ben, On Mon, 11 Sep 2017, Ben Hutchings wrote: > The answer seems to be that udev doesn't just listen for device events, > but also uses inotify to watch block devices. But inotify operates on > inodes, not the underlying devices. The chroot has a separate /dev > directory and inodes, so writing to a block device through one of those > inodes doesn't trigger the inotify watch. > > If I bind-mount /dev into the chroot before running mkfs there, udev > does see the change events because mkfs opens the inodes that it's > watching. This is strange because schroot does bind-mount /dev in the default profile that I used: $ grep profile /etc/schroot/chroot.d/sid-amd64 profile=default profile=default $ grep /dev /etc/schroot/default/fstab /dev/devnonerw,bind 0 0 /dev/pts/dev/ptsnonerw,bind 0 0 /dev/shm /dev/shmnonerw,bind 0 0 (and a stat call inside the chroot and outside of it returns the same inode number and the same device number) > So this is a limitation of udev and of the kernel's inotify interface, > but I don't think it's a bug in either of them. vmdebootstrap should > not assume that udev will notice changes made by mkfs unless they are > operating on the same /dev filesystem (and even then, it should use > 'udevadm settle' to avoid races). Assuming your analysis is right, what would be the right course of action? Calling "udevadm trigger " after the mkfs call? FWIW, this udevadm trigger call does work (as in the missing symlink gets created)... and it works when called outside of the chroot but also when called within the chroot. And thanks for the investigation you made! Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 07 Sep 2017, Ben Hutchings wrote:
> On Thu, 2017-09-07 at 12:53 +0200, Raphael Hertzog wrote:
> > On Thu, 07 Sep 2017, Raphael Hertzog wrote:
> > > What informs udev about the new filesystem?
> >
> > Somehow, it's the kernel apparently.
> >
> > > Or is this a bug in the kernel really?
> >
> > At least "udevadm monitor" shows that the kernel is sending
> > less uevents when I run the command in the chroot.
>
> Which command?
vmdebootstrap (for example as called by "make sid.raw" in that directory):
https://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/tree/vmdebootstrap-generic-qcow2
The command creates the disk image with commands similar to those shown in this
log:
2017-09-07 16:11:54 DEBUG runcmd: ['qemu-img', 'create', '-f', 'raw',
'/srv/autopkgtest-images/sid-amd64-new.img', '100'] None {}
2017-09-07 16:11:54 INFO Creating partitions
2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
'/srv/autopkgtest-images/sid-amd64-new.img', 'mklabel', 'msdos'] None {}
2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
'/srv/autopkgtest-images/sid-amd64-new.img', 'mkpart', 'primary', '0%', '100%']
None {}
2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
'/srv/autopkgtest-images/sid-amd64-new.img', 'set', '1', 'boot', 'on'] None {}
2017-09-07 16:11:54 DEBUG runcmd: ['kpartx', '-avs',
'/srv/autopkgtest-images/sid-amd64-new.img'] None {}
2017-09-07 16:11:54 INFO Creating filesystem ext4
2017-09-07 16:11:54 DEBUG runcmd: ['mkfs', '-t', 'ext4',
u'/dev/mapper/loop0p1'] None {}
2017-09-07 16:11:55 DEBUG mkdir /tmp/tmpSEWpRs
2017-09-07 16:11:55 INFO Mounting /dev/mapper/loop0p1 on /tmp/tmpSEWpRs
2017-09-07 16:11:55 DEBUG runcmd: ['mount', u'/dev/mapper/loop0p1',
'/tmp/tmpSEWpRs'] None {}
Then goes on with debootstrap but at this point already you are past the point
where the kernel should have emitted the uevent that triggers the by-uuid
symlink
creation.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 07 Sep 2017, Raphael Hertzog wrote: > Is there anything that can be done by vmdebootstrap to force-trigger the > creation of that entry even when chrooted? Yes, "udevadm trigger" or "udevadm trigger /dev/mapper/loop0p1" works well for that. So we have a work-around at least (thanks to Felipe Sateler for the suggestion, thanks also to Mantas Mikulėnas who taught me about the kernel/udev interactions). But I'm clearly not able to go further than that, debugging the kernel would be too time-consuming for me since I'm not a kernel developer... so I'll stop my investigations here. (Somehow I wonder whether this is not the result of some kernel hardening... limiting the impact of things done within a chroot compared to the main host. schroot also uses private bind mounts, can this be related?) Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 07 Sep 2017, Raphael Hertzog wrote: > What informs udev about the new filesystem? Somehow, it's the kernel apparently. > Or is this a bug in the kernel really? At least "udevadm monitor" shows that the kernel is sending less uevents when I run the command in the chroot. I attach two logs of "udevadm monitor -k -u -p", once for the run in the host, and one for the run in schroot. And I also attach a diff of edited logs where I dropped the timestamps. We can clearly see the lack of a "KERNEL[] change /devices/virtual/block/dm-4 (block)" with its associated UDEV rule adding the by-uuid links. So this is with 4.12.6-1 (unstable). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ KERNEL[1303173.467860] change /devices/virtual/block/loop0 (block) ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk MAJOR=7 MINOR=0 SEQNUM=4256 SUBSYSTEM=block KERNEL[1303173.492386] add /devices/virtual/bdi/254:4 (bdi) ACTION=add DEVPATH=/devices/virtual/bdi/254:4 SEQNUM=4257 SUBSYSTEM=bdi KERNEL[1303173.492809] add /devices/virtual/block/dm-4 (block) ACTION=add DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk MAJOR=254 MINOR=4 SEQNUM=4258 SUBSYSTEM=block UDEV [1303173.493320] add /devices/virtual/bdi/254:4 (bdi) ACTION=add DEVPATH=/devices/virtual/bdi/254:4 SEQNUM=4257 SUBSYSTEM=bdi USEC_INITIALIZED=1303173493269 UDEV [1303173.495279] change /devices/virtual/block/loop0 (block) .ID_FS_TYPE_NEW= ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk ID_FS_TYPE= ID_PART_TABLE_TYPE=dos ID_PART_TABLE_UUID=91b643c6 MAJOR=7 MINOR=0 SEQNUM=4256 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=13952290172 KERNEL[1303173.495444] change /devices/virtual/block/dm-4 (block) ACTION=change DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_COOKIE=4194304 MAJOR=254 MINOR=4 SEQNUM=4259 SUBSYSTEM=block UDEV [1303173.510693] add /devices/virtual/block/dm-4 (block) ACTION=add DEVLINKS=/dev/disk/by-id/raid-loop0p1 DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_NAME=loop0p1 DM_PART=1 DM_STATE=ACTIVE DM_TABLE_STATE=LIVE DM_TYPE=raid DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 DM_UUID=part1-loop0 MAJOR=254 MINOR=4 SEQNUM=4258 SUBSYSTEM=block SYSTEMD_READY=0 TAGS=:systemd: USEC_INITIALIZED=1303173510442 UDEV [1303173.527433] change /devices/virtual/block/dm-4 (block) .ID_FS_TYPE_NEW= ACTION=change DEVLINKS=/dev/disk/by-partuuid/91b643c6-01 /dev/mapper/loop0p1 /dev/disk/by-id/raid-loop0p1 /dev/disk/by-id/dm-uuid-part1-loop0 /dev/disk/by-id/dm-name-loop0p1 DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_ACTIVATION=1 DM_COOKIE=4194304 DM_NAME=loop0p1 DM_PART=1 DM_STATE=ACTIVE DM_SUSPENDED=0 DM_TABLE_STATE=LIVE DM_TYPE=raid DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES=1 DM_UUID=part1-loop0 ID_FS_TYPE= ID_PART_ENTRY_DISK=7:0 ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=2048 ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_SIZE=19527680 ID_PART_ENTRY_TYPE=0x83 ID_PART_ENTRY_UUID=91b643c6-01 MAJOR=254 MINOR=4 SEQNUM=4259 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=1303173510442 --- debootstrap --- KERNEL[1303301.063685] change /devices/virtual/block/loop0 (block) ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk MAJOR=7 MINOR=0 SEQNUM=4260 SUBSYSTEM=block UDEV [1303301.069592] change /devices/virtual/block/loop0 (block) .ID_FS_TYPE_NEW= ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk ID_FS_TYPE= ID_PART_TABLE_TYPE=dos ID_PART_TABLE_UUID=91b643c6 MAJOR=7 MINOR=0 SEQNUM=4260 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=13952290172 KERNEL[1303303.480902] remove /devices/virtual/block/dm-4 (block) ACTION=remove DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_COOKIE=6291456 MAJOR=254 MINOR=4 SEQNUM=4261 SUBSYSTEM=block UDEV [1303303.497202] remove /devices/virtual/block/dm-4 (block) .ID_FS_TYPE_NEW= ACTION=remove DEVLINKS=/dev/mapper/loop0p1 /dev/disk/by-partuuid/91b643c6-01 /dev/disk/by-id/raid-loop0p1 /dev/disk/by-id/dm-uuid-part1-loop0 /dev/disk/by-id/dm-name-loop0p1 DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_ACTIVATION=1 DM_COOKIE=6291456 DM_NAME=loop0p1 DM_PART=1 DM_STATE=ACTIVE DM_SUSPENDED=0 DM_TABLE_STATE=LIVE DM_TYPE=raid DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES=1 DM_UUID=part1-loop0 ID_FS_TYPE= ID_PART_ENTRY_DISK=7:0 ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=2048 ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_SIZE=19527680 ID_PART_ENTRY_TYPE=0x83 ID_PART_ENTRY_UUID=91b643c6-01 MAJOR=254 MINOR=4 SEQNUM=4261 SUBSYSTEM=b
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
[ Ccing grub, udev, linux maintainers for the questions at the end, I want to understand why some /dev/disk/by-uuid/ entries are not properly created ] Hello, On Wed, 23 Aug 2017, Raphaël Hertzog wrote: > Hello, I'm trying to update my qemu image used for autopkgtest, so I > followed the instructions from man autopkgtest-virt-qemu to create the > image but the resulting image does not boot and thus does not work > for autopkgtest either. > > I believe that the root cause is this error shown in the vmdebootstrap > output: > > /usr/sbin/grub-probe: error: cannot find a device for / (is /dev > mounted?). > WARNING: update-grub failed! > > Maybe the behaviour of update-grub changed recently... vmdebootstrap So this is not the root cause. This is just a problem in the customize script which should mount /dev and /proc just like vmdebootstrap already does when it calls update-grub. Or it should probably get rid of it entirely as vmdebootstrap mostly overwrites the grub configuration anyway. > When I inspect /boot/grub/grub.cfg it does indeed contain > root=/dev/mapper/loop0p1 which we don't want. After a discussion on #debian-cloud, I narrowed the problem a bit more closely. In fact vmdebootstrap works properly when I run it unchrooted on my system, but when I run it in "schroot" (with a default profile which shares with the host the mount for /dev, /proc, /sys and more) then I get this problem. So it looks like that update-grub is behaving differently in each situation. I have added "set -x" to the grub-mkconfig and it looks like grub is perfectly able to find out the UUID associated to device: $ virt-cat -a sid.raw /tmp/update-grub-log |grep -i uuid + /usr/sbin/grub-probe --device /dev/mapper/loop0p1 --target=fs_uuid + GRUB_DEVICE_UUID=600ae34d-dceb-4250-a832-f07fa0c932db + /usr/sbin/grub-probe --device /dev/mapper/loop0p1 --target=fs_uuid + GRUB_DEVICE_BOOT_UUID=600ae34d-dceb-4250-a832-f07fa0c932db [...] Then I added "set -x" to /etc/grub.d/10_linux to find out why this script decided to not use the UUID even though it was available in the environment. It boils down to /dev/disk/by-uuid/600ae34d-dceb-4250-a832-f07fa0c932db does not exist. The loop partition device is /dev/dm-4 and at the time when the customize script runs, I have this output (it exists in by-partuuid, but not in by-uuid): $ ls -al /dev/disk/by-uuid/ total 0 drwxr-xr-x 2 root root 140 sept. 5 15:42 . drwxr-xr-x 7 root root 140 août 23 08:34 .. lrwxrwxrwx 1 root root 10 sept. 1 08:54 51d0-3c3e-49f5-adf6-6d53e7c0a8d6 -> ../../dm-0 lrwxrwxrwx 1 root root 10 sept. 1 08:54 5b668fa1-c4c5-44f7-bbec-ed5edfc33c0d -> ../../dm-3 lrwxrwxrwx 1 root root 10 sept. 1 08:54 92a990ff-52c2-4766-b865-a78cceb7e293 -> ../../dm-2 lrwxrwxrwx 1 root root 10 sept. 1 08:54 b3816590-a760-4815-9f43-0c2f4a362abc -> ../../sda2 lrwxrwxrwx 1 root root 10 sept. 1 08:54 BF87-23E5 -> ../../sda1 $ ls -al /dev/disk/by-partuuid/ total 0 drwxr-xr-x 2 root root 200 sept. 7 09:04 . drwxr-xr-x 7 root root 140 août 23 08:34 .. lrwxrwxrwx 1 root root 10 sept. 1 08:54 01f46df3-eb66-47b9-b0ea-a667e4a02020 -> ../../sda5 lrwxrwxrwx 1 root root 10 sept. 1 08:54 1dd56def-bfb8-423e-8ea5-d03ca1f2ff75 -> ../../sda6 lrwxrwxrwx 1 root root 10 sept. 7 09:04 3dfece35-01 -> ../../dm-4 lrwxrwxrwx 1 root root 10 sept. 1 08:54 426ccd8e-0ccd-4864-9152-31fc831ae98a -> ../../sda4 lrwxrwxrwx 1 root root 10 sept. 1 08:54 525345f4-e509-4283-8489-a6c1e7625975 -> ../../sda3 lrwxrwxrwx 1 root root 10 sept. 1 08:54 6ce3844f-39e8-4a7f-8e37-05b6bb9efe2f -> ../../sda1 lrwxrwxrwx 1 root root 10 sept. 1 08:54 caff8cf5-b264-498e-b6be-e6160fcf2085 -> ../../sda7 lrwxrwxrwx 1 root root 10 sept. 1 08:54 d67d853a-592f-4e21-9ed7-5992359aaa7d -> ../../sda2 $ ls -al /dev/mapper/loop0p1 brw-rw 1 root disk 254, 4 sept. 7 09:04 /dev/mapper/loop0p1 And when I run it outside from my schroot, then I have the entry in /dev/disk/by-uuid/. What is responsible of creating that entry? I guess it's udev. udev is not running in the chroot, obviously. But the underlying device (and the mount point) is seen by the host so I wonder why it's not created. What informs udev about the new filesystem? Is there anything that can be done by vmdebootstrap to force-trigger the creation of that entry even when chrooted? Should update-grub not try to be too smart and just trust the value obtained by grub-probe instead even if /dev/disk/by-uuid/$foo does not exist? Or is this a bug in the kernel really? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link
Control: reopen -1 Control: notfixed -1 4.10.0-1~exp1 Control: found -1 4.12.6-1 On Fri, 25 Aug 2017, Raphael Hertzog wrote: > I verified today that the issue is gone with Linux 4.12 and apparently > the appropriate patches have been merged for Linux 4.10 already (merged by > linus in commit ff0f962ca3c38239b299a70e7eea27abfbb979c3). I don't know how I did my check last time, but I was wrong. The changes merged above fixed issues about tools being confused with the unexpected st_dev values on files but they did not fix the fact that overlayfs might return EXDEV when renaming a directory that is part of the lower layer. So I'm opening the bug again. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing
Hi, On Tue, 12 Jul 2016, Raphael Hertzog wrote: > It looks like -17 reached linux-firmware.git a few hours ago. Maybe > it's time to update firmware-nonfree? We updated firmware-nonfree for Kali with the most important firmware files, you can find our work here: http://git.kali.org/gitweb/?p=packages/firmware-nonfree.git;a=summary We left some new firmware files that we did not know where to put. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing
Hi, On Wed, 20 Apr 2016, Ben Hutchings wrote: > > The -16 which is currently in the package is marked as "end-of-life". > > Might be the time to upgrade the firmware-iwlwifi package? > > Our upstream is linux-firmware.git, not a hundred vendor web sites. > Frankly I'm quite sick of the iwlwifi maintainers thinking their > firmware is special and should be distributed differently from every. It looks like -17 reached linux-firmware.git a few hours ago. Maybe it's time to update firmware-nonfree? https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f2cf4d67e8eced29c8a473d3a27057aa2df57c42 Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#815125: Boot failure with Debian linux 4.4.2 package
Hello Matt and Borislav, in Debian we got a report (see below and https://bugs.debian.org/815125) that https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit?id=67a9108ed4313b85a9c53406d80dc1ae3f8c3e36 was breaking early boot on some machines. Can you have a look at those failures? Cheers, On Tue, 23 Feb 2016, Alexis Murzeau wrote: > Hi, > > I have the same traceback as Zdravko in Message #121 (NULL pointer > dereference at RIP=0x81063682, __change_page_attr_set_clr+0x242). > > If I add "efi=old_map" parameter to kernel cmdline, the kernel boots > fine. > > Also, this might help Norbert to have a traceback printed: using > "quiet earlyprintk=efi,keep" kernel cmdline options will print only > the traceback (so it should be faster to get the kernel to the crash > traceback, if the cause is really a crash). > > > After compiling several kernels, I narrowed down the crash to the > patch "x86-efi-build-our-own-page-table-structures.patch". > > Without this patch, the kernel boots fine (dmesg output in attachment > dmesg_linux-4.4.2_[...].txt) > > With this patch, I get the crash in efi_call (photo of > "earlyprintk=efi,keep" output in attachment > traceback_linux-4.4.2_with_patch_[...].jpg). > > I also added 4 printk to add information before the crash when > calling efi_call_phys with efi_phys.set_virtual_address_map (see also > "additionnal_printk.diff" in attachment). (Not sure if it can help) > > When I added these printk, the traceback stop at efi_call > (__change_page_attr_set_clr isn't anymore in the traceback) but RIP > is still the same as without these changes. > > See also the traceback I get in attachment > traceback_linux-4.4.2-3_unmodified.jpg with the current 4.4 kernel > (version 4.4.2-3 unmodified) > > Also, let me know if a new bug should be opened for this. > > Thanks, > Alexis Murzeau > [0.00] microcode: CPU0 microcode updated early to revision 0x1c, date > = 2015-02-26 > [0.00] Initializing cgroup subsys cpuset > [0.00] Initializing cgroup subsys cpu > [0.00] Initializing cgroup subsys cpuacct > [0.00] Linux version 4.4.2-amubtdx-custom (root@Debian2) (gcc version > 5.3.1 20160220 (Debian 5.3.1-9) ) #4 SMP Tue Feb 23 18:02:39 CET 2016 > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.2-amubtdx-custom > root=UUID=be5f2ba3-ec9a-4645-8db5-eb9a6ddfd226 ro quiet crashkernel=128M@32M > [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 > [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point > registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' > [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 > bytes, using 'standard' format. > [0.00] x86/fpu: Using 'eager' FPU context switches. > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x00087fff] usable > [0.00] BIOS-e820: [mem 0x00088000-0x000b] reserved > [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable > [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved > [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable > [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved > [0.00] BIOS-e820: [mem 0x40005000-0xa4da] usable > [0.00] BIOS-e820: [mem 0xa4db-0xa61a] reserved > [0.00] BIOS-e820: [mem 0xa61b-0xaa7befff] usable > [0.00] BIOS-e820: [mem 0xaa7bf000-0xaa8adfff] type 20 > [0.00] BIOS-e820: [mem 0xaa8ae000-0xaa8aefff] reserved > [0.00] BIOS-e820: [mem 0xaa8af000-0xaa8bcfff] type 20 > [0.00] BIOS-e820: [mem 0xaa8bd000-0xaa8bdfff] reserved > [0.00] BIOS-e820: [mem 0xaa8be000-0xaa8c4fff] type 20 > [0.00] BIOS-e820: [mem 0xaa8c5000-0xaa8c5fff] reserved > [0.00] BIOS-e820: [mem 0xaa8c6000-0xaa8d5fff] type 20 > [0.00] BIOS-e820: [mem 0xaa8d6000-0xaa8d6fff] reserved > [0.00] BIOS-e820: [mem 0xaa8d7000-0xaa8f4fff] type 20 > [0.00] BIOS-e820: [mem 0xaa8f5000-0xaa937fff] reserved > [0.00] BIOS-e820: [mem 0xaa938000-0xaa9befff] type 20 > [0.00] BIOS-e820: [mem 0xaa9bf000-0xaaebefff] reserved > [0.00] BIOS-e820: [mem 0xaaebf000-0xaafbefff] ACPI NVS > [0.00] BIOS-e820: [mem 0xaafbf000-0xaaffefff] ACPI > data > [0.00] BIOS-e820: [mem 0xaafff000-0xaaff] usable > [0.00] BIOS-e820: [mem 0xab00-0xaf9f] reserved > [0.00]
Re: broken mount behaviour on jessie
Hi, On Mon, 01 Feb 2016, Brian May wrote: > I see two patches here - one patch applies easy enough to schroot - > 1.6-schroot-mount-make-bind-mounts-private.patch > > I am not sure what the > master-libexec-mount-make-bind-mounts-private.patch is for, it seems to > patch files not in schroot but has references to schroot files. > > Do I need the 2nd patch or is the 1st one sufficient? Both patches are the same but for two different schroot branches (1.7.x is in experimental, 1.6.x in unstable). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#796096: Suggested patch to fix support of some logitech wireless keyboards
Control: tag -1 + patch svn.debian.org is currently down so I cannot build a patch with latest changelog and/or commit it directly but this bug should likely be fixed with the attached change. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ diff --git a/debian/installer/modules/input-modules b/debian/installer/modules/input-modules index 8a906fd..e44c6dc 100644 --- a/debian/installer/modules/input-modules +++ b/debian/installer/modules/input-modules @@ -15,6 +15,7 @@ hid-kye ? hid-lenovo-tpkbd ? hid-logitech ? hid-logitech-dj +hid-logitech-hidpp hid-microsoft ? hid-monterey ? hid-multitouch ?
Bug#522415: firmware-nonfree: please create a mother package for all firmware
On Sat, 04 Apr 2009, Ben Hutchings wrote: > All firmware that comes from the upstream firmware/ directory will be > included in the firmware-linux package, not a driver/vendor-specific > package. This accounts for an increasing majority of the firmware. This prediction doesn't seem to have come true. Can we please have a top-level meta-package that depends on all the firmware packages that do not require any click-through agreement? Osamu sent a patch last year, it needs to be updated on the light of the recently added binary packages but it's relatively straightforward. Thank you! -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#724970: firmware-atheros: firmware for ath10k devices missing
Control: severity -1 important On Mon, 30 Sep 2013, Daniel Jared Dominguez wrote: While it is not in the upstream linux-firmware git repository on kernel.org, the Debian firmware-atheros package is missing firmware for ath10k devices. http://wireless.kernel.org/en/users/Drivers/ath10k points one to https://github.com/kvalo/ath10k. Grabbing that firmware enables an ath10k device to properly work. So there has been progress on the inclusion of this firmware into the upstream linux-firmware git repository. QCA988X hw2.0 firmware is already there: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA988X/hw2.0 The other firmwares have not yet been included. I pinged Kalle Valo about this. Dear kernel maintainers, can we have an update with this firmware included? TIA. I'm raising the severity to important as the main blocker (inclusion in linux-firmware.git) is gone and this firmware is required for some relatively widespread devices. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- 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/20150722095935.ga11...@home.ouaza.com
Re: Bug#751339: RFP: ath9k-htc-firmware -- free firmware for Atheros AR7010/AR9271 wireless adapters
On Fri, 23 Jan 2015, Daniel Kahn Gillmor wrote: Could they thus not be included as-is in firmware-free or at least firmware-non-free ? (ccing kernel team for this question) shipping in firmware-non-free would be a shortcut to ensure that we have them available for users (which would be good), but it would feel a Looking more closely, https://github.com/qca/open-ath9k-htc-firmware generates two firmwares: htc_7010.fw and htc_9271.fw Both of which are already available in firmware-atheros (albeit under a non-free license though, it dates back to before the license change apparently). So what we actually want is to move them to firmware-free... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- 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/20150123165155.gc16...@home.ouaza.com
Re: Bug#751339: RFP: ath9k-htc-firmware -- free firmware for Atheros AR7010/AR9271 wireless adapters
Hi, On Wed, 11 Jun 2014, Daniel Kahn Gillmor wrote: ath9k-ftc-firmware provides a free implementation of firmware for two available wireless chipsets. [...] It would be great to ship these firmware modules in debian now that we have the source. If we can make it easier for people to improve them, that would be great. Unfortunately, the build process appears to be a little bit involved: https://trisquel.info/en/forum/how-install-ath9k-htc-firmware-atheros-communications-inc-ar9271 [...] While this looks like complicated to package independently, the firmwares are available in http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ Could they thus not be included as-is in firmware-free or at least firmware-non-free ? (ccing kernel team for this question) It would be a first step and a big service for users who opted to buy such freedom-respecting devices. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- 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/20150123124614.ga22...@home.ouaza.com
Re: Bug#751339: RFP: ath9k-htc-firmware -- free firmware for Atheros AR7010/AR9271 wireless adapters
On Fri, 23 Jan 2015, Daniel Kahn Gillmor wrote: I don't know what the rules are for inclusion in firmware-free. [...] and while a56 is in the debian archive, it's not a build-dep of firmware-free (bootstrap.bin is shipped directly in the source package). So maybe ath9k-htc-firmware is no worse than this? I came to the same conclusion and I see that it has also been requested in #711470. I'll work on a patch for that one. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- 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/20150123160552.ga28...@home.ouaza.com
Reassign to proper source package
reassign 735462 src:firmware-nonfree 0.40 thanks I just filed #735462 to ask for the removal of the reference to the obsolete linux-image package but I typoed the source package name. Reassigning now. -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140115154959.ga2...@x230-buxy.home.ouaza.com
Bug#717269: Please set CONFIG_NET_CALXEDA_XGMAC in -armmp kernel flavor
Package: src:linux Version: 3.10.1-1 Severity: wishlist I have made some tests of the Calxeda Highbank with the -armmp kernel flavor, it seems to work except for the network because CONFIG_NET_CALXEDA_XGMAC is not set. Please enable that Kconfig setting. Thank you. -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130718164102.ga5...@x230-buxy.home.ouaza.com
Re: Donation of a Calxeda Highbank node
Hello David, On Thu, 27 Jun 2013, Lennart Sorensen wrote: Would http://packages.debian.org/jessie/linux-image-3.9-1-vexpress by any chance be a valid kernel image for the highbank? I see in the git logs of Linus's tree that there is a v7 multiplatform config that is supposed to cover the highbank, socfpga, mvebu, and vexpress in one kernel, so having a vexpress kernel in jessie could be a promising sign for the next major release. Hector Oron sent us a kernel to test on the Hihgbank node we made available to Debian, but lack of knowledge on everything IPMI related means that we didn't dare to try it out yet: http://www.rtp-net.org/misc/linux-image-3.9-1-armmp_3.9-1~experimental.1_armhf.deb If you could try it out and give some feedback, it would be appreciated I'm sure. Cheers, -- Raphaël Hertzog ◈ Debian Developer Liberate the French translation of the Debian Administrator's Handbook: → http://www.ulule.com/liberation-cahier-admin-debian/ -- 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/20130627213430.ge12...@x230-buxy.home.ouaza.com
Re: Donation of a Calxeda Highbank node
On Fri, 26 Apr 2013, Hector Oron wrote: * DSA hat: The machine shall not be a debian.org machine, so DSA could export accounts if requested. * Buildd hat: The machine shall not be used to run buildd software to build official packages. Did you get those answers from the relevant teams? Was there a rationale for those answers? Now, Raphael, apparently you got a contact already with the donator and a root account on the server machine. Would you be willing to admin or handout root access to few ARM porters, so DD accounts could either be exported or create local accounts for people willing to play with the machine? I can give root rights to porters who want to administrate the machine, yes. I'd rather not have to take care of routine maintenance but I can stay as a backup in case of need. To be a useful porter machine, it would be nice if all DD can have access to it. But if it's not administrated by DSA, I don't know if the newly announced self-served chroot service can be setup on this machine. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130426140403.ga4...@x230-buxy.home.ouaza.com
Donation of a Calxeda Highbank node
Hello, OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is willing to dedicate one of the nodes to Debian. I believe it would make a relatively fast ARM autobuilder or porter box. The specs of the hardware (4GB RAM, 500 GB SATA drives, 4 Cortex A9 cores at 1.1 to 1.4 GHz) are better than most (all?) of Debian's ARM boxes. However this host runs on Ubuntu by default (12.10 currently). AFAIK Debian's kernel doesn't support such machines yet, Ubuntu has a special ARM flavor called highbank [2]. So I'm not sure how we could handle this donation right now (putting debian-admin@ in the loop to see what requirements they have at this level, and debian-kernel@ to see whether such a flavor would be doable for Debian too). I am however running Debian armel/armhf chroots on such a machine without any problem. So it seems that the kernel is the only problematic part. I do have root access to the system and I can pass it to DSA or any porter who would need access to the host. The thing supports IPMI and various management tools but they are not currently setup and I'm not familiar with them. If needed, with guidance, and if it supports proper per-node delegation, we could imagine giving access to DSA to this management tool. If you have questions, feel free to ask. I'll do my best to answer. Some more infos: # cat /proc/cpuinfo Processor : ARMv7 Processor rev 0 (v7l) processor : 0 BogoMIPS: 2190.54 processor : 1 BogoMIPS: 2190.54 processor : 2 BogoMIPS: 2190.54 processor : 3 BogoMIPS: 2190.54 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc09 CPU revision: 0 Hardware: Highbank Revision: Serial : # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 455G 2.1G 430G 1% / udev2.0G 4.0K 2.0G 1% /dev tmpfs 809M 176K 808M 1% /run none5.0M 0 5.0M 0% /run/lock none2.0G 0 2.0G 0% /run/shm none100M 0 100M 0% /run/user /dev/sda189M 53M 32M 63% /boot # free -m total used free sharedbuffers cached Mem: 4040 1695 2344 0266 1245 -/+ buffers/cache:183 3856 Swap: 3944 0 3944 # uname -a Linux arm08 3.5.0-22-highbank #33-Ubuntu SMP Thu Jan 3 01:05:04 UTC 2013 armv7l armv7l armv7l GNU/Linux # cat /etc/os-release NAME=Ubuntu VERSION=12.10, Quantal Quetzal ID=ubuntu ID_LIKE=debian PRETTY_NAME=Ubuntu quantal (12.10) VERSION_ID=12.10 Cheers, [1] More precisely a SystemFabriCore: http://www.systemfabricworks.com/products/systemfabricore [2] http://ncommander.blogspot.fr/2012/06/announcement-of-calxeda-highbank-images.html https://wiki.ubuntu.com/ARM/Server/Install -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130412151619.ga21...@x230-buxy.home.ouaza.com
Bug#689336: initramfs-tools 0.108 cannot decrypt dm_crypt filesystems
Control: severity -1 normal Control: retitle -1 provide instructions when keymap support is requested but when loadkeys or setupcon is missing Dropping the severity since most people will have console-setup installed. On Fri, 05 Oct 2012, Samuel Hym wrote: I was indeed missing the console-setup package, and with it works as expected. I believe that the update-initramfs keymap hook should display a warning about missing packages when KEYMAP=y and when some of the required executables are missing. But that's all that is needed to fix this bug. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20121005115202.gb20...@x230-buxy.home.ouaza.com
Bug#689336: initramfs-tools 0.108 cannot decrypt dm_crypt filesystems
Hi, On Tue, 02 Oct 2012, Samuel Hym wrote: With 0.107, I have a line: Adding binary /bin/loadkeys not with 0.108. I bet that you're missing the console-setup package because you're not installing Recommends by default (kbd which provides loadkeys recommends console-setup which provides setupcon, initramfs-tools version 0.108 requires both loadkeys and setupcon). If that's the case, can you install console-setup and see whether it works again? I don't really know what's the proper solution though. Should initramfs-tools add a Recommends of its own on console-setup, kbd? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20121004143835.ga12...@x230-buxy.home.ouaza.com
Re: Bug#652026: amavisd-new: Init-script not working (stop/restart)
Hi, On Thu, 15 Dec 2011, Henrique de Moraes Holschuh wrote: 503 pcew80@reincke:~ ps -aef | grep amavis amavis2299 1 0 00:47 ?00:00:01 amavisd (master) amavis2496 2299 0 00:47 ?00:00:00 amavisd (ch7-avail) amavis2497 2299 0 00:47 ?00:00:00 amavisd (ch7-avail) amavis2498 2299 0 00:47 ?00:00:00 amavisd (ch6-avail) reincke 7749 7078 0 08:32 pts/100:00:00 grep amavis 504 pcew80@reincke:~ cat /proc/2299/stat 2299 (amavisd (master) S 1 2299 2299 0 -1 4202560 9771 0 4 0 119 5 0 0 20 0 1 0 22660083 221208576 22204 18446744073709551615 1 1 0 0 0 0 0 4224 81927 18446744073709551615 0 0 17 2 0 0 7 0 0 Crap. The kernel has done us in. Reassigning to dpkg to get some input on what should be done. Raising severity because it will cause some services to not be stopped or restarted properly, which has security implications. Guys, 3.1 changes /proc/pid/stat, and breaks anything using start-stop-daemon --name that also messes with the name of the process. Due to the chage in /proc/pid/stat, the executable name is not matched anymore. What are those changes exactly? Because the kernel doesn't seem to always respect the name that the process sets for itself. I run 3.1.0-1-amd64 here and I have this: ┏rivendell:~/deb/core/dpkg (test-build) ┗(706)$ ps axf|grep 1758 1758 ?S 0:00 \_ avahi-daemon: chroot helper 4660 pts/8S+ 0:00 | \_ grep 1758 ┏rivendell:~/deb/core/dpkg (test-build) ┗(707)$ sudo cat /proc/1758/stat 1758 (avahi-daemon) S 1756 1754 1754 0 -1 4202560 83 0 1 0 0 0 0 0 20 0 1 0 2639 3158016 21 18446744073709551615 134512640 134630244 4292694960 4292694424 4151297072 0 0 0 0 0 0 0 17 1 0 0 0 0 0 This probably affects only processes that change their visible identity (or whatever the string output by ps -aef is called) like amavisd-new does. Unfortunately, using --exec is not enough when you're dealing with perl, python or other scripts. How should we proceed? Drop use of start-stop-daemon --name in amavisd-new and document this kernel ABI issue in start-stop-daemon(8)? Reassign to the kernel on the grounds that it broke the userspace ABI? Enhance start-stop-daemon to take a --namere (regexp) and use that in amavisd-new instead? I would first like to understand the problem because you said probably multiple times and I prefer to decide in full knowledge. Can anyone from the kernel team say us if there have been relevant changes here? Henrique, what lead you to conclude that there was a kernel change? I tried to look at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=fs/proc/array.c;hb=refs/heads/master but did not find any relevant change. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- 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/20111216101520.ga4...@rivendell.home.ouaza.com
Re: Increasing minimum 'i386' processor
On Sat, 19 Nov 2011, Ben Hutchings wrote: Also possibly: 6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all 586-class features except an FPU, and we could probably keep FPU emulation for them. FWIW, I do run Debian on such systems albeit with a custom kernel. Given those CPU tend to be used in an embedded context I guess it's ok if the official kernel does not support them. But it would be nice if Debian's userspace could be kept compatible. Not sure what this requires though... Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- 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/2020074047.gi3...@rivendell.home.ouaza.com
The trigger in your Debian packages
Hello, you're maintaining a Debian package which provides a trigger file. Currently a package that activates a trigger is put in the triggers-awaited status where it doesn't fulfill dependencies. The trigger must first be processed and only then is the package considered as installed. I believe that the vast majority of triggers do not provide a functionality that is so important as to require that the triggering package be put in that status. Thus I'm considering to change this and to introduce new trigger directives that would keep the old behaviour. I need your help to identify the set of package which would have to use the new directives, if I decide to introduce this incompatible change. My recent mail to -devel[1] only suggested ghc6 so I'm asking all the maintainers directly this time. [1] http://lists.debian.org/debian-devel/2011/05/msg01180.html Please reply for the packages that you maintain to the question that concerns you: 1/ If your package uses the interest directive in the triggers files, is it important that the triggering packages that activate your triggers be considered as not configured (and thus not satisfying dependencies) until the trigger has been processed? 2/ If your package uses the activate directive, is it important that your package be considered as not configured (and thus not satisfying dependencies) until the trigger has been processed? I have put no as answer for the install-info and man-db packages. For the others, I would like you to answer explicitly yes or no with a short rationale. If you don't know what to answer, please reply describing what your trigger does, and we'll try to find out through discussion. To make it easier to find the packages that concerns you, I have put a dd-list below. Thanks for your help! Ying-Chun Liu (PaulLiu) paul...@debian.org clutter-imcontext libomxil-bellagio Russ Allbery r...@debian.org lintian (U) nvidia-graphics-drivers (U) Bill Allombert ballo...@debian.org gap menu Henrik Andreasson deb...@han.pp.se pike7.8 (U) Osamu Aoki os...@debian.org xpdf (U) maximilian attems m...@debian.org initramfs-tools (U) Sebastien Bacher seb...@debian.org gnome-menus Adam D. Barratt a...@adam-barratt.org.uk lintian (U) Mirco Bauer mee...@debian.org mono (U) Daniel Baumann dan...@debian.org live-boot (U) open-vm-tools (U) plymouth (U) Daniel Baumann dan...@lists.debian-maintainers.org plymouth Daniel Baumann daniel.baum...@progress-technologies.net ntfs-3g Andreas Beckmann deb...@abeckmann.de nvidia-graphics-drivers (U) Vincent Bernat ber...@debian.org nevow Michael Biebl bi...@debian.org hal (U) Laurent Bigonville bi...@debian.org gdk-pixbuf (U) Fathi Boudra f...@debian.org icecc (U) Nicholas Breen nbr...@ofb.net grace Joachim Breitner nome...@debian.org ghc6 (U) Marc 'HE' Brockschmidt h...@debian.org gnome-menus (U) lintian (U) Rob Browning r...@defaultvalue.org guile-1.8 Ross Burton r...@debian.org desktop-file-utils hicolor-icon-theme Vagrant Cascadian vagr...@debian.org ltsp (U) Jesus Climent jesus.clim...@hispalinux.es spamassassin (U) C.M. Connelly c...@debian.org tex-common (U) Debian Forensics forensics-de...@lists.alioth.debian.org rkhunter unhide unhide.rb Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org gconf (U) gdk-pixbuf glib2.0 (U) gnome-icon-theme (U) gnome-menus (U) hicolor-icon-theme (U) Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org icecc Debian kernel team debian-kernel@lists.debian.org initramfs-tools Debian LibreOffice Maintainers debian-openoff...@lists.debian.org libreoffice Debian Live Project debian-l...@lists.debian.org live-boot Debian Mono Group pkg-mono-gr...@lists.alioth.debian.org mono Debian multimedia packages maintainers pkg-multimedia-maintain...@lists.alioth.debian.org vlc Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org nvidia-graphics-drivers Debian Octave Group pkg-octave-de...@lists.alioth.debian.org octave3.2 Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org php5 Debian Python Modules Team python-modules-t...@lists.alioth.debian.org nevow (U) Debian TeX maintainers debian-tex-ma...@lists.debian.org tex-common texinfo Jan Dittberner ja...@debian.org cracklib2 Agustin Martin Domingo agmar...@debian.org dictionaries-common Benjamin Drung bdr...@debian.org vlc (U) Sebastian Dröge sl...@debian.org gconf (U) gdk-pixbuf (U) glib2.0 (U) gnome-icon-theme (U) hal (U) shared-mime-info Free Ekanayaka fr...@debian.org twisted (U) twisted-conch (U) twisted-runner (U) Rene Engelhard r...@debian.org dictionaries-common (U) libreoffice (U) Sean Finney sean...@debian.org php5 (U) Raphael Geissert geiss...@debian.org lintian (U) php5 (U) readahead-fedora Michael Gilbert
Bug#615941: /etc/modprobe.d/alsa-base-blacklist.conf doesn't blacklist pcspkr despite the comment saying so
On Fri, 04 Mar 2011, Elimar Riesebieter wrote: reassign 615941 linux-latest-2.6 thanks * Raphael Hertzog [110302 08:01 +0100]: On Tue, 01 Mar 2011, Elimar Riesebieter wrote: So there'se a comment referring to a non-existing entry. Additionnaly I noticed that I hear again the annoying pcspkr beep since a few days... I don't know why and while looking into this I found this. Maybe it's related, maybe not. I managed to turn it off by muting the beep channel within the mixer. Hmmm, is pcspkr been loaded by your kernel? The comment can be removed easy but do we have to blacklist that module? I thought it wasn't built from Debian's kernel. Yes, the module is loaded and it's not due to any modification of me. So the kernel or some other piece of software must have auto-loaded it. $ lsmod |grep pcspkr pcspkr 1739 0 So this is a bug from Debian's kernel. This driver is useful for embedded systems only but not for an amd64 kernel. Huh? The comment in alsa's file is still misleading. You're a bit quick in reassigning the problem I think. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110305075417.gc27...@rivendell.home.ouaza.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Fri, 18 Feb 2011, Michael Gilbert wrote: This will also help to provide a bit more stability for CUT [0]. Over a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream kernels will be released, and each new kernel comes along with a high probability of introducing breakage. I'm trying to provide CUT releases once a month, so every 3 months I will be looking at a likely broken CUT release (or 25% of the time). However, if there is just one kernel transition in testing development cycle, then there is only 1 likely broken period (or 4% of the time). The kernel is not the sole component that can introduce breakage. So it seems ridiculous to do such statistics based on the kernel only. And like Lucas said, CUT users want recent software and that includes the kernel (which is also important for new hardware support). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110219130950.ga32...@rivendell.home.ouaza.com
Re: Bug#605009: serious performance regression with ext4
On Mon, 29 Nov 2010, Jonathan Nieder wrote: Guillem Jover wrote: Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) instead, skimming over the kernel source seems to indicate it might end up doing more or less the same thing but in a portable way? Probably a silly question, but what does The specified data will not be accessed in the near future have to do with preventing delayed allocation? It means we don't need to keep it in RAM since we're not going to read/modifiy it again in the near future. Thus the writeback can be started right now since delaying it will not save us anything. At least that's the way I understand the situation. Put another way: if this works now, is it likely to continue to work? Well, it will always work (the code is unlikely to introduce failures), but the resulting behaviour is entirely up to the kernel to decide. So there's no guaranty that the optimization will last. On the other hand, the whole point of posix_fadvise() is to give hints to the kernel so that he can decide on the best course of action. So I hope the interpretation above is one the main motivation behind that hint. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101129131602.gb24...@rivendell.home.ouaza.com
Re: [RFC/PATCH 0/4] Re: Bug#605009: serious performance regression with ext4
On Mon, 29 Nov 2010, Theodore Tso wrote: BTW, if you had opened the file handle in subsequent passes using O_RDONLY|O_NOATIME, the use of fdatasync() instead of fsync() might not have been necessary. And as far as the comments in patch #4 was Hum, fsync()/fdatasync() require a fd opened for writing, so this is not really possible? (Or at least the man page says so and indicates EBADF as return value in that case) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101129134611.ge24...@rivendell.home.ouaza.com
Re: Bug#605009: serious performance regression with ext4
(Dropping bug report) On Mon, 29 Nov 2010, Olaf van der Spek wrote: Hence the fact that all file system developers, whether they were btrfs developers or XFS developers or ext4 developers, made the joke at the file system developers summit two years ago, that what the application programmers really wanted was O_PONY, with the magic pixie dust. Unfortunately: I think a lot would be happy with O_ATOMIC. Please don't hijack/spam a bugreport for random complaints about the design of file systems. Ted's answer has been very valuable to solve the problem we have and I really dislike when constructive threads turn into bikeshedding over file system design. Thanks for your comprehension. Feel free to go discuss your issues on upstream mailing lists. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101129192337.ga16...@rivendell.home.ouaza.com
Re: Bug#605009: serious performance regression with ext4
Hi, On Tue, 30 Nov 2010, Michael Biebl wrote: Something interesting I noticed: I created the ext4 file system on a spare partition and installed a chroot. After running the test, I exited the chroot, immediately unmounted the partition and measured how long it took: 1.15.8.5: 0.4s Expected, this version calls sync() so there's nothing to write back when you umount the filesystem. 1.15.8.6: 7.2s 1.15.8.6+patch: 18.4s I can't explain the difference between both but it doesn't matter much IMO. If I wait a bit (+60s) after exiting the chroot and then do the unmount, it is almost instant ( 0.2s) in all three cases. 60s is more than the default writeback delay so again it's normal. $ sudo cat /proc/sys/vm/dirty_writeback_centisecs 500 - writeback after 5 sec Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101130065826.gb29...@rivendell.home.ouaza.com
Re: Bug#605009: serious performance regression with ext4
On Sat, 27 Nov 2010, Jonathan Nieder wrote: c) extract(a.dpkg-new); extract(b.dpkg-new); extract(c.dpkg-new); fsync(a.dpkg-new); fsync(b.dpkg-new); fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); (c) will perform the best for most file systems, including ext4. [...] I am guessing you are doing (a) today --- am I right? (c) or (d) would be best. We are doing (c) today. Actually we are doing this: extract(a.dpkg-new); extract(b.dpkg-new); extract(c.dpkg-new); fsync(a.dpkg-new); rename(a.dpkg-new, a); fsync(b.dpkg-new); rename(b.dpkg-new, b); fsync(c.dpkg-new); rename(c.dpkg-new, c); But as I said, I tried (c) and it's not performing noticably better than the above. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101127085346.gd14...@rivendell.home.ouaza.com
Re: Bug#605009: serious performance regression with ext4
Hi, adding debian-devel, debian-boot, debian-kernel and Theodore Y. Ts'o in CC because I'm fed up with this problem. Sorry for the massive crosspost, you might want to follow up only on -devel and on the bug report. Some clones/reassign should probably result from this discussion anyway. On Fri, 26 Nov 2010, Michael Biebl wrote: I'm using ext4 with the default mount option and the fs was created with the default settings from /etc/mke2fs.conf. Since the latest upgrade, performance suffered badly. E.g. installing vim-runtime took ~8 secs with 1.15.8.5, now it takes ~44secs. It was suggested that I use the nodelalloc mount option for ext4. But that not only takes away some of the benefits of ext4, it also requires explicit configuration. dpkg should work properly(with good performance) out-of-the-box on ext4. There's currently no way we're going to fix this. It all started with report of corrupted (zero-length) files on ext4/ubifs (see http://bugs.debian.org/430958). We did the right thing to fix this which is to call fsync() on the fly on each file that dpkg unpacks. That was introduced in dpkg 1.15.6. (Ubuntu had more than 80 bug reports related to this and Debian very few because we don't use ext4 by default) That was disastrous in terms of performance, so we then grouped the fsync()+rename() calls at the end of the unpack phase before updating the dpkg database. That can be witnessed in dpkg 1.15.7. That was ok everywhere except on ext4. For some unknown reasons, with the nodelalloc option the performance are again reasonable (but we discovered that only recently). Ubuntu is using ext4 by default and this performance was not acceptable and we tried to work-around the problem by replacing all the fsync() by a single sync() on Linux only (because Linux's sync() is synchronous while it's not necessarily the case on other systems). This was enabled in dpkg 1.15.7.2 in response to http://bugs.debian.org/578635. Now using sync() appears to be a bad choice since it resulted in RC bugs like http://bugs.debian.org/595927 and http://bugs.debian.org/600075 and was an annoyance for people using dpkg on tmpfs to get super-high speed (http://bugs.debian.org/588339). So we reverted that hackish work-around of using sync() and we're back to the situation where dpkg is very slow on ext4. But we have added a new option --force-unsafe-io that can be used when data safety is not important (in a temporary chroot, during initial installation, etc.) as requested in http://bugs.debian.org/584254. Where does that leaves us? Here are various options to consider (they are not necessarily mutually exclusive): 1/ This problem and the known work-arounds should be documented in the release notes. 2/ d-i should be modified to use --force-unsafe-io if it detects a dpkg version = 1.15.8.6. 3/ d-i might want to setup the nodelalloc option by default when a partition is formatted with ext4 and mounted as / or /usr. 4/ Theodore might want to find out why ext4 is behaving so badly under this usage pattern while ext3 doesn't... i.e. fix https://bugzilla.kernel.org/show_bug.cgi?id=15910 Or at least suggest another usage pattern which result in the same guaranty for dpkg but without the poor performance (and sync() is not the right answer as experience showed us). Note that doing N x fsync() followed by N x rename() is not giving us any better result that doing N x (fsync()+rename()). Note that calling posix_fallocate() before writing the files that are fsynced() did not help either (Mike Hommey thought it could be a way to emulate nodelalloc at the dpkg level only but apparently not). What has not been tried: reordering the fsync() based on FIEMAP information. Or using fdatasync() instead of fsync() and calling fsync() on directories. 5/ maybe the debian-kernel team wants to discuss the issue on LKML. Both for the bad ext4 performances (see above) and the (incorrect?) behaviour of sync() which is never finishing under important I/O loads (cf https://bugzilla.kernel.org/show_bug.cgi?id=18632). But right now from the point of view of dpkg maintainers, this bug is a wontfix at our level. Just to sum up what dpkg --unpack does in 1.15.8.6: 1/ set the package status as half-installed/reinst-required 2/ extract all the new files as *.dpkg-new 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by rename(foo.dpkg-new, foo) 4/ set the package status as unpacked Note that the directories are not fsynced() because we mainly don't care if the rename is recorded or not, as long as the installed file always has the content of either the old or the new file. This could be fixed but is unlikely to help in getting better performances I guess. The only thing we want to achieve is that: - when the package is set to unpacked status, all changes have been committed - when the process is abruptly interrupted, we don't leave corrupted files around (like unwanted empty files) Cheers, -- Raphaël Hertzog
Re: Pre-approval request for dpkg sync() changes for squeeze
On Sun, 21 Nov 2010, Ben Hutchings wrote: I'm coming to this late. It sounds like dpkg has changed its behaviour several times recently. Please can you summarise dpkg's current and proposed use of fsync() vs sync(), and the reasons for this. Jonathan made a good summary of the history. I should add that dpkg uses sync() instead of fsync() only on systems where we know that sync() is synchronous (i.e. Linux only). Now we want to stop using sync() because of the bad side-effects: - using on a tmpfs is slower because it syncs changes on unrelated filesystems - there are those reports of dpkg blocked due to the sync see http://bugs.debian.org/595927 http://bugs.debian.org/600075 Also do I understand correctly that fsync() is more expensive when ext4 delayed allocation is in use? Apparently, at least for dpkg's usage pattern. But the performance are so much slower that you have been asked whether it would make sense to change the defaults on ext4 to include nodelalloc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101121081804.gc11...@rivendell.home.ouaza.com
DKMS not always working
[ Please cc me I'm not subscribed to debian-kernel ] Hi, in the last upgrades the auto-compilation of the virtualbox-ose module did not work for me. Since the auto-compilation on boot got removed, we must ensure that it's properly compiled by the postinst of the linux-image package and there's no guaranty that it's possible since the linux-headers might not (yet) be installed. As it happens, I have linux-headers-2.6-amd64 installed and the headers are installed during upgrades... but they might be installed after the linux-image is configured apparently. Thus I believe it would be useful for DKMS to hook into the postinst of the linux-headers packages too to ensure that modules are built for the corresponding linux-image package too. Feel free to feed this mail in the BTS if you believe that my analysis is accurate. Otherwise, can someone tell me why that autocompilation feature did not work in the latest upgrades? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100325110454.ga21...@rivendell
Re: OpenVZ - deb-packages
Hi, On Wed, 14 Oct 2009, Dmitry E. Oboukhov wrote: I need OpenVZ 2.6.27 with ppp-features available. I was on the point of building the package, but I am not very good in building of kernels and the current openvz is built somehow strange: apt-get source linux-image-2.6.26-2-openvz-686 gets an src-package with no mentions of openvz in debian/control in it. Kernel packages are special: http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage 1. Have I understood correctly that openvz doesn't have its own Source in Debian now and it is simply added/removed from linux-source as the need arises? How should I act and with whom should I communicate if I want to add something to the package? The main source is the linux-2.6 source package. You should talk to its maintainers (people reachable on debian-kernel@lists.debian.org). 2. May be somebody has already built openvz 2.6.27 (with ppp-features). Could You share the link on repository? I have built a 2.6.26 openvz kernel with the ppp support (a single supplementary patch): The patch on the source package: https://svn.ac-grenoble.fr/svn/slis/slis/sources/trunk/backports/patches/linux-2.6_2.6.26-15~slis41+1.patch The source package: http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-2.6_2.6.26-15~slis41+1.dsc The binary package: http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-image-2.6.26-slis.1-openvz-686_2.6.26-15~slis41+1_i386.deb I would like this patch to be added in a point release update given it's only a supplementary feature in the -openvz kernel and should not disturb anything else. But it's not in line with the traditional stable update policy so I did not bother to propose it up to now. Dann, what's your stance on this ? Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OpenVZ - deb-packages
On Wed, 14 Oct 2009, maximilian attems wrote: I'm taking care of openvz, please file a bug report with severity important including the patch or link to patch, so that it can be added. Will do. if it does not break ABI it is easiest to add to next stable release, if it does i'll add it to the queued ABI breaking patches. did you test that? No, I had to change the abiname anyway as I wanted different package names for the target derivative distribution to avoid unwanted cross-upgrades. How can I test that ? Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#402414: linux-latest-2.6: Build metapackage xen-linux-system-2.6-xen-*
On Sun, 10 Dec 2006, Vincent Bernat wrote: Package: linux-latest-2.6 Severity: wishlist Hi ! A metapackage xen-linux-system-2.6-xen-* depending on the latest xen-linux-system-2.6.*-*-xen-* (similar to linux-image-2.6-*) would be nice. Indeed, it should be easy to do and would really be useful. Can someone take care of it? Vincent, if your offer of preparing a patch is still valid, please go ahead, at least it would make the bug more visible with its patch tag. :) Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#530880: dpkg: E: _cache-open() failed
reassign 530880 initramfs-tools 0.93.2 retitle 530880 update-initramfs broken probably due to bad symlink libmtp8.rules thanks On Thu, 28 May 2009, Stefano Costa wrote: Il giorno gio, 28/05/2009 alle 16.18 +0200, Raphael Hertzog ha scritto: Report against synaptic I guess... and not dpkg. What about copying its (english) output instead of an strace ? Please run LANG=C dpkg --configure -a and show us what it says. Sorry. I somehow misinterpreted the error message. Here's the output: So the problem is not at all dpkg related... it's just linux-image-2.6.29-2-amd64 that can't be configured because update-initramfs fails for some unknown reason. Reassigning it to update-initramfs. Do you have enough space in /boot ? What gives df -h /boot ? st...@gibreel:~$ LANG=C dpkg --configure -a dpkg: requested operation requires superuser privilege st...@gibreel:~$ sudo !! sudo LANG=C dpkg --configure -a [sudo] password for steko: Setting up initramfs-tools (0.93.2) ... update-initramfs: deferring update (trigger activated) Setting up linux-image-2.6.29-2-amd64 (2.6.29-5) ... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.29-2-amd64 dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead. dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead. W: Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin for module tg3 W: Possible missing firmware /lib/firmware/tigon/tg3_tso.bin for module tg3 W: Possible missing firmware /lib/firmware/tigon/tg3.bin for module tg3 cpio: ./etc/udev/rules.d/libmtp8.rules: Cannot stat: No such file or directory This is probably the core of the problem. Do you have libmtp8 installed ? What gives the following commands ? ls -al /etc/udev/ /etc/udev/rules.d/ dpkg -s libmtp8 libmtp7 In any case, update-initramfs could be more resistant to a what is probably a dangling symlink... update-initramfs: failed for /boot/initrd.img-2.6.29-2-amd64 update-initramfs failed to create initrd image. Failed to create initrd image. dpkg: error processing linux-image-2.6.29-2-amd64 (--configure): subprocess installed post-installation script returned error exit status 2 Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#530880: dpkg: E: _cache-open() failed
On Thu, 28 May 2009, Stefano Costa wrote: st...@gibreel:~$ LANG=C df -h /boot FilesystemSize Used Avail Use% Mounted on /dev/sda1 108G 94G 7.8G 93% / looks ok ? yes. /etc/udev/rules.d/: totale 116 drwxr-xr-x 2 root root 4096 27 mag 10:25 . drwxr-xr-x 4 root root 4096 27 mag 10:10 .. [...] lrwxrwxrwx 1 root root16 6 mag 13:53 libmtp8.rules - ../libmtp8.rules /etc/udev/rules.d/libmtp8.rules points to ../libmtp8.rules which is not there. What version of libmtp8 do you have ? Because this sounds similar to #527206 fixed in 0.3.7-5. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- 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
On Sun, 24 May 2009, Bastian Blank wrote: This means that Debian will get uninstallable on the following CPUs: - Intel i486, There is new hardware sold today that is (only) compatible to the 486 SX instruction set. But it runs at 300 MHz. So it would be a pity to loose support for such hardware. http://www.dmp.com.tw/tech/Vortex86SX/ http://www.compactpc.com.tw/ebox-2300.htm Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497717: firmware-iwlwifi: Please include the ucode for the new 5000-series cards
On Wed, 03 Sep 2008, Nate Carlson wrote: Intel recently released the 5000-series wireless cards (I have a 5300); it would be nice if you could include the firmware for these so we would not need to install them separately. Ping ? I have just bought a new Dell E4300 with a 5100 wifi card from Intel and it also needs the firmware... Should be a simple fix for sid and can't create problems for lenny. http://intellinuxwireless.org/?p=iwlwifin=downloads http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-5000-ucode-5.4.A.11.tar.gz Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#491057: linux-image-2.6.25-2-686: Dell Latitude D610 laptop doesn't resume with 2.6.25
On Thu, 17 Jul 2008, Lucas Nussbaum wrote: reassign 491057 acpi-support 0.109-5 clone 491057 -1 reassign -1 pm-utils 1.1.2.3-1 thanks Usually, suspend/resume should not require anything from userspace. The fact that some operations (alsa shutdown) have to be done from userspace could be considered as a kernel bug AFAIK. So I don't understand why you don't leave the bug open against the kernel... in particular when it's clearly a regression. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447611: [PATCH] updated patch
On Tue, 01 Apr 2008, Joey Hess wrote: The attached patch is against current git, and has been tested with the trigger-enabled dpkg in experimental. This patch is ready to be applied immediately. I think the patch lacks the triggers files itself. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453681: linux-modules-extra-2.6: virtualbox-ose-modules-2.6.22-3-686 is broken, module badly named
Package: linux-modules-extra-2.6 Version: 2.6.22-9 Severity: important virtualbox-ose-modules-2.6.22-3-686 contains virtualbox-ose.ko instead of the expected vboxdrv.ko that's generated by module-assistant. This renders this binary package useless. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441860: initramfs-tools: Resume from swap partition in LVM doesn't work
Hi, thanks for the quick reply. On Tue, 11 Sep 2007, maximilian attems wrote: On Tue, Sep 11, 2007 at 03:56:15PM +0200, Raphael Hertzog wrote: I grepped for RESUME in /etc/initramfs-tools/ and /usr/share/initramfs-tools/ but found no obvious use of that variable (except it's sourced by the init script). Where is it used? hmm thanks for report, at a quick look i think this is a regression in the unstable version, could you downgrade to i-t in testing and give feedback? Yes, I just did so, I confirm that it works with the version in testing (0.90a). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#441860: initramfs-tools: Resume from swap partition in LVM doesn't work
Package: initramfs-tools Version: 0.91 Severity: important I recently changed my setup and my swap partition has been integrated into LVM. Since then, I can't resume from suspend-to-disk (it's been quite some time since I last suspended to disk, so something else might be the root cause in reality). The image is written in the swap space (this is confirmed by the fact that I have no swap at the next boot until I mkswap / swapon manually). I tried to debug this but unfortunately I'm unable to understand how the resume parameter is supposed to be defined. I modified /etc/initramfs-tools/conf.d/resume to match with the change I made: $ cat /etc/initramfs-tools/conf.d/resume RESUME=/dev/mapper/vg_home-lv_swap And I regenerated the initrds with update-initramfs -k all -u but this didn't help. I booted with break=premount to get a shell at the init-premount time and I noticed that I had no resume or RESUME variable set. I also noticed that none of the hard disk drivers were loaded at that time. I grepped for RESUME in /etc/initramfs-tools/ and /usr/share/initramfs-tools/ but found no obvious use of that variable (except it's sourced by the init script). Where is it used? Do I have to add the resume parameter to the kernel command line? If yes, it means that I had those and they got lost... any idea how ? and is there some integration with grub and/or d-i that I missed? Feel free to ask me for any info/tests/etc. (FYI, my setup is *without* uswsusp, I also tried with uswsusp installed but it failed to find the swap device) -- Package-specific info: -- /proc/cmdline root=/dev/hda5 ro -- /proc/filesystems cramfs ext3 -- lsmod Module Size Used by i915 22432 2 drm76020 3 i915 binfmt_misc2 1 rfcomm 36280 0 l2cap 22432 5 rfcomm ppdev 8676 0 lp 10980 0 button 7920 0 ac 5188 2 battery 9988 0 cpufreq_stats 5120 0 cpufreq_powersave 1792 0 cpufreq_ondemand8300 1 cpufreq_conservative 6888 0 ipv6 236964 12 ipt_MASQUERADE 3616 2 iptable_nat 7204 1 nf_nat 17964 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 17772 2 iptable_nat nf_conntrack 60424 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 nfnetlink 5752 3 nf_nat,nf_conntrack_ipv4,nf_conntrack ip_tables 12260 1 iptable_nat x_tables 14372 3 ipt_MASQUERADE,iptable_nat,ip_tables tun10560 1 i8k 5976 1 speedstep_centrino 9572 0 freq_table 4512 3 cpufreq_stats,cpufreq_ondemand,speedstep_centrino cpufreq_userspace 4128 0 ide_generic 1216 0 [permanent] ide_cd 36416 0 snd_intel8x0m 16684 0 snd_seq_dummy 3748 0 snd_seq_oss29408 0 snd_seq_midi8160 0 snd_rawmidi22624 1 snd_seq_midi snd_intel8x0 32124 1 snd_ac97_codec 92836 2 snd_intel8x0m,snd_intel8x0 pcmcia 37100 0 snd_seq_midi_event 6880 2 snd_seq_oss,snd_seq_midi ac97_bus2272 1 snd_ac97_codec snd_pcm_oss39200 0 snd_mixer_oss 15424 1 snd_pcm_oss ipw2200 131396 0 snd_seq46320 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_seq_device 7692 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq ieee80211 31592 1 ipw2200 ieee80211_crypt 5792 1 ieee80211 intel_agp 23188 1 psmouse36016 0 parport_pc 33796 1 parport33960 3 ppdev,lp,parport_pc iTCO_wdt9924 0 tsdev 7968 0 firmware_class 9504 2 pcmcia,ipw2200 snd_pcm72324 4 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss snd_timer 21028 2 snd_seq,snd_pcm hci_usb16220 2 yenta_socket 24844 1 rsrc_nonstatic 11968 1 yenta_socket pcmcia_core37108 3 pcmcia,yenta_socket,rsrc_nonstatic agpgart31912 3 drm,intel_agp bluetooth 49348 7 rfcomm,l2cap,hci_usb serio_raw 6692 0 pcspkr 3104 0 rtc12856 0 joydev 9568 0 snd48324 13 snd_intel8x0m,snd_seq_oss,snd_rawmidi,snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_pcm,snd_timer soundcore 7520 1 snd evdev 9312 7 snd_page_alloc 9512 3 snd_intel8x0m,snd_intel8x0,snd_pcm ext3 121224 2 jbd55336 1 ext3 mbcache 8260 1 ext3 sg 32668 0 sr_mod
Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
On Tue, 26 Jun 2007, Bastian Blank wrote: On Fri, Jun 15, 2007 at 10:46:04AM +0200, Raphael Hertzog wrote: Indeed, and the version of the metapackages doesn't include an explicit reference to the ABI. IMO it should, then we could do: Depends: linux-image-2.6-686 (= 2.6.21-1), linux-image-2.6-686 ( 2.6.21-2) 2.6.21-1 = 2.6.21-1-1 = 2.6.21-2? I doubt it. The dash induces the comparison wrong... but that can be solved by introducing explicitely the debian revision in all versions numbers. 2.6.21-1-0 = 2.6.21-1-1 = 2.6.21-2-0 And the linux-2.6 version also don't describe the abi. What do you mean? linux-latest-2.6 doesn't include the ABI in the version number currently, but that's easy to solve since you have to update that package anyway every time the ABI changes... Currently you have to lookup the changelog of linux-image-2.6-686 to know the ABI it corresponds to, which is somehow inconvenient. No, the depends clearly stats which abi this is. Right. BTW, the version numbers in the changelog doesn't correspond to the version numbers of the generated package. While this is allowed, its there a compelling reason to do so in this case? Otherwise the linux version would complete go away. Why can't you put the linux version in the changelog itself? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
On Thu, 14 Jun 2007, Steve Langasek wrote: My two objections to this are scalability, and lack of comprehensiveness. It's not scalable because it means the maintainers of the linux-latest-2.6 package have to centrally keep track of every package in the archive providing a module metapackage; and it's not comprehensive because you say at the end that you only want it to list packages that are autobuilt. Well, the fact that I restrict it to auto-built package is precisely a compromise in favor of scalability. Auto-built packages are already centralized in linux-modules-* and it should be doable to automate this process much like the rest is already automated. Why would it not be sufficient for the metapackages to each depend on the corresponding linux-image package? That eliminates the need for a central registry of such packages. You could be right... do you mean something like this? Package: something-modules-2.6-686 Depends: linux-image-2.6-686 (= 2.6.21+7) This should give the same behaviour indeed. The modules meta-package would be broken when the linux-image-2.6 metapackages are upgraded unsynchronized. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
On Fri, 15 Jun 2007, Steve Langasek wrote: This should give the same behaviour indeed. The modules meta-package would be broken when the linux-image-2.6 metapackages are upgraded unsynchronized. Hmm; I guess I meant Depends: linux-image-2.6-686 (= 2.6.21), linux-image-2.6-686 ( 2.6.22) but I realize now that breaks when the ABI changes within an upstream kernel revision. Indeed, and the version of the metapackages doesn't include an explicit reference to the ABI. IMO it should, then we could do: Depends: linux-image-2.6-686 (= 2.6.21-1), linux-image-2.6-686 ( 2.6.21-2) Currently you have to lookup the changelog of linux-image-2.6-686 to know the ABI it corresponds to, which is somehow inconvenient. BTW, the version numbers in the changelog doesn't correspond to the version numbers of the generated package. While this is allowed, its there a compelling reason to do so in this case? $ zless /usr/share/doc/linux-image-2.6-686/changelog.gz linux-latest-2.6 (7) unstable; urgency=low * Update to 2.6.21-1. * Remove etch transition packages. -- Bastian Blank [EMAIL PROTECTED] Tue, 29 May 2007 14:26:20 +0200 [...] $ dpkg -l linux-image-2.6-686 | grep ^ii ii linux-image-2.6-6 2.6.21+7 Linux kernel 2.6 image on PPro/Celeron/PII/PIII/P4 Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
Package: linux-latest-2.6
Version: 2.6.21-4
Severity: wishlist
It would be great if we could have a mechanism to avoid installing a newer
kernel if the packaged modules that the user has installed are not yet
available. A simple example: I have 2.6.18-5 with the corresponding
kqemu-modules 2.6.18-5.
Yesterday I upgraded to sid and linux-image-2.6-686 pulled the new 2.6.21
kernel. However there's no kqemu-modules for 2.6.21 and thus I lost
support during the upgrade even though I have kqemu-modules-2.6-686
installed.
My suggestion to solve this is to use the new Breaks field as soon as
it's introduced in dpkg (it's planned in the next dpkg upload,
apt does already support it).
linux-image-2.6-686 in version 2.6.21+7 would be marked as breaking
the old versions of packages like kqemu-modules-2.6-686.
Package: linux-image-2.6-686
Breaks: kqemu-modules-2.6-686 ( 2.6.21+7), unionfs-modules-2.6-686 (
2.6.21+7), ...
That way the package manager has a clear hint on when it can safely
proceed with the upgrade.
However when you do this, you must also decide to regularly update the
linux-modules-{contrib,extra} packages. Of course, you should only list in
the Breaks field the packages that are autobuilt. Those that are only created
by the user with modules-assistant shouldn't be listed other the upgrade
will never happen (unless the user is clever enough to do it by himself).
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
Hi,
On Thu, 14 Jun 2007, Sven Luther wrote:
This is why i proposed instead to handle the kernel packages otherwise,
outside the normal kernel infrastructure.
We would have a kernel part of the archive, which would be independent
from the normal stable/testing/unstable/experimental setup.
In it, we would have a per kernel-abi version sub hierarchy, which would
contain all modules and other kernel related stuff (even .udebs), so
there would *NEVER* be this kind of breakage, nor a breakage of the
netboot d-i images, since we would always have a given abi available.
There's no real breakage and it's limited to sid anyway, for the time
between the upload of linux-2.6 and linux-modules-{contrib,extra}. Both
those packages are the responsibility of the kernel team, so it's just a
matter of coordination inside the kernel team.
I don't see the benefit of an extra archive, it would require changes in
the buildd to get this archive autobuilt. Furthermore it would lead to
less user testing since it's outside of unstable and we don't really want
that.
My suggestion takes into consideration the fact that the uploads of
linux-2.6 and linux-modules-{contrib,extra} are not synchronized (because
it's difficult to get all the external modules to build) and proposes a
simple mechanism to make sure that the user notices this
non-synchronization instead of being silently bitten by it.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#289690: cannot access some files with samba
Le vendredi 08 avril 2005 à 19:22 -0700, Steve Langasek a écrit : Does this bug also occur when using the cifs driver instead of the smbfs driver? I couldn't reproduce the problem now... it looks like the bug only happens with a Windows (2000) SMB server because I tried to reproduce the problem with Samba as server and I couldn't manage it (I can't remember the name of the problematic file but I was able to md5sum all files below my directory which contained the problematic file). It's my impression that the smbfs driver is no longer well-maintained upstream in 2.6, and that the cifs driver is a better choice. I'm not sure if we should consider this bug release-critical when there are lots of other problematic smbfs bugs out there even if this one gets fixed. Okay, then maybe a release note telling this would be welcome. Regards, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#289690: This bug is release critical IMO
Le vendredi 18 mars 2005 à 18:15 +0900, Horms a écrit : Can you please update to a more recent version of 2.6.8 and retest? Which one ? I don't know of anything newer than 2.6.8-13 ... (I was using -13 as I reported in my mail) Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#289690: This bug is release critical IMO
severity 289690 serious thanks This bug should really be fixed for sarge... releasing with broken Samba support isn't an option. I also encountered the bug on my side (with version 2.6.8-13 of the kernel). You must be able to find out the relevant change in the kernel bitkeeper history, isn't it ? As a starting point, you may contact the guy who posted that mail : http://lwn.net/Articles/112514/?format=printable Regards, Raphaël.
Re: [PROPOSAL] 2.4.27 as default 2.4 kernel for sarge
Quoting Joey Hess: 15. Get ftp-master to remove kernel udebs for the old kernel version from testing. This will *break* some old released install media (floppy, netboot, not cdrom), but it's necessary before release. Why is this necessary ? I'm a bit worried that rc1 netinst images do no more work when sarge is released ... those images are widespread due to the testing, and it's a pity to make them useless if we don't really need to. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
