Re: RFC: Possible (partial) solution for device persistence issue
Op 17-10-2006 om 16:36 schreef dann frazier: On Tue, Oct 17, 2006 at 11:59:15PM +0200, Geert Stappers wrote: Please provide names of such tools. (TIA) udev - see /dev/by-id, etc. Doing `udevinfo -e` got me: P: /block/hda N: hda S: disk/by-id/ata-IC25N020ATMR04-0_MRG108K1HJSLPH S: disk/by-path/pci-0.0001f000:ata-4-ide-0:0 E: ID_TYPE=disk E: ID_MODEL=IC25N020ATMR04-0 E: ID_SERIAL=MRG108K1HJSLPH E: ID_REVISION=MO1OAD4A E: ID_BUS=ata E: ID_PATH=pci-0.0001f000:ata-4-ide-0:0 P: /block/hda/hda1 N: hda1 S: disk/by-id/ata-IC25N020ATMR04-0_MRG108K1HJSLPH-part1 S: disk/by-path/pci-0.0001f000:ata-4-ide-0:0-part1 E: ID_TYPE=disk E: ID_MODEL=IC25N020ATMR04-0 E: ID_SERIAL=MRG108K1HJSLPH E: ID_REVISION=MO1OAD4A E: ID_BUS=ata E: ID_PATH=pci-0.0001f000:ata-4-ide-0:0 P: /block/hda/hda10 N: hda10 S: disk/by-id/ata-IC25N020ATMR04-0_MRG108K1HJSLPH-part10 S: disk/by-path/pci-0.0001f000:ata-4-ide-0:0-part10 S: disk/by-label/bootstrap E: ID_TYPE=disk E: ID_MODEL=IC25N020ATMR04-0 E: ID_SERIAL=MRG108K1HJSLPH E: ID_REVISION=MO1OAD4A E: ID_BUS=ata E: ID_PATH=pci-0.0001f000:ata-4-ide-0:0 E: ID_FS_USAGE=filesystem E: ID_FS_TYPE=hfs E: ID_FS_VERSION= E: ID_FS_UUID= E: ID_FS_LABEL=bootstrap E: ID_FS_LABEL_SAFE=bootstrap I think that by-path is the presistent thing I want (expect that it is long) Anyway: I hope that /dev/sda1 survives UUID=way-too-long-unique-string Thank you Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
On Wed, October 18, 2006 11:32, Geert Stappers said: P: /block/hda N: hda S: disk/by-id/ata-IC25N020ATMR04-0_MRG108K1HJSLPH S: disk/by-path/pci-0.0001f000:ata-4-ide-0:0 ... I think that by-path is the presistent thing I want (expect that it is long) I think in general the by-id path would be better since that'd still work if you plug the harddrive into a different port on the IDE controller or change controllers... As udev is always installed with current d-i, the necessary change would be to generate a fstab which uses the by-id paths instead of the UUID= or LABEL= stuff, like so: /dev/disk/by-id/ata-IC25N020ATMR04-0_MRG108K1HJSLPH / ext3 defaults 1 1 This approach requires little to no changes to initramfs scripts which do not (yet?) understand LABEL= and UUID= syntax (like the cryptoroot scripts) and makes it quite simple to see which disk fstab refers to (ls -al /dev/long-path). And of course I've already nagged Frans about it on IRC :) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
Op 16-10-2006 om 00:06 schreef Frans Pop: On Sunday 15 October 2006 23:45, Geert Stappers wrote: The thing I would like to see is that the _difference_ in device naming between d-i kernel plus fellows and installed kernel plus fellows is solved. See the discussions that we have had about this in the past. The culprit is the kernel/udev: that can load drivers in a different order any time. It is not something we can solve in the installer. The experts have said that using UUID is the best solution. I agree that it is extremely ugly. Dear Kernel developers, Your work is appriceated, but I have a request: Please allow reproducable hardware detection. As systemadministrator I can't affort having a disk that is one moment /dev/sda and the next reboot /dev/sdb. Having a fast booting system is great, having disks swapped not. Please prefer consistence above speed. Thank you for reading this humble plea. Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
On Tue, Oct 17, 2006 at 04:27:19PM +0200, Geert Stappers wrote: Op 16-10-2006 om 00:06 schreef Frans Pop: On Sunday 15 October 2006 23:45, Geert Stappers wrote: The thing I would like to see is that the _difference_ in device naming between d-i kernel plus fellows and installed kernel plus fellows is solved. See the discussions that we have had about this in the past. The culprit is the kernel/udev: that can load drivers in a different order any time. It is not something we can solve in the installer. The experts have said that using UUID is the best solution. I agree that it is extremely ugly. it is see very practical, see for example this usage example http://michael-prokop.at/blog/2006/08/11/stable-root-device-aka-uuid/ Dear Kernel developers, Your work is appriceated, but I have a request: Please allow reproducable hardware detection. As systemadministrator I can't affort having a disk that is one moment /dev/sda and the next reboot /dev/sdb. Having a fast booting system is great, having disks swapped not. the kernel _never_ guaranteed stable device nodes, that is an userspace policy. use the tools that provide that. Please prefer consistence above speed. Thank you for reading this humble plea. Geert Stappers edgy udev transforms the fstab to use plain uuids, to guarantee correct root recognition. i guess their installer also add uuid entries to the newly installed fstab - why is that not in d-i? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
Op 17-10-2006 om 17:10 schreef maximilian attems: On Tue, Oct 17, 2006 at 04:27:19PM +0200, Geert Stappers wrote: Dear Kernel developers, Your work is appriceated, but I have a request: Please allow reproducable hardware detection. As systemadministrator I can't affort having a disk that is one moment /dev/sda and the next reboot /dev/sdb. Having a fast booting system is great, having disks swapped not. the kernel _never_ guaranteed stable device nodes, that is an userspace policy. I should smile. In 1997 I had /dev/sda, which had SCSI target Id #3. When I added another disk, being target #2, that became /dev/sda And the original /dev/sda went into /dev/sdb rendering the system _unbootable_ So after about 10 years, is the answer use UUID. I should laugh ... use the tools that provide that. Please provide names of such tools. (TIA) Please prefer consistence above speed. Thank you for reading this humble plea. Geert Stappers edgy udev transforms the fstab to use plain uuids, to guarantee correct root recognition. i guess their installer also add uuid entries to the newly installed fstab - why is that not in d-i? -- maks Cheers Geert Stappers -- During system recovery provide the boot option: root=UUID=4a6aed11-42dd-4c82-81ce-8f469e93f210 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
On Tue, Oct 17, 2006 at 11:59:15PM +0200, Geert Stappers wrote: Please provide names of such tools. (TIA) udev - see /dev/by-id, etc. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
