Root account is locked. Cannot access console.

[Zweitaktmotor]

I installed LMDE 3 on a USB stick. At first it seemed fine but then this came up

Pressing Enter will make it try again but then I am stuck again there.

The recovery options from the boot menu get me there as well, without any interruption to let me use a console.

I've put quite a bit of effort into customising the installation and it would be a shame to loose it.

My questions:

- Is there anything I can edit using this USB stick on a different computer?

- Where is this locking information stored? (I have 2 partitions, one for the installation and one for Home)

- I have 2 timeshift backups from before this happened. Are they any good? Can I copy and paste something? (as an Administrator, if necessary)

Many thanks for pointing me into the right direction.

[deck_luck]

Do you remember seeing the "dm-raid45 not found in the module.dep" error before this problem? What changes have occurred since the last clean boot? Did you install any patches? Did you install any other software? Did you make any kernel parameter changes? Relax and think back what have you recently change? Get a notepad and write it down. Sometimes, it helps just outlining the changes to help you remember.

When you used the recovery mode did you get to the root shell? Did you enter the "journalctl -xh" command?

While booting you can try selecting an older kernel and initramfs by hitting escape to interrupt the grub process. Select the Advanced option and use one of the older kernels. If you have installed a new kernel or patch causing the problem this method will in a sense back out the change by using the older kernel and initramfs. You may have to go back more than one version.

[Zweitaktmotor]

Many thanks for looking at it from so many angles.

Let's see how many of your questions I can answer:

> Do you remember seeing the "dm-raid45 not found in the module.dep" error before this problem?

I don't remember seeing it, mainly because it may have flashed past too quickly. The thread below seems to suggest that it is not the cause of my problem as other users were able to boot normally even with this warning:

viewtopic.php?f=246&t=277400&p=1525644& ... 5#p1525644

> What changes have occurred since the last clean boot? Did you install any patches? Did you install any other software?

I set this stick up back in March for another family member. I installed it from a DVD downloaded here in August 2018, choosing the German locale. The first thing I did was to fully update the system using update manager. This included an update from kernel 4.9.0.7 amd64 to 4.9.0.8 amd64. I tweaked lots of gui features to make it look more like old gnome, downloaded and installed panel applets and a number titles from the repo. - I cannot remember them all, unfortunately, but they included the Microsoft fonts, Sylpheed e-mail client, evice PDF viewer, Kolor Paint simple image editing, Linphone SIP client, gparted, ConvertAll unit converter, gThumb image viewer, various video viewers and perhaps some more stuff.

> Did you make any kernel parameter changes?

No, I didn't.

The strange thing is: I did all this back in March and the stick worked absolutely fine. I then put it in a drawer waiting to meet the family member. Now, when I took it out of the drawer, it came up with this. The first thought that came to my mind was that I might not have shut the system down properly, but I believe I always did (Of course I know not to just pull a live USB stick out!)

***

I have not been able to get to any command shell, always running into the same error message. I can get a grub command line, but this is actually before the system is booted, just to add custom parameters. - Is this any good? Can I add any parameters to bypass or unlock the root access?

I tried to boot the older kernel, with the same result. - I assume if the root account is locked, it doesn't matter much which kernel I boot.

I feel what is really missing is a disk analyser in the style of old Norton Disk Doctor for DOS which used to help me so many times when disks were smaller. Here it could give the disk a thorough check if any blocks are faulty.Testdisk is not really in the same league (and rather crytic as well).

***

One thing I haven't tried yet is to use another bstick of the same size, do a fresh install, copy all files (including hidden ones) over from the old stick and see what happens.

[Zweitaktmotor]

Further update:

I found this link

https://raspberrypi.stackexchange.com/q ... spberry-pi

The Raspberry PI uses a Debian flavour called Raspbian.

The discussion suggests that adding

fsck.repair=yes

to

cmdline.txt

The only problem is that we do not have cmdline.txt in LMDE. So where can I add this option?

[deck_luck]

The reason I suggested selecting an older kernel/initramfs was due to the raid45 message. If you believe it is unrelated then so be it.

Can you clarify this "The recovery options from the boot menu get me there as well, without any interruption to let me use a console." comment? Are you saying you can access the recovery menu from the console? The recovery menu will have the "root Drop to the root shell prompt" option. This will give you root access in the recovery mode. Assuming the file system is good it will be mounted when you get to the root shell. If you are versed in using the terminal cli you can look around.

Do you have another similar Linux machine you can attach the usb stick? Using the other machine you could try to mount the file system and get your data. Or, boot up a live image and try to access the data.

As far as the root account being locked well that is normal for the majority of Linux main stream desktop distros. The sudo facility is used to gain privileged access. I see you are using LMDE3. I will have to create a virtual machine and test it out.

Are you running a Raspbery Pi?

[Zweitaktmotor]

> The reason I suggested selecting an older kernel/initramfs was due to the raid45 message. If you believe it is unrelated then so be it.

I don't think it is. Also see here:

viewtopic.php?f=246&t=277400&p=1525644& ... 5#p1525644

> Can you clarify this "The recovery options from the boot menu get me there as well, without any interruption to let me use a console." comment? Are you
> saying you can access the recovery menu from the console?

No, in the grub menu. when I select extended options, I can see each installed kernel version (two in my case) and each of them has a separate entry with "recovery mode". All this seems to do is to give me verbose output of the boot process. At one point, it seems to wait for 1:30 mins:

leading to an error message and carrying on to the error I mentioned in my OP:

Can this 1:30 min delay somehow be interrupted to get to a console? I tried CTRL-X, CTRL-D etc, but with no success.

