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

[Thomas Bächler]

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).

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.

> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20131126/034cb2c9/attachment-0001.asc>