Debian Bug report logs - #401393
Previously working LVM setup mysteriously broken.

Toggle useless messages

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

From: Daniel Burrows <dburrows@debian.org>

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

Subject: Previously working LVM setup mysteriously broken.

Date: Sat, 02 Dec 2006 20:22:59 -0800

Package: lilo
Version: 1:22.6.1-9
Severity: grave

  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].

  Daniel

  [0] because the console is the TV, and right now my girlfriend is using
it to play video games :-P

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages lilo depends on:
ii  debconf                      1.5.9       Debian configuration management sy
ii  libc6                        2.3.6.ds1-8 GNU C Library: Shared libraries
ii  libdevmapper1.02             2:1.02.12-1 The Linux Kernel Device Mapper use
ii  mbr                          1.1.9-2     Master Boot Record for IBM-PC comp

lilo recommends no packages.

-- debconf information:
  liloconfig/fstab_broken:
  liloconfig/banner:
  liloconfig/liloconf_incompatible:
  lilo/bad_bitmap:
  liloconfig/use_lba32: true
  lilo/upgrade:
  liloconfig/liloconf_exists:
  liloconfig/configuring_base:
  lilo/runme: false
  liloconfig/use_current_lilo: true
  liloconfig/wipe_old_liloconf: false
  liloconfig/instruction:
  liloconfig/activate_error:
  liloconfig/select_bitmap: /boot/coffee.bmp
  liloconfig/lilo_error:
  lilo/new-config:
  liloconfig/odd_fstab:
  liloconfig/install_from_root_device: true
  liloconfig/make_active_partition: true
  liloconfig/maintitle:
  liloconfig/mbr_error:
  liloconfig/lilo_warning:
  liloconfig/install_mbr: false
  liloconfig/no_changes:

Message #12 received at 401393@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 #17 received at 401393@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 #22 received at 401393@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 #27 received at 401393@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 #32 received at 401393@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 #37 received at 401393@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

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

Cc: 401393@bugs.debian.org, Marco d'Itri <md@Linux.IT>, sjoerd@debian.org

