You are not logged in.
The report has been received and assigned to #454: https://bugs.devuan.org/cgi/bugreport.cgi?bug=454
With thanks to ralph.ronnquist for not complaining about my crappy bug reporting skills :-)
I had issues with my hardware not being compatible with trousers. It was dependant on tss2 but debian stable is only tss1?
Try https://pkginfo.devuan.org/stage/beowul … 1.3-2.html instead, trousers is now obsolete.
Was not systemD introduced as a unification of hosts and their API and also as an easy method to pawn them and control from hardware agencies trojans too (virtualization bootkits in UEFI, boot storage controllers, may be injected by proprietary software like browsers, etc.) ?
Vulnerabilities in UEFI and hard drive firmware operate below ring 0, the init system is irrelevant in those cases.
how is it possible then to keep installation free of systemD without Devuan like patches?
They pin systemd to -1 and have a separate "nosystemd" repository for packages that usually depend on systemd but are repackaged without that dependency.
it seems antiX is dependent on Devuan work
Not directly, they just take advantage of the elogind package that the Devuan developers helped introduce into Debian.
All real work to clean out code infected by systemD is done in Devuan and most likely even Slackware reuses it, e.g. eudev.
Gentoo are responsible for eudev: https://wiki.gentoo.org/wiki/Project:Eudev
And please stop referring to systemd with a capital "d", it's really beginning to get to me...
I added entries to /etc/resolv.conf
What exactly did you add the /etc/resolv.conf?
I could start a terminal when running as root and that would give me a type of root terminal
That's just silly, use sudo -i to start a "root terminal".
my bash script that re-assigns their 'normal', 'ethX' names
That is entirely irrelevant for this thread but if you must post long scripts then please use code tags, guide here: https://dev1galaxy.org/help.php#bbcode
And anyway why not just use the net.ifnames=0 kernel parameter to force the traditional interface nomenclature? Note that this is not needed for Devuan, which uses the old style naming scheme by default.
The neofetch script grabs that information from the output of lsb_release -a so you should check that output and if it's wrong then file a bug against the lsb-release package in ceres.
But as I made changes and got upgrades/updates etc
Ah, the joys of the development branches :-)
Check the reported screen size & DPI:
xdpyinfo|grep -A1 dimWhich desktop environment is this? Check to see which packages were updated.
mckaygerhard wrote:currently i used Devuan Jesie.. that have lack of good multi language support but works more lighter of course.. and have less systemd shit rather than ascii
Devuan does not have any systemD in any of its released including Jessie.
How about https://pkginfo.devuan.org/stage/jessie … eb8u7.html?
AFAIUI it's not actually used at any point but it is needed to satisfy the dependencies for other packages.
Please post the verbatim error messages rather than vague descriptions, it's easier for you and less confusing for us.
I wonder how is it possible to use such a distro in production
Well Alpine is very popular indeed, it's the default image for Docker. And it's fundamentally incompatible with systemd thanks to the musl libc base.
Sure Alpine package integrity is verified before installation, but after files have been installed how to verify them once again say like by
wajig integrity
in Devuan?
Individual packages can be verified after installation:
apk verify $packageIt seems to miss binary compatibility with other distros which is not convenient but at least overcomeable by building from source.
Have you actually tried building much software from source using a musl libc base? Most software is intended for use with GNU's bloated libc variant and so might not compile under musl without patching.
I can easily configure services in any distro free from systemD
Yes but it is irritating to have to disable services after installing packages. And it's spelled "systemd" btw, it doesn't end with a capital "d".
But there is much more security in OpenBSD
Yes indeed, unlike the Linux devs the developers of that operating system prioritise security over shiny new features.
But it's not perfect: https://madaidans-insecurities.github.io/openbsd.html
See also https://madaidans-insecurities.github.io/linux.html
Need to configure AppArmor.
AppArmor is enabled by default for Debian buster and I think Devuan's beowulf release will also follow that path.
Btw, is it possible to rebuild a complete workable subset (like for a mini debootstrap) of Devuan/Debian packages for i586?
I don't think so but I may be wrong.
Why not having a Linux distro with default configuration similar to OpenBSD, which is the most secure by default and any custom change would be an opt out of security rather than opt in?
Arch is similar to OpenBSD in that respect — no services are enabled automatically, unlike Devuan & Debian.
But the main problem with security in GNU/Linux is that the kernel devs just don't give a damn: https://lkml.org/lkml/2008/7/14/465
Alpine seems to be less rolling than Arch/Parabola but it lacks installed files verification too.
Alpine Linux do offer an edge branch which is rolling but their stable release schedule is about every six months. They do sign their repositories though and apk verifies the packages before installation. Alpine Linux rocks but the musl libc base might prove slightly limiting.
That message suggests that you did not select a mirror during the installation process so the installer left the CD-ROM source entries enabled.
Use
# apt edit-sourcesthen remove the CD-ROM lines and add some repositories as per https://devuan.org/os/etc/apt/sources.list
But I really don't recommend VirtualBox, it's the worst virtualisation solution around and was removed from Debian's stable release because the VB devs don't give a crap about security issues: https://bugs.debian.org/cgi-bin/bugrepo … bug=794466
I would recommend QEMU/KVM instead: https://wiki.debian.org/KVM
That's the same kernel configuration as is used by Arch's linux-hardened package, which no longer includes firmware blobs.
You can build your own kernel with that configuration by following https://kernel-team.pages.debian.net/ke … n-official
Is gentoo-hardened still more secure than Devuan when used with the same anthraxx kernel ?
What makes you think Gentoo is more secure than Devuan? Their PaX integration is no longer officially supported now that grsecurity have moved to a paying model.
# apt install binutils[ 12.272] (==) Using config file: "/etc/X11/xorg.conf"
Remove that file.
PATH is still messed up, most commands don't work in console.
How is your PATH "messed up"? Which commands don't work?
To help us understand the problem please log in as your normal user and show us the output of
echo $PATHThen run this command and post the PATH again:
su -^ That should result in the /sbin directories being included.
Could this be related to the start of /dev/sda?
Sector 2048 is the optimal start point for a correctly-aligned drive.
It still sounds like there is a config problem at a very deep level
It's just that xbacklight doesn't work with the modesetting driver. That wouldn't matter at all if the kernel supported the hardware properly and provided the correct interface for the keyboard backlight controls. If the laptops are very old then this might be due to regressions, or perhaps the kernel just never worked properly with those machines.
I'm not going to engage in any debate on this issue but I'd just like to point out how monumentally ill-informed that TechRepublic article is — the author claims that v245 of systemd is still in RC status but it was in fact released two months ago: https://github.com/systemd/systemd/releases/tag/v245
See also https://wiki.archlinux.org/index.php/Systemd-homed (and note that it has to be enabled and configured, it's not a default).
Any idea as to what is wrong with line 9?
No, looks fine to me. What does this say:
findmnt --verify --verboseWhy does the swap file have priority -2?
I think that's the default value, swapon(8) claims the default is -1 but it's always -2 when I try to create a fresh swap partition.
And btw you appear to have a swap partition rather than a swap file.
When it's ready... ![]()
Changing the prompt (PS1) is another option, for example: https://unix.stackexchange.com/question … st-via-ssh