Reassigning to systemd, which is in control of the boot-time mounting.
** Package changed: util-linux (Ubuntu) => systemd (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463120
Title:
Failu
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: util-linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463120
Title:
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Tim Whisonant (tswhison)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463120
Title:
Failure to boot if fstab disk mounts fail
To manag
Thank you, Dane.
Hello, util-linux maintainers:
Escalating this rather serious bug to you to analyze and get your
thoughts. When this occurs, the host is rendered unreachable. In #26,
Dane proposes a possible change to avoid leaving a system in this state.
Please let us know your thoughts on how
Hi, Tim.
I ran into this issue a few days ago on a local server where I'd made an
fstab mistake. The behavior seems un-changed from previous observations
(drops to the same recovery console). I believe this would still result
in an un-bootable cloud VM.
For those who are experiencing the issue
Hello @mark-web, @dmutters, did you ever gain any traction on this?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463120
Title:
Failure to boot if fstab disk mounts fail
To manage notifications ab
Could fstab default mount options be changed so that, unless otherwise
specified, failed mount attempts would skip that filesystem and keep
booting (logging an error), instead of dropping to an inaccessible
recovery console? This would let the fstab be fixed with minimal hassle
in a headless enviro
This is a serious issue when there is no physical access to the machine.
I can confirm this issue on 16.04 happen after adding a new harddrive to
the fstab and subsequently reformatting the drive. At reboot, I have to
options to resolve the situation. All network requests are ignored,
because the
In the absence of a fix, would some be gracious enough to let me know of
a workaround? I just rebooted a remote server (14.04) and am staring at
"ssh... Connection Refused". I suspect it has to do with fstab since I
just edited it to mount a USB drive. I can provide more details (if
needed) once I
I've tested this with kernel 4.10-rc3 in a local VirtualBox VM (Ubuntu
Server 16.04), with the same fstab error as above, and am able to
confirm most of the symptoms described by the reporter.
When attempting to 'mount -a', it presents the expected "wrong
filesystem type" error, but doesn't render
(New kernel is still compiling...)
I just did a test with a fully-patched, newly spun-up Ubuntu Server
14.04 AWS instance, and the behavior seems to be present with kernel
3.13.0-107. I can't verify all of the symptoms described by the
reporter, because I don't have physical access; but I get "co
Thanks for your attention on this bug, Joseph. I'm compiling the new
kernel, now, and will let you know as soon as I have a test result.
As far as I know, all 16.04 kernel versions exhibit this problem; but I
haven't done any testing on Ubuntu 15.X.
--
You received this bug notification because
This v4.10-rc3 kernel is now available. Can you give that version a test:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc3
Also, was there a prior kernel version that did not exhibit this bug? If so,
we can perform a kernel bisect to find the offending commit.
** Changed in: linux (Ub
I work for a major educational system that utilizes Ubuntu Server
(14.04, 16.04 LTS) instances on the Amazon Web Services cloud for
critical infrastructure. This bug has come up a few times, where an
admin has a typo or other error in /etc/fstab, pertaining to a non-OS
filesystem (like an EFS data
I can confirm this affects all Ubuntu >= 15.04 installations, including
Ubuntu 16.04 (LTS).
> I am reasonably sure that this is not a kernel issue but a boot script
dependency issue...
That's absolutely the case. Your intuition has not led you astray.
> Hopefully someone can point me in the righ
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463120
Title:
Failure to boot if fstab disk mounts fail
To manage notifications about
** Tags added: kernel-bug-exists-upstream
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463120
Title:
Failure to boot if fstab
Latest kernel (4.10-040100rc2-generic):
Reaches "Ubuntu 15.04" splash screen (with the four dots) which the previous
kernel didn't, but still fails to boot, eventually dropping me into emergency
mode shell as before.
Removing the offending fstab line and continuing to boot (Ctrl-D from shell)
r
Forgot to add: Having fixed fstab, rebooting gets me a grub menu (no
timeout so have to select boot option manually), and boots fine from
there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463120
T
Performed latest set of updates and retested. Couldn't run apport-
collect from the terminal immediately after failure as it needed a
graphical book in order to authenticate via Firefox, so ran after fixing
fstab and rebooting. I don't know if the logs are therefore useful?
I don't recall exactly
apport information
** Tags added: apport-collected vivid
** Description changed:
I found this on my main 15.04 desktop but have reproduced it in a VM:
1. Install Ubuntu 15.04 (I included updates and non-free but I doubt that
matters).
2. Add a bogus entry to /etc/fstab, eg:
/dev/sdd1
Did this issue start happening after an update/upgrade? Was there a prior
kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.1 kernel
As requested, I have now set package to "linux" (ie kernel) due to the
point in the boot sequence at which the issue occurs. I'm far from
qualified to speculate but I am reasonably sure that this is not a
kernel issue but a boot script dependency issue, which was why I didn't
specify a package init
Thank you for taking the time to report this bug and helping to make
Ubuntu better. It seems that your bug report is not filed about a
specific source package though, rather it is just filed against Ubuntu
in general. It is important that bug reports be filed about source
packages so that people
24 matches
Mail list logo
