# Recent KlipperScreen commits break Klipper on Buster

**URL:** <https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370>\
**Category:** General Discussion\
**Created:** [December 14, 2022, 2:56am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370 "2022-12-14T02:56:04Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 14, 2022, 2:56am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/1 "2022-12-14T02:56:04Z")

</div>

This is a heads up that a rather bizarre issue has surfaced with some of the recent updates to KlipperScreen, see [My post on Discord](https://discord.com/channels/431557959978450984/784873574833455164/1052117424297758761) and the surrounding posts.

Two of my printers, both running Pi OS Buster started behaving erratically a few days ago - particularly when attempting `FIRMWARE_RESTART`. One printer is on Duet 3 Mini with Pi3B+ and the second one is also on Duet 3 Mini but with Pi4B. One was running buster based FluiddPI image with all components completely up to date and the second was on the latest MainsailOS, also completely up to date.

I was able to confirm with clean test installations that everything works perfectly again as long as KlipperScreen was not installed. Once KlipperScreen was installed, the same faults started occurring again. The logs show many occurrences of `Got error -1 in read: (11)Resource temporarily unavailable`. One printer would always hang on `FIRMWARE_RESTART` throwing the above faults and also `TMC stepper_y failed to init: Timeout on wait for 'tmcuart_response' response` and similar. The other printer (on Pi 4B) would actually restart most of the time but a few seconds later would crash with loss of communication with `'mcu'`.

The even weirder part is that unistalling KlipperScreen would not eliminate the issue, so it has to be one of the many pre-requisite packages that are installed in the process. On the other hand, both printers work perfectly fine again on Bullseye even with the latest KlipperScreen installed. This highly unusual behaviour made me chase my tail for hours last night as I was first convinced that I had a hardware failure, until the second printer started behaving erratically as well.

I attached logs from both printers in case Kevin would be interested in looking at them.

[klippy - Voron - v0.11.0-13-g201f715b.zip](https://klipper.discourse.group/uploads/short-url/pmN6eKvBxmVUixy0m6083RkYc9K.zip) (25.5 KB)  
[klippy - CR10SPro - v0.10.0-521-gd91939c4.zip](https://klipper.discourse.group/uploads/short-url/IHRQ2tNWoCqWem40MyM7jSZkDe.zip) (356.1 KB)

Cheers,  
Peter.

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 15, 2022, 4:28am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/2 "2022-12-15T04:28:17Z")

</div>

Here is an additional data point.

In order to eliminate any unforeseen variables and potential bit rot or cruft, I did a totally clean manual install or Raspbian, starting with `2022-09-22-raspios-buster-armhf-lite.img`, updating it to current with `apt`, installing KIAUH, then Klipper, Moonraker & Fluidd. All current versions. Following these steps the printer was working perfectly normal. I then installed the current version of KlipperScreen (v0.3.1-9-gb96adf5) and the printer immediately started exhibiting the same erratic behaviour during `FIRMWARE_RESTART` with `Got error -1 in read: (11)Resource temporarily unavailable` in the logs.

---

<div class="post-metadata">

**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\
**Post date:** [December 15, 2022, 6:40am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/3 "2022-12-15T06:40:02Z")

</div>

Interesting. It might make sense to cross post this in [GitHub - jordanruthe/KlipperScreen: GUI for Klipper](https://github.com/jordanruthe/KlipperScreen)

---

<div class="post-metadata">

**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\
**Post date:** [December 15, 2022, 4:37pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/4 "2022-12-15T16:37:53Z")

</div>

What type of displays are you attempting to connect to your rPi?

When I was setting up a 4" Miuzei HDMI (not DSI) I had some similar problems to what you’re seeing and it took a bit of searching and playing around to get it to work with the ultimate process I found to work was posted here: [Hardware known to work with KlipperScreen - #31 by mykepredko](https://klipper.discourse.group/t/hardware-known-to-work-with-klipperscreen/35/31)

I don’t know if this will help, but if you’re using an HDMI port, this might help point you in the right direction. What I did find is that KlipperScreen can be fairly sensitive to where it is installed in the process.

When I replaced the display with a BTT PI TFT5.0 (a pretty standard DSI display) it worked without any playing around.

Good luck!

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 15, 2022, 5:51pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/5 "2022-12-15T17:51:59Z")

</div>

Thanks for your comments.

I cannot speak for any others experiencing this issue, but in my case both installations use the Waveshare 4.3" IPS DSI screens. My Creality installation has been working with this screen without any issues for about a year. Just like with your BTT DSI screen, these just work “plug an play” on Buster. But they do need some additional massaging in order to work on Bullseye - so much for “progress”.

It is worth to emphasize that once the latest KlipperScreen has been installed, uninstalling it and even physically disconnecting the screen does not restore Klipper functionality - **it remains broken**.

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 15, 2022, 5:55pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/6 "2022-12-15T17:55:58Z")

</div>

I was planning to cross-post on GitHub, but time is a bit of a challenge. I originally made **alfrix** aware of the issue on Discord though.

---

<div class="post-metadata">

**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\
**Post date:** [December 15, 2022, 6:30pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/7 "2022-12-15T18:30:24Z")

</div>

> It is worth to emphasize that once the latest KlipperScreen has been installed, uninstalling it and even physically disconnecting the screen does not restore Klipper functionality - **it remains broken**.

I saw the same thing - you have to reimage the SD card and start over anytime I had a problem with KlipperScreen.

Where are you getting your rPi OS images? I stuck with the Raspberry Pi Imager and used the preconfigured “Mainsail OS” to minimize my work/provide a base that other people could work with.

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 16, 2022, 2:56am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/8 "2022-12-16T02:56:26Z")

</div>

> [@mykepredko](#):
>
> Where are you getting your rPi OS images? I stuck with the Raspberry Pi Imager and used the preconfigured “Mainsail OS” to minimize my work/provide a base that other people could work with.

The original two installations were based on FluiddPI image and MainsailOS image. The verification check I most recently did by performing a clean manual install was done with an official image pulled from [rapberrypi.com](http://rapberrypi.com).

BTW, my primary motivation for posting this in the first place was two fold:

1. Make others aware of the issue in case they are experiencing it
2. Have Kevin offer an opinion on this seemingly “impossible” interaction between KlipperScreen and Klipper, assuming he has time to do so

Cheers

---

<div class="post-metadata">

**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\
**Post date:** [December 18, 2022, 12:02am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/9 "2022-12-18T00:02:18Z")

</div>

Alas, this isn’t something I’ll be able to look at.

FWIW, from your description, it sounds like a system package may have been installed which is messing with the serial ports. See the blurb on “ModemManager” at the end of [Frequently Asked Questions - Klipper documentation](https://www.klipper3d.org/FAQ.html#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3) for details.

-Kevin

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 18, 2022, 3:26pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/10 "2022-12-18T15:26:41Z")

</div>

Thanks Kevin, I figured you’d have no time considering the recent level of activity on GitHub. The reference to ModemManager is interesting - I have not seen it before as it’s “hidden” deep in the FAQ.

I will see if I have some time to experiment and perhaps at least narrow down the potential culprit. Struggling with free time here, and what I do have is taken up by finishing my Voron.

Cheers.

---

<div class="post-metadata">

**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\
**Post date:** [December 18, 2022, 3:41pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/11 "2022-12-18T15:41:27Z")

</div>

In fact there are more than just the modemmanager that can spoil your fun. See [Ender 3 V2 - Linux Machine - NO MCU FOUND - #4 by Sineos](https://klipper.discourse.group/t/ender-3-v2-linux-machine-no-mcu-found/4635/4)

---

<div class="post-metadata">

**Author:** ![sprior](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@sprior](https://klipper.discourse.group/u/sprior)\
**Post date:** [December 20, 2022, 12:14am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/12 "2022-12-20T00:14:40Z")

</div>

I started running into this issue last week, I’m glad I didn’t start ripping the machine apart - I thought it might be a failed wire.

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 20, 2022, 11:32pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/13 "2022-12-20T23:32:29Z")

</div>

I can now confirm that it is KlipperScreen commit [9fa047e](https://github.com/jordanruthe/KlipperScreen/commit/9fa047eb8beb3f503821b560e3364e3935f52bd2) that breaks Klipper functionality on Buster. Not surprising, since the said commit causes installation of 191 (!!!) new packages.

```auto
0 upgraded, 191 newly installed, 0 to remove and 0 not upgraded.
Need to get 80.1 MB of archives.
After this operation, 288 MB of additional disk space will be used.

```

And, really, all it does is installing `libmpv-dev`…

Additional root cause investigation is above my pay grade.

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 21, 2022, 3:15am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/14 "2022-12-21T03:15:27Z")

</div>

Found a few minutes to post on GitHub:

[[BUG] Commit 9fa047e breaks Klipper serial interface on Buster · Issue #857 · jordanruthe/KlipperScreen (github.com)](https://github.com/jordanruthe/KlipperScreen/issues/857)

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 21, 2022, 8:41pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/15 "2022-12-21T20:41:08Z")

</div>

I can confirm that one of the 191 packages is the “evil” ModemManager. This issue can therefore be resolved by issuing the following command:

```auto
sudo systemctl disable ModemManager.service

```

Credits to Dragonkitty on Discord for describing the issue in detail.

---

<div class="post-metadata">

**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\
**Post date:** [December 22, 2022, 7:47am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/16 "2022-12-22T07:47:26Z")

</div>

I’d recommend to use `systemctl mask ...` instead of `disable`

A disabled service may be started nevertheless if a different service or application tries to call it. A masked service cannot.

---

<div class="post-metadata">

**Author:** ![ReXT3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/rext3d/32/200_2.png) [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)\
**Post date:** [December 23, 2022, 3:55am UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/17 "2022-12-23T03:55:00Z")

</div>

Thanks for pointing this out. I just read the manpage and `mask` does make much more sense here as we are effectively wanting to permanently disable ModemManager. I will revise my post on GitHub as well.

---

<div class="post-metadata">

**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\
**Post date:** [November 5, 2023, 8:56pm UTC](https://klipper.discourse.group/t/recent-klipperscreen-commits-break-klipper-on-buster/5370/18 "2023-11-05T20:56:38Z")

</div>


