Debian Bug report logs - #392623
NAME="" for dm- devices confuses gnome-mount / hal

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: NAME="" for dm- devices confuses gnome-mount / hal

Date: Thu, 12 Oct 2006 18:06:29 +0200

Package: udev
Version: 0.100-2
Severity: normal

        Hi,

 (I think you're already aware of the problem, this is a reminder bug as
 I think no open bug for this issue exists.)

 The gnome-mount program (currently in NEW) can handle LUKS based crypto
 mounts.  gnome-mount is called with the HAL UDI of such a device, will
 pop for a password, and will then wait until it receives an event from
 HAL for a new block device which has the LUKS device as a parent.

 However, the following line in /etc/udev/udev.rules seems to prevent
 this from happening:
    KERNEL=="dm-[0-9]*",        NAME=""  (line 100)

 If I comment it out, it works.

   Bye,

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 12
lrwxrwxrwx 1 root root  20 2005-08-02 20:04 020_permissions.rules -> ../permissions.rules
lrwxrwxrwx 1 root root  19 2005-10-12 12:30 025_libgphoto2.rules -> ../libgphoto2.rules
lrwxrwxrwx 1 root root  15 2006-01-26 10:27 85-pcmcia.rules -> ../pcmcia.rules
lrwxrwxrwx 1 root root  15 2006-08-30 17:53 libnjb.rules -> ../libnjb.rules
lrwxrwxrwx 1 root root  13 2005-08-02 20:04 udev.rules -> ../udev.rules
-rw-r--r-- 1 root root 121 2006-02-17 21:30 yy_local-touchpad
lrwxrwxrwx 1 root root  25 2006-03-28 09:38 z20_persistent-input.rules -> ../persistent-input.rules
lrwxrwxrwx 1 root root  19 2005-08-24 23:42 z20_persistent.rules -> ../persistent.rules
-rw-r--r-- 1 root root 569 2006-08-30 17:53 z25_persistent-cd.rules
-rw-r--r-- 1 root root 694 2006-09-26 20:45 z25_persistent-net.rules
lrwxrwxrwx 1 root root  33 2006-04-20 12:25 z45_persistent-net-generator.rules -> ../persistent-net-generator.rules
lrwxrwxrwx 1 root root  12 2005-08-02 20:04 z50_run.rules -> ../run.rules
lrwxrwxrwx 1 root root  16 2006-02-17 20:36 z55_hotplug.rules -> ../hotplug.rules
lrwxrwxrwx 1 root root  19 2005-08-03 10:35 z60_alsa-utils.rules -> ../alsa-utils.rules
lrwxrwxrwx 1 root root  15 2005-09-24 13:20 z60_hdparm.rules -> ../hdparm.rules
lrwxrwxrwx 1 root root  20 2006-05-04 17:37 z60_xen-backend.rules -> ../xen-backend.rules
lrwxrwxrwx 1 root root  33 2006-05-06 10:11 z60_xserver-xorg-input-wacom.rules -> ../xserver-xorg-input-wacom.rules
lrwxrwxrwx 1 root root  29 2006-08-18 11:22 z75_cd-aliases-generator.rules -> ../cd-aliases-generator.rules
lrwxrwxrwx 1 root root  12 2006-10-04 15:20 z99_hal.rules -> ../hal.rules

