The officially official Devuan Forum!

You are not logged in.

#1 Re: Other Issues » should I use unattended-upgrades? » 2024-04-15 12:15:39

FWIW, I've been running unattended-upgrades on several machines for over a decade, and have no significant borkage (aside from a recent Devuan identity-crisis SNAFU with unattended-upgrades itself) to report.
Then again, the only machines I don't have convenient physical access to have IMPI. If SSH was the only way I could administer a box, I'd likely be doing updates manually... Or at least restricting unattended-upgrades so it doesn't touch anything critical.

#2 Re: Other Issues » [SOLVED] libelogind-compat : Conflicts: libsystemd0 » 2024-04-14 10:47:06

libelogind-compat provides libsystemd0 (by symlinking libsystemd to libelogind), so they can't be installed simultaneously.
Without seeing full output (and please use code tags for such), I can only speculate that either:
* apt wants to replace libsystemd0 with libelogind-compat or vice-versa, but it can't because 'apt upgrade' won't remove already installed packages. A 'full-upgrade' or 'dist-upgrade' will.
* Something you are trying to install or upgrade depends on libsystemd0 specifically. There shouldn't be any of that in Devuan stable, but with unstable such things may well slip through from time to time.
That's why it's called unstable, and not recommended unless you are capable of and willing to deal with occasional borkage.

If you do in fact want to switch to libsystemd0 (the implications of which are up to you to research), try installing it explicitly with aptitude. It'll give you several possible solutions, one of which will likely be removing libelogind-compat and replacing it with libsystemd0.
Aside, aptitude's dependency resolver is often smarter than apt in situations like this and is usually worth a try, but it's probably not wise to use it for e.g. a full dist-upgrade on a stable sytem as it's solutions can be a bit... odd at times.

#3 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-14 06:08:55

The only thing I can really do is try to open eyes
...
saying all this here probably won't change much. Its futility unless enough people wake up though in general.

AKA, lots of preaching with very little doing. roll

The bare minimum line should be making all libraries optional for those dependencies I mentioed

In many cases these frameworks are already optional, via compile-time flags... Something which, for reasons that apparently escape me, you seem completely unwilling to consider.
Where they are not optional at compile-time, patches to upstream code would be required.

There is no standard facilty for making dynamic-linked library dependencies optional at runtime, because that's not how any of this works. The thing that is becoming most tedious of all is your insistence that there shouid be such a feature, and somebody other than you should see to it.

If you want everything built for you and served up in convenient packages, you get whatever the packagers decided on when they built them (or engage in constructive discussion where you disagree).
If you want control over compile-time options and patches, you run Gentoo or some other source-based distro.

Anything else is just blowing smoke. The tools to build a system the way you want already exist, if you're willing to put in the effort to use them.
Have you actually built and used a system without dbus and policykit, or is this all just idological bikeshedding?

All that said, if you want to be taken even remotely seriously on the idea of making such dependencies optional at the package management level (which would entail binary distros maintaining multiple variants of each affected package):
* What is your convincing technical argument for such a change?
* What do you propose replacing the projects on your "evil" list with? You want to drop dbus for example, so how should we do IPC?
* And, how is your proposed replacement (functionally) superior?
* How do you propose convincing 1000 upstream projects to drop features dependent on $evil_library or switch to your replacement?
* Who is going to do all this work, and does the benefit justify it? If upstreams aren't on board, who is going to write and test patches?

#4 Re: Devuan » liblzma CVE-2024-3094 » 2024-04-14 05:36:49

The only thing that's "hard" about modern Gentoo is the manual chroot-and-tarball install method, and that's no more difficult than Arch.
After that it's really just a CPU-time tax in return for the flexibility of building software the way you want it.

#5 Re: Devuan » liblzma CVE-2024-3094 » 2024-04-13 09:13:57

zapper wrote:

If I want a minimalistic system I have two choices...

OpenBSD or Hyperbola.

... Or NixOS, Gentoo, CRUX, Gobo, FreeBSD, or any other system that provides tooling to build packages locally with the configuration you want.
Were you motivated enough to do so, this can also be achieved with Debian/Devuan... It's just a bunch more work as the packaging tools don't really cater to global feature switches the way e.g. Gentoo USE flags or the nixpkg declarative build system do.

