1

I am using Raspberry Pi4 with 64bit OS (raspberry pi os and not NOOBS) on a 32G microSD. It was working just fine before it rebooted by itself duing an scp operation from a remote computer. After that, the password (default raspberry) is not accepted. I have access to /boot and /root partitions from the microSD on a Linux desktop.

Here is the content of /boot/cmdline.txt:

console=serial0,115200 console=tty1 root=PARTUUID=96e8f372-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

I tried different approaches:

  • appended init=/bin/sh to the file cmdline.txt and boot_delay=1 to config.txt. Result: the Pi stuck at rainbow screen for ever and never moves to cmd to change the password.
  • appended init=/bin/bash to the file cmdline.txt. Result: the same as above (stuck at rainbow screen).
  • appended systemd.unit=emergency.target to the file cmdline.txt. Result: the same as above (stuck at rainbow screen).
  • appended systemd.unit=rescue.target to the file cmdline.txt. Result: the Pi stops at cmd page with cannot open access to console, the root account is locked. press enter to continue. By pressing enter, it normally boots and shows the login page (password incorrect).
  • Pressing/holding shift at startup. Result: doesn't work as it is not NOOBs. Boots and shows the login page.

What else can I do to recover? I am trying not to do a fresh image installation as I have various libraries installed.

Improve this question
4
  • Possible keyboard language issue? If you can enter the user name anywhere check if it recognises what you type as 'raspberry'.
    – user115418
    Dec 10, 2020 at 0:04
  • That's was not the issue. Other than through connected monitor/keyboard, I also tried connecting to the pi via ssh remotely - same error.
    – zlg
    Dec 10, 2020 at 0:09
  • 1
    What you SHOULD have done is restore from your backup. Recovering from a crash leaves your system in an indeterminate state. With luck it works, but you may find other issues later.
    – Milliways
    Dec 10, 2020 at 1:57
  • Was that scp command modifying any system directories by chance?
    – Dmitry Grigoryev
    Dec 21, 2020 at 13:57

2 Answers 2

Reset to default
2

After a few trials, I finally fixed it. I will write the steps below for anyone with the same issue:

  1. Unlock and enable root (superuser) by manually editing the file /etc/shadow. There is an entry for root which should be similar to root:*:0:0.... Simply remove the * and save the file. Note: copying an existing password (for example from user pi which should be similar to pi:$X$SK5xfLB1ZW:0:0... will less likely seem to be a workaround!).
  2. Append systemd.unit=emergency.target to the file /boot/cmdline.txt and save it.
  3. Insert the microSD back in the pi, start and wait for the command-line black-screen. When asked for root password, skip by pressing ENTER as you currently have no password set for root.
  4. Once you gained root access, change the password for user pi by the command passwd pi. Then type sync and then reboot by exec /sbin/init.

The four steps above might solve the issue and your new password for user pi will be accepted at login page. In my case, however, it DID NOT! So I changed the user from pi too root and left the password blank. Once logged in, I opened a terminal and changed the password for user pi (passwd pi) and restarted the Pi.

The last step fixed the issue and I could login normally as user pi!

Improve this answer
1
  • 1
    If this solution worked for you, please mark it as the accepted answer. Or it'll keep popping up on the list again and again.
    – AnonyoZarif
    Dec 10, 2020 at 5:59
0

With locked root user account /bin/sh will no do any good. So in addition to what @zlg have written I can add, that If you have USB dongle bluetooth keyboard like me the one thing that worked was to add systemd.unit=rescue.target. Most of the places that mentioned that you need USB keyboard were not specifically mentioning that it should be wired keyboard (as it seems). I'm not quite sure why wired keyboard and USB dongle bluetooth one are different as I think from USB point of view they should be the same, but I'm no expert. So it seems that 'rescue.target' allow drivers (udev) to loads as opposed to 'systemd.unit=emergency.target' and then you can type in the console, instead of sadly looking at the blinking cursor and not being able to do anything

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.