Subject: Re: [staub@switch.ch: Bug#392623: Previously working LVM setup mysteriously broken.]

Date: Thu, 07 Dec 2006 12:41:16 +0100

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

Loïc Minier wrote:
> On Thu, Dec 07, 2006, Sjoerd Simons wrote:
>> In this case i'd say it's something lilo should work around by preferring
>> /dev/mapper/* devices.
> 
>  That's the workaround I proposed as well, but I'm not using lilo
>  anywhere and don't feel like I'm empowered to do some lilo hacking.  I
>  also suggested to check why ioctls that work no the same major/minor
>  fail against /dev/dm-* but succeed against /dev/mapper/*, as I think
>  making these succeed would also solve the bug.
> 

Attached is a log of a discussion I had with davidz and kay on irc.
Maybe that helps to understand this problem better.

Cheers,
Michael


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

[irc.log (text/x-log, inline)]

[Fr Okt 27 2006] [01:15:36] <mbiebl>	kay: hi
[Fr Okt 27 2006] [01:15:53] <kay>	mbiebl: hi
[Fr Okt 27 2006] [01:16:05] <mbiebl>	davidz and I discussed yesterday if it is correct to keep the /dev/dm-* devices.
[Fr Okt 27 2006] [01:16:21] <krh>	so what is libusual anyway?
[Fr Okt 27 2006] [01:16:23] <kay>	davidz: he should merge libususl with nash :)
[Fr Okt 27 2006] [01:16:25] <mbiebl>	Debian currently has a rule to suppress the creation of these devices.
[Fr Okt 27 2006] [01:16:52] <kay>	krh: a kernel solution to pick a driver for a device when they are competing, ugh ...
[Fr Okt 27 2006] [01:16:59] <davidz>	krh: it's uhm.. some weirdo hack so ub and usb-storage can share usb device quirks or something
[Fr Okt 27 2006] [01:17:14] <krh>	gah
[Fr Okt 27 2006] [01:17:20] 	 * davidz have no idea how pete got that past Linus
[Fr Okt 27 2006] [01:17:28] <krh>	it's upstream?
[Fr Okt 27 2006] [01:17:32] <davidz>	oh yeah
[Fr Okt 27 2006] [01:17:43] <kay>	mbiebl: well, it depends, there is no general rule
[Fr Okt 27 2006] [01:17:44] <davidz>	Linux got two (at least) usb storage device drivers
[Fr Okt 27 2006] [01:17:44] <mbiebl>	kay: I heard different opionions so far. 
[Fr Okt 27 2006] [01:17:50] <krh>	I don't see how my stack can possibly be rejected then
[Fr Okt 27 2006] [01:17:58] <davidz>	krh: heh, yup :-)
[Fr Okt 27 2006] [01:18:07] <mbiebl>	Some fellow DDs told me, that /dev/mapper/* is the canonical way nowadays.
[Fr Okt 27 2006] [01:18:09] <krh>	what's another stack?
[Fr Okt 27 2006] [01:18:16] <krh>	after all, it's all about choice!
[Fr Okt 27 2006] [01:19:01] <kay>	mbiebl: it's that way from the beginning, yes. but dm is just broken regarding hotplug, so there is no rule out there
[Fr Okt 27 2006] [01:19:01] 	 * krh ducks
[Fr Okt 27 2006] [01:19:04] <mbiebl>	Yet udev reports /dev/dm-* upon creation of dm devices.
[Fr Okt 27 2006] [01:19:20] <kay>	mbiebl: sure, that's what the kernel announces
[Fr Okt 27 2006] [01:19:44] <davidz>	mbiebl: long term it's not a very good idea to have > 1 programs writing in /dev ... it will take some time to get all this fixed though
[Fr Okt 27 2006] [01:20:00] <kay>	mbiebl: that the dm tools maintain their own nodes is just a bug of the lazy hackers ... :)
[Fr Okt 27 2006] [01:21:04] <mbiebl>	It would be good, to have a clear guideline what is supposed to be the right way (tm) and what not.
[Fr Okt 27 2006] [01:21:35] <kay>	mbiebl: the right way is to fix dm in its general operation, not the name of the nodes :)
[Fr Okt 27 2006] [01:22:12] <mbiebl>	Ok, so you also agree to keep the /dev/dm-* device nodes?
[Fr Okt 27 2006] [01:22:12] <kay>	mbiebl: it can't ignore hotplug these days, but it isn't designed with that in mind
[Fr Okt 27 2006] [01:22:59] <kay>	mbiebl: i keep them on SUSE, because I don't care if there are additional nodes
[Fr Okt 27 2006] [01:23:01] <mbiebl>	I'm not so much into the device mapper stuff, I only hear different opinions.
[Fr Okt 27 2006] [01:23:47] <kay>	mbiebl: but there is no rule, dm needs to intergrate with the hotplug world, until that's done there will be different ways to work around it ...
[Fr Okt 27 2006] [01:23:50] <mbiebl>	The d-m people tell me, that hal/g-m should be *fixed* to use /dev/mapper, and davidz tells me that /dev/dm* is the way to go.
[Fr Okt 27 2006] [01:24:21] <kay>	mbiebl: i would peraonally call /dev/mapper a silly bug :)
[Fr Okt 27 2006] [01:24:28] <mbiebl>	hehe
[Fr Okt 27 2006] [01:24:45] <davidz>	mbiebl: well... the dm people agree that fixing dm is the right approach
[Fr Okt 27 2006] [01:25:03] <kay>	mbiebl: it's a disk/blockdev, not a mapper :)
[Fr Okt 27 2006] [01:25:23] <kay>	mbiebl: and we should use /dev/disk/by-*/ for every blockdev
[Fr Okt 27 2006] [01:25:40] <kay>	mbiebl: calling dm tools to mess around in /dev is just crazy ...
[Fr Okt 27 2006] [01:26:00] <davidz>	so... basically agk (dm maintainer) says this
[Fr Okt 27 2006] [01:26:02] <davidz>	udev needs to completely ignore the 'add' event, and instead act on the 'change'
[Fr Okt 27 2006] [01:26:02] <davidz>	event.  Until the change event arrives under no circumstances should udev
[Fr Okt 27 2006] [01:26:02] <davidz>	attempt to open the dm device or query any dm device properties.  In future lvm2
[Fr Okt 27 2006] [01:26:02] <davidz>	and other applications will then wait until udev has completed processing the
[Fr Okt 27 2006] [01:26:02] <davidz>	'change' event before proceeding.  udev will then be able to assume full
[Fr Okt 27 2006] [01:26:03] <davidz>	responsibility for /dev/mapper - the 'change' event will cause the nodes to be
[Fr Okt 27 2006] [01:26:07] <davidz>	added to /dev.  There is no way to do this correctly in response to the existing
[Fr Okt 27 2006] [01:26:09] <davidz>	'add' event, because the dm properties udev needs to query are not yet defined
[Fr Okt 27 2006] [01:26:11] <davidz>	in-kernel at this point.  The 'change' event is the new signal that the
[Fr Okt 27 2006] [01:26:13] <davidz>	properties are now fully defined.
[Fr Okt 27 2006] [01:26:15] <davidz>	...
[Fr Okt 27 2006] [01:26:17] <davidz>	   and
[Fr Okt 27 2006] [01:26:19] <davidz>	Further, whenever the in-kernel device configuration changes significantly, a
[Fr Okt 27 2006] [01:26:21] <davidz>	new 'change' event will be issued, and udev will need to check the device
[Fr Okt 27 2006] [01:26:23] <davidz>	properties and may need to modify the corresponding /dev entries at that point.
[Fr Okt 27 2006] [01:26:25] <davidz>	...
[Fr Okt 27 2006] [01:26:57] <kay>	davidz: well, "add" can create the node, there is no problem with it
[Fr Okt 27 2006] [01:27:27] <kay>	davidz: only for today's hal, it may be an easy way to let hal fail on that event :)
[Fr Okt 27 2006] [01:27:28] <mbiebl>	kay: I don't have that much experiences in that regard (yet), I only see that hal with respect to luks is currently broken in Debian.
[Fr Okt 27 2006] [01:27:29] <davidz>	mbiebl, kay: so I do think medium-term we need to help distros here.... e.g. tell them to include http://lkml.org/lkml/2006/9/15/310   ... and what udev rules to use?
[Fr Okt 27 2006] [01:27:54] <davidz>	kay: so... perhaps sending a mail to the hal list about this would be useful?
[Fr Okt 27 2006] [01:27:54] <mbiebl>	And I'm looking for advise what the correct solution is.
[Fr Okt 27 2006] [01:28:00] <davidz>	then we can point people in that direction
[Fr Okt 27 2006] [01:28:34] <davidz>	kay: basically... I would make udev ignore 'add'... and only send an event to hal on 'change'.... how about that?
[Fr Okt 27 2006] [01:28:41] <kay>	the "change" is upstream, what do you mean with include? for older kernels?
[Fr Okt 27 2006] [01:28:46] <davidz>	yeah
[Fr Okt 27 2006] [01:28:59] <kay>	davidz: that does not work on coldplug, there will be no change event
[Fr Okt 27 2006] [01:29:00] <mbiebl>	upstream means .19?
[Fr Okt 27 2006] [01:29:19] <davidz>	kay: you know... if only udev shipped with predefined... rules... then this would be much easier :-)
[Fr Okt 27 2006] [01:29:21] 	 * davidz trolls
[Fr Okt 27 2006] [01:29:27] <davidz>	kay: right.. ok.. ugh.. coldplug... god point
[Fr Okt 27 2006] [01:29:34] <davidz>	good point even
[Fr Okt 27 2006] [01:30:17] <kay>	davidz: hehe, we should get a common initramfs too :)
[Fr Okt 27 2006] [01:31:03] <kay>	mbiebl: v2.6.19-rc1, yeah
[Fr Okt 27 2006] [01:32:45] <kay>	davidz: there is still the unresolved prob with snapshots, everybody needs to ignore them, but the dm tools can't get that info from the dev
[Fr Okt 27 2006] [01:33:11] <kay>	davidz: that's why the dm guys want to ignore everything
[Fr Okt 27 2006] [01:34:18] <kay>	davidz: but they seem to forget, that we want uuid/label links and we hotplug stuff and have more thatn fstab :)
[Fr Okt 27 2006] [01:34:27] <davidz>	kay: yeah
[Fr Okt 27 2006] [01:35:17] <kay>	davidz, mbiebl: so there is no real solution today, whatever you do, option you choose, something will break/not work
[Fr Okt 27 2006] [01:36:21] <kay>	davidz, mbiebl: snapshots or luks/persistent links, only one of them works with the current tools
[Fr Okt 27 2006] [01:39:28] <davidz>	kay: have anyone figured out what we need to fix?
[Fr Okt 27 2006] [01:39:34] <kay>	davidz: but we have a customer bug open, that needs to be solved, so someone is working on it already, we'll see ...
[Fr Okt 27 2006] [01:39:59] <kay>	davidz: the last idea was to use the "tagging" functionality of dm to tag stuff as private or whatever ...
[Fr Okt 27 2006] [01:40:38] <kay>	davidz: i can ask tomorrow, what's the current idea ...
[Fr Okt 27 2006] [01:41:47] <davidz>	kay: that would be appreciated, thanks
[Fr Okt 27 2006] [01:41:57] <davidz>	I need to fix it too for Fedora
[Fr Okt 27 2006] [01:42:11] <davidz>	and probably face the same kind of ppl as mbiebl is facing in the Debian community
[Fr Okt 27 2006] [01:43:08] <kay>	davidz: yeah, sure. i have that bug assigned too :)
[Fr Okt 27 2006] [01:43:37] <davidz>	so we're all in the same boat!
[Fr Okt 27 2006] [01:43:48] <davidz>	kay: anyway, thanks for asking around
[Fr Okt 27 2006] [01:44:32] <kay>	davidz: https://bugzilla.novell.com/show_bug.cgi?id=178321
[Fr Okt 27 2006] [01:44:45] <kay>	davidz: can you see it?
[Fr Okt 27 2006] [01:45:06] <davidz>	ydah
[Fr Okt 27 2006] [01:45:10] <davidz>	yeah even
[Fr Okt 27 2006] [01:45:17] <davidz>	I have a RH bug about it too
[Fr Okt 27 2006] [01:45:24] <davidz>	but, uh, it's not public
[Fr Okt 27 2006] [01:46:06] <kay>	I'll ask Jan tomorrow, he tried to patch the tools to give us the needed data ...
[Fr Okt 27 2006] [01:46:31] <davidz>	uhh, the Novell bugzilla asks for "Company" when I tried creating an account

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