What you're really asking for appears to be a binary distribution where all the configuration and packaging work is done for you, yet the choices the maintainers make are precisely aligned with your preferences... That's not going to happen, regardless of how much you complain about it.

You want the Devuan developers and maintainers to fork and rebuild everything to run without $things_you_dislike, yet you're not even willing to properly define what you want or what would be needed to achieve it?
Not to put too fine a point on things: Get off the grass. roll

#6 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-13 08:05:10

kaiyel wrote:

how does Devuan avert attack surface expansion while the upstream becomes more dependency permissive to accommodate systemd?  Could it even be done without forking packages expressly for that purpose?

IMO (at least as a general problem), it doesn't and it can't. Most dependencies are decided on at compile-time, and changing them means forking (or at least rebuilding) packages.
Frankly I don't see where Devuan is going to get the manpower for that. It might be feasible to fork some particularly important packages where all that is required is a simple configure flag change or dropping a patch, but deciding where to draw the line is well beyond my pay grade.

IMO the better approach is probably working on projects like elogind, i.e. forking parts of systemd itself, keeping the good bits and replacing all the crap we don't want with ABI-compatible stub functions.
That's something that is and can continue to be a common effort between distros, and so long as it keeps up with systemd changes it should allow most packages from e.g. upstream Debian to be used as-is in Devuan.

The downside of course is that we'll have to keep fending off nutters grinding the "Why does Devuan have libsystemd0" axe without bothering to check where that lib actually comes from or what it does. tongue

zapper wrote:

polkit, systemd,  avahi,   dbus,  networkmanager,  pulseaudio,  pipewire, wayland,  java and their libraries
...
devuan cannot be used minimally and still have what i consider to be the correct functionality

You won't get both minimal dependencies and "correct" functionality with any binary distribution that in any way targets mainstream desktop use cases.

Desktop users want, at least for the most part, low-effort GUI support for things like wireless hotspots, VPNs, bluetooth / hotplug audio devices, network discovery, and prompt-free permission elevation for common tasks. In the current ecosystem that means using some or all of the "evil" frameworks you list.
This has nothing to do with "corporate influencers", it's simply the result of trying to cater to end-user expectations without massive code duplication or packaging workload.

That leaves either distributions that cater to minimalism specifically (which discounts most Debian derivatives and general-purpose distros right away) or building from source (i.e. Gentoo and derivatives).

Bitching about "bs corporate" whatever at every opportunity achieves exactly nothing. The only realistic way to have your cake and eat it (aka have only the features and dependencies you want) is to either rebuild all the affected packages yourself or switch to a source-based meta-distro.

zapper wrote:

They need to be told to suck it and force them to gag on it.

So why don't you go do that then. roll Ranting here is utterly futile, and serves only to bloat the thread with unproductive noise.
If you must vent your non-specific anti-corporate rage, I suggest you write your $government_representative.

#7 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-11 06:43:21

Personally I have no problem with library dependencies and dynamic linking, where it adds legitimately useful functionality and reduces code duplication.

But that's not what this is. Supporting sd_notify is little more than sending a simple datagram to a unix socket, and pulling in libsystemd0 for that one function is just about the definition of gratuitous attack surface.
But hey, why not double down, ignore the fact upstream has already said no because they don't want the dependency bloat, and go and patch it in regardless. The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward. roll

Then there's that other obvious elephant of course: why does init need an LZMA (de)compressor anyway? Init's job is managing daemons, nothing more... Right?

IMO far too many projects pull in dependencies because it's the easy way to implement a feature, with precious little regard for whether it's a good way... or whether that feature is even worth having to begin with.
That includes distro packagers turning on every optional build-time dependency flag they can find, which is a long-time gripe of mine WRT Debian. Patching upstream sources for even more dependencies is just taking this trend to its (il)logical conclusion.

#8 Re: Devuan » liblzma CVE-2024-3094 » 2024-04-02 03:25:18

I'm well aware of ldd potentially executing code, however in this case:
This is stable install, with supposedly clean copy of liblzma & co.
It's also a disposable VM, because I'm not a complete idiot.
The point here is not to run ldd against compromised xz libs (everybody should have downgraded already on real systems), but to explain how liblzma is loaded into sshd and clear up the "devuan == safe" thing (which IMO is somewhat misleading).

