You are not logged in.
The beowulf package tree is apparently ready, the thing that's being worked on right now are the install images themselves.
Promising, but I don't run betas on servers... And I don't run Devuan on desktops, because it's simply too out of date.
You can use debootstrap (ascii or beowulf version) to set up your system. That's the smallest and slickest install image available, seems to have no bugs right now.
Honestly, I don't care about install images. I run Gentoo on my desktop(s), I'm fine with a stage-1 tarball. I reinstall servers pretty much never.
What I do care about is running a LAMP stack that still has some measure of upstream support.
Maybe try Arch Linux?
Systemd-only, breaks constantly, requires hand-holding for the most minor of updates, community doesn't understand concepts such as unattended-upgrades or headless servers. Been there. Spent quite some time there in fact.
Seriously though, devuan is working slow and steady. That approach is good for stability. And general health of your systems
What's not good for the health of anyone's systems is having to pull in backports on release-day and resort to local compiles or third-party repos just to get, for example, a version of PHP that anyone anywhere is still using.
There's stability, and then there's being stuck with bugs, security issues, and compatibility problems forever. Debian walks a fine-line on this, Devuan is currently still a fair way over it.
Had this happened on a production server, I would have done the same or cancelled the upgrade altogether.
I did make a snapshot before the upgrade, ability to do so is the primary reason to use zfs for me.
Here's the thing: I do run devuan on production systems.
Snapshots are all well and good, but they're no substitute for properly maintained packages that actually work.
Here's what happens:
Bug is found in Debian package.
Upstream fix makes it into release before freeze, or is not considered worthy of backporting and lands in Sid.
Devuan is stuck with bug for another 2 years because it's tracking oldstable, which only gets critical fixes.
Snapshots are no substitute for shipping software components that are still receiving upstream security support either.
Debian, for example, despite the reputation for ancient packages, bumps their PHP packages roughly in-step (2 years) with upstream security support. Devuan is still shipping PHP7.0, which is now 5 years old and went EOL over a year ago.
How many large upstreams (e.g. all of e-commerce) do you think support running their projects on a stack released in 2015 and no longer receiving patches?
Some of them put up with Debian, because userbase. None make exceptions for Devuan.
Buggering about with polkit/gnome/whatever shiny desktop thing is wanted in the moment is all well and good. Sitting on a release to do so while the server side (i.e. the primary domain of GNU/Linux in general and Debian in specific) rots is not.
My policy is always use the official sources, only compile your own version if you absolutely need it and it isn't there in the official repos.
Or else why would I even be using an apt/dpkg based distro ?
I generally take the same approach, because I like unattended-upgrades. In the specific case of ZFS though, I was using it some time before it was in the (then Debian Squeeze) repos, so I already have a check version -> print new bugs -> compile -> install shell script lurking around. Kept using it when moving to Devuan because it was late into the repos (like everything else), and I don't see a point in changing now.
That and ZFS modules are something I want to manually vet updates for, because I'm a bit of a data-hoarder and my pool is important to me.
I know it's 0.8.3, and I am already packed and almost ready to move on to beowulf pastures, which has exactly that version in it's backports.
Frankly, I've been waiting for beowulf for far longer than I would usually have patience for, at this point my systems are on average only about 85% Devuan I've had to backport so many things.
Moral support is now pretty much the only reason I haven't given up in disgust and moved to something with a sane release cycle.
As much as I do understand the reasons, being stuck with a three year old Debian release for eternity does not make for a nice user experience. Still waiting for that beowulf stable thing...
I've solved the problem by installing insserv 1.18 from beowulf. That resolved the conflict and didn't break anything (that I would notice).
Personally I prefer to backport things myself and/or compile them locally over adding mixed-release sources. That's just me though, there's probably a bad experience behind the it somewhere in the distant past.
I just thought posting an exact problem report on this forum should suffice.
I would have thought the Devuan bugtracker would be a better place, but then the thing is kinda confusing to navigate considering the relationship with upstream Debian bugtracking...
I mean this is probably a Debian bug, right?
xinomilo wrote:Unfortunately (for me) i need 386 builds, and there is only amd64.
Just fudge it with equivs. Either use the dummy package as-is or build your own that symlinks opentmpfiles.
PHP-FPM from packages.sury.org doesn't really need systemd, some nit just decided to use systemd-tmpfiles because it's there... And be a dick about it when someone tries it where systemd is not installable.
It's probably time to retire the use of that repo if this kind of idiocy is going to continue (and I expect it will), but for now a dirty little one-line shell hack keeps the wheels turning.
Probably a bit late for you I know, but I'll leave it here for reference anyway.
FWIW (and admittedly not really an answer to your question), I find it far easier to just build ZFS from upstream sources than to muck about with backports and Debian/merged packages.
./configure --prefix=/usr --enable-sysvinit --disable-systemd
make
make deb-dkms
make deb-utils
dpkg -i ./*.deb
And you get a not-ancient ZFS build to boot. Upstream is at v0.8.3 right now, and there are some nice improvements over the crusty release Debian/Devuan is shipping.
ZFS works just fine on ASCII with insserv 1.14, and it has since 0.6.x, at least with the init scripts from upstream.
Dunno what's wrong with the distro packaging, I don't immediately see a bug report explaining the conflict either.
It looks like it might only be on Linux systems
For the record, I'm running firefox 64.0 without pulseaudio here in Gentoo paradise. The sound is excellent.
On the OP, I'd probably be around here more often if it wasn't for the disturbing level of tinfoil hat insanity that goes on. Some people really need to get a grip.
steve_v has long since left the building.
steve_v is waiting for a Devuan release that isn't 2+ years behind Debian, and he still gets mail alerts.
Meanwhile, he's running a systemd-free rolling release, one with a modern desktop that works properly now.
He's running Devuan on servers though, where appallingly ancient software isn't such a problem.
I like this Devuan thing, but it seems I've tried and failed to like any of the desktops that work properly with it.
KDE/Plasma runs, which is slightly surprising, but I've yet to convince it (or sddm for that matter) to do anything related to poweroff / reboot /suspend / hibernate.
It'll kill the session and that's about it. Having to switch to a VT and log is as root just to turn the machine off is a little lame in this day and age...
This is less lame than having to use some gnome derivative instead, but still pretty annoying.
I'm not (yet) familiar with the changes in Devuan, is plasma's power management functionality completely broken sans systemd or am I just doing it wrong?
Everything else appears to work, and the various blah-kits are doing their thing, at least as far as I can tell. There's some other layer between plasma and console-kit / upower etc. yeah?
Anyone had better luck here?
Off topic, what's the plan for the release cycle after stretch / ascii? Aiming for parallel with debian's stable releases or one behind? I'm guessing the former, as I hear rumors of tracking testing as well...
To downgrade, do I need to just change the name back to Jessie in sources.list and follow the steps again?
The answer to that question is going to be exactly the same as it is for Debian: No. If the packages installed are higher versions than those in the repos, apt does nothing.
There is no easy way of downgrading a system, the packaging tools were simply not designed for it.
The is various chicanery one can play with apt pinning to force lower versions to be installed, but there are usually conflicts, and it's always a pain in the ass.
99% of the time, I'd say a reinstall is less hassle.
Or better yet, just make a backup / snapshot before trying out the new stuff.