Message #42 received at 401393@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 #47 received at 401393@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 #52 received at 401393@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 #57 received at 401393@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 #62 received at 401393@bugs.debian.org (full text, mbox, reply):

From: Warren Turkal <wt@penguintechs.org>

To: 401393@bugs.debian.org

Subject: normal severity?

Date: Mon, 11 Dec 2006 20:29:56 -0700

I was wondering why this bug is normal serverity when it causes
previously working systems to fail to boot. Is there any workaround for
this bug with root on LVM?

Thanks,
wt

Message #67 received at 401393@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 #72 received at 401393@bugs.debian.org (full text, mbox, reply):

From: aroldan@fluidsignal.com

To: Warren Turkal <wt@penguintechs.org>, 401393@bugs.debian.org

Cc: 401393@bugs.debian.org

Subject: Re: Bug#401393: normal severity?

Date: Thu, 14 Dec 2006 16:00:38 -0500

I'm preparing an upload with the latest LILO upstream version. It has 
some changes related to RAID1 problems. I can bring you the preliminar 
packages if you wish though.


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

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

From: Michel Meyers <steltek@tcnnet.com>

To: 401393@bugs.debian.org

Subject: Got the same issue

Date: Fri, 15 Dec 2006 11:36:53 +0100

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

Just adding myself here to receive bug notifications (hope that actually
works by adding a notice), I have the same issue than the first
submitter, LVM on RAID1 and lilo fails with:

device-mapper: table ioctl failed: No such device or address
Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed

Greetings,
       Michel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32) - GPGrelay v0.959

iD8DBQFFgnrH2Vs+MkscAyURAg9EAJoDI7mqYUWn1ACPpirRq+44N8GnGgCg9EYT
gceGtFd5XASNyJ85qNYT7UY=
=d29R
-----END PGP SIGNATURE-----

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

From: Warren Turkal <wt@penguintechs.org>

To: 401393@bugs.debian.org

Subject: info for those of us in the dark

Date: Sun, 17 Dec 2006 00:52:30 -0700

Could you please let us know an approximate ETA for getting 22.7.3 into the 
archive?

I also want to make a request to get it into Etch. I am running some machines 
that I wanted to settle onto Etch upon the release that need the update for 
this dev mapper problem.

wt
-- 
Warren Turkal (w00t)

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

From: Frans Pop <elendil@planet.nl>

To: 401393@bugs.debian.org, 401393-submitter@bugs.debian.org

Subject: Bug#401393: Previously working LVM setup mysteriously broken

Date: Mon, 18 Dec 2006 21:00:18 +0100

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

Looks like my BR http://bugs.debian.org/402511 against lvm-common is 
related to this issue.
The issue itself seems to be based in lvm2 and udev.

David Härdeman pointed me to 
https://bugzilla.novell.com/show_bug.cgi?id=178321
which may have a (partial) fix for this issue in
https://bugzilla.novell.com/show_bug.cgi?id=178321#c28

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

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

From: Sune Vuorela <debian@pusling.com>

To: 401393@bugs.debian.org

Subject: Previously working LVM setup mysteriously broken.

Date: Mon, 18 Dec 2006 21:48:59 +0100

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

Hi!

I have also just experiened this:
device-mapper: table ioctl failed: No such device or address
Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed

What I did: install etch with root-on-lvm from the rc1 installer.
Boot up. dist-upgrade to newest etch (udev 103, kernel 2.6.18-something...)
run lilo. Stuff works fine still.
Reboot.
Try run lilo again. No luck.
I did rm /dev/dm-* and then lilo succseeded.

(btw. why was this bug downgraded?)

/Sune
-- 
Man, do you know how may I forward to the processor?

First of all from the control tools within Flash 5.5 you need to boot from the 
BIOS of the memory but you either should overclock a monitor, or can never 
unmount the 2X EIDE directory to a proxy for booting a analogic TCP/IP file 
to a TCP/IP directory.

[Message part 2 (application/pgp-signature, inline)]

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

From: Daniel Burrows <dburrows@debian.org>

To: 401393@bugs.debian.org

Subject: Re: Bug#401393: Acknowledgement (Previously working LVM setup mysteriously broken.)

Date: Sat, 23 Dec 2006 09:04:26 -0800

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

  I noticed the NEWS.Debian item about RAID problems.  My problem is not
fixed with this version -- I have to remove /dev/dm-* to get lilo to work.

  Daniel

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

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

From: kronos@kronoz.cjb.net

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

Subject: lilo is confused by /dev/dm-*

Date: Sun, 24 Dec 2006 22:30:55 +0100

Package: lilo
Version: 1:22.7.3-1
Followup-For: Bug #401393


lilo is definetely confused by /dev/dm-* devices.

If I remove /dev/dm-0 (my root LV) lilo correcly opens
/dev/mapper/control and issues DM_TABLE_STATUS:

8870  open("/dev/mapper/control", O_RDWR|O_LARGEFILE) = 4
[...]
8870  ioctl(4, DM_TABLE_STATUS, 0x80793b0) = 0

Lilo issues the ioctl using the device name, which in case of /dev/dm-0
is not recognized by the kernel.