liblzma is an indirect dependency here, so using objdump and friends instead is awkward.

#9 Re: Other Issues » Package name extension "t64" in excalibur » 2024-03-31 17:04:53

64bit time transition.
Now is not a particularly good time to volunteer your main rig as a testing/unstable guinea pig, at least not if you want to get anything (besides being a guinea pig) done.

#10 Re: Devuan » liblzma CVE-2024-3094 » 2024-03-31 16:34:14

It's pretty trivial to just go check what /usr/sbin/sshd links against for yourself, is it not?

e.g.
with libsystemd0:

$ ldd /usr/sbin/sshd | egrep 'systemd|lzma'
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)

and with libelogind0 + libelogind-compat:

$ ldd /usr/sbin/sshd | egrep 'systemd|lzma'
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f8dfc5b8000)

ldd is not the be all and end all, but in this case it's fairly obvious whether or not liblzma (and a bunch of other extraneous crap systemd needs) is going to be loaded by sshd.

IOW:
Stable: Never shipped compromised xz packages.
Unstable/testing with libsystemd0: Probably as vulnerable as Debian.
Unstable/testing with elogind: Probably not vulnerable (but you should absolutely roll back to a pre-compromise xz anyway).

Aside, this is all assuming that sshd is the only target. It does look that way at the moment, but investigation is still underway.

#11 Re: Devuan » liblzma CVE-2024-3094 » 2024-03-31 14:51:34

libsystemd0 is not installed in Devuan - at least in Daedalus

sshd in daedalus depends on libsystemd0, which may be satisfied by either the real libsystemd0 or by libelogind0 and libelogind-compat.
The former results in sshd being indirectly linked against liblzma as it is in Debian (though I'm not sure if that alone is enough to allow the exploit), the latter does not...

So effectively, both comments are correct depending on the exact set of packages you have installed. Devuan does pull sshd from Debian, so it does link against libsystemd. However the stripped-down copy of that library provided by elogind doesn't load liblzma, because its systemd-notify functionality is a stub.

In any case this is largely academic, as daedalus never shipped the compromised xz versions.

#12 Re: DIY » Lowest memory footprint obtained. » 2024-03-30 11:27:47

My 486 runs KDE in <32MB...
To be fair that's KDE 1.1 on Slackware, but it is a full-featured DE. tongue

Then again, RAM is cheap these days. So long as it's being used to good purpose, there's little sense in fussing over numbers.

#13 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-03-30 10:37:53

targeting deb and rpm via systemd?

More accurately, targeting sshd (so far, anyway) via a vulnerable understaffed/funded project which just happens to provide attack surface because certain distros patched a security-critical package to add gratuitous linkage to systemd.

This is not about diversity, or even systemd specifically. It's about dependency bloat.

There is zero reason sshd needs to link against anything in systemd, let alone pull in liblzma just to support systemd-notify (and linking a full blown compression lib just to say "sshd is up" to systemd is another level of insane to begin with). Doing this kind of thing opens it up not only to vulnerabilities in such direct dependencies, but also the 9000 other frivolous things those in turn link to.

This is a perfect example of why anyone serious about security resists bloat and feature-creep. Without the ridiculous "because it's there" attitude of the distros involved (particularly WRT systemd integration), this exploit would not have been possible.
If sshd really needed systemd-notify support (and it doesn't), it should have been via a minimal implementation in sshd itself, not pulling in a bunch of bloat and a compression library essentially maintained by one dude.
Distros patching this kind of stuff in downstream is, frankly, pretty irresponsible.

For a quick illumination of just how out of hand this is getting in Debian/Devuan...

$ cat /etc/os-release; ldd /usr/sbin/sshd 
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)"
NAME="Devuan GNU/Linux"
VERSION_ID="5"
VERSION="5 (daedalus)"
VERSION_CODENAME="daedalus"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
        linux-vdso.so.1 (0x00007ffc96fde000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f27a6768000)
        libwrap.so.0 => /usr/lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f27a675c000)
        libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f27a672b000)
        libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f27a6719000)
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f27a6619000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f27a65c7000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f27a64ed000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f27a64e7000)
        libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f27a6000000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f27a64c8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27a5e1f000)
        libnsl.so.2 => /usr/lib/x86_64-linux-gnu/libnsl.so.2 (0x00007f27a64ab000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f27a64a3000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f27a6497000)
        libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f27a5cd8000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)
        libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f27a5bed000)
        liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f27a5bc7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f27a68ec000)
        libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f27a5b2d000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f27a5b00000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f27a6487000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f27a5af9000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f27a5ae8000)
        libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007f27a5aba000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f27a5a92000)
