On 09/26/2011 05:16 PM, Dan Bassett wrote:
> 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 :-)
>
I did some more digging after finding some more debugging flags for
start_udev and I have more information today. After serializing udev's
startup process, it looks like the boot process always hangs in the same
spot. During the processing of the persistent storage rules that ship
with udev, the following rule is encountered:
KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
This results in /sbin/blkid being run for ubd0/a as such:
util_run_program: '/sbin/blkid -o udev -p /dev/.tmp-block-98:0' started
This is where it hangs. From the blkid man page:
"The blkid program is the command-line interface to working with
libblkid(3) library. It can determine the type of content (e.g.
filesystem, swap) a block device holds, and also attributes
(tokens, NAME=value pairs) from the content metadata (e.g. LABEL
or UUID fields)."
So it sounds like udev is trying to use blkid to read metadata from
ubd0/a and is failing. Again, I don't know what goes on with the
internals of the cow filesystem, so I don't know how specifying the
backing store versus not specifying it would make a difference here.
It's my understanding that the cow file contains the information for the
backing store in a header of some sort and the kernel just takes care of
opening the backing file and presenting the two to the system as ubd0/a.
Dan
------------------------------------------------------------------------------
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
