Bug#730073: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes

[Arno Schuring]

Hi Ben,

> this configuration is no longer supported.

Fair enough. Thanks for considering.

Does that mean /etc/kernel-img.conf will disappear completely?


Arno

From: Ben Hutchings 
Sent: Sunday, June 5, 2016 12:18:50 AM
To: 730...@bugs.debian.org; Arno
Subject: Re: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes

On Wed, 20 Nov 2013 23:22:46 +0100 Arno  wrote:
> Package: src:linux
> Version: 3.11.8-1
> Severity: normal
> 
> Dearest maintainer,
> 
> The latest kernel upgrade fails to complete its installation on my system. If
> I remember correctly, the previous new kernel failed to install in the same
> way but I chose to work around it instead of reporting it back then.
> 
> The symptom is a failing postinst script because initrd is missing:

I recently found this bug myself while reviewing the maintainer scripts.

> If I'm reading the postinst script correctly, this error is from either
> line 383 or line 422, which is called from image_magic() if the
> destination path is neither missing nor a symlink. This is the case on
> my system, because I have set both do_symlinks=no and no_symlinks=yes in
> /etc/kernel-img.conf (what's the difference between them?).

do_symlinks = no disables creating symlinks for the 'default' kernel and initrd.
no_symlinks = yes enables copying to the default filenames.

> For new
> kernels, the initrd has not been generated yet (that happens at the end
> of the script) and cp doesn't handle that case as gracefully as ln does.

Yes.  This regression was introduced when we moved the call to update-
initramfs into a hook script (around version 2.6.38).

> Even though the failure mode is created by no_symlinks in kernel-img.conf,
> simply changing those settings does not allow the installation to
> continue. That's because the /initrd.img file still exists, and
> image_magic() is driven by the existing paths, not the config settings.
> Conversely, simply setting no_symlinks=yes in the config does not prevent
> a new kernel to be installed initially -- but as soon as a new initrd is
> generated (and the /initrd symlink is replaced with a file), the next
> kernel installation will fail regardless of the current config setting.

I'm afraid my answer to this is that this configuration is no longer
supported.  If many people were using it, I would try to fix it, but it
seems that yours was the only bug report.  Future kernel packages will
warn and will create symlinks instead of copying.

Ben.

--
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg

Bug#670047: linux-image-3.2.0-2-amd64: radeon card no longer detects connected TV

[Arno Schuring]

 There is no recent mention of EDID parsing in the changelog, but I'm pretty 
 sure that I've ran an earlier version of 3.2.0-2 succesfully on this box. I'll
 see if I can fetch some older 3.2.0-2 kernels to narrow down the search.

Both 3.2.10 and 3.2.12 work fine. Browsing the upstream changelogs, I seeno 
mention of edid but several i2c updates, and one likely suspect (in the3.2.14 
changelog):
drm/radeon/kms: fix analog load detection on DVI-I connectorscommit 
e00e8b5e760cbbe9067daeae5454d67c44c8d035 upstream.
https://bugs.freedesktop.org/show_bug.cgi?id=47007
My TV happens to be connected with a dvi-vga connector too.
Currently trying to compile Debian's 3.2.15 without the e00e8b commit.  
  

Bug#670047: linux-image-3.2.0-2-amd64: radeon card no longer detects connected TV

[Arno Schuring]

Hrm, let's try that again but now without the mangling of Hotmail's web
interface.

Arno Schuring (aelschur...@hotmail.com on 2012-04-22 15:10 +):
 
  There is no recent mention of EDID parsing in the changelog, but
  I'm pretty sure that I've ran an earlier version of 3.2.0-2
  succesfully on this box. I'll see if I can fetch some older 3.2.0-2
  kernels to narrow down the search.
 
 Both 3.2.10 and 3.2.12 work fine. Browsing the upstream changelogs, I
 see no mention of edid but several i2c updates, and one likely suspect
 (in the 3.2.14 changelog):
drm/radeon/kms: fix analog load detection on DVI-I connectors
commit e00e8b5e760cbbe9067daeae5454d67c44c8d035 upstream
https://bugs.freedesktop.org/show_bug.cgi?id=47007

 My TV happens to be connected with a dvi-vga connector too.
 Currently trying to compile Debian's 3.2.15 without the e00e8b commit.

Compilation without that patch went fine, and display issues are
solved. I'll follow up upstream.



-- 
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/20120422181538.5fcb8...@viper.intra.loos.site

Bug#670047: linux-image-3.2.0-2-amd64: radeon card no longer detects connected TV

[Arno Schuring]

Arno Schuring (aelschur...@hotmail.com on 2012-04-22 18:14 +0200):
 Compilation without that patch went fine, and display issues are
 solved. I'll follow up upstream.

Fix is already queued as e3632507, to be found here:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=e36325071832f1ba96ac54fb8ba1459f08b05dd8

That patch works for me.


Regards,
Arno



-- 
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/20120422210922.67244...@viper.intra.loos.site

Bug#645306: linux-image-2.6.32-5-kirkwood: page allocation failure after enabling jumbo frames

[Arno Schuring]

Maybe I should have searched the 'Net before firing...

 I'm seeing multiple swapper allocation failures (with backtrace) since I
 increased the MTU on one of the network interfaces:

According 
to http://www.mail-archive.com/debian-arm@lists.debian.org/msg10282.html this 
is actually expected behaviour?

If anyone can confirm that the messages are indeed harmless?
  


--
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/snt108-w146ddd05e6d91d77cde822b8...@phx.gbl

Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

[Arno Schuring]

Thusly spoke maximilian attems (m...@debian.org on 2011-04-05 06:44
+):
 On Mon, Apr 04, 2011 at 10:15:21PM +, Arno Schuring wrote:
  
  
   no, check your box with:
   egrep MODULES -r /etc/initramfs-tools/
  
  Great.
  
  /etc/initramfs-tools/initramfs.conf:# MODULES: [ most | netboot |
  dep | list ] /etc/initramfs-tools/initramfs.conf:MODULES=most
 
  /etc/initramfs-tools/conf.d/driver-policy:MODULES=dep
 
 you choose so on your Debian installation. on the why only you can
 respond (:
Habit. But my surprise was that MODULES was defined twice. Having never
dealt with conf.d before, I didn't think to look there.

 The expert install has a seemingly bad phrase so that many
 users seem to prefer MODULES=dep, when that question is shown.
I did use expert install, but I would have chosen dep anyway; it's
never bitten me in the past, and I used to use very small (32MB)
IDE-flash drives for /boot.

 As you noticed the file is unowned and can be removed and the
 initramfs regenerated.
 
 Nevertheless your fail in MODULES=dep is interesting and didn't have
 time yet to properly read this corresponding bug.
Since I had already spent so much time reading into the source, I spent
another hour yesterday to rewrite hook-functions to my liking. Patch
attached. It basically replaces the entire sysfs-from-dev divination
with a walker that uses sysfs' slave links to reach the underlying
device, collecting modules along the way.

Please treat this as an FYI, not a push. The exercise is academic
anyway, since this is not in any way a resource-constrained device. I'm
not comfortable signing off on this code, because
a) I simply can't test and have no experience with block devices other
than lvm, md and plain partitions.
b) the code assumes a lot about sysfs that I have not been able to
support with documentation:
- there appears to be no guarantee about the existence of a block
  device at all (maybe it's driver-dependent?)
- no guarantee about whether following slaves/ in /block/ will always
  reach an endpoint under /devices/
- Never depend on the device-link is mentioned explicitly in the
  document, but there appears to be no other way to reach driver/ from
  /block/ (?). It also explicitly says Accessing
  /sys/class/net/eth0/device is a bug in the application
c) initramfs is not exactly the place where you can afford to be naive
without consequence