$ cat /etc/os-release; ldd /usr/sbin/sshd 
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
VERSION_ID="2.14"
        linux-vdso.so.1 (0x00007ffd3cde1000)
        libcrypt.so.2 => /usr/lib64/libcrypt.so.2 (0x00007f18fdd74000)
        libpam.so.0 => /usr/lib64/libpam.so.0 (0x00007f18fdd63000)
        libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007f18fd800000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f18fdd47000)
        libc.so.6 => /usr/lib64/libc.so.6 (0x00007f18fd62f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f18fdec5000)

Which of these do you think has the larger attack surface, or more vulnerable supply-chain? I'm not even trying with that Gentoo build, and I could easily drop pam if I did.

#14 Re: Hardware & System Configuration » Reliability of desktop vs enterprise drives » 2024-03-14 22:26:32

Are there important reasons not to use an enterprise drive in a desktop?

Noise and power consumption... If those matter to you.

My understanding was that RE drives have a shorter 'fail' timeout of sector errors... Is there any other possible disadvantage of these for normal users?

I really don't see how TLER is a disadvantage in any scenario. It's also adjustable in most enterprise drive firmware.

#15 Re: Off-topic » What do you think about electric cars? » 2024-03-06 11:14:18

sun to produce H2

Ahh the old hydrgen drum...
* Extremely low energy density.
* Requires exotic tankage or cryogenics for any attempt to overcome (1)
* Is very, very energy inefficient to produce by any current "green" process (which is why most industrial hydrogen is produced through reforming natural gas).
* Is a complete bastard to work with, as it's low molecular weight means it leaks through just about everything.
* Is arguably more dangerous than either petrol or lithium-based batteries, due to its broad explosive range.

If you want to use solar to run a car, frankly you're better off with batteries for most use cases.

one-person-plus-one-child cars

bicycle... bicycle... bicycle... ad nauseum

Tell that to people who need to move a couple hundred Kg of tools and equipment for their job... Or travel from outside of urban centres... Or have more than one child... Or a disability...  Or point-to-point freight in general for that matter... Or any number of other situations where tiny vehicles or bicycles are completely inappropriate.

"Pedal power" is part of the solution. It's a long way from the whole story. Likewise rail and electrified public transport.
Just continuing to shout "everyone needs to get on a bike" is exactly as effective as "everyone needs to get an EV", all it does is make transport of everything too heavy or distant to put on a bicycle somebody else's problem.

Driving a 2-ton SUV to get milk is patently ridiculous... But so is insisting that everyone should ditch their private vehicles and "just get a bike".

has been around since 1879 on the railway with now only 20% of the energy consumption of the trucking industry.

Indeed. Even leaving out the electric part and comparing diesel trains to diesel trucks it's no contest.
What trains can't do however is roll up outside your house with whatever tat you ordered on amazon 2 days ago. The current lazy online shopper generation is fuelling road transport pretty hard right now.

As ever, what people really want is a "Buy now and fix climate change"/"Spend and feel morally superior" button. Big corporate (and EV manufacturers) are of course all too happy to oblige, and governments to turn a blind-eye to how ineffectual all that is so long as they can be seen to be promoting something with a nice thick coat of green paint on it.

Meanwhile the real elephants in the room (of which private transport is decidedly small-fry) go conspicuously unnoticed, and the solutions we do have go unimplemented, largely due to being expensive or inconvenient - either personally or politically.

#16 Re: Installation » [SOLVED] Beowulf to Chimaera - precautions » 2024-03-06 07:16:23

To use Clonezilla, you would need to boot to a live CD/DVD/USB system that (preferably) comes with Clonezilla.

Or just use clonezilla live, which is lightweight, Debian-based (though that also means systemd, unfortunately), and allows for things like easy creation of bare-metal recovery media.