For example in my setup the LV is

/dev/mapper/main_vol-root

hence the name that shall be used is main_vol-root (dm-0 is not
recognized by the kernel!). 

The name that is passed to the library is created simply with strrchar
in order to isolate the file name from the full path
(01_devmapper.dpatch) and this name is used to call dm_task_run(). Now,
since lilo knows the device that has be used it could call
DM_TABLE_STATUS using the device number, but unfortunately dm_task_run()
doesn't support this (maybe lilo should be calling the ioctl by
itself?).

To recap:

struct dm_ioctl info;
...
strcpy(info.name, "dm-0");
ioctl(fd, DM_TABLE_STATUS, &info); /* FAILS */

strcpy(info.name, "main_vol-root");
ioctl(fd, DM_TABLE_STATUS, &info); /* WORKS */

stat("/dev/whatever", &buf);
info.dev = buf.st_rdev;
ioctl(fd, DM_TABLE_STATUS, &info); /* WORKS */

Luca

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)

Versions of packages lilo depends on:
ii  debconf                      1.5.3       Debian configuration management sy
ii  libc6                        2.3.6.ds1-4 GNU C Library: Shared libraries
ii  libdevmapper1.02             2:1.02.03-1 The Linux Kernel Device Mapper use
ii  mbr                          1.1.9-2     Master Boot Record for IBM-PC comp

lilo recommends no packages.

-- debconf information excluded

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

From: "Piotr Popieluch" <piotr@hand-ebs.com>

To: <401393@bugs.debian.org>

Date: Wed, 27 Dec 2006 13:43:04 +0100

Same problem here with Lilo 22.6.1 and 22.7.3

The problems first appeared after upgrading to the newest
initramfs-tools. The upgrade didn't work I had to uninstall all old
kernel images and reinstall the running kernel image. The problem was
probably caused earlier but I didn't use Lilo until the initramfs-tools.

The systems have Debian etch installed because stable doesn't support my
hardware.
I have used the Etch installer to make LVM2 in a mdraid setup.

Are there any workarounds? I've got 6 servers running etch in
lvm2+mdraid. Some of them are in production state now.....

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

From: "Piotr Popieluch" <piotr@hand-ebs.com>

To: <401393@bugs.debian.org>

Date: Wed, 27 Dec 2006 14:02:40 +0100

Sorry for bothering.

rm /dev/md-* 

Worked out for me. (big relieve)

Message #120 received at 401393@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 #125 received at 401393@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 #130 received at 401393@bugs.debian.org (full text, mbox, reply):

From: "Piotr Popieluch" <piotr@hand-ebs.com>

To: <401393@bugs.debian.org>

Subject: rm /dev/md-* doesn't work after reboot

Date: Sat, 30 Dec 2006 17:24:28 +0100

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

I'm getting confused now.

lilo didn't work, I removed /dev/md-* and it did work.
After a reboot lilo didn't work anymore... This is tested on two machines, lilo 22.7.3 and 22.6.1.

both machines: 2.6.18-3-686 #1 SMP, udev 0.103-1

lilo -t -v -v
LILO version 22.7.3 (test mode), Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2006 John Coffman
Released 11-Aug-2006, and compiled at 23:12:34 on Dec 20 2006
Debian GNU/Linux

Warning: LBA32 addressing assumed
raid_setup returns offset = 00000000  ndisk = 0
 BIOS   VolumeID   Device
Reading boot sector from /dev/sda
pf_hard_disk_scan: ndevs=2
  0800  FFFFFFFF  /dev/sda
  0810  273A7578  /dev/sdb
device codes (user assigned pf) = 0
device codes (user assigned) = 0
device codes (BIOS assigned) = 3
device codes (canonical) = 3
device-mapper: table ioctl failed: No such device or address
Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed


I have added a strace from both machines as attachement.

If there is anything I could do/check, please let me know.

Piotr Popieluch

[Message part 2 (text/html, inline)]

[lilo_on_appserv04 (application/octet-stream, attachment)]

[lilo_on_transwarp (application/octet-stream, attachment)]

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

From: Piotr Popieluch <piotr@quicknet.nl>

To: 401393@bugs.debian.org

Date: Sat, 30 Dec 2006 17:54:16 +0100

aargh,

I confused /dev/dm-* en /dev/md-*

sorry again.

Message #140 received at 401393@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 #145 received at 401393@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>

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

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

To: 401393@bugs.debian.org

Cc: Daniel Burrows <dburrows@debian.org>, Harald Staub <staub@switch.ch>, David Härdeman <david@hardeman.nu>, Michael Biebl <biebl@debian.org>, Warren Turkal <wt@penguintechs.org>, aroldan@fluidsignal.com, Michel Meyers <steltek@tcnnet.com>, Sune Vuorela <debian@pusling.com>, Piotr Popieluch <piotr@hand-ebs.com>, kronos@kronoz.cjb.net, control@bugs.debian.org

Subject: Please test the attached patch for against lilo 22.7.3-1.3

