"The root account is locked" on rebooting the pi

[krishraghuram]

The above error message pops up on every boot.

This requires keyboard for getting into the kiosk - which defeats the point of a kiosk mode.

Need to solve this.

[krishraghuram]

Root account was "locked", in the same sense that root account is locked by default in ubuntu.

https://raspberrypi.stackexchange.com/a/48057

Unlocked root account by

• sudo passwd root and set a strong password
• confirm by sudo passwd -S root to get status of root account. It should no longer be locked.

However, this does not solve the problem. After doing this and rebooting, we get,

Need to find out why this is coming

[krishraghuram]

The Why

1. fsck is a utility that checks file system for errors.
2. If system detects improper shutdown, fsck is run at next boot.
3. That is the maintenance in "Give root password for maintenance"

The Solution

1. It's important to ensure file system does not become corrupt beyond recovery. Else, we will lose mariadb data.
2. But, as a temporary workaround, we can disable fsck at boot. To disable fsck from running, we can edit /etc/fstab and set any file systems we don't want checked to have a 0 in the 6th (last) field.

References :

• https://linux.die.net/man/8/fsck

• https://forums.kali.org/showthread.php?34928-How-to-Solve-fsck-problem-on-my-Raspberry-Pi-3

• https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=61821

[krishraghuram]

This link seems to have several ideas for a true solution

https://unix.stackexchange.com/questions/136269/corruption-proof-sd-card-filesystem-for-embedded-linux

In short, we can,

• work on a hardware solution that ensures safe shutdown, using some super capacitors and some electronics circuitry
• use BTRFS with RAID1 mode and Automatic Scrub run periodically.

[krishraghuram]

Replying to comment above

Reply

The Problem

The temporary workaround - Setting last field to '0' in /etc/fstab - is a terrible idea

After I set it to '0', on the next dirty shutdown and subsequent boot, a huge problem surfaced.

The root file system was being mounted as read-only.

Found this and this, which explained the situation clearly

The default behaviour for most Linux file systems is to safeguard your data. When the kernel detects an error in the storage subsystem it will make the filesystem read-only to prevent (further) data corruption.

and

perhaps it is because the disk is unclean, try changing: /dev/sda1 / ext3 defaults 0 0 to /dev/sda1 / ext3 defaults 0 1 or at least do an fsck and then reboot

The Solution

• The obvious solution was to revert /etc/fstab to its original state, and run fsck to clean the filesystem
• However, I could not write to /etc/fstab, since the file system is read only.
• I tried to remount the filesystem as with write permission, following this
• That didnt work either. Got this error.
  • mount: / not mounted or bad option In some cases useful info is found in syslog - try dmesg | tail or so.
• dmesg told me this
  • EXT4-fs (mmcblk0p2): Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead
• Found this answer which solved the orphan inode problem.
• After that, e2fsck asked me to reboot. After the reboot, root was clean and had write access by default.
• To avoid future chaos, I reverted /etc/fstab to its original state.

The Conclusion

So, we still don't have a solution for the original issue. Need to work on it.

[krishraghuram]

Workaround 2 - Auto-respond to fsck prompt at boot

• Auto responding to fsck in ubuntu and debian is done using FSCKFIX setting in /etc/default/rcS

  • https://askubuntu.com/questions/818797/how-to-automatically-fix-fileystem
  • http://xmodulo.com/automatic-filesystem-checks-repair-linux.html
  • https://manpages.debian.org/stretch/initscripts/rcS.5.en.html

• Note that auto responding in pi is a little different.

  • https://www.raspberrypi.org/forums/viewtopic.php?p=955104#p955104
  • https://raspberrypi.stackexchange.com/questions/61723/raspberry-pi-3-and-raspbian-jessie-how-to-run-fsck-at-boot

In the Foundation's spindle-era images, FSCKFIX=yes was actually the default. In recent images, /boot/cmdline.txt has "fsck.repair=yes". I believe that takes precedence and is basically equivalent. If you want "no", remove the stanza from /boot/cmdline.txt as well.

We have to add the following to /boot/cmdline.txt fsck.mode=force fsck.repair=yes Make sure that file remains all one line. Parameters should be separated with spaces.

[krishraghuram]

Workaround 3 / Solution 1 (depending on whether it suceeds)

BTRFS with RAID 1

https://unix.stackexchange.com/questions/136269/corruption-proof-sd-card-filesystem-for-embedded-linux

[krishraghuram]

Workaround 4 / Solution 2 (depending on whether it succeeds)

Power backup for Rpi