On the OP... The only way to be sure is to send it. Personally I have machines that have been dist-upgraded all the way from Lenny, and while there are always things to attend to they are usually pretty minor and far less trouble than a fresh install - especially if you avoid leaving it until you are multiple releases behind stable.

Either way, if you don't like the result you just restore your backup (or swap drives if you go for a live clone). No harm, no foul.

#17 Re: Off-topic » What do you think about electric cars? » 2024-03-06 06:44:58

Electric traction? Sure. We've had that in various forms for ages, and advances in battery technology have now made it viable (if still a mite explodey) for the private automobile.
Electric traction as the solution to anthropomorphic climate change on the other hand... That's just another episode of the same old consumerist "magic pill" bullshit... See quickfur's excellent coverage above.

Now, that's not to say I wouldn't want to own an electric vehicle. They do have some advantages, particularly where relatively clean electricity is cheap and charging infrastructure isn't woefully inadequate.

However... As far as I can see, it's next to impossible to really own any modern vehicle, regardless of powerplant. So if someone would like to point out an EV that isn't a rolling spyware platform full of obnoxious "safety" features designed explicitly to piss me off and prevent my vehicle from doing what I tell it to, I'm listening...
Otherwise I'll stick to my simple, obedient '70s and '80s tech. No cameras, no GPS, no manufacturer phone-home or remote killswitches, no feature subscriptions, no touchscreens, no driver attention monitoring, and most important of all, no goddamn incessant beeping about every trivial thing.

As for fission vs (fossil fuel) combustion, "clean"ness and timescales... Sure. The only missing component there is that we have some viable solutions for processing and containing spent fission fuel on the table. Carbon capture and storage on the other hand is a complete joke if you take even a cursory look at the numbers (and volume) involved.

#18 Re: Hardware & System Configuration » Daedalus 5.0.0 desktop-live shutdown problem » 2024-03-02 12:23:47

Whether the blacklist completely disables it, I don’t know.

I doubt it.

“CONFIG_TCG_TPM=y”

Indicates TPM support is compiled in, so blacklisting modules will not disable it unless an additional driver (compiled as a module) is also required for this hardware.
Easy enought to test though, just recompile the kernel with that option unset.

#19 Re: Installation » Installing from src and apt » 2024-02-11 01:28:22

Altoid wrote:

It has already made it to Debian trixie and as a result, to Devuan ceres.

If it's already in unstable, 99% of the work is done and the best option is probably a simple backport.

Altoid wrote:

gdebi says there is a dependency problem - version of libc6 needs to be higher than the one installed.

That's only because the binary was built against that version, a problem which will go away by itself if you recompile it as above.

#20 Re: Installation » Installing from src and apt » 2024-02-10 17:22:44

Suggestion 1: Build a proper Debian package, based on the version available in the repos. If it's just a version bump (i.e. no new dependencies), the 'uupdate' utility from devscripts makes this very easy.
Quick version (details in relevant manuals or here):
Get the source tree for the existing package with your choice of apt-src, apt-get source, dget, or manual download and unpack, and the new upstream tarball.
Run 'uupdate' from the source tree top level (i.e. beside "debian"), giving it the new upstream archive.
Fix any patches, where applicable.
Update the changelog with 'dch'.
Build the new (unsigned) package with 'dpkg-buildpackage -b -us -uc'.

Suggestion 2: If all you want is a .deb and you don't care how nice it is (or intend to redistribute it), just use checkinstall. Does much as boughtonp described above, but with more magic and less manually finding all the files 'make install' drops.

#21 Re: Other Issues » [SOLVED] Devuan 5 Installation without Grub » 2024-02-01 10:34:59

aluma wrote:

All the user needs to do is point the mouse.
Envy, honestly.

Yeah, nah. Why?
First you need a mouse and a GUI, both of which make it a non-starter for serial console or SSH on headless machines. Then you've got the not-uncommon gpu-driver/KMS shenanigans, and on top of that you're dependent on a particular tool on a particular live disc that you will sooner or later not have handy.

That's without even starting on all the fun to be had with "automatic" repair tools if the system has an unusual bootloader, custom boot configuration or chainloading, RAID, root-on-ZFS, netboot, the list of things such tools will probably either not handle properly or completely louse up goes on.

