On Mon, May 19, 2014 at 10:03:47PM +0800, WANG Chao wrote:
On 05/19/14 at 08:21am, Vivek Goyal wrote:
> On Mon, May 19, 2014 at 03:45:27PM +0800, WANG Chao wrote:
>
> [..]
> > > IIUC, if for whatever reason some dracut service fails, systemd will
> > > continue to boot and if need be fail much later and put user into
> > > emergecny shell.
> > >
> > > That means if we fall into kdump emergency handler, we have already
> > > tried to run dracut-initqueue already. And either it succeeded or it
> > > failed.
> >
> > No, this is not right. Error could happen at any point of the boot
> > process. We can't guarantee dracut-initqueue is already started when
> > drop into kdump error handler.
>
> Does current code do that? I did a quick grep of current code and could
> not see emergency hanlder being invoked early.
In this context, "early" is a relative word. By "early", I mean
earlier
than dracut-initqueue.
>
> So that means that emergency handler will be invoked much later, even if
> error happens before dracut-initqueue. And that also means that
> dracut-initqueue will be either run by then or failed by then.
>
> So are you able to reproduce this that you fall into kdump handler and
> dracut-initqueue has not run yet. Can you let me know how do you get
> there. Or you are just future proofing the code.
I actually run into this issue when testing it in my kvm guest.
kdump.conf is configured as the following:
ext4 /dev/sda1
path /
default dump_to_rootfs
(rootfs is a lvm device)
After appling my error handler patchset and rebuilding the kdump
initramfs, I corrupted the filesystem of /dev/sda1 and crash the system.
And when systemd tried to mount the corrupted filesystem of /dev/sda1
and failed right away, systemd isolated to emergency service (kdump
error handler) and ran the error handler script. At this point, the
root device isn't brought up. I looked up the systemd boot log, and I
found dracut-initqueue service was not even started.
The thing is /dev/sda1 is brought up by udev rules, but lvm devices are
brought up by dracut-initqueue.service. So when /dev/sda1 is up, systemd
will try to mount it rigtht away, it won't wait for dracut-initqueue. As
for lvm root device, it will indirectly wait for dracut-initqueue,
because the device is brought up there.
Ok, so if you are dumping to a non-root fs, it is possible that we mount
that device first and fail before dracut-initqueue runs. It is kind of
odd but you are running into this issue so it is definitely happening.
So I am fine with trying to start dracut-initqueue before starting
sysroot.mount. Please repost your patch series.
Thanks
Vivek