-- /sys/:
/sys/block/dm-0/dev
/sys/block/dm-1/dev
/sys/block/hda/dev
/sys/block/hda/hda1/dev
/sys/block/hda/hda2/dev
/sys/block/hdc/dev
/sys/block/loop0/dev
/sys/block/loop10/dev
/sys/block/loop11/dev
/sys/block/loop12/dev
/sys/block/loop13/dev
/sys/block/loop14/dev
/sys/block/loop15/dev
/sys/block/loop16/dev
/sys/block/loop17/dev
/sys/block/loop18/dev
/sys/block/loop19/dev
/sys/block/loop1/dev
/sys/block/loop20/dev
/sys/block/loop21/dev
/sys/block/loop22/dev
/sys/block/loop23/dev
/sys/block/loop24/dev
/sys/block/loop25/dev
/sys/block/loop26/dev
/sys/block/loop27/dev
/sys/block/loop28/dev
/sys/block/loop29/dev
/sys/block/loop2/dev
/sys/block/loop30/dev
/sys/block/loop31/dev
/sys/block/loop32/dev
/sys/block/loop33/dev
/sys/block/loop34/dev
/sys/block/loop35/dev
/sys/block/loop36/dev
/sys/block/loop37/dev
/sys/block/loop38/dev
/sys/block/loop39/dev
/sys/block/loop3/dev
/sys/block/loop40/dev
/sys/block/loop41/dev
/sys/block/loop42/dev
/sys/block/loop43/dev
/sys/block/loop44/dev
/sys/block/loop45/dev
/sys/block/loop46/dev
/sys/block/loop47/dev
/sys/block/loop48/dev
/sys/block/loop49/dev
/sys/block/loop4/dev
/sys/block/loop50/dev
/sys/block/loop51/dev
/sys/block/loop52/dev
/sys/block/loop53/dev
/sys/block/loop54/dev
/sys/block/loop55/dev
/sys/block/loop56/dev
/sys/block/loop57/dev
/sys/block/loop58/dev
/sys/block/loop59/dev
/sys/block/loop5/dev
/sys/block/loop60/dev
/sys/block/loop61/dev
/sys/block/loop62/dev
/sys/block/loop63/dev
/sys/block/loop6/dev
/sys/block/loop7/dev
/sys/block/loop8/dev
/sys/block/loop9/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/class/drm/card0/dev
/sys/class/graphics/fb0/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/input2/mouse0/dev
/sys/class/input/input2/ts0/dev
/sys/class/input/input3/event3/dev
/sys/class/input/input3/mouse1/dev
/sys/class/input/input3/ts1/dev
/sys/class/input/mice/dev
/sys/class/misc/agpgart/dev
/sys/class/misc/device-mapper/dev
/sys/class/misc/hpet/dev
/sys/class/misc/hw_random/dev
/sys/class/misc/psaux/dev
/sys/class/misc/rtc/dev
/sys/class/misc/snapshot/dev
/sys/class/ppdev/parport0/dev
/sys/class/printer/lp0/dev
/sys/class/sound/adsp/dev
/sys/class/sound/audio1/dev
/sys/class/sound/audio/dev
/sys/class/sound/controlC0/dev
/sys/class/sound/controlC1/dev
/sys/class/sound/dsp1/dev
/sys/class/sound/dsp/dev
/sys/class/sound/mixer1/dev
/sys/class/sound/mixer/dev
/sys/class/sound/pcmC0D0c/dev
/sys/class/sound/pcmC0D0p/dev
/sys/class/sound/pcmC0D1c/dev
/sys/class/sound/pcmC0D2c/dev
/sys/class/sound/pcmC0D3c/dev
/sys/class/sound/pcmC0D4p/dev
/sys/class/sound/pcmC1D0c/dev
/sys/class/sound/pcmC1D0p/dev
/sys/class/sound/seq/dev
/sys/class/sound/sequencer2/dev
/sys/class/sound/sequencer/dev
/sys/class/sound/timer/dev
/sys/class/usb_device/usbdev2.1/dev
/sys/class/usb_device/usbdev3.1/dev
/sys/class/usb_device/usbdev3.4/dev
/sys/class/usb_device/usbdev3.5/dev
/sys/class/usb_device/usbdev4.1/dev
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0/usbdev2.1_ep81/dev
/sys/devices/pci0000:00/0000:00:1d.0/usb2/usbdev2.1_ep00/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-0:1.0/usbdev3.1_ep81/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/usbdev3.4_ep81/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0/usbdev3.5_ep01/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0/usbdev3.5_ep82/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/usbdev3.5_ep00/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/usbdev3.4_ep00/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb3/usbdev3.1_ep00/dev
/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-0:1.0/usbdev4.1_ep81/dev
/sys/devices/pci0000:00/0000:00:1d.2/usb4/usbdev4.1_ep00/dev

-- Kernel configuration:


-- System Information:
Debian Release: Debian unstable (sid)
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)

Versions of packages udev depends on:
ii  libc6                        2.3.6.ds1-6 GNU C Library: Shared libraries
ii  libselinux1                  1.30.28-2   SELinux shared libraries
ii  libvolume-id0                0.100-2     libvolume_id shared library
ii  lsb-base                     3.1-17      Linux Standard Base 3.1 init scrip

udev recommends no packages.

-- no debconf information

-- 
Loïc Minier <lool@dooz.org>

Message #10 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 392623@bugs.debian.org, lool@dooz.org

Subject: NAME="" for dm- devices confuses gnome-mount / hal

Date: Thu, 26 Oct 2006 12:01:27 +0200

[Message part 1 (text/plain, inline)]

Hi Martin, hi Loic!

being the gnome-mount maintainer I'm aware of this problem. Martin, you
surely remember that we already discussed this issue some time ago.
Your concerns were mostly, that reintroducing /dev/dm-* devices might
break dm/lvm related packages. Asking around on IRC the only answer I
got from DDs with lvm/dd experience was, that /dev/dm-* are not created
to avoid clutter in /dev (well, that point is surely arguable) and apps
*should* use /dev/mapper devices directly, because that was the
canonical way nowadays. I didn't get more specific answers.

Talking to hal/gnome-mount upstream (davidz) and Kay Sievers, they both
confirmed, that suppressing the creation of /dev/dm-* is broken and
should be reverted.

So, I'd recommend to remove this rule from /etc/udev/udev.rules.
Weighing a less cluttered /dev against a working hal, I definitely go
for the latter.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Marco d'Itri <md@Linux.IT>, 392623@bugs.debian.org

Subject: Re: NAME="" for dm- devices confuses gnome-mount / hal

Date: Thu, 26 Oct 2006 12:41:39 +0200

[Message part 1 (text/plain, inline)]

Michael Biebl wrote:
> Hi Martin, hi Loic!
> 
> being the gnome-mount maintainer I'm aware of this problem. Martin, you
> surely remember that we already discussed this issue some time ago.
[..]

Sorry Marco,

I somehow managed to mix up your name. Won't happen again.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 392623-close@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: 392623-close@bugs.debian.org

Subject: Bug#392623: fixed in udev 0.103-1

Date: Sun, 26 Nov 2006 23:47:08 +0000

Source: udev
Source-Version: 0.103-1

We believe that the bug you reported is fixed in the latest version of
udev, which is due to be installed in the Debian FTP archive:

libvolume-id-dev_0.103-1_i386.deb
  to pool/main/u/udev/libvolume-id-dev_0.103-1_i386.deb
libvolume-id0_0.103-1_i386.deb
  to pool/main/u/udev/libvolume-id0_0.103-1_i386.deb
udev-udeb_0.103-1_i386.udeb
  to pool/main/u/udev/udev-udeb_0.103-1_i386.udeb