OTOH, pretty much every bootable GNU/Linux media in existence has mount and chroot, and once you're in that way you have all the tools and existing configuration of the installed OS right there.
You also have the opportunity to fix the problem properly the first time and verify that the installed tools (i.e. update-grub, update-initramfs, dpkg configuration etc.) can reliably update the bootloader for next time.

Why reinvent a perfectly good (and not particularly oft-used) wheel just to make your mouse pointer feel useful?

aluma wrote:

Maybe there is a way to run refractainstaller only to install the bootloader?

Or you could just chroot in and do 'dpkg-reconfigure grub-[insert platform]', which is pretty much how d-i installs the bootloader anyways and should suffice for most scenarios.
Personally I have no use whatsoever for refractainstaller, but if I were a betting man I'd say that's what it calls for the bootloader step too.

#22 Re: Other Issues » [SOLVED] Devuan 5 Installation without Grub » 2024-02-01 04:02:08

Short version for general fixing of bootloaders or otherwise unbootable installs: Boot a livecd with a similar-ish kernel version (e.g. matching install media), chroot into your install, install/fix/reconfigure bootloader.

Generic UEFI version here, or many other places on the 'net. Anything more specific would require more information on your install partition layout etc. etc.

#23 Re: Devuan » Praise for the security updates » 2024-01-26 12:12:21

if a window is hijacked, X11 also leaks the data from the other windows to the attacker.

That's not a bug, it's a design decision.
X was not developed for personal computers, it's fundamentally a graphical mainframe technology. In that scenario the trust model is inverted WRT a PC - i.e. the network is secure, applications are served from the mainframe and implicitly trusted, the terminal running the xserver is not.

X is as secure as it has ever been and (at least for now) it's still getting patches for any newly discovered issues, but the core design concepts don't transfer particularly well to the age of software-as-an-enemy... Then again, as long as you don't run untrusted applications that might want to screenscrape or keylog you, you're fine.

#24 Re: Documentation » How to: Devuan 5 Daedalus an pipewire » 2024-01-23 18:09:33

I kinda did, a few posts earlier in this thread:

steve_v wrote:

using daemon to manage pipewire (and cdemu, which has the same problems). Binding to the user session requires [e]logind and backporting daemon from unstable

daemon has very few dependencies, so a backport is trivial.

#25 Re: Documentation » How to: Devuan 5 Daedalus an pipewire » 2024-01-23 09:20:30

mirrortokyo wrote:

This seems to be a bit of a rough hack.

It is, and writing custom shell hacks for every user-session "daemon" that doesn't bother to behave like a daemon because systemd user units exist isn't a particularly elegant or sustainable solution.

If Devuan is going to transition to pipewire following upstream Debian, we're going to need a better answer than "user finds random script / autostart / .xinitrc hints on the 'net" for starting and stopping its services.
IMO some kind of process supervisor (be it part of an init system or standalone) is the only realistic (and reliable) option, and I already mentioned one possibility. Another might be adapting supervise-daemon or runits runsvdir, or running dinit in a user-session context.

This BS is only going to become more common, pipewirwe is just the thin end of this particular freedesktop/redhat/ibm wedge.

FWIW (in case I haven't mentioned it already elsewhere, which I probably have) my current solution is daemon, and these three lines:

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber

In 3 autostart files (or wherever else you might want them).

Order no longer matters and sleep / while loop hacks are eliminated, because --respawn.
Pipewire not exiting with the user session is fixed (without pkill hacks), because --bind.
Pipewire not doing any of the other things a daemon should do (like writing a pid file or detaching from stdout and forking into the background) is also fixed, and --name and --pidfiles allow for e.g.

$ daemon --list --verbose
cdemu is running (pid 4577) (client pid 4578)
pipewire is running (pid 4573) (client pid 4574)
pipewire-pulse is running (pid 4568) (client pid 4572)
pipewire-wireplumber is running (pid 4547) (client pid 4549)
systembus-notify is running (pid 4583) (client pid 4587)

If you don't want pipewire noise in your xsession log (or want it in it's own logfile), daemon can fix that too with the --output, --stdout, and --stderr switches.

The cost for all this convenience is ~170KB of memory per managed process (on-par with supervise-daemon). Make of it what you will. As much as I like shell, IMO this is a much cleaner solution.

Board footer

Forum Software