[arch-projects] [mkinitcpio] [PATCH 2/2] resume: generate a udev rule for specifying device

[Dave Reisner]

On Tue, Nov 26, 2013 at 04:35:13PM +0100, Thomas Bächler wrote:
> Am 26.11.2013 16:22, schrieb Dave Reisner:
> >> * Linux loads, starts /init
> >> * Udev is started
> >> * Hard drive A is detected.
> >> * fsck is started, repairs the "dirty" root file system (and changes
> >> on-disk structures, clears the journal, ...)
> > 
> > Who/what triggered fsck here? Why is fsck being run before the udev
> > event queue is flushed?
> > 
> >> * Hard drive B is detected -> udev start the resume procedure.
> > 
> > ...
> 
> So, you're still using udevadm settle, which mitigates the situation
> most of the time - but it is no guarantee. Just because the udev queue
> is empty does not mean that all hardware is enumerated (look into
> people's inboxes for mails from Kay Sievers or Greg K-H for the full
> speech).

I'm the last person this needs to be explained to ;)

> Your patch does not keep udev from initiating the resume even when
> mkinitcpio started fsck'ing/mounting already. This is incorrect and
> dangerous behaviour.
> 
> > but I don't really think your earlier posted order of
> > events paints a realistic picture of what happens in early userspace.
> 
> Orly? Sure, only the USB examples will be easily reproducible due to the
> udevadm settle. But release these changes and wait for a day until some
> guy turns up and says he has a resume image on USB and now his data is
> corrupt.
> 

In other words, never underestimate the stupidity of users.

> > I'll ask Harald about this -- Dracut uses a very similar mechanism (but
> > a bit more complex/convoluted).
> 
> Nobody said this was easy to solve.
> 

Consider the patch shelved for now. It's not something I care about --
just thought I'd take a stab at fixing it for others.