Helium: Cannot open access to console, the root account is locked.

hhh · 2019-01-09 23:28:33

What happens if you hit Ctrl-d?

johnraff · 2019-01-10 03:52:35

beng wrote:

The idea is to review the /etc/fstab as I suspect the issue could be there
...so, partially following S7.L instructions, I will go:
grub booting --> press "e"
at the end of the line that starts with linux, i will add:
init=/bin/bash
then press f10
once at the root@(none) I will type:
mount -n -o remount,rw /
(this will make my filesystem writable)
Here I do not want to set a password for root but merely review my fstab, so I will type:
nano /etc/fstab
review the fstab make changes if necessary
then type
reboot -f
what do you reckon - any comments?
thanks

As it happens, I had to do an edit to fstab a couple of weeks ago for similar reasons, and the above procedure worked OK. (I edited the boot line with 'rw' instead of 'ro' instead of remounting after boot, but otherwise the same.)

johnraff · 2019-01-10 04:08:06

@Bearded_Blunder I moved the root-startx issue to Bug Reports here: https://forums.bunsenlabs.org/viewtopic.php?id=5487

ohnonot · 2019-01-10 05:51:49

folks, you're all missing the obvious.

OP posted a screenhot in #5, where you can see:
- fsck failed
and as a result:
- dependency for local filesystems failed

that is what needs to be fixed.
i guess the way you did it now is ok, i would have just booted live and done a fsck on the filesystem(s)

i suspect a hardware problem...

S7.L · 2019-01-10 08:06:20

^ also to see what journalctl had in the logs.

A simple ..

journalctl -xb > journalctl.txt

and then possibly send it to a pastebin of your choice or use wgetpaste

https://www.ostechnix.com/how-to-easily … mmandline/

Last edited by S7.L (2019-01-10 08:06:55)

johnraff · 2019-01-10 08:52:00

ohnonot wrote:

folks, you're all missing the obvious.
OP posted a screenhot in #5, where you can see:
- fsck failed

But fsck might have failed because the partition had the wrong UUID in fstab. That seems to be what beng suspected, so let's wait and see if he could fix it that way.

beng · 2019-01-10 12:27:19

Hi everyone

Thanks a lot for your help!

I could not find anything wrong in my /etc/fstab but let it be clear I'm no expert!
(for instance, as indicated in the above post by johnraff, how could I find out whether UUID is not right / where can I find the right reference to compare it with?)

I changed the last number at the end of each partition line to 1 so I could get fschk to check them at reboot.

When I do a control + D it loops to:

You are in emergency mode....give root password for maintenance(or press control-D to continue):

So second time I type in the password previously set and i get at

root@dgneb:~#

then I can run:

journalctl -xb > journalctl.txt

did it, just need to mount a usb stick to copy it to - will try tonight

Well, yes I would definitely like

to start the user's graphical desktop

thanks again to everyone for their efforts here

Last edited by beng (2019-01-10 12:31:04)

damo · 2019-01-10 16:58:42

beng wrote:

... how could I find out whether UUID is not right / where can I find the right reference to compare it with?

Use the following command:

blkid

Last edited by damo (2019-01-10 17:45:44)

johnraff · 2019-01-11 03:58:48

An alternative approach to fixing the system is to boot a live session. You can then open the hard disk in Thunar and make edits to files as you wish.

beng · 2019-01-11 08:46:22

Hi everyone

here is the return of

journalctl -xb

journalctl.txt

(sorry i have not had time to compare /etc/fstab with

blkid

yet)

[EDIT] UUIDs match
+ don't know whether this is relevant to the issue, one of the booting screens before says:
"Failed to connect lvmetad"

Thanks

Last edited by beng (2019-01-11 12:35:13)

S7.L · 2019-01-11 14:10:05

Your pastebin is asking to decrypt it.

Have you booted to a live disc or usb and fsck yet?

Bearded_Blunder · 2019-01-11 14:29:25

I'd at this point be wondering if the HDD is at the root of the issue (excuse pun) my next test at this point personally would run along the lines:

Boot the live session > disable screen blanking under power options
open thunar and disable volume management on the advanced tab
open a terminal and run

sudo badblocks -svn /dev/sda

With those options it's a non-destructive read/write test of the entire disk, If that gives errors, the disk has problems. If it gives more than one or two errors that don't get cleared on a second run, proving the drive firmware successfully replaced bad sectors, the disk is toast. Even on a single run, lots of errors = new hard drive time.
It takes a long time to finish, hence the stopping screen blanking. It's also very write intensive, & not something to be run routinely on SSDs, or even at all if avoidable. You didn't mention anything about being on an SSD so I'm assuming spinning rust.

If that's OK, try running fsck on the filesystems in an environment where you have time to see any output, ie still booted from the live DVD.