That said, this code WorksForMe(tm), I've tried very hard not to
break any old code paths. It can't replace the existing code anyway
because it relies on udev, which is non-essential. I think
sys_walk_device might be useful though.

Oh, and there's several indentation violations to avoid huge
whitespace-only changes. Like I said, it's not a submission.--- hook-functions.orig	2011-01-28 15:11:01.0 +0100
+++ hook-functions	2011-04-06 00:54:41.307212833 +0200
@@ -213,10 +213,37 @@
 	fi
 }
 
+sys_walk_device()
+{
+	local dev_path
+
+	dev_path=${1}
+	# regular device or partition
+	if [ ${dev_path#/sys/devices/} != ${dev_path} ]; then
+		sys_walk_mod_add ${dev_path}
+	elif [ -e ${dev_path}/dev ]; then
+		sys_walk_mod_add $(readlink -f ${dev_path}/device)
+	fi
+	# possible dm/md device node
+	if [ -e ${dev_path}/dm ]; then
+		manual_add_modules lvm
+	elif [ -e ${dev_path}/md ]; then
+		#this works even for level=raid5 (module raid456.ko)
+		manual_add_modules $(cat ${dev_path}/md/level)
+	fi
+
+	if [ -e ${dev_path}/slaves ]; then
+		#FIXME this breaks on spaces in the devpath
+		for slave in ${dev_path}/slaves/* ; do
+			sys_walk_device $(readlink -f ${slave})
+		done
+	fi
+}
+
 # find and only copy root relevant modules
 dep_add_modules()
 {
-	local block minor root FSTYPE root_dev_path x
+	local block minor root FSTYPE root_dev_path sys_path x
 
 	# require mounted sysfs
 	if [ ! -d /sys/devices/ ]; then
@@ -274,6 +301,11 @@
 	# Add rootfs
 	manual_add_modules ${FSTYPE}
 
+	# query udev for the sysfs device path
+	sys_path=$(udevadm info --query=path --name=${root})
+
+# use old code path only if we failed to find the correct device
+if [ -z ${sys_path} ]; then
 	# lvm or luks root
 	if [ ${root#/dev/mapper/} != ${root} ] \
 		|| [ ${root#/dev/dm-} != ${root} ]; then
@@ -359,10 +391,15 @@
 		echo mkinitramfs: Error please report the bug 2
 		exit 1
 	fi
+fi
 
+	if [ -n ${sys_path} ]; then
+		sys_walk_device /sys${sys_path}
+	else
 	# sys walk ATA
 	root_dev_path=$(readlink -f /sys/block/${block}/device)
 	sys_walk_mod_add ${root_dev_path}
+	fi
 
 	# catch old-style IDE
 	if [ -d ${DESTDIR}/lib/modules/${version}/kernel/drivers/ide ]; then

Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

[Arno Schuring]

Package: initramfs-tools
Version: 0.98.8
Severity: normal

(resending manually because exim hadn't been configured yet)

This is a new Wheezy install on an old server machine. The machine has four
PATA disks, tied to two controllers. The four disks are combined into a SW-raid
volume using mdadm:

ladmin@fury:/tmp$ sudo mdadm --detail /dev/md0|grep /dev/
/dev/md0:
   0   8   360  active sync   /dev/sdc4
   1   8   521  active sync   /dev/sdd4
   2   842  active sync   /dev/sda4
   4   8   203  active sync   /dev/sdb4

[ 1.145853] scsi0 : pata_sil680
[ 1.146143] scsi1 : pata_sil680
[ 1.147018] ata1: PATA max UDMA/133 cmd 0xc400 ctl 0xc000 bmdma 0xb000 irq 23
[ 1.147085] ata2: PATA max UDMA/133 cmd 0xb800 ctl 0xb400 bmdma 0xb008 irq 23
[ 1.148407] scsi2 : pata_serverworks
[ 1.148835] scsi3 : pata_serverworks
[ 1.156965] ata3: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
[ 1.157034] ata4: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15


During installation, I configured initramfs-tools to determine the required
modules automatically, which resulted in a non-booting system (notice that
the sil680 module is missing):

ladmin@fury:/tmp$ lsinitramfs /boot/initrd.img-2.6.32-5-686 |grep ata
lib/udev/ata_id
lib/modules/2.6.38-2-686/kernel/drivers/ata
lib/modules/2.6.38-2-686/kernel/drivers/ata/ata_generic.ko
lib/modules/2.6.38-2-686/kernel/drivers/ata/pata_serverworks.ko
lib/modules/2.6.38-2-686/kernel/drivers/ata/libata.ko


As a workaround, I've now added both pata_ modules to /e/i-t/modules,
but that is about as far as my knowledge of initramfs-tools will go.
I'll be glad to try other suggestions, or provide more info.


--
(regarding the below: I apologize, I can get carried away sometimes...
I'll leave solving this up to you :)

From my reading of sh -x output, it appears that there is just one level too  
much indirection going on. We have a
  + readlink -f /dev/mapper/fury-root
  /dev/dm-0
Which finds the correct dm device. Following the trace, 
  + ls -1 /sys/block/dm-0/slaves
  + block=md0
md0 is identified as the correct md device underlying the lvm VG. But this is
also where it breaks down; the sed expression following it reduces /proc/mdstat
to just a single block device:
  + block=sdc
  [...]
  + readlink -f /sys/block/sdc/device

This code maps to dep_add_modules() in hook-functions, particularly the sed
expression on line 288 (preceded by comment lvm on md). The code surely
doesn't look like it's designed to handle more than one block device per
invocation, but that is probably what's needed here.  It's trivial to modify
the sed expression to that end (replacing the last -e argument):
  sed [...] -e 's/\[[0-9]\+\]//g' -e '/^'${block}' :/s/^[^[]*\[ //p'
But that still leaves the issue that the rest of the code expects $block to
only represent a single block device. At the very least, the #Error out and
# sys walk ATA code blocks (line 350+) would need a loop.



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 4.2M Apr  3 21:37 /boot/initrd.img-2.6.32-5-686
-rw-r--r-- 1 root root 4.3M Apr  3 21:37 /boot/initrd.img-2.6.38-2-686
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.38-2-686 root=/dev/mapper/fury-root ro

-- resume
RESUME=/dev/mapper/sda3_crypt
-- /proc/filesystems
btrfs
ext4
ext3

-- lsmod
Module  Size  Used by
ext3   98001  1 
jbd40818  1 ext3
dm_mirror  17249  1 
dm_region_hash 13072  1 dm_mirror
dm_log 13269  3 dm_mirror,dm_region_hash
loop   17805  0 
sha256_generic 16709  8 
aes_i586   16608  16 
aes_generic37066  1 aes_i586
cbc12659  8 
dm_crypt   17809  4 
snd_pcm52774  0 
snd_timer  22171  1 snd_pcm
ohci_hcd   21928  0 
ehci_hcd   34889  0 
snd38153  2 snd_pcm,snd_timer
usbcore99058  3 ohci_hcd,ehci_hcd
soundcore  12878  1 snd
snd_page_alloc 12841  1 snd_pcm
tpm_tis12949  0 
tpm17454  1 tpm_tis
tg3   103807  0 
pcspkr 12515  0 
tpm_bios   12799  1 tpm
aic7xxx97720  0 
i2c_piix4  12480  0 
libphy 18279  1 tg3
evdev  13084  2 
processor  26983  0 
nls_base   12649  1 usbcore
i2c_core   18989  1 i2c_piix4
thermal_sys17667  1 processor
scsi_transport_spi 19032  1 aic7xxx
button 12866  0 
ext4  251726  3 
mbcache12810  2 ext3,ext4
jbd2   55701  1 ext4
crc16  12327  1 ext4
dm_mod 56394  37 dm_mirror,dm_log,dm_crypt
raid45651595  1 
async_raid6_recov  12459  1 

Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

[Arno Schuring]

Hi Ben,

  During installation, I configured initramfs-tools to determine the required
  modules automatically, which resulted in a non-booting system (notice that
  the sil680 module is missing):
 [...]
 
 The initramfs-tools 'MODULES=dep' mode is primarily meant for small
 systems with limited RAM and disk space for the initramfs.  The
 dependency detection code does not currently handle all module
 dependencies, as you see.  I recommend using 'MODULES=most'.
 

But MODULES=most is exactly what is set:

 -- /etc/initramfs-tools/initramfs.conf
 MODULES=most

Regards,
Arno

  


--
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/snt108-w200a41ec816f1e33f7649eb8...@phx.gbl

Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

[Arno Schuring]

 no, check your box with:
 egrep MODULES -r /etc/initramfs-tools/

Great.

/etc/initramfs-tools/initramfs.conf:# MODULES: [ most | netboot | dep | list ]
/etc/initramfs-tools/initramfs.conf:MODULES=most
/etc/initramfs-tools/conf.d/driver-policy:MODULES=dep

So, which one is the preferred location? Will anything break if I just clear 
out the conf.d directory?
ladmin@fury:~$ dpkg -S /etc/initramfs-tools/conf.d/*
dpkg: /etc/initramfs-tools/conf.d/driver-policy not found.
dpkg: /etc/initramfs-tools/conf.d/resume not found.

  

Bug#550392: firmware-linux: Radeon kernel modesetting requires pre-initramfs firmware loading

[Arno Schuring]

Package: firmware-linux
Version: 0.18
Severity: wishlist
Tags: patch

(Yes I know, I'm way ahead of the curve. Since I had to tackle this problem, I 
figured I might just as well publish my results)

Starting with kernel 2.6.32, the radeon in-kernel driver will stall the boot 
process while waiting for the microcode to be supplied. The 2.6.31 kernel did 
not do this (was it in-kernel before?). I'm using kernel modesetting, and have 
not tried the non-kms case but I suspect it will stall as well (but maybe later 
in the boot process). Entries in dmesg look like:

[0.316326] [drm] Loading R300 Microcode
[0.316332] platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
[   60.316136] radeon_cp: Failed to load firmware radeon/R300_cp.bin
[   60.316177] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[...]
[   60.318534] [drm] Forcing AGP to PCI mode
[   60.318847] [drm] GPU reset succeed (RBBM_STATUS=0x0140)
[...]
[   60.319458] [drm] Loading R300 Microcode
[   60.319463] platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
[  120.316114] radeon_cp: Failed to load firmware radeon/R300_cp.bin
[  120.316156] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[  120.316194] radeon :01:00.0: failled initializing CP (-2).
[  120.316230] radeon :01:00.0: Disabling GPU acceleration

So the machine will appear to hang for two minutes. The regular firmware 
loading sequences do not appear to work when KMS is enabled (radeon.modeset=1), 
because the kernel will only try to load this firmware once: before running 
/init !

This means that even when the firmware and the udev firmware agent are 
available in the initramfs, the firmware load will fail because /sys isn't 
mounted yet. And without /sys, there is no way to abort the firmware load 
either.

I'm attaching the script I use to get around this issue. Basically, what I'm 
doing is reproducing part of the initialization performed by /init before 
spawning the Udev firmware agent. I'm not really sure what to do about /sys 
though: the current implementation introduces a race condition where /sys might 
get unmounted after /init has run. It might be better to just leave /sys 
mounted and have /init mount it again, but I'm not sure about the implications 
(my tests showed no negative consequences). This script must be installed as 
/sbin/hotplug - no code has run yet to alter the path to the hotplug event 
manager...

I'm filing this against firmware-linux because that's where the Radeon firmware 
lives. If there is a better place where this should be fixed, please feel free 
to redirect. And if you already have a better solution in place, feel free to 
ignore me :)


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (800, 'testing'), (550, 'stable'), (101, 'unstable'), (100, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-rc3 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

firmware-linux depends on no packages.

firmware-linux recommends no packages.

Versions of packages firmware-linux suggests:
ii  initramfs-tools   0.93.4 tools for generating an initramfs
ii  linux-image-2.6.30-2-686 [lin 2.6.30-8   Linux 2.6.30 image on PPro/Celeron
ii  linux-image-2.6.31-rc9 [linux 20090909   Linux kernel binary image for vers
ii  linux-image-2.6.32-rc3 [linux 20091008   Linux kernel binary image for vers

-- no debconf information
#!/bin/sh
#
## Simple firmware hotplug handler. When kernel modesetting is enabled for ATi
## Radeon graphics cards, the firmware load is triggered even before running
## /init (but still after initramfs is unpacked). This means that the hotplug
## script itself becomes responsible for mounting /sys, because otherwise the
## firmware can't be loaded.
## Ignoring the firmware request is not an option - the kernel will simply keep
## waiting for data until the timeout has passed, which is 60 seconds by
## default. Aborting the firmware load can be performed by echo'ing -1 to the
## firmware control file, but that also requires /sys to be mounted.

# no console - messages won't be visible
#echo HOTPLUG Loading, please wait...


# only respond to firmware requests
if [ -n $FIRMWARE ]; then
	MTSYS=
	[ -d /sys ] || mkdir /sys
	[ -d /sys/kernel ] || MTSYS=1
	[ -z $MTSYS ] || mount -t sysfs -o nodev,noexec,nosuid none /sys

	# try the udev firmware loader first
	if [ -x /lib/udev/firmware.agent ]; then
		. /lib/udev/firmware.agent
	else
		# poor-man's loader script
		if [ -r /lib/firmware/$FIRMWARE ]; then
			echo 1  /sys/$DEVPATH/loading
			cat /lib/firmware/$FIRMWARE  /sys/$DEVPATH/data
			echo 0  /sys/$DEVPATH/loading
		else
			echo -1  /sys/$DEVPATH/loading
		fi
	fi
	# perform cleanup so as not to confuse /init
	[ -z $MTSYS ] || umount /sys
fi


exit 0

Bug#515009: another source

[Arno Schuring]

It looks like https://bugs.launchpad.net/pulseaudio/+bug/213053
describes the same bug. Like that bug, I have been unable to reproduce
it since.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org