You are not logged in.
A few days ago I had to install libc-2.32 and the dependencies from Ubuntu just to solve dependency problems with the Firefox plugin Scrapbee. It works great.
Until there is a vulnerability in glibc that will not be corrected on your system because your version is seen as "newer" than the fixed package — that would then expose pretty much every program on your system to the vulnerability.
You also now won't be able to install any packages in Devuan that depend on libc6 <v2.32 and you may experience strange problems because the Devuan packages are expecting a different API version for glibc.
I have never experienced any stability issues related to oldstable distro problems though using all backports too.
Absence of evidence is not evidence of absence. You have been lucky. So far.
Is there a command which could downgrade or at least indicate a list of all backported packages
aptitude search '?narrow(?installed, ?archive(ascii-backports))'Do you mean that it is better to narrow upgrades to backports only for a very few set of packages which are needed very much?
Yes, that is the official recommendation from the Debian developers:
Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!
It is therefore recommended to only select single backported packages that fit your needs, and not use all available backports.
Any quick and easy reference to the pros/cons of the three?
Not that I know of.
Note that the situation in respect of ksh93 & ksh2020 has changed since my quoted post — the development of ksh2020 has been stopped because the KornShell community complained about the management of the project and also noted some performance regressions:
https://github.com/att/ast/issues/1449
So as of now the only currently developed KornShell implementations are mksh and OpenBSD's ksh. The packages supplied by my repositories are a Linux-specific port of OpenBSD's ksh (loksh) and a port of the same software by one of the OpenBSD developers which is designed specifically for usage with any operating system. The mksh package in De{bi,vu}an was created by the developer of mksh, who is also a Debian developer.
To enable expressvpn as a daemon in sysvinit you use
I'm fairly sure that the postinst script for the .deb package will do that automatically via dh_installinit(1).
This sounds like PEBKAC so please also post your sources:
apt-cache policyapt-get dist-upgrade -t=ascii-backports
Attempting to upgrade the entire system from a backports repository is a really bad idea.
What is the disposition of your sources?
apt-cache policySo what happens if you start it manually?
expressvpn statusDoes that work or do you see any error messages?
Check if it's running with
pgrep -a expressvpn && echo 'It's running' || echo 'Not running'I use open-rc and I am able to control services with "service $service start|stop|restart|status".
That also works under sysvinit, I only used a direct call to the service script because it was slightly less ambiguous than posting
# service $service restartExpressVPN released a new .deb (expressvpn_3.4.0.62-1_amd64.deb), which resulted in the following error when I tried to connect
Can you share the content of /etc/init.d/expressvpn for the new version?
If you don't want to install it again then you can extract the file with
ar x expressvpn_3.4.0.62-1_amd64.deb
tar xf data.tar*
cat etc/init.d/expressvpnNote the lack of a leading forward slash for the path on the last command — etc/init.d/ is relative to the current working directory, the full path should not be used.
What's the Devuan equivalent?
There is no equivalent for sysvinit because that doesn't have a dependency tree to rebuild or any socket management to reset. It's fine to just restart the init service though:
# /etc/init.d/$service restartReplace $service with the actual name of the service.
What is the actual problem that the support staff are trying to solve? There might be a sysvinit-specific solution for it.
there is a directory "/etc/systemd" but is that actually in use or is it an artifact from Debian?
That directory is for enabling & masking unit files and also for local units and the systemd configuration files so I don't think it's used at all in Devuan.
i appear to have installed Devuan without efi ...I think...it was two years or more since i installed so cant remember
Check for /sys/firmware/efi, that will only exist if you are booted in UEFI mode. You could also use parted --list and see if you have any EFI system partitions (which will have the "boot,esp" flags) — UEFI booting is not possible without an ESP.
Sooo, if I was being a purist I'd try to ignore that file as it was driven by the systemd changes to Linux.
You are free to ignore it but any applications that rely on it may not be pleased if it's malformed or missing and you may experience some strange behaviour or even dysfunction.
Is/was there an pre systemd equivalent and where would i find it on Devuan ?
/etc/debian_version & /etc/lsb-release spring to mind but I'm in OpenBSD at the moment so I don't know how Devuan handles those files.
Did you try installing sysvinit-core before attempting to install eudev?
See if you can guess who created the file. [Spoiler Alert!]
Read os-release(5) for the implementation details.
Note that any edits to the file will be over-written whenever the base-files package is updated. EDIT: actually dpkg might ask you what to do with it if it has been edited.
it seems like a lot of work for --- what, exactly?
Resource control via cgroups is useful (although also possible with OpenRC, runit, s6, etc). I really like that all logging is unified in the systemd journal, which provides a nice interface and a filtering mechanism that doesn't require you to be a regex expert.
It's also easier to check which services are enabled and active and simpler to enable and disable services. Masking services can be useful if you really don't want them activated under any circumstance.
Custom .targets are nice, although again that can also be done with OpenRC.
For some other opinions see https://bbs.archlinux.org/viewtopic.php … 0#p1149530 & https://grml.org/faq/#systemd
EDIT: and this from Mr. Poettering himself: http://0pointer.de/blog/projects/why.html
The non-free firmware is supposed to be present on both the live and netinstall ISO images, at least according to https://www.devuan.org/get-devuan
Can you provide the exact URL from which you downloaded the image?
Hello and welcome to the forums :-)
SystemD
It's spelled "systemd" actually.
the intelligence test
There's a test now? *worried look*
iwlwifi-7260-17.ucode
That's not a "driver", it's a firmware file. Perhaps consider changing the thread title. The file is supplied by the firmware-iwlwifi package.
Or just rename the directory and create a new boot entry for it:
# efibootmgr --create --label "Devaun Secure Boot' --disk /dev/sdX --part Y --loader \EFI\debian\shimx64.efiReplace X & Y with the drive letter & partition number assigned to the EFI system partition. The command assumes this to be /dev/sda1 so those options can be omitted if that is the case.
**** me, I agree with that twat Russel Brand. This truly is the End of Days.
Secure boot should work out of the box for Devuan beowulf with no special configuration needed. Just boot the machine in UEFI mode with Secure Boot enabled and make sure that the target drive has either a GUID partition table (GPT) or no partition table at all.
https://www.debian.org/releases/stable/ … ecure-boot
If you want to pre-partition before installation then use a GPT disk and make sure it has an EFI system partition. I prefer to create the partition table using gdisk, which uses the EF00 code for the ESP. For {g,}parted the "boot,esp" flags should be applied. The FAT filesystem should be used for the ESP but the installer will do that for you and mount it under /boot/efi.
I don't see much sense in using the backport kernel as it (afaik) does not get regular security updates
The backported kernel is drawn from testing and is updated from there so it's usually a couple of weeks out of date but that's surely better than having to keep track of upstream manually and compiling a fresh kernel locally every time there's an update.
However, the packages in Debian unstable (5.10 currently or very likely also 5.9 in backports) do *not* work as the kernel is compiled with said configuration parameter that prevents the display from working.
Sounds like you should submit a bug report to Debian then. Just be sure to reproduce the issue with a Debian system, some of the developers can be funny about bug reports from Devuan users.
Does the Pinebook Pro need kernel 5.10? 5.9 is currently available from the beowulf-backports repository:
https://pkginfo.devuan.org/cgi-bin/pack … -1~bpo10+1
^ That would obviate the need to compile the kernel and would also ensure that the user isn't left running an increasingly outdated kernel in the future.
And in respect of this statement:
Using further deblobbed sources (e.g. Linux/Libre or cleaned trusted firmware) has not been tried.
Note that the stock Devuan kernel is already fully de-blobbed, that's why the non-free firmware is supplied in separate packages. The "Libre" [sic] kernel has had the ability to load firmware blobs removed so it would not be possible to get the wireless card working, unlike with the Devuan kernel.
See https://wiki.gentoo.org/wiki/Comparison_of_init_systems
It may be worth noting that OpenRC is still under development and is being maintained by the Gentoo developers and used by Alpine Linux, which is massively popular thanks to docker, so there are many "eyes on the code". Sysvinit is no longer under development and is being maintained by Jesse from DistroWatch...
Having said that the OpenRC option in Devuan only changes the service manager, sysvinit still runs as PID1.