Date: Wed, 31 Jan 2007 15:22:13 +0100

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

tags 401393 + patch
stop

        Hi,

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

 Could people experiencing this bug please test the attached
 lilo_22.7.3-1.4.diff against lilo 22.7.3-1.3?

 I don't run lilo nor RAID 1, but I could verify that dmsetup() calls on
 major/minor work on my devices and that the patched lilo builds.

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

[lilo_22.7.3-1.4.diff (text/x-diff, attachment)]

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

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

To: Frans Pop <elendil@planet.nl>

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

Subject: Re: Bug#402511: Device nodes are not removed when devices are brought down

Date: Wed, 31 Jan 2007 15:27:34 +0100

        Hi,

 I see you commented in #401393 linking to #402511.

On Thu, Jan 18, 2007, Frans Pop wrote:
> Further analysis in http://bugs.debian.org/406697 has shown that the 
> reason the /dev/dm-* devices are not removed, is the fact that udevd has 
> already been killed by the time the crypto and lvm scripts are run on 
> shutdown and thus the events created by the kernel are no longer 
> processed as they would be if the system was running normally.

 So what's happening in #402511 is that some process is working on all
 devices such as /dev/mapper/* and /dev/dm-*, when it processes
 /dev/mapper/*, it causes some devices to disappear in the kernel, but
 /dev/mapper/* nodes and /dev/dm-* are not removed by udev.

 This is IMO different from #401393 where the problem seems to be that
 lilo decides to call dm operations on device names such as "dm-0" but
 this is never supported; instead, either dm-0 should be converted to
 device-mapper names or operations should be done via major/minor (which
 is the patch I just proposed).

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

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

From: Harald Staub <staub@switch.ch>

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

Cc: 401393@bugs.debian.org, Daniel Burrows <dburrows@debian.org>, David Härdeman <david@hardeman.nu>, Michael Biebl <biebl@debian.org>, Warren Turkal <wt@penguintechs.org>, aroldan@fluidsignal.com, Michel Meyers <steltek@tcnnet.com>, Sune Vuorela <debian@pusling.com>, Piotr Popieluch <piotr@hand-ebs.com>, kronos@kronoz.cjb.net, control@bugs.debian.org

Subject: Re: Please test the attached patch for against lilo 22.7.3-1.3

Date: Wed, 31 Jan 2007 17:34:02 +0100

>  This is a followup for Debian bug <http://bugs.debian.org/401393>.
> 
>  Could people experiencing this bug please test the attached
>  lilo_22.7.3-1.4.diff against lilo 22.7.3-1.3?
> 
>  I don't run lilo nor RAID 1, but I could verify that dmsetup() calls on
>  major/minor work on my devices and that the patched lilo builds.

Looks good :-)
As you can see above, this is without RAID 1, but LVM-only anyway. lilo runs
fine now and the machine boots, all without my udev-workaround (I also
rebuilt my initrd without the workaround).

Cheers
 Harry

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

From: Michel Meyers <steltek@tcnnet.com>

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

Cc: 401393@bugs.debian.org

Subject: Re: Please test the attached patch for against lilo 22.7.3-1.3

Date: Wed, 31 Jan 2007 17:11:18 +0100

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

Loïc Minier wrote:
>  Could people experiencing this bug please test the attached
>  lilo_22.7.3-1.4.diff against lilo 22.7.3-1.3?

Seems to be working on my box. At least I didn't get any error messages
when running lilo, and it rebooted properly. (That said, there was no
change to the kernel since the last time lilo worked, so the latter
might just be coincidence.)

Greetings,
       Michel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32) - GPGrelay v0.959

iD8DBQFFwL+o2Vs+MkscAyURAuStAJ9fgALLaalTm7JCiXnExiWWBOhvgwCfZ/e4
EgZI52hz/x64P+4XTBmEml4=
=54Hf
-----END PGP SIGNATURE-----

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

From: Luca Tettamanti <kronos@kronoz.cjb.net>

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

Cc: 401393@bugs.debian.org, Daniel Burrows <dburrows@debian.org>, Harald Staub <staub@switch.ch>, David Härdeman <david@hardeman.nu>, Michael Biebl <biebl@debian.org>, Warren Turkal <wt@penguintechs.org>, aroldan@fluidsignal.com, Michel Meyers <steltek@tcnnet.com>, Sune Vuorela <debian@pusling.com>, Piotr Popieluch <piotr@hand-ebs.com>, control@bugs.debian.org

Subject: Re: Please test the attached patch for against lilo 22.7.3-1.3

Date: Fri, 2 Feb 2007 18:56:05 +0100

Il Wed, Jan 31, 2007 at 03:22:13PM +0100, Loïc Minier ha scritto: 
> tags 401393 + patch
> stop
> 
>         Hi,
> 
>  This is a followup for Debian bug <http://bugs.debian.org/401393>.
> 
>  Could people experiencing this bug please test the attached
>  lilo_22.7.3-1.4.diff against lilo 22.7.3-1.3?

Tested here. Works fine with root on LVM.

Luca
-- 
"L'amore consiste nell'essere cretini insieme." -- P. Valery

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

From: Loic Minier <lool@dooz.org>

To: 401393-close@bugs.debian.org

Subject: Bug#401393: fixed in lilo 1:22.7.3-1.4

Date: Sat, 03 Feb 2007 09:32:04 +0000

Source: lilo
Source-Version: 1:22.7.3-1.4

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

lilo-doc_22.7.3-1.4_all.deb
  to pool/main/l/lilo/lilo-doc_22.7.3-1.4_all.deb
lilo_22.7.3-1.4.diff.gz
  to pool/main/l/lilo/lilo_22.7.3-1.4.diff.gz
lilo_22.7.3-1.4.dsc
  to pool/main/l/lilo/lilo_22.7.3-1.4.dsc
lilo_22.7.3-1.4_i386.deb
  to pool/main/l/lilo/lilo_22.7.3-1.4_i386.deb



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 401393@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Loic Minier <lool@dooz.org> (supplier of updated lilo 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: Sat,  3 Feb 2007 09:49:47 +0100
Source: lilo
Binary: lilo-doc lilo
Architecture: source i386 all
Version: 1:22.7.3-1.4
Distribution: unstable
Urgency: low
Maintainer: Andrés Roldán <aroldan@debian.org>
Changed-By: Loic Minier <lool@dooz.org>
Description: 
 lilo       - LInux LOader - The Classic OS loader can load Linux and others
 lilo-doc   - Documentation for LILO (LInux LOader)
Closes: 401393 403222
Changes: 
 lilo (1:22.7.3-1.4) unstable; urgency=low
 .
   * Non-maintainer upload with approval of maintainer for RC bug fix.
   * New patch, 02_devmapper-use-major-minor, to address device-mapper devices
     via major/minor instead of name for DM_DEVICE_TABLE;
     closes: #401393, #403222.
Files: 
 4ea64eeedc993ca9ef10997d166e130d 735 admin optional lilo_22.7.3-1.4.dsc
 230e5d201321b4a53880cfc1fa9f3a36 204316 admin optional lilo_22.7.3-1.4.diff.gz
 4294445ebc5ac5ae65b593c18c6cc5ae 357382 admin optional lilo_22.7.3-1.4_i386.deb
 d59d1aaff91b0368579fa1aa32085eae 344020 doc optional lilo-doc_22.7.3-1.4_all.deb

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

iD8DBQFFxFTd4VUX8isJIMARAmDGAJ4gmjQX1Tuy6VC5C+8pz3eKLIhahgCdE4L5
lAXsaRiS05VM4ivdSsJbExk=
=kH4R
-----END PGP SIGNATURE-----

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

From: Loic Minier <lool@dooz.org>

To: 401393-close@bugs.debian.org

Subject: Bug#401393: fixed in lilo 1:22.6.1-9.3

Date: Sat, 03 Feb 2007 09:32:03 +0000

Source: lilo
Source-Version: 1:22.6.1-9.3

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

lilo-doc_22.6.1-9.3_all.deb
  to pool/main/l/lilo/lilo-doc_22.6.1-9.3_all.deb
lilo_22.6.1-9.3.diff.gz
  to pool/main/l/lilo/lilo_22.6.1-9.3.diff.gz
lilo_22.6.1-9.3.dsc
  to pool/main/l/lilo/lilo_22.6.1-9.3.dsc
lilo_22.6.1-9.3_i386.deb
  to pool/main/l/lilo/lilo_22.6.1-9.3_i386.deb



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 401393@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Loic Minier <lool@dooz.org> (supplier of updated lilo 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: Sat,  3 Feb 2007 09:22:23 +0100
Source: lilo
Binary: lilo-doc lilo
Architecture: source i386 all
Version: 1:22.6.1-9.3
Distribution: testing-proposed-updates
Urgency: high
Maintainer: Andrés Roldán <aroldan@debian.org>
Changed-By: Loic Minier <lool@dooz.org>
Description: 
 lilo       - LInux LOader - The Classic OS loader can load Linux and others
 lilo-doc   - Documentation for LILO (LInux LOader)
Closes: 401393 403222
Changes: 
 lilo (1:22.6.1-9.3) testing-proposed-updates; urgency=high
 .
   * Non-maintainer upload with approval of maintainer targetted at
     testing-proposed-updates for RC bug fix.
   * New patch, 02_devmapper-use-major-minor, to address device-mapper devices
     via major/minor instead of name for DM_DEVICE_TABLE;
     closes: #401393, #403222.
Files: 
 c7c2cba6879583621a899ded75263549 735 admin optional lilo_22.6.1-9.3.dsc
 aa1316ed4a10a5f07a441419551039f6 203220 admin optional lilo_22.6.1-9.3.diff.gz
 dcb436419d8d4e6b2adedcb75f4dd6f7 362776 admin optional lilo_22.6.1-9.3_i386.deb
 89a66e08cc7637361c03f83ddb844b74 343730 doc optional lilo-doc_22.6.1-9.3_all.deb

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

iD8DBQFFxFKfmEvTgKxfcAwRArAhAJ0eiWUtWdTB+Lbw5B148co/Au2RxACgmD3M
aGytC2Mm788wrlzp1keE2LM=
=nmVA
-----END PGP SIGNATURE-----

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

From: Andrés Roldán <aroldan@debian.org>

To: johninsd@gmail.com, 401393@bugs.debian.org

Subject: [Fwd: Bug#401393: Please test the attached patch for against lilo 22.7.3-1.3]

Date: Tue, 20 Feb 2007 15:24:57 -0500

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

Hi John, please consider to merge this patch to LILO source. It has been 
sent for a Debian user. For more details about this problem, please 
refer to http://bugs.debian.org/401393

Thanks in advance,

Sincerely,

Andrés Roldán
Debian Developer
Key-ID: 0xb29396eb

[Bug#401393: Please test the attached patch for against lilo 22.7.3-1.3 (message/rfc822, inline)]

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

To: 401393@bugs.debian.org

Cc: Daniel Burrows <dburrows@debian.org>, Harald Staub <staub@switch.ch>, David Härdeman <david@hardeman.nu>, Michael Biebl <biebl@debian.org>, Warren Turkal <wt@penguintechs.org>, aroldan@fluidsignal.com, Michel Meyers <steltek@tcnnet.com>, Sune Vuorela <debian@pusling.com>, Piotr Popieluch <piotr@hand-ebs.com>, kronos@kronoz.cjb.net, control@bugs.debian.org

Subject: Bug#401393: Please test the attached patch for against lilo 22.7.3-1.3

Date: Wed, 31 Jan 2007 15:22:13 +0100

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

tags 401393 + patch
stop

        Hi,

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

 Could people experiencing this bug please test the attached
 lilo_22.7.3-1.4.diff against lilo 22.7.3-1.3?

 I don't run lilo nor RAID 1, but I could verify that dmsetup() calls on
 major/minor work on my devices and that the patched lilo builds.

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

[lilo_22.7.3-1.4.diff (text/x-diff, attachment)]

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

From: Andrés Roldán <aroldan@debian.org>

To: 401393-close@bugs.debian.org

Subject: Bug#401393: fixed in lilo 1:22.8-1

Date: Thu, 22 Feb 2007 23:17:04 +0000

Source: lilo
Source-Version: 1:22.8-1

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

lilo-doc_22.8-1_all.deb
  to pool/main/l/lilo/lilo-doc_22.8-1_all.deb
lilo_22.8-1.diff.gz
  to pool/main/l/lilo/lilo_22.8-1.diff.gz
lilo_22.8-1.dsc
  to pool/main/l/lilo/lilo_22.8-1.dsc
lilo_22.8-1_i386.deb
  to pool/main/l/lilo/lilo_22.8-1_i386.deb
lilo_22.8.orig.tar.gz
  to pool/main/l/lilo/lilo_22.8.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 401393@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andrés Roldán <aroldan@debian.org> (supplier of updated lilo 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: Thu, 22 Feb 2007 22:52:37 +0000
Source: lilo
Binary: lilo-doc lilo
Architecture: source i386 all
Version: 1:22.8-1
Distribution: unstable
Urgency: low
Maintainer: Andrés Roldán <aroldan@debian.org>
Changed-By: Andrés Roldán <aroldan@debian.org>
Description: 
 lilo       - LInux LOader - The Classic OS loader can load Linux and others
 lilo-doc   - Documentation for LILO (LInux LOader)
Closes: 396487 399057 400150 401393 403222 404409 406543 407697 407847 408576
Changes: 
 lilo (1:22.8-1) unstable; urgency=low
 .
   * New upstream release.
   * Acknowledging NMUs, big thanks guys.
     Closes: #396487, #399057, #400150, #404409, #406543, #408576
     Closes: #407847, #407697, #401393, #403222
   * debian/patches/{02_makefile-adds.dpatch,07_devfs_msg.dpatch}:
     - Updated to fit new version.
   * debian/patches/17_dont_scan_udev.dpatch:
     - Not longer applied as upstream already managed this problem.
Files: 
 a01bd814d0f48b3881aea37d7d0ea91c 725 admin optional lilo_22.8-1.dsc
 3111b5f52cc0dc96ebe8903702a9d29f 449315 admin optional lilo_22.8.orig.tar.gz
 7957c2c462e3a4d677792ed0ca2f666c 204636 admin optional lilo_22.8-1.diff.gz
 26a3ca815a0a200da94aebaedc182b9d 364974 admin optional lilo_22.8-1_i386.deb
 3971590a51c8770e7b1f478bbd9e9381 226734 doc optional lilo-doc_22.8-1_all.deb

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

iD8DBQFF3iBQ2OByS7KTlusRAkN4AKClKaU/BOJN7zX5O0W/ltNohb+tMQCcCvV/
L8y5OXk/smBYAjcUEbFjM9E=
=mntA
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.