On Wed, Mar 31, 2010 at 09:54:59AM +0100, Ian Campbell wrote:
> On Wed, 2010-03-31 at 09:45 +0100, Keir Fraser wrote:
> > AFAIK that means that the read-only-ness is not being propagated up to
> > domU block layer by the xen_blockfront driver. I'm not sure exactly
> > what other possibilities there are, but if the kernel has been OOMing
> > processes then perhaps you're in a runlevel or mode, or even a kenrel
> > bug, in which rootfs is forced read-only for other reasons? There have
> > been bugs around OOM in the past, and really it's a kernel path that's
> > obviously best avoided! Any idea why the OOM occurred in the first
> > place?
>
> Root filesystems are often mounted with the "errors=remount-ro" option
> (is it the Debian default?). So it's possible this is a domU decision to
> go read-only, but the question remains as to what happened in the domU
> to trigger this decision, can an OOM do that? There might be something
> earlier in the domU dmesg?
Yes, it's the default, but it doesn't explain why I can't go *back* to rw.
remount-ro should be functionally equivalent to mount -o remount,ro /, but
something made the system think that the block device is read-only.
And, there's nothing out of the OOM context in dmesg, as in, nothing
mentions xvda explicitly, but here's the entire kernel log from the last
boot to the end. (Hopefully the list allows gzipped attachments, it's a lot
of text.)
--
2. That which causes joy or happiness.
oom.kern.log.gz
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home