"failed to connect to lvmtad" > "falling back to scanning" happens on my installs too it seems to be harmless, scanning works still.
I think that only happens when I instaall from CD/DVD as opposed to doing a netinstall ('m feeling dozy so that might be the reverse way round), possibly lvmtad doesn't get set up, but in my limited experience it doesn't seem to matter, lvmtad only caches metadata, lvmtad is more about speeding up boot than actually needed.

S7.L · 2019-01-11 14:48:30

^ beng has an ssd...

https://forums.bunsenlabs.org/viewtopic … 381#p80381

beng · 2019-01-11 23:19:17

S7.L wrote:

Your pastebin is asking to decrypt it.
Have you booted to a live disc or usb and fsck yet?

ooops - sorry.
journalctl.txt

no i didn't boot off a live usb, as explained before, I edited my /etc/fstab so a fsck was carried out at boot and rebooted

johnraff · 2019-01-12 01:17:21

Give B_B's suggestion of badblocks a try.

Bearded_Blunder wrote:

"failed to connect to lvmtad" > "falling back to scanning" happens on my installs too it seems to be harmless, scanning works still

+1
That message started to appear for a lot of people with Stretch (default setting change), and everywhere I looked the word was harmless.

beng · 2019-01-12 09:02:44

Hi
in live usb

sudo badblocks -svn /dev/sda

-->

/dev/sda is apparently in use by the system, it is not safe to run badblocks

[EDIT]
Ok, as i want to get moving on this and not spend the week-end on it, i have this other,bigger actually, ssd drive; the home data on my current locked ssd is backed up so I'm going to install LB helium on the bigger ssd and then paste the backup data.
Thanks everyone for your help, i will hold on to the locked ssd and see if i can connect it to the new system to further investigate ... Or simply refirmat it.
Thanks again, i love this forum as i know people are really helpful.
Cheers

Last edited by beng (2019-01-12 10:53:50)

Bearded_Blunder · 2019-01-12 12:43:10

[rant] I bet thunar auto mounted it.. that volume management is a royal pita, second thing I turn off after a new install after screen blanking, if I want a disk mounted *I'll* mount it ty.. frankly I connect them as often to test as to access :S [/rant]

I wish you every success, and yes you can always investigate later with it hooked up by usb, or e-sata

With an SSD something as simple as

cat /dev/sd? /dev/null

should alert the drive firmware to any dodgy blocks and cause a remap once it knows it's got a problem reading, if possible it's better to avoid running badblocks on an SSD, or at least any of the read/write tests. With conventional spinning drives the reverse is true and the -svn option refreshes the data, reducing the chance of corruption through bit-rot.

S7.L · 2019-01-12 13:15:46

Usually if a disk is dying it will give hints like io errors, have you had any of these opening applications Beng? Your journal looks like it has some read errors according to systemd but it could be a weird dependency issue that is not being met or has been lost somehow.

When my disk started dying it kept throwing input/output read errors, then again mine was pretty abrupt and i suppose they can just go without warning too.

All the best with it Beng, hope you get it sorted.

beng · 2019-01-20 07:37:32

S7.L wrote:

Usually if a disk is dying it will give hints like io errors, have you had any of these opening applications Beng? Your journal looks like it has some read errors according to systemd but it could be a weird dependency issue that is not being met or has been lost somehow.

Hi
no no such errors, the problem happened following the removal of an external 4To HD (2 backup partitions, fat32 and NTFS), i requested the eject of the NTFS partition, it gave me the ok but I got a notification it was still writing data to the other partition (I had not used it whatsoever) and just hung (could not move the cursor) - I removed the hard disk and forced restart, on reboot, that's when the issue occured.

Now I have just plugged in the lock SSD drive via USB3 sata connector and my new system does not even pick it up - maybe the power is not sufficient via the USB3 connector; will give it a go with my fully powered universal disk dock, but the power plays at times...

Do you reckon I could put back the disk in and thanks to a live usb access my home directory - i realised i missed some of the data.
what's the best / alternative way to proceed in your opinion?
thanks

S7.L · 2019-01-20 12:32:22

^ Beng, probably the easiest way to go is boot up into a live session of your chosen distro, BL will do. Have the Drive connected and mounted and get Gparted to check it, gparted maybe able to do some magic. Then as has been said, chroot into the dud drive if you can and get your files out and reformat that sucker.

Failing that and gparted doesn't see your device, maybe take it to a data recovery expert.

Last edited by S7.L (2019-01-20 12:35:50)

#21 2019-01-09 23:28:33

Re: Helium: Cannot open access to console, the root account is locked.

#22 2019-01-10 03:52:35

Re: Helium: Cannot open access to console, the root account is locked.

#23 2019-01-10 04:08:06

Re: Helium: Cannot open access to console, the root account is locked.

#24 2019-01-10 05:51:49

Re: Helium: Cannot open access to console, the root account is locked.

#25 2019-01-10 08:06:20

Re: Helium: Cannot open access to console, the root account is locked.

#26 2019-01-10 08:52:00

Re: Helium: Cannot open access to console, the root account is locked.

#27 2019-01-10 12:27:19

Re: Helium: Cannot open access to console, the root account is locked.

#28 2019-01-10 16:58:42

Re: Helium: Cannot open access to console, the root account is locked.

#29 2019-01-11 03:58:48

Re: Helium: Cannot open access to console, the root account is locked.

#30 2019-01-11 08:46:22

Re: Helium: Cannot open access to console, the root account is locked.

#31 2019-01-11 14:10:05

Re: Helium: Cannot open access to console, the root account is locked.

#32 2019-01-11 14:29:25

Re: Helium: Cannot open access to console, the root account is locked.

#33 2019-01-11 14:48:30

Re: Helium: Cannot open access to console, the root account is locked.

#34 2019-01-11 23:19:17

Re: Helium: Cannot open access to console, the root account is locked.

#35 2019-01-12 01:17:21

Re: Helium: Cannot open access to console, the root account is locked.

#36 2019-01-12 09:02:44

Re: Helium: Cannot open access to console, the root account is locked.

#37 2019-01-12 12:43:10

Re: Helium: Cannot open access to console, the root account is locked.

#38 2019-01-12 13:15:46

Re: Helium: Cannot open access to console, the root account is locked.

#39 2019-01-20 07:37:32

Re: Helium: Cannot open access to console, the root account is locked.

#40 2019-01-20 12:32:22

Re: Helium: Cannot open access to console, the root account is locked.

Board footer