Debian bug on Pi Model B+

Basic Information:

Printer Model: Mendel90
MCU / Printerboard:BTT SKR Mini E3 / Pi Model B
klippy.log

I have been trying to get communication going between these boards so as to properly set the printer.cfg. The " ls /dev/serial/by-id/
ls: cannot access ‘/dev/serial/by-id/’: No such file or directory " is the problem. Following the suggest fixes yesterday did not work so I re-imaged the Pi system and tried again. Adding the Keys allowed the update and the reboot brought me to a completely useless state ! As the Raspberry Pi is headless [no keyboard] and the network interface is not up at this point I will have to image again.

Any suggestions to prevent a repeat ?


Interesting. Have not seen such an effect in my test.
It seems that your Pi can no longer access its SD card’s partition. I wonder if this is related.

Which distribution?

That was an image I made yesterday from the raspberry imagery utility. A slightly older one did not fall so spectacularly. The earlier attempted fix with the “allow insecure” didn’t work for me and I thought a fresh start was a good idea…

The network was connected prior to the update with keys added

This does not really answer my question. It was which image and not how you brought it to your SD card

But just for the fun of it:

root@raspberrypi:/home/pi# apt-cache policy udev
udev:
  Installed: 252.5-2~bpo11+1
  Candidate: 252.5-2~bpo11+1
  Version table:
 *** 252.5-2~bpo11+1 100
        100 http://ftp.debian.org/debian bullseye-backports/main arm64 Packages
        100 /var/lib/dpkg/status
     247.3-7+deb11u2 500
        500 http://deb.debian.org/debian bullseye/main arm64 Packages
root@raspberrypi:/home/pi#

Works flawlessly

Mainsail OS 1.1.1 32 bit
Released: 2023-03-26

This is on an old Model 1 B circa 2013. I recently put a Model 2 with a SKR Mini E3 into my rebuild of a daVinci 1 AIO without a problem. I wonder if I get the USB id from the board I’m trying to install by temporarily connecting to the Pi 2., build my printer.cfg and proceed from there…

Sineos,
I will try that method you posted again though.

Since I would pretty much hate posting an instruction that does not work, I tried it on the 32bit MainsailOS with the RPi Imager.

Same procedure as above and same result: Works

Unfortunately I have thrown away my older Pis, so the RPi3B is the oldest I can try with.
But to sum up, I have now validated this procedure on:

  • OrangePi 3 LTS with Armbian 64bit
  • Banana PI BPI-M5 with Armbian 64bit
  • RPi 3B with MainsailOS 32bit
  • RPi 3B with RaspiOS 64bit

Thank you for that reassurance although I was not in doubt. Finding a newer RPi at a reasonable price seems impossible of late. I will try again as it could just have been a typo.

Ran the whole proceedure again, with exactly the same result… After reboot it came back as before in Emergency mode, and console locked. Had this error message before reboot:

May 11 20:39:47 mainsailos systemd[1]: Starting Rule-based Manager for Device Events
and Files…
dpkg: error processing package udev (–configure):
installed udev package post-installation script subprocess returned error exit statu
s 1
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u5) …
Processing triggers for man-db (2.9.4-2) …
Processing triggers for initramfs-tools (0.140) …
Errors were encountered while processing:
udev
E: Sub-process /usr/bin/dpkg returned an error code (1)
bill@mainsailos:~ $

I’m beginning to think the old RPi isn’t the best choice for this. I can get an Orange Pi for $65 CDN in a week. RPi s 3 and 4 just aren’t available right now so I’m looking at the alternatives. Rock Pi is another one I’m considering.

Bummer, this is bad. Unfortunately I have no idea what could be causing this or why this is related to RPi B vs RPi 3B

Can you try following command (just copy and paste the entire beast) on a fresh install (execute as root):

cd ~;wget http://ftp.us.debian.org/debian/pool/main/s/systemd/libudev1_252.5-2~bpo11+1_`dpkg --print-architecture`.deb http://ftp.us.debian.org/debian/pool/main/s/systemd/udev_252.5-2~bpo11+1_`dpkg --print-architecture`.deb;APT_LISTCHANGES_FRONTEND=none sudo apt install --fix-broken ./libudev1_252.5-2~bpo11+1_`dpkg --print-architecture`.deb ./udev_252.5-2~bpo11+1_`dpkg --print-architecture`.deb; rm libudev1_252.5-2~bpo11+1_`dpkg --print-architecture`.deb udev_252.5-2~bpo11+1_`dpkg --print-architecture`.deb  

It should only install two packages and if it tries to shuffle around lots of other files then stop.

Here is the result of that command:
"
May 12 09:52:10 mendel90 systemd[1]: Starting Rule-based Manager for Device Events and Files…
dpkg: error processing package udev (–configure):
installed udev package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u5) …
Processing triggers for man-db (2.9.4-2) …
Processing triggers for initramfs-tools (0.140) …
Errors were encountered while processing:
udev
E: Sub-process /usr/bin/dpkg returned an error code (1)
bill@mendel90:~ $
"
Reboot ended with a locked console as before :frowning:

BTW I did use a different SD card this time although neither card reported errors. I am concluding that this old Pi just won’t ! I appreciate your time and efforts but it is looking like an Orange Pi maybe the solution.

To use an Orange Pi, do you image with the same utility but using a down loaded one from github, then run the Kiauh script ?

Thanks for trying. Appreciated!
I really wonder why this does not work on the older RPis.

Be careful with the Orange Pi. At least the Orange Pi 3 LTS is giving me mixed results. The WIFI is unstable with the original distribution by Orange as well as with the Armbian one. Wired networking and overall stability is fine though.
Before buying, I recommend to browse the Armbian forums to see if there are already any shortcomings known.

Yes, basically the same procedure. Provision the SD with the respective image and e.g. a tool like Balena Etcher, boot and use KIAUH or do it manually.

Maybe you could try using the stock 32-bit Raspberry Pi OS Lite image rather than MainsailOS and see if that boots up properly. If so, maybe there’s something wonky with the MainsailOS additions. If not, that points to a hardware issue.

With the exception of the udev bug, the Mainsail OS works fine. The problem starts with getting the udev bug patch on that board. Sineos patch works well for other Pi s.

The real bug is I’m stubborn! The board cost $25 CDN 10 years ago and I have spent more time on it than I should have!

Totally understand. I’m the same way. Maybe try the “legacy” version of Raspberry Pi OS lite (based on Buster) and avoid the need for the udev workaround in the first place?

That is a thought but I have ordered an Orange Pi and will make a weather station or such with the old one ! I suspect that it might have trouble with some Klipper tasks. Watching the CPU load when doing updates and such it was slow compared to a Pi 2.

@Bill, if you feel bored: I’d be interested if the command

sudo apt install systemd udev -t bullseye-backports

changes anything.

1 Like

I think, that is not an old hardware issue. Must be SW related (Debian Bullseye Bug causing Klipper to no longer find the printer board)?

Good luck, hcet14