|
Bugzilla – Full Text Bug Listing |
| Summary: | systemd-fstab-generator generates entries for lines marked noauto | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.3 | Reporter: | Ralf Friedl <Ralf.Friedl> |
| Component: | Basesystem | Assignee: | E-mail List <bnc-team-screening> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | fcrozat, Ralf.Friedl |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 12.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Ralf Friedl
2013-03-16 20:27:46 UTC
use nofail instead of noauto. I would suggest to use "udisks" to properly handle removable medias. (In reply to comment #1) Thank you for the tip with nofail. It sounds good, but it seems the option is not honored by systemd-fstab-generator. This is my new fstab: /dev/sdb /mnt vfat nofail,shortname=win95,fmask=133,utf8 0 0 /dev/sdb1 /mnt vfat nofail,shortname=win95,fmask=133,utf8 0 0 According to man fstab, "nofail: do not report errors for this device if it does not exist." My problem is not that the device does not exist, but that systemd-fstab-generator exits with an error if there is more than one entry for one destination directory, even if they should not be executed at all. Using "mount -a" would just ignore these lines, and it is not clear why systemd-fstab-generator generates files for noauto lines in fstab at all. I also read up on the suggestion with udisks. It seems that I can get almost the same effect that I have now with mount -r /dev/sdb1 if I type instead udisks --mount /dev/sdb1 --mount-options ro,shortname=win95,fmask=133 I just have to type much more, and I don't know where it will be mounted. I hope there is a way to specify the mount options, but I read the man pages and I didn't find any mention of configuration files. I found out that udisks will take the mount options and even the mount point from the fstab file, although I didn't find hints about that in the man pages. With this, I would for the same effect only need udisks --mount /dev/sdb1 --mount-options ro But then I have again the problem that systemd-fstab-generator aborts the boot sequence. For me, having two fstab entries which point to the same mount points seems broken (and I'm pretty sure I'll get the same answer from systemd upstream). Dynamic devices like USB sticks should be handled by udisks/udisks2 which will do "the right thing" regarding the device detection. You might want to check udisksctl (from udisks2). I looked at udisksctl, and it seems similar to udisks, just with a little different syntax. According to the man page, udisksctl is a command-line interface for the udisksd daemon, while udisks is a command-line interface for the udisks system bus service. This udisks system bus service is either also the udisksd daemon, or it is the udisks-daemon, or gvfs-udisks2-volume-monitor. Together these are four processes running for no good reason. 1316 ? Ssl 0:35 /usr/lib/udisks2/udisksd --no-debug 21053 ? Sl 0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor 25299 ? Sl 0:00 /usr/lib/udisks/udisks-daemon 25300 ? S 0:00 udisks-daemon: not polling any devices I don't know what you consider "the right thing" regarding the device detection, but I don't want anything to happen upon device detection, except for the creation of the files /dev/sd*. udisks2 is a rewrite of udisks (which will be phased out soon). For me, "the right thing" is to not bother amount mount points nor mount options when I plug a usb stick and have it mounted automatically, but that's me ;) The updated packages from https://bugzilla.novell.com/show_bug.cgi?id=809820#c2 fix this problem, too. Thank you. By the way, I have another use case for this, but that system is not yet updated. There I have fstab entries like LABEL=backup1 /path/backup LABEL=backup2 /path/backup ... |