> Do you have another similar Linux machine you can attach the usb stick? Using the other machine you could try to mount the file system and get your data. Or,
> boot up a live image and try to access the data.

Yes, I can get to the data on another machine. I just wanted to rescue all my settings and tweakings as I cannot remember everything I did for that relative. Not everything is saved in the Home folder. Some seem to be deep down in etc, usr and other system folders.

Many thanks.

[deck_luck]

Sorry, I had a brain fart. Totally forgot Linux Mint had a Debian variant. In the native Debian release the root account has a live password. Also, the Debian rescue, emergency, single, S, and s mode will require the root password. However, you are using a Linux Mint Debian variant. The good folks at Linux Mint configured the system to have a passwordless or locked root account. This is in line with the Ubuntu base as well as other distro using a passwordless root and requiring a proper sudo usage. I have a work around for you if you are willing to try it.

During the boot hit the escape to interrupt the grub process and enter an e to edit. Find the stanza beginning with Linux. Use the down arrow key to scroll down the page. The linux stanza contains the kernel parameters. To help with troubleshooting remove the "splash" and "quiet" parameters at the end of the line. Add the "init=/bin/bash" parameter at the end of the list. Examine the line and check for typos. With my weak eyes I missed a typo of inif instead of init. Once you are satisfied with the kernel parameters enter a control X. This will initiate the boot using the altered kernel parameters. If it goes well you will eventually see a message as follows:

Begin: Running /scripts/local-premount ...

Begin: Will now check root file system ...


If the file system is not mountable the /bin/bash will not be present to execute. You will need to use the installer or Live image to boot up and examine a possible disk failure or attempt further troubleshooting steps.

Assuming the file system is not corrupted, the kernel will mount the / (root) file system read only mode. In an attempt to resolve the problem use the dmesg to review the kernel errors ring buffer.

demsg | less

If needed you can remount the / file system with the following command:

mount -o remount,rw /

When you are finished do sync to flush any write buffers and wait for the sync to finish. We are not under the normal init/systemd control, so you can reboot or halt using the -f option.

reboot -f

[thx-1138]

The strange thing is: I did all this back in March and the stick worked absolutely fine. I then put it in a drawer waiting to meet the family member. Now, when I took it out of the drawer, it came up with this. The first thought that came to my mind was that I might not have shut the system down properly, but I believe I always did (Of course I know not to just pull a live USB stick out!)

...it's not the stick necessarily that has changed and it might not have been corrupted either.
Your screen above shows that 'Time out waiting for device...' & 'Dependency failed for /boot/efi'.

I'm not experienced with usb stick installs - they can be done with various modes (UEFI, BIOS, Hybrid etc...read here).
Based on the above error messages, i would thereby suspect something among the following lines...
1) either the USB install method that you had chosen in not compatible with the system that you're now trying the stick...
2) or, if it's the same system, then something maybe has changed in the system itself
(re-partitioned, disks added / removed, changed from uefi to mbr, who knows etc)...

No matter what might have changed there, as deck_luck already suggested,
try either init=/bin/bash (& if needed, mount -o remount,rw / ), or alternatively, boot with a secondary /another...live stick,
and do check what is going with sudo blkid and under /etc/fstab. Example. Hope that helps.

[Zweitaktmotor]

Many thanks both of you.

I will try all this and report back, but it may be a day or two.

[Zweitaktmotor]

Hi,

Sorry for the delay. Despite all efforts, I have not been able to get to a root prompt and have now started to re-create the original customised installation on a different disk (still have the USB, out of interest).

I made, however, an interesting observation:

I did the original installation on the USB stick on a machine with LMDE3 already installed on its internal hard disk. Afterwards, I shut the machine down, removed the stick and did a normal boot from the HD.

Now (2 months later) I tried to boot the USB stick on a machine with no internal HD with the error results described above.

So I went back to the original installation machine, tried to boot there and also got the results described above.

But I have now noticed that the internal HD on that machine makes working noises when I try to boot the USB stick. It shouldn't do that as I was under the impression that I created a self-contained installation that could be used on (nearly) any machine.

My conclusion is that the installer somehow recognised the hd and used it to store temp or cache files which were later lost when I did a normal hd boot. This is why I end up with an incomplete boot, no matter what I do.

Does this make sense?

Anyway, I did not loose any critical data, just 2 days of work tweaking the installation. So no point in wasting any more time (mine and yours).

Just wanted to let you know the outcome.

Many thanks for your help.

[clem]

Hi,

Quick note for people hitting a similar issue in the future. As said above, the root account is locked by default. This means the emergency mode doesn't work out of the box.

What you can do if you're stuck like this, is the following:

- Boot from a live ISO
- Open a terminal and create a directory (let's call it hdd here..)

Code: Select all

mkdir hdd

- Mount your main partition into it

Code: Select all

sudo mount /dev/sda1 hdd

(replace sda1 with your actual partition of course.. type

Code: Select all

blkid

to get a list of partitions if unsure)

- Get into your installed OS with chroot:

Code: Select all

sudo chroot hdd

- Give the root account a password with passwd:

Code: Select all

passwd root

You can then reboot the installed OS get back into emergency mode and type the root password to start troubleshooting.

[eone]

tonight, i encounter exactly same problem. i was able to figure out the root cause.

the info "Root account is locked. Cannot access console." you got from the screen is a red herring.

the root cause is my live use stick have two partition, one of the partition was been added to /etc/fstab wrongly. caused tyou are not able to reach the login screen, if you put the usb stick in, login screen will show up.

i assuming there is a bug in mint's installation app. caused the usb partition been added to /etc/fstab.

the solution is simple, just remove the entry from /etc/fstab. problem will resolve.