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 <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President
