| Summary: | sys-apps/util-linux: nofail is not considered in the ENOMEDIUM case | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | William Hubbs <williamh> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bug, floppym |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/11927 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
William Hubbs
2015-09-01 21:18:36 UTC
The manual says: mount(8): nofail - Do not report errors for this device if it does not exist. systemd.mount(5): With nofail this mount will be only wanted, not required, by local-fs.target or remote-fs.target. This means that the boot will continue even if this mount point is not mounted successfully. (In reply to Mike Gilbert from comment #1) > The manual says: > > mount(8): nofail - Do not report errors for this device if it does not exist. On my system, /dev/cdrom does exist. In that case, if the mountpoint listed in fstab (/media/cdrom in my example) doesn't exist, or if there is no cdrom in the drive when you run mount -a, you get a failure. Is this how mount -a is supposed to work, or is this a bug? (In reply to William Hubbs from comment #2) > Is this how mount -a is supposed to work, or is this a bug? I would say it is working as documented. I found a situation in which mount -a incorrectly disregards the nofail option; here is the method to reproduce: 1. add the following to fstab: /dev/cdrom /mnt/cdrom auto nofail,ro 0 0 2. make sure the mount point, /mnt/cdrom, exists. 3. do not put a cd in the cdrom drive. 4. run mount -a Because of nofail in the line in fstab, I would expect this mount -a to be successful. However, it is not. (In reply to William Hubbs from comment #4) which is more or less what Mike highlighted. the man page says "device ... does not exist" as in ENOENT as in `test -e /dev/cdrom` is false. it is not the same as what happens in the cdrom case -- the device (the cdrom reader) exists, but the disk (the CD) does not, so it returns ENOMEDIUM. sys-utils/mount.c could be updated to do: case ENOMEDIUM: if (uflags & MNT_MS_NOFAIL) return MOUNT_EX_SUCCESS; warnx(_("no medium found on %s"), src); break; but that would be a question for upstream. What about case: module wupporting spadfs wasn't compiled so localmount failed: # /etc/init.d/localmount start * Mounting local filesystems ... mount: unknown filesystem type 'spadfs' * Some local filesystem failed to mount [ !! ] * ERROR: localmount failed to start "nofail" didn't help me - OS has no network, because localmount failed. Doc for openrc says: "In this version, they will be able to fail if file systems they mount fail to mount." (In reply to Marcin Mirosław from comment #6) a different scenario, although you'd still have to ask upstream about this. userland can't tell the difference between a typo (spadfslajdfasdf) and a system-isn't-properly-configured situation. but if you use a hammer like "nofail", maybe it's your problem to deal with typos. i've posted both suggestions upstream now: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/11927 i sent a patch for nofail in the ENOMEDIUM case and it's been merged. it'll be in the next release. upstream said they'd rather not extend nofail in the case of bad FS selection. if you want to lobby for that, you can post to the upstream list ;). Yeah, missing /var/tmp/ is very good reason to have no network access to server. Welcome to mounting in local.start :/ (Btw, there are two posibilities, one is " to lobby for that", second is revert: https://github.com/OpenRC/openrc/commit/7341cd882fba522c1f1d183603334839bd4df7fc and I'm lobbing for that:) ) |