meOS version 20201026 hangs on "Starting eudev", RPi 4B 8GB

[djrobzilla]

I originally tried using meOS version 20200606 for Raspberry Pi 4 but discovered there are a plethora of issues with the 8GB version and that even after being able to boot into the OS, users were having other lingering issues like being unable to access the USB ports and cameras. Probably because that version was not written with the 8GB model in mind? When I booted that version, I get the same message as everyone else in the Google threads I saw:

Note: The above image is copy and pasted from an online thread and not taken from my actual Pi, however the message I saw was identical.

Then I tried the newer 20201026 flashed onto a FAT32 formatted 32GB SD card, and the boot screen looks a bit different now. No errors this time, it simply hangs on:

* Starting eudev: done

That's about as far as I've been able to get, unfortunately. I waited up to a half hour just in case maybe the first boot just takes super long? But nothing ended up happening even after that long wait.

motionEyeOS Version

I am running motionEyeOS version: 20201026

Board Model

I am using the following board/model: Raspberry Pi 4b 8GB

Thank you so much for reading and for your work on this awesome project! Hopefully I get to enjoy it soon 😎

[starbasessd]

Make sure your rpi-eeprom is updated to at lease 4/2021. pi@raspi5:~ $ sudo rpi-eeprom-update BOOTLOADER: up to date CURRENT: Thu 29 Apr 2021 04:11:25 PM UTC (1619712685) LATEST: Thu 29 Apr 2021 04:11:25 PM UTC (1619712685) RELEASE: default (/lib/firmware/raspberrypi/bootloader/default) Use raspi-config to change the release.

VL805_FW: Using bootloader EEPROM VL805: up to date CURRENT: 000138a1 LATEST: 000138a1 If it isn't, run the command sudo rpi-eeprom-update -a to get it up to date, then you should be able to boot the motionEyeOS dev20201026 https://github.com/ccrisan/motioneyeos/releases/download/nightly-dev/motioneyeos-raspberrypi4-dev20201026.img.xz

[djrobzilla]

Hello again! I gave the above instructions a try, and inserted a raspbian SD Card to run the "sudo rpi-eeprom-update" command. I used a different SD card from the motioneyeos since I was unable to boot using that SD card, or even get a useable terminal. That should be ok though, since this was a pi firmware update and not a OS update correct?

Anyway, after running the command I was informed by the command that the bootloader had an update. I ran "sudo rpi-eeprom-update -a" and was prompted to reboot. After rebooting, I reran "sudo rpi-eeprom-update" and the command said everything was up to date now. However, after reinserting the motioneyeOS SD card with the dev20201026 image on it, I am still getting the same results: the bootloader hangs on "Starting eudev". Did I maybe do some part of the process incorrectly? I tried to describe my process in as much detail as possible but please let me know if you need any other information or logs. Thank you for your assistance!

[starbasessd]

Downloaded image fom here burn to SDCard using Win32DiskImager to 16GB card Copied my wpa_supplicant.conf file & ssh.txt file to /boot partition, ejected, and inserted into Pi4-8GB powered on, after a few, it booted normally. Repeated steps to a 16GB USB drive, (change cmdline.txt from root=/dev/mmcblk0p2 to /dev/sda2) and it also worked.

[djrobzilla]

I'm using a 32 GB SD card, maybe that is related? I am connecting to internet via ethernet and not using SSH, so not sure if that would change anything in my case. But in case it would make a difference, where would I grab those wpa_supplicant.conf file & ssh.txt files from? A functioning Raspbian install from a different SD card?

[starbasessd]

32GB is fine, I've used as large as 256GB before, I just had a free 16GB in my stack for testing. ssh or ssh.txt is just an empty file, but if it isn't booting up, then it's not going to be of any use. I would try a clean image, first. What are you using to write the image to the SDCard?

[djrobzilla]

I'm using the official Raspberry Pi imager

[djrobzilla]

If it helps here it the exact boot message I get before it hangs

[starbasessd]

If you've used any of the 'special' functions "\<ctrl>\<shift>x" of RPiImager then be sure to turn them off. You can try using Balena Etcher (all OSes) or Win32DiskImager (Windows)

[djrobzilla]

Does that include the "telemetry" setting in the ctrl+shift+x menu? I do see that is enabled but it seems like a pretty harmless setting. Other than that everything is enabled. I'll try the Win32DiskImager instead. Thanks!

[starbasessd]

I always do a clean image, then copy the 2 files over. If you are ethernetted, then no need for the wpa_supplicant.conf file. Ssh is helpful, though, but can be enabled in the WebGUI. Settings, Services, Enable SSH Server.

[starbasessd]