udev_0.103-1.diff.gz
  to pool/main/u/udev/udev_0.103-1.diff.gz
udev_0.103-1.dsc
  to pool/main/u/udev/udev_0.103-1.dsc
udev_0.103-1_i386.deb
  to pool/main/u/udev/udev_0.103-1_i386.deb
udev_0.103.orig.tar.gz
  to pool/main/u/udev/udev_0.103.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 392623@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marco d'Itri <md@linux.it> (supplier of updated udev package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 26 Nov 2006 23:16:09 +0100
Source: udev
Binary: libvolume-id-dev udev libvolume-id0 udev-udeb
Architecture: source i386
Version: 0.103-1
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri <md@linux.it>
Changed-By: Marco d'Itri <md@linux.it>
Description: 
 libvolume-id-dev - libvolume_id development headers
 libvolume-id0 - libvolume_id shared library
 udev       - /dev/ and hotplug management daemon
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 321642 369479 389743 392580 392623 393433 394897 395136 395160 395340 395889 396072 396149 396841 396933 397476 397528 398724 399107 399624 400258
Changes: 
 udev (0.103-1) unstable; urgency=medium
 .
   * New upstream release.
   * permissions.rules: detect upper case Epson scanners too. (Closes: #392580)
   * permissions.rules: fix the permissions of the partitions of removable
     block devices. (Closes: #321642)
   * permissions.rules: added lirc[0-9]* group audio. (Closes: #396841)
   * permissions.rules: added rtc[0-9]* group audio. (Closes: #395160)
   * permissions.rules: added tun mode 666, for recent kernels.
   * persistent.rules: ignore gnbd* devices.
   * persistent.rules: added links for MMC devices.
   * persistent.rules: create disk/by-id/ata-* links for IDE devices
     controlled by libata.
   * hotplug.rules: autoload the mmc-block driver.
   * hotplug.rules: do not attempt to autoload i82365 because it's broken
     and may cause a modprobe loop (see #398962 for details).
   * udev.rules, devfs.rules: stop suppressing creation of dm-* devices,
     because they are needed by HAL. (Closes: #392623)
   * udev.rules, devfs.rules: run PROGRAMs only for "add" ACTIONs.
   * hotplug.rules: removed call to ide.agent from the udeb. (Closes: #396933)
   * Added a new 020_id.rules file with calls to cdrom_id for the udeb.
     (Closes: #400258)
   * Create the kernel-upgrade flag file also in the debconf upgrade path,
     or the new udevd will be started (and fail).
   * write_net_rules: document that MAC addresses must be written in
     lowercase. (Closes: #389743)
   * Set the SELinux contexts for devices created in the initramfs.
     (Closes: #397528)
   * Implemented no_static_dev when a initramfs is used. (Closes: #397476)
   * Robustness: fixed postinst to not fail if /dev/{pts,shm}/ do not exist,
     which usually should not happen. (Closes: #395136)
   * Do not mention CONFIG_KOBJECT_UEVENT in README.Debian. (Closes: #399624)
   * Made the init script recognize /dev/null as a valid boot-time console,
     to work better with upstart (see #397002).
   * New debconf templates: sv, ru, fr, da, de, eu.
     (Closes: #393433, #394897, #395340, #396072, #396149, #398724, #399107)
   * Merged the NMUs. (Closes: #369479, #395889)
Files: 
 1d8517b22e3049f406e4a00be3ccbc85 635 admin important udev_0.103-1.dsc
 a29dbf712002433085e759bec5005a85 200270 admin important udev_0.103.orig.tar.gz
 64fd4333679fd491cad960bfc083a76c 57411 admin important udev_0.103-1.diff.gz
 d57d59febfa0ac554db5574370eb9fd4 273598 admin important udev_0.103-1_i386.deb
 d281b5dbffe8f125d641c5802d8e0654 60822 libs important libvolume-id0_0.103-1_i386.deb
 d8734e2e795075af30f060f0d9725c1b 15542 libdevel optional libvolume-id-dev_0.103-1_i386.deb
 3e6999259a3b848ccdc0cdc2c7701f32 104402 debian-installer important udev-udeb_0.103-1_i386.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFaiHYFGfw2OHuP7ERAvgdAKCgwYojjhz40+zZbo66C1p/lKycGwCfa2h/
JfA8dYP3kDCvmi+6B/zEL0A=
=WTgF
-----END PGP SIGNATURE-----

Message #25 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Harald Staub <staub@switch.ch>

To: 401393@bugs.debian.org, 392623@bugs.debian.org

Subject: Previously working LVM setup mysteriously broken.

Date: Wed, 06 Dec 2006 08:48:10 +0100

I got this error message too. My workaround was to revert this patch:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392623
NAME="" for dm- devices confuses gnome-mount / hal


--- udev.rules.0        2006-11-27 00:22:36.000000000 +0100
+++ udev.rules  2006-12-05 17:37:33.000000000 +0100
@@ -97,5 +97,6 @@
 SUBSYSTEM=="aoe", KERNEL=="revalidate",        NAME="etherd/%k"

 # device mapper creates its own device nodes, so ignore these
+KERNEL=="dm-[0-9]*",           NAME=""
 KERNEL=="device-mapper",       NAME="mapper/control"


--- devfs.rules.0       2006-11-27 00:22:36.000000000 +0100
+++ devfs.rules 2006-12-06 07:45:02.000000000 +0100
@@ -148,5 +148,6 @@
 SUBSYSTEM=="aoe", KERNEL=="revalidate",        NAME="etherd/%k"

 # device mapper creates its own device nodes, so ignore these
+KERNEL=="dm-[0-9]*",           NAME=""
 KERNEL=="device-mapper",       NAME="mapper/control"


These settings are also needed in the initrd!

This is on an Intel Mac, i.e. with EFI, and with BIOS emulation. In this
case, partitioning is very restricted (no extended partitions, EFI itself
takes a partition). So I went with one LVM partition, also / is LVM, no
separate /boot.

Cheers
 Harry

Message #30 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Daniel Burrows <dburrows@debian.org>, Harald Staub <staub@switch.ch>

Cc: 401393@bugs.debian.org, 392623@bugs.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Wed, 6 Dec 2006 13:16:27 +0100

On Sat, Dec 02, 2006, Daniel Burrows wrote:
>   My system has a somewhat unusual setup: I'm using lvm on RAID1.  Sometime
> recently, lilo just quit working:
> daniel@jeeves:~$ sudo lilo
> Warning: COMPACT may conflict with LBA32 on some systems
> device-mapper: table ioctl failed: No such device or address
> Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed
>   This happens with all versions of lilo back to 7.1 (which is from before
> the computer in question existed).  Web searches turn up references to old
> bugs that prevented lilo from working with lvm2 systems.  But the disk
> configuration on this system hasn't changed since I built it and it's always
> used lilo, so that can't possibly be it.  The only thing I can think of is
> that maybe there's an incompatibility with recent 2.6.18 kernels; I don't
> have easy access to the console at the moment, though [0].

 Could you send a lilo run in verbose mode and your lilo.conf to the
 bug?  A "dmsetup ls" would be nice as well.

  Thanks,
-- 
Loïc Minier <lool@dooz.org>
 "I have no strong feelings one way or the other." -- Neutral President

Message #35 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Daniel Burrows <dburrows@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: Harald Staub <staub@switch.ch>, 401393@bugs.debian.org, 392623@bugs.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Wed, 06 Dec 2006 21:52:26 -0800

[Message part 1 (text/plain, inline)]

On Wed, Dec 06, 2006 at 01:16:27PM +0100, Loïc Minier <lool@dooz.org> was heard to say:
> On Sat, Dec 02, 2006, Daniel Burrows wrote:
> >   My system has a somewhat unusual setup: I'm using lvm on RAID1.  Sometime
> > recently, lilo just quit working:
> > daniel@jeeves:~$ sudo lilo
> > Warning: COMPACT may conflict with LBA32 on some systems
> > device-mapper: table ioctl failed: No such device or address
> > Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed
> >   This happens with all versions of lilo back to 7.1 (which is from before
> > the computer in question existed).  Web searches turn up references to old
> > bugs that prevented lilo from working with lvm2 systems.  But the disk
> > configuration on this system hasn't changed since I built it and it's always
> > used lilo, so that can't possibly be it.  The only thing I can think of is
> > that maybe there's an incompatibility with recent 2.6.18 kernels; I don't
> > have easy access to the console at the moment, though [0].
> 
>  Could you send a lilo run in verbose mode and your lilo.conf to the
>  bug?  A "dmsetup ls" would be nice as well.

  Sure.  I'd like to add that I object to the reclassification of this bug
as "normal", since it leads to a nonbootable system.  (I can only run because
I'm using a boot image that was previously installed and hasn't been wiped
out behind lilo's back; I can't use grub because it doesn't work with root on
RAID).

  I've also attached an strace, but at a very cursory scan, it looks like it
just repeats the above info (that an ioctl failed).  I'd analyze this stuff
more myself, but I'm about half asleep right now...

  dmsetup sez:

dmsetup: command not found

  Whoops, let's try that again.

system-var	(253, 1)
system-home	(253, 3)
system-swap	(253, 2)
system-root	(253, 0)

    Thanks,
  Daniel

[lilo.strace (text/plain, attachment)]

[lilo.out (text/plain, attachment)]

[lilo.conf (text/plain, attachment)]

Message #40 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Harald Staub <staub@switch.ch>

To: Loïc Minier <lool@dooz.org>

Cc: Daniel Burrows <dburrows@debian.org>, 401393@bugs.debian.org, 392623@bugs.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Thu, 07 Dec 2006 08:04:09 +0100

[Message part 1 (text/plain, inline)]

Loïc Minier wrote:
[...]
>  Could you send a lilo run in verbose mode and your lilo.conf to the
>  bug?  A "dmsetup ls" would be nice as well.

Ok, so here are lilo.conf, dmsetup ls, and some lilo output:
- lilo-t-v.bad
- lilo-t-v5.bad
- lilo-t-v.ok

Cheers
 Harry

[lilo.conf (text/plain, inline)]

boot=/dev/sda3
root=/dev/mapper/vg0-lv1
install=menu
map=/boot/map
delay=40
prompt
timeout=40
default=Linux

image=/vmlinuz
	label=Linux
	read-only
	append="lpj=10000000"
	initrd=/initrd.img

image=/vmlinuz.old
	label=LinuxOLD
	read-only
	optional
	initrd=/initrd.img.old

[dmsetup (text/plain, inline)]

vg0-lv5	(254, 5)
vg0-lv4	(254, 4)
vg0-lv3	(254, 3)
vg0-lv2	(254, 2)
vg0-lv1	(254, 1)
vg0-lv0	(254, 0)
cswap	(254, 6)

[lilo-t-v.bad (text/plain, inline)]

LILO version 22.6.1 (test mode), Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2004 John Coffman
Released 17-Nov-2004, and compiled at 15:50:43 on Nov 17 2006
Debian GNU/Linux

Warning: LBA32 addressing assumed
Reading boot sector from /dev/sda3
device-mapper: table ioctl failed: No such device or address
Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed

[lilo-t-v5.bad (text/plain, inline)]

LILO version 22.6.1 (test mode), Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2004 John Coffman
Released 17-Nov-2004, and compiled at 15:50:43 on Nov 17 2006
Debian GNU/Linux

Warning: LBA32 addressing assumed
raid_setup: dev=000C  rdev=0803
raid_setup returns offset = 00000000  ndisk = 0
 BIOS   VolumeID   Device
Reading boot sector from /dev/sda3
geo_get: device 0803, all=1
pf_hard_disk_scan: (8,0) /dev/sda
pf_hard_disk_scan: (8,1) /dev/sda1
lookup_dev:  number=0800
lookup_dev:  number=0800
pf:  dev=0800  id=06647869  name=/dev/sda
geo_query_dev: device=0800
lookup_dev:  number=0800
lookup_dev:  number=0300
exit geo_query_dev
bios_dev:  device 0800
lookup_dev:  number=0800
bios_dev:  masked device 0800, which is /dev/sda
bios_dev: geometry check found 0 matches
bios_dev: (0x80)  vol-ID=06647869  *PT=080770BC
bios_dev: PT match found 1 match (0x80)
pf_hard_disk_scan: (8,2) /dev/sda2
pf_hard_disk_scan: (8,3) /dev/sda3
pf_hard_disk_scan: (8,4) /dev/sda4
pf_hard_disk_scan: (254,0) /dev/dm-0
Caching device /dev/dm-0 (0xFE00)
pf_hard_disk_scan: (254,1) /dev/dm-1
Caching device /dev/dm-1 (0xFE01)
pf_hard_disk_scan: (254,2) /dev/dm-2
Caching device /dev/dm-2 (0xFE02)
pf_hard_disk_scan: (254,3) /dev/dm-3
Caching device /dev/dm-3 (0xFE03)
pf_hard_disk_scan: (254,4) /dev/dm-4
Caching device /dev/dm-4 (0xFE04)
pf_hard_disk_scan: (254,5) /dev/dm-5
Caching device /dev/dm-5 (0xFE05)
pf_hard_disk_scan: (254,6) /dev/dm-6
Caching device /dev/dm-6 (0xFE06)
  0800  06647869  /dev/sda
pf_hard_disk_scan: ndevs=1
  0800  06647869  /dev/sda
Resolve invalid VolumeIDs
Resolve duplicate VolumeIDs
  0800  06647869  /dev/sda
device codes (user assigned pf) = 0
device codes (user assigned) = 0
device codes (BIOS assigned) = 1
device codes (canonical) = 1
geo_query_dev: device=0803
lookup_dev:  number=0803
exit geo_query_dev
bios_dev:  device 0803
lookup_dev:  number=0800
bios_dev:  masked device 0800, which is /dev/sda
bios_dev: geometry check found 0 matches
bios_dev: (0x80)  vol-ID=06647869  *PT=080770BC
bios_dev: PT match found 1 match (0x80)
Device 0x0803: BIOS drive 0x80, 255 heads, 9729 cylinders,
               63 sectors. Partition offset: 51003432 sectors.
registering bios=0x80  device=0x0803
Using Volume ID 06647869 on bios 80
part_verify:  dev_nr=0803, type=1
geo_get: device 0800, all=1
geo_query_dev: device=0800
lookup_dev:  number=0800
exit geo_query_dev
bios_dev:  device 0800
lookup_dev:  number=0800
bios_dev:  masked device 0800, which is /dev/sda
bios_dev: geometry check found 0 matches
bios_dev: (0x80)  vol-ID=06647869  *PT=080770BC
bios_dev: PT match found 1 match (0x80)
Device 0x0800: BIOS drive 0x80, 255 heads, 9729 cylinders,
               63 sectors. Partition offset: 0 sectors.
registering bios=0x80  device=0x0800
Using Volume ID 06647869 on bios 80
lookup_dev:  number=0800
part_verify:  part#=3
lookup_dev:  number=FE01
device-mapper: table ioctl failed: No such device or address
Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed

[lilo-t-v.ok (text/plain, inline)]

LILO version 22.6.1 (test mode), Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2004 John Coffman
Released 17-Nov-2004, and compiled at 15:50:43 on Nov 17 2006
Debian GNU/Linux

Warning: LBA32 addressing assumed
Reading boot sector from /dev/sda3
Warning: '/proc/partitions' does not match '/dev' directory structure.
    Name change: '/dev/dm-0' -> '/dev/.static/dev/mapper/vg0-lv0'
    The kernel was compiled without DEVFS, but the '/dev' directory structure
        implements the DEVFS filesystem.
    Name change: '/dev/dm-1' -> '/dev/.static/dev/mapper/vg0-lv1'
    Name change: '/dev/dm-2' -> '/dev/.static/dev/mapper/vg0-lv2'
    Name change: '/dev/dm-3' -> '/dev/.static/dev/mapper/vg0-lv3'
    Name change: '/dev/dm-4' -> '/dev/.static/dev/mapper/vg0-lv4'
    Name change: '/dev/dm-5' -> '/dev/.static/dev/mapper/vg0-lv5'
    Name change: '/dev/dm-6' -> '/dev/mapper/cswap'
Using MENU secondary loader
Calling map_insert_data

Boot image: /vmlinuz -> boot/vmlinuz-2.6.18-rc7-686
Mapping RAM disk /initrd.img -> boot/initrd.img-2.6.18-rc7-686
Added Linux *

Boot image: /vmlinuz.old -> boot/vmlinuz-2.6.18-rc6-686
Mapping RAM disk /initrd.img.old -> boot/initrd.img-2.6.18-rc6-686
Added LinuxOLD

The boot sector and the map file have *NOT* been altered.

Message #45 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Harald Staub <staub@switch.ch>

Cc: Daniel Burrows <dburrows@debian.org>, 401393@bugs.debian.org, 392623@bugs.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Thu, 7 Dec 2006 09:33:33 +0100

        Hi,


 some trivia first:
 - Debian's lilo is patched with an unofficial patch for device-mapper
   support which was not updated since mid 2005
 - Debian just hits the problem, but it seems to be a common problem if
   I look at google queries; see also:
   https://launchpad.net/distros/ubuntu/+source/lilo-installer/+bug/23835

 The conclusion of most threads / (open) bug reports / forums is that
 you should not have /boot on md / lvm / whatever, but since this used
 to work, I suppose we are somehow bound to continue supporting this.

 Now, that said, my basic understanding is that something like this
 happens:
 - lilo builds a device map with device blocks major/minor ids
 - this map is filtered for duplicates
 - lilo then tries some device-mapper ioctls on the devices which fail

 The problem triggered by udev creating the /dev/dm-* devices is that
 lilo now prefers using these rather than the device-mapper entries
 (/dev/mapper/*).  The device-mapper ioctls fail for some reason on the
 /dev/dm-* devices (no idea why).

On Thu, Dec 07, 2006, Harald Staub wrote:
> pf_hard_disk_scan: (254,0) /dev/dm-0
> Caching device /dev/dm-0 (0xFE00)
> pf_hard_disk_scan: (254,1) /dev/dm-1
> Caching device /dev/dm-1 (0xFE01)

 Here lilo caches that would it want to do ioctls on a device with
 major/minor 0xFE00, it would do so on dev/dm-0.  Ditto for 0xFE01.

> lookup_dev:  number=FE01
> device-mapper: table ioctl failed: No such device or address
> Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed

 Here lilo tries to lookup the device mapper table of FE01, and it
 fails.  I can confirm it fails here, with a similar example of a device
 on LVM:
 bee:~# file /dev/dm-1
 /dev/dm-1: block special (254/1)
 bee:~# file /dev/mapper/bee--sata-refuge 
 /dev/mapper/bee--sata-refuge: block special (254/1)
 bee:~# dmsetup table /dev/mapper/bee--sata-refuge
 0 131072 linear 8:2 117440896
 bee:~# dmsetup table /dev/dm-1
 dm_task_set_name: Device /dev/dm-1 not found
 Command failed
 bee:~# dmsetup table bee--sata-refuge
 0 131072 linear 8:2 117440896
 bee:~# dmsetup table dm-1
 device-mapper: table ioctl failed: No such device or address
 Command failed

 So, if the device-mapper table errors you are seeing in the verbose
 lilo run are the fatal part and the problem we are trying to solve, the
 next steps I would see are:
 - check why running ioctls on dm-* devices fails (is it bad style?
   should we create /dev/mapper/dm-* devices?  why does it fail when we
   pass a full device path?); perhaps we can fix the problem at the
   libdevmapper level and make dmsetup table /dev/dm-1 work
 - if it's incorrect to use /dev/dm-* nowadays, or if we can't tell,
   blacklist /dev/dm-* from the lilo device map

 I happen to not be a kernel hacker, a lilo hacker, or anything close,
 so anyone with a clue can try the above; thanks!

 I hope the dm table ioctl is the real underlying problem, and not a
 bunch of confusing warnings.

   Bye,
-- 
Loïc Minier <lool@dooz.org>
 "I have no strong feelings one way or the other." -- Neutral President

Message #50 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Daniel Burrows <dburrows@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: Harald Staub <staub@switch.ch>, 401393@bugs.debian.org, 392623@bugs.debian.org, debian-boot@lists.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Thu, 07 Dec 2006 19:12:41 -0800

On Thu, Dec 07, 2006 at 09:33:33AM +0100, Loïc Minier <lool@dooz.org> was heard to say:
>  some trivia first:
>  - Debian's lilo is patched with an unofficial patch for device-mapper
>    support which was not updated since mid 2005
>  - Debian just hits the problem, but it seems to be a common problem if
>    I look at google queries; see also:
>    https://launchpad.net/distros/ubuntu/+source/lilo-installer/+bug/23835
> 
>  The conclusion of most threads / (open) bug reports / forums is that
>  you should not have /boot on md / lvm / whatever, but since this used
>  to work, I suppose we are somehow bound to continue supporting this.

  If that's the case, the installer team needs to print a much bigger
warning.  As of a month or two ago, they just say you can't use Grub for
boot-on-raid, but that Lilo works (that's how I got my system set up).

  As an irrelevant aside, I actually tried to set up a separate /boot with
grub and/or lilo, but neither seemed to be able to handle that configuration
at all (I don't remember why at the moment; I think it smelled like some weird
Epia idiosyncracy).

  Daniel

Message #55 received at 392623@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: "Daniel Burrows" <dburrows@debian.org>

Cc: Loïc Minier <lool@dooz.org>, "Harald Staub" <staub@switch.ch>, 401393@bugs.debian.org, 392623@bugs.debian.org, debian-boot@lists.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Fri, 8 Dec 2006 10:10:52 +0100 (CET)

On Fri, December 8, 2006 4:12, Daniel Burrows said:
> On Thu, Dec 07, 2006 at 09:33:33AM +0100, Loïc Minier <lool@dooz.org> was
> heard to say:
>>  some trivia first:
>>  - Debian's lilo is patched with an unofficial patch for device-mapper
>>    support which was not updated since mid 2005
>>  - Debian just hits the problem, but it seems to be a common problem if
>>    I look at google queries; see also:
>>    https://launchpad.net/distros/ubuntu/+source/lilo-installer/+bug/23835
>>
>>  The conclusion of most threads / (open) bug reports / forums is that
>>  you should not have /boot on md / lvm / whatever, but since this used
>>  to work, I suppose we are somehow bound to continue supporting this.
>
>   If that's the case, the installer team needs to print a much bigger
> warning.  As of a month or two ago, they just say you can't use Grub for
> boot-on-raid, but that Lilo works (that's how I got my system set up).

Don't mix up boot-on-raid and boot-on-device-mapper, they are two
different things using different kernel subsystems (md and dm).

boot-on-raid(1) works fine.

-- 
David Härdeman

Message #60 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool+debian@via.ecp.fr>

To: David Härdeman <david@hardeman.nu>

Cc: Daniel Burrows <dburrows@debian.org>, Harald Staub <staub@switch.ch>, 401393@bugs.debian.org, 392623@bugs.debian.org, debian-boot@lists.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Fri, 8 Dec 2006 10:31:14 +0100

On Fri, Dec 08, 2006, David Härdeman wrote:
> Don't mix up boot-on-raid and boot-on-device-mapper, they are two
> different things using different kernel subsystems (md and dm).

 Err, md is dm based, right?  You mean boot on LVM versus boot on MD?

 Or did you mean dmraid which is yet something else?

-- 
Loïc Minier <lool@dooz.org>
 "I have no strong feelings one way or the other." -- Neutral President

Message #65 received at 392623@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Loïc Minier <lool+debian@via.ecp.fr>

Cc: "Daniel Burrows" <dburrows@debian.org>, "Harald Staub" <staub@switch.ch>, 401393@bugs.debian.org, 392623@bugs.debian.org, debian-boot@lists.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Fri, 8 Dec 2006 11:19:12 +0100 (CET)

On Fri, December 8, 2006 10:31, Loïc Minier said:
> On Fri, Dec 08, 2006, David Härdeman wrote:
>> Don't mix up boot-on-raid and boot-on-device-mapper, they are two
>> different things using different kernel subsystems (md and dm).
>
>  Err, md is dm based, right?

Nope, see http://lwn.net/Articles/169140/ for example.

-- 
David Härdeman

Message #70 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Warren Turkal <wt@penguintechs.org>

To: 401393@bugs.debian.org

Cc: 392623@bugs.debian.org

Subject: plans

Date: Tue, 12 Dec 2006 23:46:20 -0700

Are there any plans for fixing this? Is a fix in progress?

I have several machines using lvm root, and I am willing to help in any way to 
get a fix developed and distributed. Please let me know what I can do to 
help.

Thanks,
wt
-- 
Warren Turkal (w00t)

Message #75 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: 392623@bugs.debian.org, 401393@bugs.debian.org

Subject: lilo should ignore /dev/dm-*?

Date: Thu, 28 Dec 2006 14:59:15 +0100

Hi,

we just had a discussion on IRC:

14:41 < pusling> Md: I haven't seen any comments from you on 392623 (I would
actually consider the side effects critical)
14:43 < Md> pusling: because it's not a bug in udev and I do not know enough dm
to comment on the issues in other packages
14:43 < Md> I think there is a consensus that lilo is broken
14:43 < aba> Md: does it only affect lilo-based installs?
14:44 < Md> grub works fine, if this is what you are asking
14:44 < pusling> aba: it affects root/boot on lvm (which the installer sets up
easily with udev 100, but upgrading to udev 103 makes it not work)
14:44 < pusling> grub won't boot on root on lvm
14:44 < Md> check the message from lool
14:45 < aba> hm, ok. That sounds like an RC-bug "somewhere", wherever that somewhere is
14:45 < pusling> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401393
14:45 < pusling> is the lilo bug
14:45 < pusling> but the bug is not in lilo according to vorlon
14:46 < Md> the problem is that 100 broke other things... I think we can safely
agree that all programs confused by the existence or non-existence of /dev/dm-*
devices are broken, and as a matter of personal taste I'd rather not have the
dm-* devices, but fixing lilo looks (?) easier
14:46 < Md> I can do either way, but I am not going to decide this myself
14:47 < Md> one argument in favour of the change is that it is what other distributions do
14:47 < Md> so it may be worth investigating how rhel and suse cope with lilo
and root on lvm
14:47 < Md> or else lilo could install a rules file to stop creating the
devices :-)
14:49 < pusling> mv lilo lilo.real ; echo -e #! /bin/sh\nrm -f
/dev/dm-*\nlilo.real > /sbin/lilo
14:49 < pusling> ;)
14:50 < Md> I can't see why it should be hard to teach lilo to ignore /dev/dm-*
anyway...
14:55 < aba> Md: well, that should be easy enough, yes ...

Summary is that it's probably easiest if lilo would just ignore
/dev/dm-* - is that ok from "it does not have other side-effects" as
well?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

Message #80 received at 392623@bugs.debian.org (full text, mbox, reply):

From: aroldan@fluidsignal.com

To: Andreas Barth <aba@not.so.argh.org>, 401393@bugs.debian.org

Cc: 392623@bugs.debian.org

Subject: Re: Bug#401393: lilo should ignore /dev/dm-*?

Date: Fri, 29 Dec 2006 22:21:19 -0500

Quoting Andreas Barth <aba@not.so.argh.org>:

> Summary is that it's probably easiest if lilo would just ignore
> /dev/dm-* - is that ok from "it does not have other side-effects" as
> well?

I'll check that but I think that's not a problem. If you are right, it 
will be implemented.

Thanks for the help.



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Message #85 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Harald Staub <staub@switch.ch>

Cc: Daniel Burrows <dburrows@debian.org>, 401393@bugs.debian.org, 392623@bugs.debian.org, control@bugs.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Wed, 31 Jan 2007 11:50:36 +0100

[Message part 1 (text/plain, inline)]

forwarded 401393 dm-devel@redhat.com
stop

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/401393>.

On Thu, Dec 07, 2006, Loïc Minier wrote:
>  - check why running ioctls on dm-* devices fails (is it bad style?
>    should we create /dev/mapper/dm-* devices?  why does it fail when we
>    pass a full device path?); perhaps we can fix the problem at the
>    libdevmapper level and make dmsetup table /dev/dm-1 work

 I've explained the problem in the hope of getting some answers on
 dm-devel@redhat.com in the attached message.

   Bye,
-- 
Loïc Minier <lool@dooz.org>

[Message part 2 (message/rfc822, inline)]

From: Loïc Minier <lool+redhat@via.ecp.fr>

To: dm-devel@redhat.com

Subject: Weird discrepancy between /dev/mapper/* and /dev/dm-* devices breaks lilo

Date: Wed, 31 Jan 2007 11:47:37 +0100

        Hi,

 When issuing the same dmsetup commands on two device nodes with the
 same major/minor, the results are puzzling:
 bee:~# file /dev/dm-1
 /dev/dm-1: block special (254/1)
 bee:~# file /dev/mapper/bee--sata-refuge
 /dev/mapper/bee--sata-refuge: block special (254/1)
 bee:~# dmsetup table /dev/mapper/bee--sata-refuge
 0 131072 linear 8:2 117440896
 bee:~# dmsetup table /dev/dm-1
 dm_task_set_name: Device /dev/dm-1 not found
 Command failed

 (Same problem with short names:)
 bee:~# dmsetup table bee--sata-refuge
 0 131072 linear 8:2 117440896
 bee:~# dmsetup table dm-1
 device-mapper: table ioctl failed: No such device or address
 Command failed


 This is a problem hitting lilo relatively hard as it has logic to
 ignore devices with the same major/minor; that is, if lilo sees "dm-1"
 first and then the corresponding /dev/mapper device, it will drop any
 reference to the mapper device.  As having /boot on RAID 1 for lilo
 requires calling "dmsetup table" on the root device, this breaks lilo
 for a lot of people.

 Of course, it would be possible to patch lilo to explicitely skip
 /dev/dm-* devices, but it seems this would be a workaround instead of
 the real fix.


 This is under 2.6.18 and libdevmapper 1.02.12-1.


 You can find more details in Debian bug
 <http://bugs.debian.org/401393>, the bug was triggered by the addition
 of the /dev/dm-* device in udev (see <http://bugs.debian.org/392623>),
 and affects other distributions as well,
 <https://launchpad.net/distros/ubuntu/+source/lilo-installer/+bug/23835>.


 (RAID 1 support in lilo comes from a third-party patch added in the
 Debian packaging.)

   Bye,
-- 
Loïc Minier <lool@dooz.org>

Message #90 received at 392623@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Harald Staub <staub@switch.ch>

Cc: Daniel Burrows <dburrows@debian.org>, 401393@bugs.debian.org, 392623@bugs.debian.org

Subject: Re: Previously working LVM setup mysteriously broken.

Date: Wed, 31 Jan 2007 11:57:50 +0100

On Thu, Dec 07, 2006, Loïc Minier wrote:
>  So, if the device-mapper table errors you are seeing in the verbose
>  lilo run are the fatal part and the problem we are trying to solve, the
>  next steps I would see are:
>  - check why running ioctls on dm-* devices fails (is it bad style?
>    should we create /dev/mapper/dm-* devices?  why does it fail when we
>    pass a full device path?); perhaps we can fix the problem at the
>    libdevmapper level and make dmsetup table /dev/dm-1 work
>  - if it's incorrect to use /dev/dm-* nowadays, or if we can't tell,
>    blacklist /dev/dm-* from the lilo device map

 Thinking about the problem again, I checked the dmsetup man page and
 saw that it mention "device_name" as a parameter to commands.  I think
 that this device_name is a different name space than device nodes under
 /dev; this just happen to be named with the same name.

 I think lilo can continue merging the devices with the same major
 minor, but the RAID 1 support code should not blindly use lilo's device
 names, it should translate major:minor into a device mapper
 "device_name" first, for example via "info":
 bee:~# file /dev/dm-1 
 /dev/dm-1: block special (253/1)
 bee:~# dmsetup info -c --noheadings -j 253 -m 1
 bee--sata-refuge:253:1:L--w:1:1:0:LVM-beM0G1UiiCSaWGi1RkcyX3EhGET9D7GbyLPU0wXiCsOswbyC2LoECortBYa3prWw
 bee:~# dmsetup table bee--sata-refuge
 0 131072 linear 8:2 117440896

-- 
Loïc Minier <lool@dooz.org>

Send a report that this bug log contains spam.