Hirsute went offline late July 2022, how to manage?


hey, registered here just so that I can get some clarification about the image @guu 's posted.

Is it normal for the balenaetcher to be that long? or something’s wrong with the .bz2 image posted?

EDIT: tried with the 0.1a old image to see if the problem’s on my laptop’s usb but that one’s fine, took only 20 minutes tops.

456m is too long
0.2mb/s is too slow for USB device

but the size of the image seems ok

I dont know where is the problem , guess the USB port issue

I don’t have this problem at all, the 0.2d image flashes in about 10 mins or so for me with my laptop’s inbuild SD card slot. Not tried e yet.

@guu I’ve been running the d image for the last week or so. It has been very stable and everything works so far. What has been changed between d and e?


I had several problems getting the file to finish downloading from Mega, it would sit at 100% but not finish past that point. Finally worked on a different computer this morning.

Tried to flash it to a card and had the same problem with etcher, it basically just sat there. Cancelled, ran etcher as Admin, same issue. Used 7zip to unzip it to an .img file. Etcher then blaster the .img onto my card very quickly and I’ve been configuring things for about an hour.


Never occured to me to extract the .bz2 file in the first place!

I can attest now that after extracting the file and went with balenaetcher, all’s smooth sailing! thanks!

also if @guu would be so kind as to explain the differences between d and e ie: any problem regarding the screen and HDMI have been resolved here?

I double checked the d image, seems that the d image I forgot to mask two packages

linux-dtb-current-rockchip64 and linux-image-current-rockchip64

and this will lead apt upgrade fail to boot

please check your system to see if those two packages have been masked by

sudo dpkg --get-selections | grep hold

if not ,no packages
then use

sudo apt-mark hold linux-dtb-current-rockchip64
sudo apt-mark hold linux-image-current-rockchip64

to do the mask job

HDMI on a04 is hard

but cpi is working on it

I will upgrade the kernel package as soon as the HDMI got fix

1 Like

Both of those are already being held on my system and I’ve been using apt upgrade without any issues.

Not sure if it is related to the new image or not but my DevTerm ran out of power and shut itself off and now when it boots sys/class/backlight/backlight@0/brightness is always set to 1 which isn’t easy to use meaning I have to set it higher each time it boots.

so now everytime DT boots, the screen is like totally black ?

and you have to set /sys/class/backlight/backlight@0/brightness to see the content ?

It isn’t totally black, just very dim. I’d take a photo but the camera is compensating and makes it look a lot brighter.

I currently just have a script at boot now to set it automatically but without it the file just contains 1 (I think it was 5 by default).

echo 8 > /sys/class/backlight/backlight@0/brightness

Could you explain a bit more? Is it due to the DE3/mixer1/mixer2/TCON driver? Or the silicon IPs? Or allwinner’s unclear docs resulting problematic device tree? Or simply using hdmi micro/pcb wiring issue?

I am also trying to understand how this whole display engine in H6 chip works for both LCD and HDMI, maybe you can give some hints already based on your current status.

be very honest with you

kernel is really not my stuff, I can barely understand the words DE3/mixer1/mixer2/TCON driver ,lol

but the cpi whole team is working on it

if you want to get more information ,maybe send email to them

I noticed that there’s a more updated release (with Jammy) on the Clockworkpi site: DevTerm_A04_v0.2h.img.bz2

I download today and it seems fine except for HDMI but I wrote to the support and they told me that they are working on it.

This issue persists in the 0.2h firmware

Can you elaborate on this?

I’ve just fixed up my armbian hirsute mirror in prep for the upgrade and was assuming I’d be re-enabling it for jammy but I’m holding off.

Btw if anyone is having issues with the armbian mirrors at apt.armbian.com they’re on the fritz still.

So it is my understanding that the ClockworkPi (DevTerm specific stuff) for A04 motherboard on Armbian haven’t been integrated into the Armbian trunk yet. For A06 (and I guess Raspberry Pi CM3+4) it has however: Armbian 22.05 has been released!

Conclusion then, that an armbian upgrade can/will break the DevTerm A04 hardware support, and that’s why I haven’t re-enabled it. I plan to either start with a new OS image (which has the Clockwork Pi patches on top of whatever Armbian is in there) at some point, or move to RPI CM4, which should circumvent this problem.

