Cannot open access to cosole, the root account is locked
See sulogin(8) man page for more details
However it does seem a bit 'unfriendly' to make the system totally
unbootable if a drive that isn't needed at all for the boot process
can't be mounted by fstab.
On Mon, May 25, 2026 at 12:41:30 +0100, Chris Green wrote:
Cannot open access to cosole, the root account is locked
See sulogin(8) man page for more details
Does the system have a root password, or did you leave that blank
during installation, and have been administering it entirely with
sudo the whole time?
Unfortunately, if you leave the root password blank, there is no way
to enter single-user mode during boot -- because you must supply the
root password to do that. A lot of people are not aware of this,
because it's so rarely needed.
Instead of booting into single-user mode, you can try booting directly
into a root shell (init=/bin/bash and so on). You should search the
web for full instructions on how to do that, because there are a few
steps involved.
If you ever do get the system back to a working state (defined as having
the root file system mounted read-write), you should consider setting a
root password at that time, so that single-user mode will work.
Hi,
On Mon, May 25, 2026 at 12:41:30PM +0100, Chris Green wrote:
However it does seem a bit 'unfriendly' to make the system totally unbootable if a drive that isn't needed at all for the boot process
can't be mounted by fstab.
You've already received answers about why you can't log in, and how to
boot into single user mode.
I just wanted to add that if there is a filesystem that is not
essential for system operation, you can inform systemd of this by adding "nofail" to the mount options in fstab. This is documented in systemd.mount(5).
You can also use the regular mount options "noauto" to not mount the
thing every time, requiring a manual mount.
Andy Smith <andy@strugglers.net> wrote:
Hi,
On Mon, May 25, 2026 at 12:41:30PM +0100, Chris Green wrote:
However it does seem a bit 'unfriendly' to make the system totally unbootable if a drive that isn't needed at all for the boot process
can't be mounted by fstab.
You've already received answers about why you can't log in, and how to
boot into single user mode.
I just wanted to add that if there is a filesystem that is not
essential for system operation, you can inform systemd of this by adding "nofail" to the mount options in fstab. This is documented in systemd.mount(5).
You can also use the regular mount options "noauto" to not mount the
thing every time, requiring a manual mount.
It was a drive used for hourly 'snapshot' backups so needed to be
mounted normally. I think the nofail mount option would fulfil what I
need though.
Hi,
On Mon, May 25, 2026 at 12:41:30PM +0100, Chris Green wrote:
However it does seem a bit 'unfriendly' to make the system totally unbootable if a drive that isn't needed at all for the boot process
can't be mounted by fstab.
You've already received answers about why you can't log in, and how to
boot into single user mode.
I just wanted to add that if there is a filesystem that is not
essential for system operation, you can inform systemd of this by adding "nofail" to the mount options in fstab. This is documented in systemd.mount(5).
You can also use the regular mount options "noauto" to not mount the
thing every time, requiring a manual mount.
Thanks,
Andy
At Mon, 25 May 2026 13:49:40 +0100 Chris Green <cl@isbd.net> wrote:
[...]Andy Smith <andy@strugglers.net> wrote:
Hi,
On Mon, May 25, 2026 at 12:41:30PM +0100, Chris Green wrote:
However it does seem a bit 'unfriendly' to make the system totally unbootable if a drive that isn't needed at all for the boot process can't be mounted by fstab.
Around here, the mount/umount are part of the backup procedure (along with an fsck -fn, so I get early warning when the medium gets flaky). I don't want to have that medium mounted (and thus LUKS-unlocked) for longer than necessary. But yes, this is an iteresting topic, because different people tend to have pretty diverse needs/preferences.It was a drive used for hourly 'snapshot' backups so needed to be
mounted normally. I think the nofail mount option would fulfil what I
need though.
The autofs/automount option would also work. I've done this to save "wear" of
the backup disk, setting it to spin down and "sleep" when not in use, thus extending its life. (It would do for the backup disk to wearout *before* the main live disk(s)...)
I run Debian 13 on a ThinkPad t470 laptop. It has been very reliable
over the years but just recently a secondary drive (not used at all
for boot) has become a bit flakey and now it won't boot at all.
It gets to:-
Cannot open access to cosole, the root account is locked
See sulogin(8) man page for more details
Press enter to continue
Pressing enter gets one nowhere.
I'm creating a new boot/installation USB stick so I can boot from USB
and then edit the system's /etc/fstab to remove the faulty drive's
mount.
However it does seem a bit 'unfriendly' to make the system totally
unbootable if a drive that isn't needed at all for the boot process
can't be mounted by fstab.
However it does seem a bit 'unfriendly' to make the system totally
unbootable if a drive that isn't needed at all for the boot process
can't be mounted by fstab.
In case it helps anyone else in future, the same applies if a remote
samba share is mounted by fstab, the share will not be available during
boot, so it must be marked in fstab as 'not required for boot', for
which I use the 'noauto' and 'x-systemd.automount' options.
Hi,
On Mon, May 25, 2026 at 08:13:35PM +0100, Joe wrote:
In case it helps anyone else in future, the same applies if a remote
samba share is mounted by fstab, the share will not be available
during boot, so it must be marked in fstab as 'not required for
boot', for which I use the 'noauto' and 'x-systemd.automount'
options.
I think you may have other issues, as this is not supposed to happen.
systemd is supposed to be able to tell (by their type) that network filesystems like smbfs and nfs require to wait until network is up.
For filesystems that require network but don't necessarily make it
obvious by their type, you are supposed to use the "_netdev" mount
option to let systemd know.
If it's trying to mount these before the network is up then something
odd is going on. If it's failing to mount these after the network is
up then there is a problem somewhere.
This is documented in systemd.mount(5).
On Mon, 25 May 2026 20:29:36 +0000
Andy Smith <andy@strugglers.net> wrote:
Hi,
On Mon, May 25, 2026 at 08:13:35PM +0100, Joe wrote:
In case it helps anyone else in future, the same applies if a remote samba share is mounted by fstab, the share will not be available
during boot, so it must be marked in fstab as 'not required for
boot', for which I use the 'noauto' and 'x-systemd.automount'
options.
I think you may have other issues, as this is not supposed to happen. systemd is supposed to be able to tell (by their type) that network filesystems like smbfs and nfs require to wait until network is up.
For filesystems that require network but don't necessarily make it
obvious by their type, you are supposed to use the "_netdev" mount
option to let systemd know.
If it's trying to mount these before the network is up then something
odd is going on. If it's failing to mount these after the network is
up then there is a problem somewhere.
This is documented in systemd.mount(5).
Maybe that's how it is now. I switched my sid installation to systemd
fairly early in its life in Debian. Maybe it was a bit less polished
then. Certainly adding the options I mentioned, as recommended by
various Net gurus at the time, fixed it. And now, If It Ain't Broke...
--
Joe
(To be fair, man fstab does contain a disclaimer:
"This document describes handling of fstab by util-linux
and libmount. For systemd, read systemd documentation.
There are slight differences."
but no references.)
On 25/05/2026 9:49 pm, David Wright wrote:
(To be fair, man fstab does contain a disclaimer:
"This document describes handling of fstab by util-linux
and libmount. For systemd, read systemd documentation.
There are slight differences."
but no references.)
<https://manpages.debian.org/systemd.mount#FSTAB>
Sorry, I am not going to ask util-linux developers to add a link (as
the manpage or to its variant hosted at the systemd web site).
P.S. At to autofs, there is systemd.automount(5).
On Tue 26 May 2026 at 10:08:15 (+0700), Max Nikulin wrote:
On 25/05/2026 9:49 pm, David Wright wrote:
(To be fair, man fstab does contain a disclaimer:
"This document describes handling of fstab by util-linux
and libmount. For systemd, read systemd documentation.
There are slight differences."
but no references.)
<https://manpages.debian.org/systemd.mount#FSTAB>
Sorry, I am not going to ask util-linux developers to add a link (as
the manpage or to its variant hosted at the systemd web site).
"No references" was not intended as a criticism of man fstab.
In fact,
the aside (the only part of the post you quoted) was to credit the man
page for at least /mentioning/ systemd, which the fstab wiki fails to
do at the present time. (Its timestamp is 2024-01-21 19:29:15)
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 495146:44:59 |
| Calls: | 165 |
| Files: | 574 |
| D/L today: |
29 files (9,998K bytes) |
| Messages: | 78,216 |