You must remember, motiuonEyeOS is not like RPiOS, Debian, Ubuntu, or others. It is VERY stripped down (doesn't even have 'bash' or 'sh', it uses links for them to busybox (along with a lot of other functions, too). It doesn't have apt or other methods of adding other software, either. Turning on 'telemetry' may depend on a non-installed app, and breaks the rest of the boot.

[djrobzilla]

Hmm, tried with Win32DiskImager and got the same results. Dang. Will try Rpi Imager again and turn off telemetry this time.

[starbasessd]

Could be a bad card or bad copy of the image. Got a USB Memory Stick? You could do that, with the change to cmdline.txt...

[djrobzilla]

Yeah, same results with telemetry off. Huh. I must be doing something stupid here...? I can't imagine what though, I've followed every instruction to the letter. I'm wondering now if maybe it could be the fan peripheral I have connected to the pi? Let me try unplugging that and see what happens.

[djrobzilla]

Same thing again. I'll try your USB drive suggestion, but I'll probably need to pick one up somewhere. Thanks again for all your help!

[starbasessd]

You're not changing any other files to the /boot partition, are you? Some of the older instructions did have you replace files...

[djrobzilla]

I made no changes to the files on these most recent attempts

Process looked like:

1. Format card as FAT32
2. Install 2020/10/26 image to card with all advanced settings off
3. Insert in Pi and boot resulting in hang

[starbasessd]

Can you go back to RPiOS, and run the command:

rpi-eeprom-config

I get on my Pi4-8GB: [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 BOOT_ORDER=0xf124 Can you please report yours?

[starbasessd]

BTW, no need to format a SDCard (Or USB Drive) before imaging with the Big 3 (Win32DiskImager, BalenaEtcher, or RPiImager), and the extra write cycles can help wear the card beyond use.

[djrobzilla]

Here is what I see:

[all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0

[djrobzilla]

I'm missing the BOOT_ORDER line I notice

[starbasessd]

To fix no boot order: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-4-bootloader-configuration

[djrobzilla]

Made that fix to the boot order and set the boot order to 0xf41 (ie the default boot order), but still seeing a hang on Starting eudev 🤔

[starbasessd]

make sure that nothing else is plugged in but the monitor and ethernet, including mice, keyboards, cameras, hats, gpio devices, etc. eudev is a device discovery program that is seeing (or not seeing) a particular device.

[djrobzilla]

So weird! I unplugged my keyboard and the GPIO fan (the only thing plugged in besides power, ethernet and my monitor) and still getting a hang on "Starting eudev"

[starbasessd]

Have you re-imaged? Or does it say 'formatting data drive'? With the clean image, with everything disconnected, try it again...

[djrobzilla]

I hadn't, but I just did and tried again with everything disconnected but same hang on "starting eudev"

[djrobzilla]

Does the first boot process save logs anywhere that might give us more detailed information on what is happening with eudev?

[starbasessd]

Unfortunately not much. You would need a linux or MacOS machine to read the /data (3rd) partition, but it's not fully set up, so doubtful. I'm sorry, but I really don't know what else it could be. You could always install RPiOS Lite (Buster Legacy or Bullseye) (or several other OSs) and install motionEye, Specific OSs on the right, here and get most of the features....

[djrobzilla]

Here is my cmdline.txt file:

dwc_otg.fiq_fix_enable=1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait ro rootflags=noload panic=10 quiet loglevel=1

I noticed that rootfstype is set to ext4. That should be fat32 though, right? Since my SD card is formatted FAT32? I tried changing it to FAT32 by using rootfstype=fat32 (this is after reformatting the SD card with a fresh meOS) and this time I get a huge string of errors related to the CPU and other system things and then goes into a boot loop.

Seeing as how that was a deadend I reformatted again and left the rootfstype at the default of ext4 since that at least seems to boot normally up until it hangs instead of going into a restart loop. I changed one other thing. In cmdline.txt I removed "quiet" and changed the "loglevel" to 8 so I could hopefully see more details in the error message I got on boot. Level 8 is apparently the maximum log level and upon rebooting I did indeed see a lot more interesting information! Although, I'm not certain what any of it means. Posting here for posterity:

It seems to be hanging on the "Loading X.509 cert" line. Don't know if that makes any difference in troubleshooting but thought I'd throw it in the pile of evidence just in case it helps identify the problem!

[starbasessd]

motionEyeOS uses 3 partitions (RPiOS uses 2). Partition1 (/boot) is Fat32/exFAT and is Read Only. Partition2 (/root also seen as / ) is ext4, also set to Read Only. Partition3 (/data) is also ext4, but is set to Read Write. These are the 'normal' settings.
There are several 'overlay' file systems (files that need to be read-write but exist in the read-only tree, so the system can allow the files to be written to, like logs and such) I see the x.509 issue is related to the WiFi settings (cfg80211). Are you sure you aren't using WiFi? It is an interesting situation. If you have wifi (or even if you don't, set up a wpa_supplicant.conf file as if you did, and put it in the /boot partition prior to first boot. I am re-testing without the wpa_supplicant.conf but with an ethernet connection, will let you know.

[starbasessd]

Nope for me. Still booted correctly, even without a valid wpa_supplicant.conf file. I am really at a loss...

[djrobzilla]

So this is interesting: I'm still unable to fully boot but now I'm at least able to get past the X.509 cert line. I tried adding wpa_supplicant.conf with all the correct settings for my network (i.e. ssid and pass) and here are the boot results:

So it seems that adding wpa_supplicant did something, but now a new problem is occurring. Phew, this is wild. I have another spare SD card so I'm going to try that one also. And if that also fails, I'll try grabbing a USB later and see if maybe that helps? I feel like I've spent so much time on this that I can't give up now haha!

[starbasessd]

I feel like it's a corrupted download / extraction of the dev20201016 image being written to the SDCard. Or the possible bad card. Other than that I'm still at a loss.

[djrobzilla]

Hmm I think I can rule out a corrupted download most likely, because I tried three different downloads of the same 20201026 image at different points and all had the same result. But yeah, it could perhaps be a corrupted SD card or maybe even the particular brand/model of SD card I'm using? Perhaps trying a USB boot as you suggested could help. Once I'm able to pick one up I'll update this thread with my results.

[djrobzilla]

Dang, tried a usb disk and still getting a hang. Ugh. I guess I'll try installing it on an existing Raspbian installation, but I didn't have a lot of luck with that last time I tried. :-( Oh well

[starbasessd]

If you post for help it's over at motionEye and be sure to tell me what OS you use...