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