You are not logged in.
Pages: 1
Hi,
in order to be able upgrade a virtuzzo based vserver running Devuan ASCII 32bit i need something with a different libc than the glibc provided by the newer Devuan releases.
Reason: the installation is old, the container has been created unter virtuozzo 6. It runsmy main web and email server - so it is mission critical. After migrating the container to virtuozzo 7 (by my provider), the kernel shows up as 3.10.x. In order to be able to upgrade from ASCII i need a libc working with that given kernel API. However, Beowulf and Chimaera's libc both require at least an api as of kernel version 3.20.x.
AFAIK, musl libc has more relaxed demands on the kernel API. So if there was some Devuan based on musl that would open a possible upgrade path.
THX for any hints.
BTW: i just installed Alpine linux on an old eeePC 1016P with an atom n455 cpu and am impressed on the performance and moderate memory footprint. Even firefox is usable ... thats another reason to switch from glibc to musl libc.
Offline
I've been banging the musl libc drum for years now. GNU's libc version is bloated and just as guilty of feeping creaturism as systemd, IMO. In fact systemd relies on GNU's non-standard libc extensions for many of it's features, which is why musl libc is incompatible.
However, rebasing the distribution to musl would require rebuilding and repackaging the entire Debian distribution, including the toolchain, which is a stupid amount of work. Expecting the Devuan developers to take that on is just not reasonable.
Stick to Alpine, it's completely awesome and it's also one of the more popular Linux (not GNU/Linux btw, no GNU bloat in the stock system) distributions so it's not going anywhere in a hurry.
Brianna Ghey — Rest In Power
Offline
Mhmm the question was actually not sticking to alpine which i intend to install on a 2nd old machine (replacing chimaera) but that very specific virtuozzo instance which cannot be upgraded beyond ASCII (at least not without dirty tricks). And ASCII has already passed EOL. And that on a production server visible to the world.
Offline
Looks like you should have posted here instead then:
Brianna Ghey — Rest In Power
Offline
Why?
Thats for customers of virtuozzo, not for end users. My contract is with my provider and not with virtuozzo. So i would have to open a(nother) call with my provider, maybe regrding this (apparantly not possible in an running template even if the conatainer is not running).
Which might lead me to the conclusion that either hacking the glibc version test which should be harmless because the actual kernel api is a lot newer than the apparent one because the kernel is actually a lot newer might be a way out. One that i really do not like at all.
Offline
I'm uncertain if I understand the underlying issue, but for anything mission critical I would not upgrade live servers across distro versions.
I would instead recreate the server as an entirely separate instance on a current version, with a repeatable migration script so you can both test things before switching over and also have an escape route if issues are encountered after switching.
3.1415P265E589T932E846R64338
Offline
Pages: 1