[PATCH] discover/udev.c: Added warning in system status log

[Jeremy Kerr]

Hi Lulu,

> For the user, when the device is mounted and displayed on the
> petitboot list (sda), they will not care whether the device has a
> partition (sda1); but when they tries to mount a new device (sdc),
> Due to duplicate UUID, it will not be mounted and will not be
> displayed any warning (although pb-discover.log has a record, but the
> user will not take the initiative to confirm this log), they will be
> confused whether the device or the system is malfunctioning.
> 
> 1) sda: shows a boot option < DEVTYPE=disk
> 2) sda1: is a duplicate of sda, skipped, no message displayed <
> DEVTYPE=partition
> 3) sdc: duplicate of sda, skipped, message is displayed <
> DEVTYPE=disk
> 4) sdc1: duplicate of sda, skipped, no message displayed <
> DEVTYPE=partition
> 
> udev_handle_block_add
> #111    typestr = udev_device_get_devtype(dev);
> 
> What do you think about using DEVTYPE to distinguish sdc and sdc1?

No, that's not suitable. It's pretty unusual for there to be a
filesystem on the base device and a partition. The reason this is
occurring is that the install image is reporting itself as both an
iso9660 device, *and* a MBR partition table. That's why we're seeing the
duplicates on the same device.

The regular scenario for discovered filesystem is just the partitions
carrying filesystems, and none on the top-level device. I assume you
still need warnings for that case too. If you only generate the message
when DEVTYPE == disk, then you'll miss those, and this code will only
work for these specific installer-type images.

> Only warnings are displayed on the disk because not all devices have
> partitions.
> Although it will be displayed 3 times on my machine, it can
> distinguish sdc and sdc1 under normal circumstances, right?
> 
> I want to use the boolean you mentioned below, but I haven't fully
> understood it yet, sorry...

My suggestion is to sort-of reverse the duplicate detection - and just
record in the first device (that provided a specific UUID) whether we've
warned about that UUID.

So, when we find the first duplicate (sda1, sdc, or sdc1 in your
examples), you generate the log message, and set ->dup_warn on the
discover_device for sda.

Then, subsequent duplicates do not generate a warning, because
->dup_warn is already set on the original duplicate (ie, sda).

However, this may not be sufficient for your example - I assume you
require the warning to be generated when the new device, sdc, is
attached. With this flow, it would be generated when we detect sda1,
so may not be obvious to indicate to the user what is happening when the
new virtual media device appears.

So, to implement it the way you're wanting here, it sounds like you're
going to have to implement a system for duplicate tracking - eg, by
keeping a enough info about the devices & UUIDs that you've seen,
separate from the main device set, so you can generate the warnings in
the way that you require (ie, warn once for a complete new device).

> > Yes, I understand there will be duplicates if you connect the same
> > filesytstem both locally and via virtual media. However, seeing the
> > same device (sdc in your logs) appear in three separate udev events
> > is unusual - we might want to investigate that.
> 
> Tracking the code, it is found that the device action of the first
> two sdc and sdc1 is "add", and the device action of the last two sdc
> and sdc is "change".

OK, that makes sense then, all sounds fine there.

Regards,


Jeremy