[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: udev causing data loss?



On Saturday 15 November 2008, lee <lee@yun.yagibdah.de> wrote about 'Re: 
udev causing data loss?':
>On Sat, Nov 15, 2008 at 01:13:15PM -0600, Boyd Stephen Smith Jr. wrote:
>> so the USB disk that you left in the system might be assigned a name
>> before your SCSI bus.  Any of your two SCSI buses and one SATA bus
>> could be assigned name(s) first and this could vary from boot to
>> boot.
>
>Hm. What's the priority of detecting USB devices? You could have
>several disks on USB ...

There's no priorities.  The kernel assigns names to all the device it can 
initially see, and if the kernel thinks there can be other devices to ask 
all of them (at roughly the same time) to enumerate said devices.  As it 
gets responses, it assigns more names and sends out more probes, until it 
can see no more devices.  During this process it subscribes to and may 
receive hotplug events, which cause more names to be assigned and possibly 
more probes to be issued.

>> >If that is true, how does the user, how does the system know which
>> >disk is which one?
>>
>> Well, the system assigns those names as it detects devices.  It gets
>> some input from the user via their udev configuration.
>
>But I don't have an udev configuration, not one I made myself. I was
>thinking udev is to make things working right automatically ...

The default, core udev rule is to use the kernel's name for the device.  
This is supplemented with rules under /etc/udev/rules.d, which debian's 
udev package populates and the user can add files to.

>> The system has no notion of "should be".  The system uses the device
>> name you list in /etc/fstab.  It's the administrator's responsibility
>> to make sure that's what should be referred to.
>
>How can he do that without a way of telling which device is which,
>under whatever circumstances?

By communicating how they identify the device to the kernel via udev rules 
and using the assigned name.  Most devices could be identified by model # 
and/or serial #, partitions get uuids when they are created, you can also 
specify by the bus type and address.  There are tools to have the kernel 
enumerate all enumerate all the attributes of a device that it can 
observe, and up to the user to since which of these they can also use to 
identify the device.

>And if that is so, why does the 
>installer write an /etc/fstab with device names in it?

It's old code, it works much of the time (even now), and editing udev rules 
in the installer could be bad (you'd want to udevtrigger/udevsettle and 
then have the installer rescan after adding a rule).

For debootstrap installs, you have to roll your own /etc/fstab.

ISTR an Ubuntu install (and Ubuntu's installer is, or at least was at this 
time, based on d-i) that did write UUIDs to my /etc/fstab.

>That would 
>appear as a sure way to eventually brake things if someone plugs in an
>USB drive or unplugs it after installing. It might work on the first
>and second and fifth reboot and suddenly stop working, leaving him
>with an unbootable system and no clue what might have gone wrong.

Certainly possible.  I would not be averse to d-i creating a udev rules 
file, properly commented, and using the resulting names in /etc/fstab.  
But, I don't know enough about d-i, nor do I really have the time to make 
such a change.

Also, I could be very wrong, but I think udev is still optional in etch.  I 
think you could still use devfs.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: