Enable compatibility with older distros #128

New Issue

2021-10-22T04:20:49+02:00

Grntrenchman commented

2021-10-22 04:20:49 +02:00

(Migrated from github.com)

As most people are using this on a throwaway (sd image) os that can be wiped easily, big changes aren't such a big deal. Most people say to avoid this sort of thing, but in the name of Make It Work™, here it is:

I have several "targets" to get this installed on, as my openwrt router couldn't manage klipper.
I installed klipper, octoprint, and mjpg_streamer.

This ran and installed fine on an ancient EEE PC 900 running debian 11 (bullseye, i686). I don't think I had to manually install much, if at all.
It did not run on an android tv box (rk3229, armv71). I tried several images I could find (not supported pretty much anywhere), and the most stable one was on debian 9 (stretch), based on armbian I believe, for a "respeaker core 2.0". It installed and ran fine on the device, just old distro. trying later official images ended up with system locking after a few hours.

BUT, I did a distupgrade to bring to debian 11, and it ran, installed and configured no problem. It might help spread this to more devices, and it is automated enough to run through your KISS script, being more apt work and a single sed to change the sources, this wouldn't be too much to add to your script's init. Check debian version, do the distupgrade if the user doesn't care about "damage".

run

sudo apt update 
sudo apt upgrade -y

then per release you are behind:

sudo nano /etc/apt/sources.list

replace the codename of your release with that of the next release in APT's package sources
For instance, the line
deb https://deb.debian.org/debian/ buster main
should be replaced with
deb https://deb.debian.org/debian/ bullseye main
Release order: stretch --> buster --> bullseye
security: stretch/update --> buster/update --> bullseye-security
any custom repos leave (I had respeaker repo for custom image)

sudo apt clean
sudo apt update
sudo apt full-upgrade -y
sudo apt autoremove -y
sudo shutdown -r now

This will help people with older static image systems, where current builds aren't really available.

As most people are using this on a throwaway (sd image) os that can be wiped easily, big changes aren't such a big deal. Most people say to avoid this sort of thing, but in the name of Make It Work™, here it is: I have several "targets" to get this installed on, as my openwrt router couldn't manage klipper. I installed klipper, octoprint, and mjpg_streamer. This ran and installed fine on an ancient EEE PC 900 running debian 11 (bullseye, i686). I don't think I had to manually install much, if at all. It did *not* run on an android tv box (rk3229, armv71). I tried several images I could find (not supported pretty much anywhere), and the most stable one was on [debian 9 (stretch), based on armbian I believe](https://wiki.seeedstudio.com/ReSpeaker_Core_v2.0/), for a "respeaker core 2.0". It installed and ran fine on the device, just old distro. trying [later official images](https://www.armbian.com/rk322x-tv-box/) ended up with system locking after a few hours. BUT, I did a distupgrade to bring to debian 11, and it ran, installed and configured no problem. It might help spread this to more devices, and it is automated enough to run through your KISS script, being more apt work and a single sed to change the sources, this wouldn't be too much to add to your script's init. Check debian version, do the distupgrade if the user doesn't care about "damage". run ``` sudo apt update sudo apt upgrade -y ``` then per release you are behind: ``` sudo nano /etc/apt/sources.list ``` replace the codename of your release with that of the next release in APT's package sources For instance, the line ` deb https://deb.debian.org/debian/ buster main` should be replaced with ` deb https://deb.debian.org/debian/ bullseye main` Release order: stretch --> buster --> bullseye security: stretch/update --> buster/update --> bullseye-security any custom repos leave (I had respeaker repo for custom image) ``` sudo apt clean sudo apt update sudo apt full-upgrade -y sudo apt autoremove -y sudo shutdown -r now ``` This will help people with older static image systems, where current builds aren't really available.

dw-0 commented

2021-10-22 10:23:55 +02:00

(Migrated from github.com)

Hi, thanks for the suggestion.

Check debian version, do the distupgrade if the user doesn't care about "damage".

That's my biggest concern here. That's also why there is a notification at the end of the system package updates (if you choose to update them from within KIAUH), that KIAUH won't do an apt-get dist-upgrade.
My personal experience is, that this can lead to broken systems.

Let me think about it because as of now i am not quite sure if the idea is as great as it might sound at first glance.
Not in terms of a feature... but in terms of "damage prevention". Not sure how to describe exactly but maybe you know what i mean. If something breaks, who fixes it? The user who might doesn't have the skills or advanced knowledge about linux and just wanted to happily use that feature to make klipper run on such an older distro, because he doesn't know how to prepare that distro to make it run the way like you did? That will cause heavy frustration on the users side because it rendered his system useless for that moment.

Also my capabilities of testing is limited. I prefer to test each feature i include carefully and make sure it works (as) flawless (as possible) before i merge it into master. That gets really time consuming, if not impossible to achive, if testing includes special hardware or hardware+software combinations of any kind for example.

