On Tue, 2004-08-24 at 23:58, Greg KH wrote: > On Tue, Aug 24, 2004 at 11:12:16PM +0200, Martin Schlemmer [c] wrote: > > On Tue, 2004-08-24 at 03:04, John McCutchan wrote: > > > > > > Which then results in a panic as the dm volumes cannot be setup > > > > and no / found by kernel. So basically it seems like inotify > > > > mess with dm in some way or other - any quick ideas what it > > > > could be? > > > > > > > > > > This is very strange. 'inotify device opened' is printed when an app > > > opens /dev/inotify. Do you have code that is doing that? I am wondering > > > if inotify's MAJOR/MINOR is getting confused with device mappers. I > > > don't know how it could be happening since /dev/inotify has the kernel > > > assign it an available minor number, and its major number is the major > > > number for all misc char devices. > > > > > > > Ok, seems like this was my own stupidity - I used an static node in > > initramfs which the kernel assigned the minor of to inotify if compiled > > in (I did not know DM used dynamic minors) :/ Fixed it to use udev > > instead. > > > > I am wondering about two things though: > > 1) Should things like device-mapper that are many times boot critical > > use dynamic minors? Guess if we make an exception for one, somebody > > will always get some silly device to be boot critical :( So I'll > > imagine it should stay as is - maybe add some nice fat message > > somewhere? > > I don't see why a dynamic minor would not work properly, you've shown > how to get it to work already :) > Yeah, well - was more a retoric question anyhow :-) Seems also the klibc issue was rather a (l)user error, as -L seems to work now (not sure where I got -s for symlink ... bit too late already :/), or maybe its the older klibc I had, and I got the bins mixed up (could have sworn it said something about unknown operand for -L). Thanks, -- Martin Schlemmer
Attachment:
signature.asc
Description: This is a digitally signed message part