Your message dated Sat, 1 Feb 2020 05:37:55 +0100
with message-id <[email protected]>
and subject line Re: Bug#754340: Unable to run fsck manually when instructed to
do so
has caused the Debian Bug report #754340,
regarding Unable to run fsck manually in rescue shell, / fs mounted rw and busy
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
754340: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754340
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd-sysv
Version: 204-14
Severity: critical
Justification: impossible to boot system
(The severity seems inflated, but it didn't fit any of the lower RC levels and
it should be RC IMO. It is also pretty easy to fix, I hope, so I'd suggest
doing that instead of worrying about the proper severity.)
My system had some serious hard drive problems and because of that remounted my
root file system read-only. Before investigating anything, I rebooted the
system to see if that would solve anything.
On reboot, fsck was run and it failed, telling me to run it manually. Then it
provided me a shell. So far so good.
However, fsck / failed because the filesystem was mounted read-write. mount /
-o remount,ro failed because the filesystem was busy. This being my only
computer at that moment, I did not have internet to look up how to do this in
systemd (which I'm guessing has a way to make remounting read-only work, but
I'm not familiar with it).
The only reason I was able to continue, was that after some trying it hit a bad
file and automatically remounted the filesystem read-only. At that point, I
could run fsck and it would boot again, allowing me to proceed with diagnosing
the problem.
My suggested solution is to document the method for remounting the root
filesystem read-only (or the method for getting help on the commands that do
such things) in the error message that says fsck must be run manually, or
perhaps whenever a shell is spawned so early during boot. This is essential to
be able to rescue the system, and since it's changed compared to how it worked
for decades, you can't assume that everyone knows how to do it.
This is even more important given systemd's dependency scheme which installs it
on machines where the owner isn't aware of it.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd-sysv depends on:
ii systemd 204-14
systemd-sysv recommends no packages.
systemd-sysv suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On Sat, 19 Jul 2014 23:48:58 +0200 Bas Wijnen <[email protected]> wrote:
> On Sat, Jul 19, 2014 at 10:27:48PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Jul 18, 2014 at 06:18:28PM +0200, Bas Wijnen wrote:
> > > When booting into single user mode, things worked as expected. I was
> > > unable to remount the fs read-only; the logs you requested are attached.
> > > (The mei_me messages have always been there, also with sysv init; I
> > > don't think they are related to the problem.)
> > Running fsck on a filesystem mounted in rw mode is a bad idea.
>
> I don't think that's happening. The kernel commandline specifies "ro",
> and AFAIK fsck would refuse to run on a read-write filesystem. The
> problem seems to be that when it fails, several services are started,
> one of which is mounting the fs read-write.
>
> > So instead of trying to fix things to remount the fs ro, fsck should
> > finish and succeed or fail *before* the filesystem is remounted rw.
>
> Yes, that's a good point. I'm not sure how it worked before; I haven't
> had fsck fail a lot. It might be that it used to spawn a shell on the
> read-only fs; that would make sense, especially because the next
> recommended action is to run fsck again.
Afaics, this issue is obsolete nowadays, as we have initramfs checking /
(and /usr for that matter). If there is an issue with your root
directory, you will be thrown into the initramfs rescue shell where you
can inspect things.
For non-/ directories, systemd will not mount them (ro) before they have
been fscked.
So closing the bug report.
Regards,
Michael
signature.asc
Description: OpenPGP digital signature
--- End Message ---
