On 09/26/2011 04:04 PM, richard -rw- weinberger wrote: > Dan, > > On Mon, Sep 26, 2011 at 6:27 PM, Dan Bassett<dbass...@oreilly.com> wrote: > >> I'm having issues when using cow files with CentOS6 system images. It >> is specific to CentOS6. When I tried with a debian image built with >> debootstrap, the system booted just fine. I am experiencing this issue >> both with a custom built UML kernel as well as the kernel I obtained >> from the debian repository (2.6.32-1um-4+34squeeze1) >> > Is the issue related to CentOS 6 or udev? > IOW does the same udev version work on e.g. Debian? > Actually It looks like udev isn't even installed on the Debian box, it must have a static /dev. I think I may have assumed that this image built with debootstrap was more like a regular debian install than it actually is. That doesn't really answer the question of why not specifying the backing storage file on the kernel command line would cause udev to hang, though. > >> The issue I am experiencing is that during the boot process, udev hangs >> forever and the boot process does not complete. It only occurs when I >> use a cow file by specifying just the cow file on the command line like >> "ubd0=cow_fs" rather than "ubd0=cow_fs,root_fs". When I specify both >> the cow file and the backing file, the problem doesn't happen. I am >> able to specify ubd0 either way with a debian image and the system boots >> as expected. I have tried editing the appropriate rc script in the >> CentOS6 image to take udev out of the boot process, and the system >> boots, but has problems related to udev not running. >> > Can you find out _where_ udev hangs? > Is it a endless loop? A blocking system call? > > I did some digging just now and found that in CentOS6, udev is initialized using a script at /sbin/start_udev. I began putting echo statements here and there trying to narrow down where things were actually getting stuck and I found that it always happens at a "udevadm" command, and usually it's at a "udevadm settle". I honestly don't know enough about udev and/or the uml cow format to make an educated (or even uneducated) guess as to why those particular commands hang. If you have suggestions about other methods I could use to glean more debugging information, I would be happy to investigate further.
I could just potentially throw up my hands, say "forget it" and go with a static /dev since I don't need a udev controlled /dev for this particular application, but it would be nice to debug this for future UML users all over the world :-) ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
