Hey everyone, I recently set my Raspberry Pi 4 Model B with 8 GB of RAM up with Manjaro ARM KDE and while everything else works as it should—everything I set up: Borgbackup, Kodi with UPnP, etc. works wonderfully, and I can update the whole system via Pamac—I just can’t get the device to shutdown and thus it also won’t properly reboot.
My observations so far:
I enter “reboot” into terminal/via SSH
The system seems to turn itself off → Manjaro logo with a little spinning circle underneath appears
both green and red LEDs are on, green one is flashing
red LED goes out
green LED is no longer flashing but now shines steadily
after a while the green LED flashes twice and then goes out as well
the Manjaro logo with the little spinning circle remains, but the system doesn’t shut down or reboot
same behaviour for “shutdown”
The system doesn’t take any inputs either, I even believe that the keyboard isn’t being supplied with power any more.
Pulling the plug and plugging it back in boots the device flawlessly.
Did I, at some point, unwittingly mess up or forget some setting? I also can’t really tell, if it’s been like this from the moment I first flashed the SD card, or if it happened at some point within the configuration, as setting everything up went surprisingly smoothly and was finished in just a couple of hours, so there wasn’t really any need to reboot a lot and meet this issue beforehand.
Any help would be appreciated. As there aren’t even any error messages, I really don’t know where to even start looking.
That didn’t even occur to me. I can’t really interpret the output, though:
$ sudo fsck /dev/mmcblk0
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mmcblk0
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
/dev/mmcblk0 contains `DOS/MBR boot sector; partition 1 : ID=0xc, start-CHS (0x7a,140,1), end-CHS (0x3d4,100,1), startsector 62500, 437501 sectors; partition 2 : ID=0x83, start-CHS (0x284,2,2), end-CHS (0x8f,3,16), startsector 500001, 61833951 sectors' data
I’ll leave this here for you, while I look up “superblock” and “magic number.”
Yeah, that was a bit of a brain-bug there last night. I just blindly threw in your suggestion. I tested all partitions separately and it seems that the boot partition has issues.
$ sudo fsck /dev/mmcblk0p1
fsck from util-linux 2.37.2
fsck.fat 4.2 (2021-01-31)
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 2
/dev/mmcblk0p1: 268 files, 13357/54628 clusters
$ sudo fsck /dev/mmcblk0p2
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
ROOT_MNJRO: clean, 286809/1914432 files, 2609189/7729243 blocks
$ sudo fsck /dev/sda1
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
Backup_Toshiba: clean, 289709/122101760 files, 86149068/488378368 blocks
I then went ahead and removed the “dirty bit,” but to no avail. The system still won’t properly shut down and after another failed shutdown the “dirty bit” reappears.
$ sudo fsck -a /dev/mmcblk0p1
fsck from util-linux 2.37.2
fsck.fat 4.2 (2021-01-31)
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.
*** Filesystem was changed ***
Writing changes.
/dev/mmcblk0p1: 268 files, 13357/54628 clusters
One failed shutdown later:
$ sudo fsck /dev/mmcblk0p1
fsck from util-linux 2.37.2
fsck.fat 4.2 (2021-01-31)
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 2
/dev/mmcblk0p1: 268 files, 13357/54628 clusters
So I guess I’ll have to look for a reason why the file system wouldn’t be properly unmounted during shutdown.
Edit: This is a bit weird to me. Wouldn’t --boot=-1 tell me about the boot previous to the current one? I don’t really know why I would tell me about 29th September, then …
$ last -x shutdown
shutdown system down 5.10.63-2-MANJAR Tue Oct 5 11:09 - 15:11 (-34+19:58)
shutdown system down 5.10.63-2-MANJAR Tue Oct 5 10:49 - 15:11 (-34+19:38)
shutdown system down 5.10.63-2-MANJAR Tue Oct 5 10:27 - 15:11 (-34+19:15)
shutdown system down 5.10.63-2-MANJAR Mon Oct 4 20:19 - 15:11 (-34+05:08)
shutdown system down 5.10.63-2-MANJAR Mon Oct 4 15:39 - 15:11 (-34+00:27)
shutdown system down 5.10.63-2-MANJAR Mon Oct 4 15:32 - 15:11 (-34+00:21)
shutdown system down 5.10.63-2-MANJAR Mon Oct 4 14:02 - 15:11 (-33+22:51)
shutdown system down 5.10.63-2-MANJAR Sat Oct 2 14:11 - 15:11 (-31+22:59)
shutdown system down 5.10.63-2-MANJAR Sat Oct 2 13:52 - 15:11 (-31+22:41)
shutdown system down 5.10.63-2-MANJAR Sat Oct 2 13:38 - 15:11 (-31+22:26)
shutdown system down 5.10.63-2-MANJAR Wed Sep 29 15:16 - 15:11 (-29+00:04)
shutdown system down 5.10.63-2-MANJAR Wed Sep 29 15:12 - 15:11 (-29+00:01)
shutdown system down 5.10.63-1-MANJAR Wed Sep 29 15:07 - 15:11 (-28+23:56)
shutdown system down 5.10.63-1-MANJAR Wed Sep 29 13:45 - 15:11 (-28+22:34)
shutdown system down 5.10.63-1-MANJAR Wed Sep 29 13:39 - 15:11 (-28+22:27)
shutdown system down 5.10.63-1-MANJAR Mon Sep 27 19:36 - 15:11 (-27+04:24)
shutdown system down 5.10.63-1-MANJAR Mon Sep 27 19:24 - 15:11 (-27+04:13)
shutdown system down 5.10.63-1-MANJAR Sun Sep 26 16:47 - 15:11 (-26+01:35)
shutdown system down 5.10.63-1-MANJAR Sun Sep 26 13:26 - 15:11 (-25+22:15)
shutdown system down 5.10.59-1-MANJAR Sun Sep 26 02:28 - 15:11 (-25+11:17)
shutdown system down 5.10.59-1-MANJAR Sun Aug 8 20:58 - 20:55 (-00:03)
wtmp begins Sun Aug 8 20:55:42 2021
Add 8250.nr_uarts=1 to /boot/cmdline.txt and reboot… see if it will then reboot/shutdown.
If that does not work, try systemctl disable wpa_supplicant and reboot… see if it will then reboot/shutdown. (This will disable wifi until it is re-enabled).
This didn’t change anything in my Pi4’s behaviour.
Sadly, no good.
I noticed something else, though. The wpa_supplicant wouldn’t let itself be disabled … or I should say, it won’t remain disabled. Perhaps the issue here is that Pi4 doesn’t reboot, though, as it gets stuck somewhere during shutdown. After I used systemctl disable wpa_supplicant (as root) and restarted the Pi4 (using the “power-plug method”, after it got stuck again, as it wouldn’t reboot itself), systemctl status wpa_supplicant revealed that it was still running.
Those are the two things that I know of that can cause this. It may still be related to wpa_supplicant.
The 8250.nr_uarts=1 adds /dev/ttyS0 which resolved a very similar reboot issue with the 5.12 kernel. You can remove it or leave it, should not cause issues going forward.
Make sure to re-enable wpa_supplicant, even though it does not seem to need it. Just so things are back to the way they should be. Maybe @Darksky will have some more ideas.
I am sorta at a loss. I have been reading this thread all along. No one else seems to be having this issue with an updated system and plasma.
All of the things in the past that has caused this issue tried was an issue with an old kernel or when booting using uefi/grub.
To test if wpa_supplicant is really the cause of the issue rename the /usr/bin/wpa_supplicant bin to something else as NetworkManager.service will pull it in at boot. Then reboot.
Sometimes if one does dot have crda installed and your country regulatory domain set it hampers full communication with your router and causes issues.
I went ahead and tried your three suggestions as well, alas, to no avail. I’m all out of ideas—have been for a while now. So now, I’m going to flash a second SD card using the same Manjaro ARM image file I used for this one, and then I will set up this system on that new SD card exactly as I did the old one. Each step of the way I will check whether shutting down and rebooting the system still works.
Best case scenario: At some point it stops working and I can then say what package, process, or service is the culprit.
Worst-ish case: I end up with a fully functional system, but we’ll never know what the hell was going on here.
Thank you all for all your time and help so far. I’m going to try to keep you posted on my findings.
