Have just received my Radxa Zero. Installed the Debian image on it, boots up great. Hoping that a DietPi image will be made available soon as I’m a big fan.
If any questions or beta testing needed I’d be happy to help out. Mine’s the 1Gb version without EMMC.
Cheers
Dhry
If Debian is running, you simply could try to install DietPi on top using our PREP script https://dietpi.com/docs/hardware/#make-your-own-distribution
Did not know this existed! I’ll try it out later today. Thank you!
Dhry
let us know how it’s going.
Unfortunately it didn’t work. I tried it twice, once when SSHing into the box, once from a terminal started from within the desktop environment. Downloaded the script, elected to go with the beta version, Bullseye, and keep wifi enabled. Script ran fine for a while, downloaded and installed a stack of stuff. Window manager stopped. Still had the shell. Then it got to a point where it just kept repeating the same info over and over. Shut down and the system wouldn’t boot up again. Tried this twice, from SSH and from local.
See screenshot.
Should I be trying the master version instead?
Dhry
Edit: I chose “Generic device”, BTW.
did you used Debian Bullseye before or Debian Buster? Usually there is no difference between Beta or Master as we just released a new version. Looks like a loop of connecting USB devices
MichaIng
any ideas.
The official Radxa debian release is Buster with xfce. https://github.com/radxa/radxa-zero-images-released/releases
Edit: Did I screw up by using a Buster release, but in the Dietpi script, electing to go with Bullseye? I kind of figured that was the end-result of what I was going for, and didn’t think that it might mean “what are you STARTING with?”…
Dhry
well there you would need select Buster as well and not Bullseye. At least I would avoid going to a different Debian version as long as DietPi is not up
Started from scratch again. Chose all the same options as before when SSH’ing into the box, except selected Buster this time. Again, script seemed to run fine, removed a whole bunch of stuff but the same thing eventually happened. Always seems to die when removing “dbus”. Once again, output on the Zero just shows mouse detected on USB every 60 seconds or something. See screens.
Dhry
could be our PREP script is purging important stuff needed Radxa Zero device as these things might not be expected. In this case it is not working than.
That’s what it looks like. Well, it’s very easy for me to revert to the default image, boot up and try again, so if there’s anything I can contribute or test for you please feel free to reach out. These devices are absolutely sensational, extremely good value for money - this one cost me $21 and it’s a full on quad core device, a/b/g/n/ac wifi, 4k/60 video, USB-C and literally the size of a Raspberry Pi 0 W. Mine’s just 1Gb RAM though, but it still ran the Debian desktop like a dream. Would love to get DietPi on it to get the bloat dropped.
Note that it’s from the same manufacturer as the RockPi devices. Do you think it’s worth trying the setup again but marking it as one of those units?
Cheers
Dhry
something I could not answer. For this we definitely need developer support of MichaIng
Gave it a shot with the master branch, Buster, but this time chose the Rock Pi S as the starting device. Same thing happened - gets to removing the dbus package and freezes there.
Will wait for MichaIng’s advice.
yes, dbus is something we don’t use/need by default. Is it already freezing while purging the package or just on a reboot?
The script immediately freezes after showing that this package was removed. I waited more than ten minutes. On the actual Zero output window all you can see is that every 60 seconds or so it is polling USB and finds my connected mouse. No other activity and it doesn’t boot up at all if power cycled. It’s in a previously attached screenshot.
not sure why I did not found it before but there is exactly same topic on GitHub about image creation for Radxa Zero. It wasn’t created it right? just a coincident?
So that defect entry covers a lot of ground and didn’t specifically say that the script processes through to dbus and then freezes. Also, the original poster never got back to MichaIng stating that they managed to get it to work properly, I don’t think?
I’m not entirely sure whether there is something in there that I’m supposed to try myself in order to get things working? For example I did sed -i ‘/firmware-brcm80211/d’ on the prep script and it still failed.
And, I’ve been using the master prep script - should I be using the beta instead?
I guess they are using dev branch. But probably best would be if you could join GitHub. It’s much easier to have all in one place.
Agreed. I’m already on Github and just posted on that entry.
