mountall hangs boot if first field of an fstab entry starts with the name of a filesystem
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| mountall (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Bug Description
Binary package hint: mountall
After upgrading a server to Ubuntu 10.04, I found it hanging early in
the boot process with no error messages. Eventually I discovered the
the problem: entries in fstab that have a first field (fs_spec) which
starts with the name of a filesystem type caused the boot to hang.
Renaming or simply prefixing them to avoid clashes with a filesystem
type avoided the problem.
So for example, the following fstab would hang during boot:
| proc /proc proc defaults 0 0
| UUID=e8e54459-
| UUID=dbe2dc82-
| proc-epic-i386 /srv/epic.
| devpts-epic-i386 /srv/epic.
While the following works:
| proc /proc proc defaults 0 0
| UUID=e8e54459-
| UUID=dbe2dc82-
| lolproc-epic-i386 /srv/epic.
| loldevpts-epic-i386 /srv/epic.
Arguably our use of fs_spec is 'out of spec' (sorry), but FWIW I've
been doing this for years on both Debian and Ubuntu systems and I've
not run into a problem with it until now. In any event, silently
hanging on boot is a fairly user hostile way to react and (IMO) a bug,
regardless of the validity of our use of fs_spec.
| James Troup (elmo) wrote | #1 |
| tags: |
added: regression-release removed: regression-potential |
| Changed in mountall (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| Steve Langasek (vorlon) wrote | #2 |
| Changed in mountall (Ubuntu): | |
| status: | Triaged → Fix Released |
So, the prefixing trick doesn't seem to work all the time. Some boots
still hang. I'm 99% sure I didn't entirely imagine it working and
that it really did boot for me with the prefixed-entries in there.
But in any event it doesn't anymore. Setting the first field to be
'none' for both the proc + devpts chroot mounts appears to work
reliably over the course of 3-4 reboots.