So unless someone is willing to contribute that specific feature, who can test it throughoutfully AND is willing to maintain it in the future if stuff needs to be changed/fixed so i can maybe include it in KIAUH as some kind of "experimental" function in the advanced menu section, i have to say that this is probably something i won't get on to in the short run.

Hi, thanks for the suggestion. > Check debian version, do the distupgrade if the user doesn't care about "damage". That's my biggest concern here. That's also why there is a notification at the end of the system package updates (if you choose to update them from within KIAUH), that KIAUH won't do an `apt-get dist-upgrade`. My personal experience is, that this can lead to broken systems. Let me think about it because as of now i am not quite sure if the idea is as great as it might sound at first glance. Not in terms of a feature... but in terms of "damage prevention". Not sure how to describe exactly but maybe you know what i mean. If something breaks, who fixes it? The user who might doesn't have the skills or advanced knowledge about linux and just wanted to happily use that feature to make klipper run on such an older distro, because he doesn't know how to prepare that distro to make it run the way like you did? That will cause heavy frustration on the users side because it rendered his system useless for that moment. Also my capabilities of testing is limited. I prefer to test each feature i include carefully and make sure it works (as) flawless (as possible) before i merge it into master. That gets really time consuming, if not impossible to achive, if testing includes special hardware or hardware+software combinations of any kind for example. So unless someone is willing to contribute that specific feature, who can test it throughoutfully AND is willing to maintain it in the future if stuff needs to be changed/fixed so i can maybe include it in KIAUH as some kind of "experimental" function in the advanced menu section, i have to say that this is probably something i won't get on to in the short run.

Grntrenchman commented

2021-10-22 11:40:08 +02:00

(Migrated from github.com)

I definitely understand where you're coming from. I'm mostly a script kiddie that's learned how to fix the scripts for the most part.
coming from an "I just want to run a script and have it work", that did it for me. I thought this would appeal more for you/your userbase, especially as you're targeting armbian, which is a SD-image orientated setup.

I did notice a lack of error catching in the script, lots of times a build/apt-get/python module would fail, but the script acted like no issue and continued, mostly when apt-get responded in a strange way, or I was missing a basic package. I can't really think of a way to catch problems, and for this type of move, there's no going back.

I guess I'd leave it as an option that appears if it's on an older version, with a big nuclear warning that this is a highly destructive hail mary for people who absolutely can't manage a newer base image (embedded devices etc.). It's much simpler for people with strange devices to run a script to do this. Even something like "Attempt distro upgrade" to be more clear that we're not sure of the outcome. I also don't really see the cross section of people who have an ancient distro, and are also using it for critical things, and are trying to get it to control their 3d printer.

The instructions I gave should work on anything Debian, much like your script. This is the official method, so it should be solid. I've tested it on the strangest hardware I could find (random android box, flashed with an ancient image for some sort of speaker repeater). no problem going from 9 -> 10 -> 11.

I'd be willing to run some tests against VMs. Not sure how I'd realistically emulate strange setups though.
Maybe include it as a separate script? I really think this can open up a lot more devices to being useful for klipper/octoprint etc. I know it did for me.

Ultimately, this is your project, and I fully understand not wanting to include something knowingly when you can guess how easily and badly it can damage someone's installation. I tried skipping 10, it didn't go well..

I definitely understand where you're coming from. I'm mostly a script kiddie that's learned how to fix the scripts for the most part. coming from an "I just want to run a script and have it work", that did it for me. I thought this would appeal more for you/your userbase, especially as you're targeting armbian, which is a SD-image orientated setup. I did notice a lack of error catching in the script, lots of times a build/apt-get/python module would fail, but the script acted like no issue and continued, mostly when apt-get responded in a strange way, or I was missing a basic package. I can't really think of a way to catch problems, and for this type of move, there's no going back. I guess I'd leave it as an option that appears if it's on an older version, with a big nuclear warning that this is a highly destructive hail mary for people who absolutely can't manage a newer base image (embedded devices etc.). It's much simpler for people with strange devices to run a script to do this. Even something like "Attempt distro upgrade" to be more clear that we're not sure of the outcome. I also don't really see the cross section of people who have an ancient distro, and are also using it for critical things, and are trying to get it to control their 3d printer. The instructions I gave should work on anything Debian, much like your script. This is the official method, so it should be solid. I've tested it on the strangest hardware I could find (random android box, flashed with an ancient image for some sort of speaker repeater). no problem going from 9 -> 10 -> 11. I'd be willing to run some tests against VMs. Not sure how I'd realistically emulate strange setups though. Maybe include it as a separate script? I really think this can open up a lot more devices to being useful for klipper/octoprint etc. I know it did for me. Ultimately, this is your project, and I fully understand not wanting to include something knowingly when you can guess how easily and badly it can damage someone's installation. I tried skipping 10, it didn't go well..

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: h3n3/kiauh#128