Super helpful, thank you!!

Hello. I have not posted to this forum in a long time. I first wish to apologize for my former behavior and the manner in which I composed myself earlier in the year after discovering a major security vunribility. There were better ways to handle that, and I did not follow them. Earlier in the year I was a nervous wreck. Things are much better now for my own situation and I am very sorry for my outrage.

Now that the blog post is over…

I have been doing an audit of all my prepper tech, and my Clockwork Pi was one of the things in which I was checking up. I ran an apt-upgrade which lead me to this thread. I have followed @arru’s advice, but this lead to the issue reported by @Daeraxa that the screen does not work. However, the problem is not that simple. For me, the screen backlight turns on but there is no boot. It is not simply dark to the point of not being able to be seen. Second, I have concluded the device is not booting period due to an inability to log back in via SSH. As such I have no access to a terminal in the system.

It is my speculation that this issue may be caused by conflict in package version. The previous system was using Hirsuit, then all I did was change the sources.list* files to be Index of /ubuntu The full list of packages that apt upgraded before this issue is as follows (under the command apt update; apt upgrade -y; do-release-upgrade in a superuser terminal)

armbian-config armbian-firmware-full armbian-hirsute-desktop-xfce
devterm-first-start-a04 devterm-thermal-printer linux-dtb-current-sunxi64
linux-headers-current-sunxi64 linux-image-current-sunxi64 linux-libc-dev

The unrelated package fonts-noto-cjk was also installed for the first time, as part of the Chromium repositiory.

The command do-release-upgrade produced the following error afterwards:

You have not rebooted after updating a package which requires a reboot. Please reboot before upgrading.

I sent the reboot command to the SSH session and it did reboot, then the issue presented itself. I had believed the system froze so I tried to hard-shutdown with the physical button, then removed the batteries and tried again. No fix.

I see that @guu has provided a beta disk image based on the latest version of Armbian, but as I have installed a number of non-default packages to the system, as well as went through the trouble of encypting my /home/cpi directory, I don’t wish to try this out just yet. I may have to reflash though if I am unable to even boot, though I could edit conf from the SD card on another machine. I don’t understand how such an issue could occur on such a minor change. The kernel upgrade may have contributed, I am unsure.

For all I know the screen is just black, it is working, and I can’t SSH because networking connects after login. I try to open a TTY but am unable. I see nothing whatsoever except the screen’s lllumination.

Also recall my own observation for an observed Kernel Framebuffer Error that was never fully explored. Possibly related?

It appears that I had setup my transparently encrypted /home incorrectly. I question whether or not that was even nessesary to begin with. Because of being incorrectly setup I can not decrypt on another machine. I have decided that because the only thing that was in my /home/cpi directory (besides conf files) was The Paladin Press Collection, I have decided to simply flash the new disk image and start back at square one. Perhaps this will also solve the other seemingly-related issues that presented themselves throughout my review back at the beginning of this year.

Interestingly, the original disk image had not taken up the whole card and left two seperate unallocated parts of the card. I noticed this before I began to dd the new disk image. Now having finished I see that the new image also has the same problem.

This is a strange error, but the new image does boot. Perhaps related to armbian? I know that the Raspberry Pi needs to expand its image post-boot, so I will check and see if this is also the case for armbian in armbian-config.

Now strangely when I booted and went to run an apt-upgrade I recieved these errors:


I rebooted, and now the screen is completely at a loss and I again can not log into SSH. I then flashed the image again.

I have setup ssh and then rebooted the system. The system has rebooted succesfully. I then ssh into the device. (NOTE: I had to remove the githubcli repo per this thread. These are the only two things I had done prior to running apt update; apt full-upgrade in an ssh session.) Previously I must have selected an improper option in armbian-config not realizing what I was doing. I run the apt full-upgrade and there was a giant list of packages presented. I waited for it to complete its download and the upgrade works. apt is able to extract the packages properly and I recieve prompts for changes to conf files. I kept the currenly installed version on each prompt.

This looks like it will take a while to install. I’ve spent most of the day on this so after it finishes, I will put it away to continue tomorrow. I now also need to reinstall many of the packages that were previously installed and move over my custom dotfiles. As far as I can tell at the present moment (with the apt upgrade still in progress there are no issues.