Debian Bug report logs -
#401393
Previously working LVM setup mysteriously broken.
Reported by: Daniel Burrows <dburrows@debian.org>
Date: Sun, 3 Dec 2006 04:33:06 UTC
Severity: serious
Tags: patch
Merged with 403222
Found in versions lilo/1:22.6.1-9, lilo/1:22.7.3-1
Fixed in versions lilo/1:22.7.3-1.4, lilo/1:22.6.1-9.3, lilo/1:22.8-1
Done: Andrés Roldán <aroldan@debian.org>
Bug is archived. No further changes may be made.
Full log
Message #37 received at 401393@bugs.debian.org (full text, mbox, reply):
[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)]
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Sun Aug 20 17:36:10 2023;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.