RFC: handling of external usb devices
Hello,
I'd like to ask for your comments about handling of external usb devices on grml.
As you might know mounting usb pens on grml is possible via running 'mount /mnt/external1' (corresponding to /dev/sda1) and 'mount /mnt/external' (corresponding to /dev/sda).
As stated in a mail by Tong to the grml user mailinglist the problems start with multiple devices or devices with several partitions on it. I'd like to improve usability and handling of it therefore.
Thanks for input goes to Tong and Alexander Steinboeck, please read on for details about my solution.
################################################################################ /mnt/external[1] will be left without any changes, we will stay completely backwards compatible. Additionally we will create /dev/usb-sd* devices via udev rules like:
# cat /etc/udev/usbpen.rules SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", SYMLINK+="usb-%k", GROUP="users", NAME="%k" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/bin/mkdir -p /mnt/usb-%k" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/bin/sleep 2" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/usr/sbin/create_mnt_labels" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/usr/sbin/rebuildfstab -r -u 1000 -g 1000" ACTION=="remove", KERNEL=="sd[a-z]*", RUN+="/usr/sbin/rebuildfstab -r -u 1000 -g 1000" ACTION=="remove", KERNEL=="sd[a-z]*", RUN+="/bin/rmdir /mnt/usb-%k", OPTIONS="last_rule"
So we have the following devices available when plugging in an usb pen with 4 partitions on it:
# ls -la /dev/usb* /dev/external* /dev/sd* lrwxrwxrwx 1 root root 3 2006-09-03 17:25 /dev/external -> sda lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/external1 -> sda1 lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/external2 -> sda2 lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/external3 -> sda3 lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/external4 -> sda4 brw-rw---- 1 root users 8, 0 2006-09-03 17:25 /dev/sda brw-rw---- 1 root users 8, 1 2006-09-03 17:25 /dev/sda1 brw-rw---- 1 root users 8, 2 2006-09-03 17:25 /dev/sda2 brw-rw---- 1 root users 8, 3 2006-09-03 17:25 /dev/sda3 brw-rw---- 1 root users 8, 4 2006-09-03 17:25 /dev/sda4 lrwxrwxrwx 1 root root 3 2006-09-03 17:25 /dev/usb-sda -> sda lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/usb-sda1 -> sda1 lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/usb-sda2 -> sda2 lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/usb-sda3 -> sda3 lrwxrwxrwx 1 root root 4 2006-09-03 17:25 /dev/usb-sda4 -> sda4
According to that we will have the following directories available in /mnt:
# ls -lad /mnt/[eu]* drwxr-xr-x 2 root root 4096 2006-03-08 19:55 /mnt/external/ drwxr-xr-x 2 root root 4096 2006-03-08 19:55 /mnt/external1/ drwxr-xr-x 2 root root 4096 2006-09-03 17:25 /mnt/usb-sda/ drwxr-xr-x 2 root root 4096 2006-09-03 17:25 /mnt/usb-sda1/ drwxr-xr-x 2 root root 4096 2006-09-03 17:25 /mnt/usb-sda2/ drwxr-xr-x 2 root root 4096 2006-09-03 17:25 /mnt/usb-sda3/ drwxr-xr-x 2 root root 4096 2006-09-03 17:25 /mnt/usb-sda4/
As /dev/sda4 contains a labeled filesystem the script /usr/sbin/create_mnt_labels will create a new directory in /mnt:
# vol_id /dev/sda4 ID_FS_USAGE=filesystem ID_FS_TYPE=xfs ID_FS_VERSION= ID_FS_UUID=dc79eb17-9f98-49c7-9cfc-10d8fd279215 ID_FS_LABEL=foobar ID_FS_LABEL_SAFE=foobar # ls -la /mnt/foobar total 8 drwxr-xr-x 2 root root 4096 2006-09-03 18:05 ./ drwxr-xr-x 24 root root 4096 2006-09-03 18:05 ../
So mounting via label is possible therefore too with root-permissions:
# mount -L foobar /mnt/foobar
/etc/fstab will be updated as well (see the udev rule above, 2 seconds delay so we really catch all devices) and therefore will look like:
# cat /etc/fstab [...] # Added by GRML /dev/hda1 /mnt/hda1 ntfs noauto,nouser,dev,suid,exec,ro,umask=000,uid=1000,gid=1000 0 0 # Added by GRML /dev/sda1 /mnt/sda1 vfat noauto,nouser,dev,suid,exec,umask=000,uid=1000,gid=1000 0 0 # Added by GRML /dev/sda2 /mnt/sda2 vfat noauto,nouser,dev,suid,exec,umask=000,uid=1000,gid=1000 0 0 # Added by GRML /dev/sda3 /mnt/sda3 vfat noauto,nouser,dev,suid,exec,umask=000,uid=1000,gid=1000 0 0 # Added by GRML /dev/sda4 /mnt/sda4 vfat noauto,nouser,dev,suid,exec,umask=000,uid=1000,gid=1000 0 0 # Added by GRML /dev/usb-sda /mnt/usb-sda auto users,noauto,nodev,noatime,nosuid,noexec,rw,uid=1000,gid=1000 0 0 # Added by GRML /dev/usb-sda1 /mnt/usb-sda1 auto users,noauto,nodev,noatime,nosuid,noexec,rw,uid=1000,gid=1000 0 0 # Added by GRML /dev/usb-sda2 /mnt/usb-sda2 auto users,noauto,nodev,noatime,nosuid,noexec,rw,uid=1000,gid=1000 0 0 # Added by GRML /dev/usb-sda3 /mnt/usb-sda3 auto users,noauto,nodev,noatime,nosuid,noexec,rw,uid=1000,gid=1000 0 0 # Added by GRML /dev/usb-sda4 /mnt/usb-sda4 auto users,noauto,nodev,noatime,nosuid,noexec,rw,uid=1000,gid=1000 0 0
So you have the old /dev/sd* entries as usual and additionally the new, but more restricted ones meant for use as normal user. Mounting as user with uid 1000 (= user grml on the live-cd) is possible via running for example "mount /mnt/usb-sda2".
As soon as you unplug the usb device /etc/fstab will be updated again so all invalid/not-anymore-existing entries will be removed automatically. The /mnt/usb-sd* directories will be deleted as well. The fs-label directories in /mnt won't be deleted automatically.
If you want to disable the above feature at all on your grml system you would just have to remove the according udev rules file. This will be documented of course. ################################################################################
Please let me know what you think about it. If you're happy with this solutions I'd implement it so you can test it in real-live with the upcoming grml 0.7-1 devel-release.
regards, -mika-
Hi,
On 2006-09-03 at 18:14:01 +0200, Michael Prokop mika@grml.org wrote:
I'd like to ask for your comments about handling of external usb devices on grml.
Really nice work!
Out of interest: Would you want this to be part of udev.deb or do you want to ship it in a separated package, so you could also install it on any debian system?
/mnt/external[1] will be left without any changes, we will stay completely backwards compatible. Additionally we will create /dev/usb-sd* devices via udev rules like:
# cat /etc/udev/usbpen.rules SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", SYMLINK+="usb-%k", GROUP="users", NAME="%k" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/bin/mkdir -p /mnt/usb-%k" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/bin/sleep 2" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/usr/sbin/create_mnt_labels" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/usr/sbin/rebuildfstab -r -u 1000 -g 1000"
May I suggest s/BUS/SUBSYSTEMS/ according to the recent changes in upstream udev. Or we might completely loose one of SUBSYSTEM or BUS/SUBSYSTEMS, but I'd have to test that.
ACTION=="remove", KERNEL=="sd[a-z]*", RUN+="/usr/sbin/rebuildfstab -r -u 1000 -g 1000" ACTION=="remove", KERNEL=="sd[a-z]*", RUN+="/bin/rmdir /mnt/usb-%k", OPTIONS="last_rule"
Purely cosmetic: Reordering the directives (ACTION being first on "add" and "remove") would improve readability.
[snip]
If you want to disable the above feature at all on your grml system you would just have to remove the according udev rules file. This will be documented of course.
Better just put the real rules file in /etc/udev and symlink it to /etc/udev/rules.d like we already do with the current rules.
Please let me know what you think about it. If you're happy with this solutions I'd implement it so you can test it in real-live with the upcoming grml 0.7-1 devel-release.
That would be 0.8-1, wouldn't it? ;-)
Cheers, Tobias
* Tobias Klauser tklauser@grml.org [20060903 18:54]:
On 2006-09-03 at 18:14:01 +0200, Michael Prokop mika@grml.org wrote:
I'd like to ask for your comments about handling of external usb devices on grml.
Really nice work!
Thanks. :)
Out of interest: Would you want this to be part of udev.deb or do you want to ship it in a separated package, so you could also install it on any debian system?
I think our udev package would be the right place for shipping the udev rules. Therefore the rules file can be updated with any upstream changes in udev as well.
# cat /etc/udev/usbpen.rules SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", SYMLINK+="usb-%k", GROUP="users", NAME="%k" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/bin/mkdir -p /mnt/usb-%k" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/bin/sleep 2" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/usr/sbin/create_mnt_labels" SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd[a-z]*", ACTION=="add", RUN+="/usr/sbin/rebuildfstab -r -u 1000 -g 1000"
May I suggest s/BUS/SUBSYSTEMS/ according to the recent changes in upstream udev. Or we might completely loose one of SUBSYSTEM or BUS/SUBSYSTEMS, but I'd have to test that.
Thanks.
ACTION=="remove", KERNEL=="sd[a-z]*", RUN+="/usr/sbin/rebuildfstab -r -u 1000 -g 1000" ACTION=="remove", KERNEL=="sd[a-z]*", RUN+="/bin/rmdir /mnt/usb-%k", OPTIONS="last_rule"
Purely cosmetic: Reordering the directives (ACTION being first on "add" and "remove") would improve readability.
Good catch, thanks.
If you want to disable the above feature at all on your grml system you would just have to remove the according udev rules file. This will be documented of course.
Better just put the real rules file in /etc/udev and symlink it to /etc/udev/rules.d like we already do with the current rules.
Oh, sure.
Please let me know what you think about it. If you're happy with this solutions I'd implement it so you can test it in real-live with the upcoming grml 0.7-1 devel-release.
That would be 0.8-1, wouldn't it? ;-)
Of course, another good catch - thanks. :)
Tobias, can you work on the udev package? I'd implement the rest in the meanwhile. (Let's meet on IRC for further questions.)
thx && regards, -mika-
* Michael Prokop mika@grml.org [20060903 18:20]:
I'd like to ask for your comments about handling of external usb devices on grml. ################################################################################
[snip details about implementation]
The proposed solution has been implemented. grml-users just need to update the according packages via running:
# apt-get update ; apt-get install udev grml-scripts grml-rebuildfstab
Feel free to report any problems you notice.
grml 0.8-1 will include the solution as well, I'll just do some more development before the new ISO is available to grml beta-testers and developers.
regards, -mika-
Without commenting on the specifics of Mika's new implementation (I need to study it), I still want to offer opinions about USB. My users fall into the USB category.
problems start with multiple devices or devices with several partitions on it
Or moving the USB device from PC to PC. That is the whole point of using USB for many people. When you move the device, however, /dev/sda becomes /dev/sdd so the old-style fstab syntax just breaks.
Mika is probably right about automount. His opinions are what make grml so great.
On the other hand, *nix is a 30-year-old design. Not all of it is still 100% right for today. The fstab topic deserves more comments. I have opinions about fstab.
The /dev/XYZ syntax does not help. I much prefer labels/UUIDs. They are *much* less brittle for OS design. It makes more sense to use labels/UUIDs than to synchronize /dev/XYZ changes. A system based on labels/UUIDs has nothing to sync. It "just works."
Labels/UUIDs are not merely preference. They can be *necessary*
http://www.wlug.org.nz/PartitioningSuggestions
"In most cases the raw device name will do, but there are some situations in which...fstab to remember things...just won't work."
'mount /mnt/external1' (corresponding to /dev/sda1) and 'mount /mnt/external' (corresponding to /dev/sda).
I never liked those and never use them. They are irritating because there are many types of external devices. Am I mounting a camera? A scanner? A disk? A flash stick?
The traditional /dev/XYZ syntax is just a sysadmin preference. It should not be turned into a fixed rule. The rule being cemented now is this: "grml will always use /dev/XYZ syntax no matter what you want, but we offer some alternative /dev/ABC-XYZ syntax too."
The way to handle syadmin preferences is cheatcodes. A grml cheatcode already toggles "build fstab." A new cheatcode could toggle "use labels when building fstab" and "use UUIDs when building fstab." That way, old-school sysadmins could keep /dev/XYZ (and risk the brittleness).
Duplicate label problems are solved by UUIDs. People worried about that should use UUIDs. Incidentally, blkid gives the UUID.
Additionally we will create /dev/usb-sd* devices via udev rules like:
The philosophy of grml was to avoid "symlink hell." I'm ok with any solution that is not better handled by fstab labels.
If the entire purpose is to avoid labels, then I do not like the solution, because syntax is a poor reason to do anything. Besides, you could still put /dev/XYZ in comment sections of the fstab file.
Swap partitions are even worse. There is no fine control. I'm not sure how to handle them automatically in any Debian system very well. It's all-or-nothing. Grml activates all swap partitions without regard to fstab unless you boot with cheatcode "noswap" which turns them *all* off.
You can do swapon by label. You can also boot noswap. So then, by hand, you have full control: boot noswap and do swapon by label, one swap at a time. This technique gives you full control over which partitions are used.
Some of us like automation. Some of us *need* automation for end users. It would be nice to have labels for this purpose in fstab. So, in effect, the rule might be this: "only use a swap patition with these UUIDs and no other swaps you detect."
These are my inputs: Consider the mobile USB case. Think about putting /dev/XYZ in fstab comments (where they are still visible, but not active). Avoid symlink hell. Think about using cheatcodes to implement sysadmin prefs.
And ... many thanks for listening.
On Mon, 2006-09-04 at 15:58 -0700, Mark wrote:
Labels/UUIDs are not merely preference. They can be *necessary*
Take my case - laptop travels everywhere - niece's camera, colleague's usb memory stick, daughter's boyfriend's usb hd, and so on.
Whatever the technical implementation, let me, with some sense of humour, describe a typical laptop night at my house:
Niece says: Martin, look at these cool pictures. Plug in usb camera. Daughter's bf: can you transfer this code from my hdd, compile it and see what gives. thanks, dude. unplug camera, plug usb hdd Daughter: Yung Min has a paper in German, can you correct the grammar and style? unplug hdd, plug usb stick...
This should all occur with no other user knowledge than the drive becomes visible, accessible via konqueor, nautilus, or whatever, one views, transfers, opens files, edits documents, returns hw to original owner with corrected term paper, compiled binary, and/or some emotional sanity intact.
Mounting drives was necessary in my day, because one, literally physically mounted large disks onto spindles.
Time has come for someone to make usb drives work as intended, so it might as well be mika. ;)
In my case, actually, I simply have an embarrassing entry in fstab, which with file and command simply functions so far.
For sysadmins, I have no idea, but for people like me, dumb endusers, we need to automount whatever drive comes to our laptops wherever and whenever needed.
Or rid ourselves of pesky kids and friends....
Best, M
Fronti nulla fides
P.S. A kind of bug report:
We already have label-based partitions in fstab, but the auto-builder duplicates our manual entries with /dev/XYZ syntax. So now the fstab refers to the same partition twice.
It is possible to boot "nofstab" but that is not desirable. We still want autodetection. What we would like: grml detects if the fstab already has a certain partition, and if so, does not add a /dev/XYZ entry.
Thanks
M
Mark wrote:
P.S. A kind of bug report:
We already have label-based partitions in fstab, but the auto-builder duplicates our manual entries with /dev/XYZ syntax. So now the fstab refers to the same partition twice.
It is possible to boot "nofstab" but that is not desirable. We still want autodetection. What we would like: grml detects if the fstab already has a certain partition, and if so, does not add a /dev/XYZ entry.
Yes, that hits the nail on the head. The script is cool for a new system, but I have the GRML-repo on my (stock-)-Debian installation and it made some nice mess in /mnt. Mark's idea is great, I would love to see that in GRML!
Thanks
Thanks, as well, Frank
* Frank Lehmann eggsperde@gmx.net [20060905 12:15]:
Mark wrote:
P.S. A kind of bug report: We already have label-based partitions in fstab, but the auto-builder duplicates our manual entries with /dev/XYZ syntax. So now the fstab refers to the same partition twice.
Yes, but I personally don't see this as a bug, because therefore you have the option which version you want to use.
It is possible to boot "nofstab" but that is not desirable. We still want autodetection. What we would like: grml detects if the fstab already has a certain partition, and if so, does not add a /dev/XYZ entry.
Well, duplicates won't happen for /dev/XYZ entries, even if they are configured manually. But currently we don't recognise LABELs and UUIDs, right. I'll take a look at it whether it can be done reasonable to implement support for LABELs. I'm afraid of duplicate labels (I really don't like UUIDs in /etc/fstab on workstations) but I've to discuss the issue with the other grml-devs on next devel-meeting. Let's see what's the result.
Yes, that hits the nail on the head. The script is cool for a new system, but I have the GRML-repo on my (stock-)-Debian installation and it made some nice mess in /mnt. Mark's idea is great, I would love to see that in GRML!
The reason for "mess in /mnt": grml makes sure that you have all the directories available, which are given as target directory in /etc/fstab. But as written above I'll think about the label-stuff for fstab.
regards, -mika-
* Mark 27e3kk302@sneakemail.com [20060905 01:15]:
problems start with multiple devices or devices with several partitions on it
Or moving the USB device from PC to PC. That is the whole point of using USB for many people. When you move the device, however, /dev/sda becomes /dev/sdd so the old-style fstab syntax just breaks.
ACK.
Mika is probably right about automount. His opinions are what make grml so great.
On the other hand, *nix is a 30-year-old design. Not all of it is still 100% right for today. The fstab topic deserves more comments. I have opinions about fstab.
The /dev/XYZ syntax does not help. I much prefer labels/UUIDs. They are *much* less brittle for OS design. It makes more sense to use labels/UUIDs than to synchronize /dev/XYZ changes. A system based on labels/UUIDs has nothing to sync. It "just works."
It fails as soon as multiple devices have the same fs-label.
[...]
The traditional /dev/XYZ syntax is just a sysadmin preference. It should not be turned into a fixed rule. The rule being cemented now is this: "grml will always use /dev/XYZ syntax no matter what you want, but we offer some alternative /dev/ABC-XYZ syntax too."
The way to handle syadmin preferences is cheatcodes. A grml cheatcode already toggles "build fstab." A new cheatcode could toggle "use labels when building fstab" and "use UUIDs when building fstab." That way, old-school sysadmins could keep /dev/XYZ (and risk the brittleness).
People don't read the docs (ask my mailbox). I want to avoid the use of bootoptions as far as possible.
Duplicate label problems are solved by UUIDs. People worried about that should use UUIDs. Incidentally, blkid gives the UUID.
Yes, but UUIDs are long and IMO they suck a little bit on non-server-systems.
Additionally we will create /dev/usb-sd* devices via udev rules like:
The philosophy of grml was to avoid "symlink hell." I'm ok with any solution that is not better handled by fstab labels.
"symlink hell" in regards to "init-stuff which has to be handled manually" (/etc/rc*.d). You don't have to take care of /dev/usb-sd* at all. All symlinks will be deleted automatically as soon as the devices aren't present anymore. Nothing to care about.
If the entire purpose is to avoid labels, then I do not like the solution, because syntax is a poor reason to do anything. Besides, you could still put /dev/XYZ in comment sections of the fstab file.
Swap partitions are even worse. There is no fine control. I'm not sure how to handle them automatically in any Debian system very well. It's all-or-nothing. Grml activates all swap partitions without regard to fstab unless you boot with cheatcode "noswap" which turns them *all* off.
You can do swapon by label. You can also boot noswap. So then, by hand, you have full control: boot noswap and do swapon by label, one swap at a time. This technique gives you full control over which partitions are used.
Yes.
Some of us like automation. Some of us *need* automation for end users. It would be nice to have labels for this purpose in fstab. So, in effect, the rule might be this: "only use a swap patition with these UUIDs and no other swaps you detect."
Usually you set up a swap partition because you want to *use* it. :) If you set up several swap partitions and want to use only a specific one I think you have to handle this in your own initscript.
These are my inputs: Consider the mobile USB case. Think about putting /dev/XYZ in fstab comments (where they are still visible, but not active).
Ok.
Avoid symlink hell.
As written above: don't care about stuff you don't have to manage on your own. :)
Think about using cheatcodes to implement sysadmin prefs.
I'll talk about it with the other grmldevs on the next develmeeting.
regards, -mika-
It fails as soon as multiple devices have the same fs-label.
Not as bad as /dev/XYZ breakage. One can always construct failure scenarios. In all my years I have not once encountered a duplicate fs label on any OS. It doesn't happen. Duplicate files happen all the time, not duplicate volume names.
The problem is not bad anyway. Designing a graceful error handler is easy. Pick one duplicate and leave the other unmounted. Or do what Linux does for files, append ".N" to the mount point name, where N is an incrementing number.
People don't read the docs (ask my mailbox). I want to avoid the use of bootoptions as far as possible.
I have never seen this thought expressed by grml anywhere. If you have a link or grml-tip or other command, I will read the docs. The important thing is not the handling mechanism, but this main point: OS brittleness "sucks" a lot more than syntax.
Yes, but UUIDs are long and IMO they suck a little bit on non-server-systems.
"They suck" is not a technical argument. Mules and camels are uglier than horses. They also do far more work much more reliably. UUIDs are reliable.
All symlinks will be deleted automatically as soon as the devices aren't present anymore. Nothing to care about.
OK; just think it through carefully with a USB-boot device that moves from PC to PC to PC. The BIOS can change hard drive ordering, etc. At next boot, all /dev entries will be wrong, so grml has to reconfigure them gracefully.
Usually you set up a swap partition because you want to *use* it. :) If you set up several swap partitions and want to use only a specific one I think you have to handle this in your own initscript.
Fair point. The reason is tuning. Tuning is important for large programs with zillions of data elements.
It helps to assign swap to other drives and keep it off your OS disk. But you still want a swap on the OS in case there isn't any other swap on the PC you're using. Let alone cipher-swap issues.
M
* Mark 27e3kk302@sneakemail.com [20060908 07:15]:
It fails as soon as multiple devices have the same fs-label.
Not as bad as /dev/XYZ breakage. One can always construct failure scenarios. In all my years I have not once encountered a duplicate fs label on any OS. It doesn't happen. Duplicate files happen all the time, not duplicate volume names.
For example I have several devices with label GRMLCFG, so your "It doesn't happen." definitely isn't true. You can't take your own setup as a base for several thousand grml-users. :)
The problem is not bad anyway. Designing a graceful error handler is easy. Pick one duplicate and leave the other unmounted. Or do what Linux does for files, append ".N" to the mount point name, where N is an incrementing number.
"Pick one duplicate and leave the other unmounted." Whatever you want to tell me, I don't get it. :) Duplicate labels will suck, and grml's rebuildfstab does not mount the devices at all.
People don't read the docs (ask my mailbox). I want to avoid the use of bootoptions as far as possible.
I have never seen this thought expressed by grml anywhere. If you have a link or grml-tip or other command, I will read the docs. The important thing is not the handling mechanism, but this main point: OS brittleness "sucks" a lot more than syntax.
Sure, but when designing new implementation you have to take care of users which are used to "Linux' default".
Yes, but UUIDs are long and IMO they suck a little bit on non-server-systems.
"They suck" is not a technical argument. Mules and camels are uglier than horses. They also do far more work much more reliably. UUIDs are reliable.
Hehe. 8-)
When reading UUID=<insert_long_nummer_here> in fstab you very probably won't know what kind of device it is. That's what I don't like.
All symlinks will be deleted automatically as soon as the devices aren't present anymore. Nothing to care about.
OK; just think it through carefully with a USB-boot device that moves from PC to PC to PC. The BIOS can change hard drive ordering, etc. At next boot, all /dev entries will be wrong, so grml has to reconfigure them gracefully.
That's why udev exists and is used for. :)
regards, -mika-
For example I have several devices with label GRMLCFG, so your "It doesn't happen." definitely isn't true.
Wow, that's right: grml encourages duplicate labels that way. Quite a bad thing. How does grml decide among all those duplicates?
you have to take care of users which are used to "Linux' default".
Right: A sysadmin should decide how he wants to do things, and grml should maximize his options. Preference settings can help.
When reading UUID=<insert_long_nummer_here> in fstab you very probably won't know what kind of device it is. That's what I don't like.
A simple comment line above the UUID solves that.
Anyway you are the best and will come up with something good. You asked for comments. Grml listens well. Even though we may disagree over minor stuff, I appreciate grml. It is the most capable Linux I have ever used. That is saying something too, because I have tried them all.
* Mark 27e3kk302@sneakemail.com [20060908 23:15]:
For example I have several devices with label GRMLCFG, so your "It doesn't happen." definitely isn't true.
Wow, that's right: grml encourages duplicate labels that way. Quite a bad thing. How does grml decide among all those duplicates?
That's what you have to expect when designing software. That's real-life. :)
Of course we recommend to use only *one* device with label GRMLCFG. The first device found with GRMLCFG label wins, because we use "blkid -t LABEL=GRMLCFG" and not directly mount.
you have to take care of users which are used to "Linux' default".
Right: A sysadmin should decide how he wants to do things, and grml should maximize his options. Preference settings can help.
Yes, but non-sysadmins should be able to handle the system as well. I just don't want to break the system users are used to at all. Improvements are welcome of course. :)
When reading UUID=<insert_long_nummer_here> in fstab you very probably won't know what kind of device it is. That's what I don't like.
A simple comment line above the UUID solves that.
Yes, another approach on my "design-list". I've to discuss it with the other grml-devs and find out which solution might be the best.
Anyway you are the best and will come up with something good. You asked for comments. Grml listens well. Even though we may disagree over minor stuff, I appreciate grml. It is the most capable Linux I have ever used. That is saying something too, because I have tried them all.
:)
regards, -mika-
* Michael Prokop mika@grml.org [20060909 00:15]:
- Mark 27e3kk302@sneakemail.com [20060908 23:15]:
When reading UUID=<insert_long_nummer_here> in fstab you very probably won't know what kind of device it is. That's what I don't like.
A simple comment line above the UUID solves that.
Yes, another approach on my "design-list". I've to discuss it with the other grml-devs and find out which solution might be the best.
Ok, I just took some minutes to finally implement it.
(grml-)rebuildfstab supports LABELs and UUIDs now.
One approach is to check all present partitions/filesystems for their LABELs and if duplicates are found (for example two filesystems with a LABEL named "TEST") generate just one entry (the first device found with the label wins when running "mount /mnt/$LABEL"), this would look like:
http://grml.org/tmp/gkrellShoot_09-11-06_001808.png
The other approach is to check for label duplicates and use UUIDs instead for the labels where uniqueness can't be guaranted:
http://grml.org/tmp/gkrellShoot_09-11-06_002811.png
Both versions add additional information to the fstab-entry so it should be clear what's going on. Of course all the LABEL/UUID stuff will be documented. The according /mnt/[$LABEL|$UUID] directories are created automatically as well, so you don't have to care about anything at all.
Please let me know what you think about it. I will run some more tests before grml-rebuildfstab is going online. If we find a solution most of us like I would prepare a new devel-release so you can explore all the new development stuff on your own.
regards, -mika-
participants (5)
-
Frank Lehmann -
Mark -
Martin Yazdzik -
Michael Prokop -
Tobias Klauser