Re: [DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
...on 2022-03-21 21:31:25, Bob Proulx via Dng wrote: > Alexander Bochmann wrote: > > because it seems the whole tmpfiles.d stuff is a systemd thing > > all around, and probably isn't even used on Devuan? I got confused > It happens to all of us at times. No worries. :) > However AFAIK the /var/lock/subsys directory is a Red Hat specific > directory such as found on RHEL and Fedora for use for their init > scripts. It doesn't have a use by other scripts. It is created by an Actually what brought me on this track turns out to be the init script for acct, which has: > LOCKFILE=/var/lock/subsys/acct > [..] > touch $LOCKFILE This is in turn run each night from the acct cron.daily script which rotates the accounting log files and restarts the service, producing a message that /var/lock/subsys/acct can't be touched... > And then a piece of software meant for Red Hat would run happily > without knowing it was on Devuan. At least for this portion. Thanks for the detailed explanation! Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
...on 2022-03-21 23:33:41, Alexander Bochmann wrote: > I am running some software that expects the /var/lock/subsys directory > to exist. It seems that this (and a few other directories) are created > by /usr/lib/tmpfiles.d/legacy.conf, which is owned by systemd in Debian, > and doesn't seem to exist in Devuan, or at least on my machine? Hrm, sending that mail out might have been slightly premature, because it seems the whole tmpfiles.d stuff is a systemd thing all around, and probably isn't even used on Devuan? I got confused by existing config files which are shipped by a bunch of the Debian packages... Sorry for the noise, Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
Hi - I am running some software that expects the /var/lock/subsys directory to exist. It seems that this (and a few other directories) are created by /usr/lib/tmpfiles.d/legacy.conf, which is owned by systemd in Debian, and doesn't seem to exist in Devuan, or at least on my machine? If Devuan ships this file, does anyone know which package it belongs to? If it's missing completely, that's maybe something that should be fixed... Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] cryptsetup-initramfs "Try again later"
Hi - I've been converting a chimaera setup to an encrypted root file system with the option to enter the unlock passphrase via dropbear-initramfs. This almost works, except I'm running into the problem that the cryptsetup-initramfs script terminates with a "Try again later" message (unlocking the root fs from the console is still possible). This problem is being mentioned a few times, but without a real solution, like here: http://dev1galaxy.org/viewtopic.php?id=3642 http://maemo.cloud-7.de/irclogs/freenode/_devuan/_devuan.2020-02-09.log.html As quoted in the dev1galaxy thread, the code that displays "Try again later" is this, right at the top of cryptsetup-initramfs: > TABFILE="/cryptroot/crypttab" > unset -v IFS > > if [ ! -f "$TABFILE" ] || [ "$TABFILE" -ot "/proc/1" ]; then > # Too early, init-top/cryptroot hasn't finished yet > echo "Try again later" >&2 > exit 1 > fi After some poking around I found the --full-time option in the busybox ls, and it turns out that $TABFILE is actually a few seconds older than the /proc/1 directory in the initramfs on my system: ~ # ls -al --full-time /cryptroot/crypttab -rw---1 root root75 2022-03-21 00:54:12 + /cryptroot/crypttab ~ # ls -ald --full-time /proc/1 dr-xr-xr-x9 root root 0 2022-03-21 00:54:31 + /proc/1 When I then touch /cryptroot/crypttab to update the timestamp, the script runs successfully...? Does anyone have an idea why that happens? Is the cryptsetup-initramfs logic wrong, or did -ot at some point have less resolution and didn't look at the timestamp seconds? Is this something Devuan-specific for some reason? Searching the 'net only finds a small handful of results, and only in relation to Devuan. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] fail2ban running out of memory during beowulf -> chimaera upgrade?
Hi - this is not a Devuan-specific problem, since I've also had it happen when upgrading a Debian system: During the dist-upgrade process, fail2ban is restarted and then tries to do something with the previous sqlite database that's stored in /var/lib/fail2ban/fail2ban.sqlite3 by default. While working on the db, the fail2ban python3 process eats up all available memory, and gets killed by the oom killer, leaving behind a timestamped copy of the sqlite file. Depending on the size of the database, this cycle repeats quickly, using up (all) disk space on the way. The problem can be solved by just removing the old database file and restarting fail2ban. Did this hit anyone else? I haven't seen it mentioned anywhere, but I've run into this several times now. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
...on Wed, Jul 08, 2020 at 05:12:54PM +0200, Alexander Bochmann wrote: > ...on Wed, Jul 08, 2020 at 06:14:51PM +1000, Andrew McGlashan via Dng wrote: > > Using the /dev/mapper device name would likely have been just as good, > but I'm not sure as I didn't try that > I'll try if using UUIDs in the fstab makes a difference in the > boot process later tonight (and maybe why, if it indeed does). So yes, using a UUID for a split /usr mount (on lvm) in the fstab totally doesn't work. I'm landing in the "Begin: Running /scripts/local-block ... done." loop too, ending with "ALERT! UUID= does not exist. Dropping to a shell!" I apparently changed my fstab from UUIDs to the /dev/mapper symlinks some time in 2019, way before my upgrade to beowulf (possibly when I migrated that machine into a VM) - so at least for some configurations, this problem has also been present in ascii. Searching for the error messages, the hint to use device names shows up for older Ubuntu versions too, but I haven't found a good explanation why this happens. Initramfs scripting for lvm was never fixed to work with UUIDs? Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
...on Wed, Jul 08, 2020 at 06:14:51PM +1000, Andrew McGlashan via Dng wrote: > Using the /dev/mapper device name would likely have been just as good, but > I'm not sure as I didn't try that I'll try if using UUIDs in the fstab makes a difference in the boot process later tonight (and maybe why, if it indeed does). The system has been migrated from hardware into a VM some time ago, so I can recover easily. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
Hi, ...on Tue, Jul 07, 2020 at 02:00:38AM +1000, Andrew McGlashan via Dng wrote: > After the dist-upgrade, it failed to boot and remained at the ministrants > shell environment after having complained about not being able to find the > /usr file system via it's UUID. I have a system mostly like this (minus mdraid) with split root and /usr on lvm each, and didn't run into your problem. My fstab uses /dev/mapper device names instead of UUIDs, but I don't see why that should make a difference, seeing as it isn't used in the initramfs. (On the other hand, I usually use UUIDs too, so there might be a reason it looks that way, and I just don't remember about it right now...) Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] ascii > beowulf upgrade report (home server)
Upgraded my shell server at home yesterday, and ran into a couple of problems. None of them were specific to Devuan though, as far as I can see - all the affected packages were inherited from Debian, and most of the trouble was due to certain configuration details on my system. Anyway, maybe someone hits one of those too and can make use of the info: 1) mariadb-server didn't upgrade to 10.3 This was my own fault, since I removed the old mysql-server package left over from a previous dist-upgrade during my pre-upgrade cleanup, and I didn't check if the mariadb-server metapackage was installed instead (it wasn't). This brought up a couple of followup errors since no database server was running, but all of them were recoverable. 2) missed a subtle change in /etc/init.d/cryptdisks The cryptdisks init script sources /lib/cryptsetup/cryptdisks-functions In previous releases this was /lib/cryptsetup/cryptdisks.functions - and I totally did not notice that change when the diff was shown during the upgrade, so I kept the old init script, and subsequently wondered my some encrypted volumes weren't mounted anymore. (This should only happen when you modified the init script, like I did.) 3) dovecot starts with a warning When you previously used the ssl_dh_parameters_length option in the dovecot configuration, the server will show a warning after the upgrade: > doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:37: > ssl_dh_parameters_length is no longer needed > doveconf: Warning: please set ssl_dh= doveconf: Warning: You can generate it with: dd > if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam > -inform der > /etc/dovecot/dh.pem Just do what it sais. 4) sendmail behaviour change Apparently sendmail now refuses to connect to remote servers that run TLS with weak DH parameters. Since the remote in question was under my control I fixed that one, and didn't try to find out where that configuration change is hidden. 5) SOGo upgrade needs manual intervention SOGo was upgraded from 3.x to 4.x, which needs some changes in the SQL database. There are upgrade scripts in /usr/share/doc/sogo, but they are not run automatically. My SOGo still can't connect successfully to the dovecot server after the upgrade, and I haven't yet found out what the problem is (other clients work). 6) php FCGIWrapper in apache2 I had a custom FCGI configuration left over from PHP5 times, which used a php binary installed to /usr/lib/cgi-bin. This is gone now with PHP7.3. I switched to the default setup provided by libapache2-mod-fcgid instead. As far as I can see, there were no problems with any of the infrastructure and packages provided by Devuan. Quite happy with that, thanks! Alex. P.S. By the way, just today I came across a mention of the debsums utility that I can't believe I didn't know about after all this time of running Debian/Ubuntu/Devuan systems: > debsums --config | grep FAILED Running that will show all configuration files that have been changed from the original provided by the deb package. Knowing those would have been so useful when preparing for upgrades... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists
...on Tue, May 28, 2019 at 04:17:44PM -0700, Bruce Ferrell wrote: > You *could* make a tarball and copy that to NTFS. Imperfect but no semantic > loss that way Last I checked, --no-xattrs --no-acls --no-selinux still was the default for GNU tar. So if you want to keep any of those, you need tho enable them, as appropriate, when creating or extracting an archive. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] calendars, contacts, to do lists
...on Thu, May 23, 2019 at 10:44:00AM -0400, Hendrik Boom wrote: > I'm looking for software to handle appointment calendars, contact > lists, and todo lists. I'm running SOGo, and use various CardDAV/CalDAV-Clients to connect to that (or the SOGo web UI). Devuan ascii has a package for some version of SOGo 3, which works for me, though probably isn't maintained by anyone. The original SOGo release packages from Inverse.ca require a subscription, but current nightly builds are still available directly from them. Note that correctly running SOGo is slightly involved - it's an GNUstep service that uses some of that infrastructure to store preferences, for example. Setting up things like calendar mail notifications and invites requires additional configuration too. And toggling some switch to disable the annoying Gravatar thing in SOGo 3. If you don't need the webmail integration that SOGo provides, Nextcloud is probably easier to set up and operate, and also has a host of plugins for additional features in the web UI. Provided a web service that also has some client APIs like CardDAV/CalDAV is what you want in the first place. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [cor...@debian.org: [SECURITY] [DSA 4371-1] apt security update]
...on Wed, Jan 23, 2019 at 11:54:10PM +0100, KatolaZ wrote: > explained in the email I forwarded. Or, if you trust Devuan, to use > pkgmaster.devuan.org in your sources.list (that one is the master > Devuan repo, and is on a machine to which only a reduced number of Using the usual deb.devuan.org, I've seen this once during my last ascii update: Get:1 http://packages.roundr.devuan.org/merged jessie InRelease [21.8 kB] Is that something that's expected? Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] bug reporting on unmodified Debian packages?
Hi, I recently used Devuan reportbug on an ascii system against a package that comes unmodified from Debian. The bug itself is unrelated to Devuan (missing backport of a change that fixes a broken external dependency). The report has landed on the Devuan bug tracker, but how do things progress from there? I haven't really found any info on that. Does the bug tracking system (or someone on the bugs list) forward the report to the Debian maintainer? Should I re-report to Debian directly? When I do that, should I close the Devuan bug? Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] swap problems with ascii 686-pae kernel
Hi, the current linux-image-4.9.0-8-686-pae for ascii seems to run into this bug: "Truncating oversized swap area, only using 0k out of 2047996k" https://lkml.org/lkml/2018/8/20/172 > On 32bit PAE kernels on 64bit hardware with enough physical bits, > l1tf_pfn_limit() will overflow unsigned long. This in turn affects > max_swapfile_size() and can lead to swapon returning -EINVAL. Don't ask why I'm running that kernel in a VM on 64bit hardware. This looks like a Debian kernel package, so I should probably go ask them about an update? Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] jessie MySQL -> ascii MariaDB
Hi,
I recently updated an old (former) Debian system from Devuan
jessie to ascii.
As it turns out, its MySQL database still had a root password
in the (very) old format, which isn't accepted by MariaDB. The
upgrade routine doesn't handle that problem, leading to followup
errors.
I had to manually start MariaDB with --skip-grant-tables,
update mysql.user with a root password using the new hash format,
and then complete the dist-upgrade.
> update mysql.user set Password = password('admin_pw') where User = 'root'
> and Host = 'localhost';
> flush privileges;
No other major problems on a system with over 1500 installed
packages (ok, insserv reenabled dependency based boot without
asking, but that unexpectedly didn't break anything).
Good work on that release!
Alex.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] strategy for missing sysvinit scripts - the tuned case
...on Tue, Jun 26, 2018 at 09:22:26AM +0200, Jaromil wrote: > Another strategy which IMHO may not be sustainable on the long term is > to fork all packages to have such a sysvinit service script in them. > I tend to disagree with this approach. Maybe create an additional companion package that just contains the sysvinit/openrc script? Though I have no idea how to declare the dependency without changing the original package. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ancient data recovery: GPE calendar
...on Mon, Jun 04, 2018 at 05:55:33PM -0400, Hendrik Boom wrote: > GPE was last seen packaged in Debian wheezy. I *might* be able to find > an old wheezy installation, but I'm not sure it will still run. Whoah, heavy bitrot around that one... I still have a working wheezy system, but it shouldn't be too hard to set up a fresh wheezy VM. I mean, someone somewhere still does security updates for that release... It ships libsqlite 2.8, which may or may not be able to load your database. One way out might be by starting a small retrocomputing adventure: Install gpesyncd (included in wheezy) and then try to build opensync from source to convert your data to a format that might still be portable. (SyncML?) Last version of opensync that included the gpe plugin seems to have been 0.36, of which archive.org has a copy: https://web.archive.org/web/20140407043108/http://opensync.org:80/download/releases/0.36/ Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] btrfs
...on Wed, Feb 21, 2018 at 09:08:15AM -0500, Hendrik Boom wrote: > Laast I heard here about btrfs is that it's recommended for use only bu > those who "know where the bodies are buried". I've been running btrfs for years now, both on distribution kernels and on newer ones I built myself. The more recent the kernel, the better though - there's been constant improvements (which sometimes also need updated versions of btrfs-tools). Some newer features limit backwards compatibility, and older kernels might throw warnings when trying to mount the volume. I'm not using a lot of features - snapshots, and mirroring mostly. Not had any problems with either, though replacing a disk (and having the system boot from a degraded mirror) has been somewhat fiddly. Most of the questions I had were answered by the btrfs wiki (https://btrfs.wiki.kernel.org/index.php/Main_Page). Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] warning: Devuan jessie i386 doesn't boot on i586
...on Wed, Feb 14, 2018 at 10:27:32PM +0100, Alexander Bochmann wrote: > Ok, currently reinstalling Debian, and then I'll try again WTF - installing from the latest Debian live CD (8.10.5-20180118), the same thing happens... How did this ever work? Sorry for the false alarm. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] warning: Devuan jessie i386 doesn't boot on i586
...on Wed, Feb 14, 2018 at 10:09:17PM +0100, Irrwahn wrote: > Alexander Bochmann wrote on 14.02.2018 21:56: > > System resets before even loading Devuan-built grub. > Now that is particularly odd, as grub is not among the packages > that were forked by Devuan but rather is merged from Debian. Agh, odd indeed. Just my bad luck again? It is old hardware after all... Ok, currently reinstalling Debian, and then I'll try again (and if it fails a second time, I'll try the Devuan installer directly). Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] warning: Devuan jessie i386 doesn't boot on i586
Ran into this when trying to move an old box with a Via C3 CPU from Debian jessie (last release to support i586) to Devuan jessie: System resets before even loading Devuan-built grub. Don't think there's any use putting work into fixing that, just mentioning it here before anyone else tries ;) Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Amprolla3 is out for testing
Hi, ...on Fri, Oct 20, 2017 at 04:47:57PM -0500, goli...@dyne.org wrote: > - replace "auto.mirror.devuan.org" with "pkgmaster.devuan.org" in > your /etc/apt/sources.list > - # apt-get update > - # apt-get install devuan-keyring I just updated an ascii system that had been shut down for three months, and the only minor nitpick is that I had to get an updated devuan-keyring *before* changing the sources to pkgmaster.devuan.org... Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
...on Mon, Jul 10, 2017 at 05:33:26PM -0400, Miles Fidelman wrote: > There's a point at which this all becomes unstoppable, unless some equally > well-placed & influential folks start pushing back VERY hard. That would certainly help, but I also think that it's much more important that someone has started actually doing something in terms of infrastructure and development, instead of spending that time on convincing others to do something. So here we are, and after following this thing for the past two years, I have no doubt that moving all my Debian systems to Devuan has been the right choice. So, thank you for making that possible, everyone. At the same time I have no illusions where the market is going - my employer now happily buys SuSE and Red Hat licenses instead of Solaris or HP-UX, and I won't get them to pick up Devuan (except maybe for some fringe stuff under my direct control). Which really doesn't matter though - it's just the same as in the early Debian days, with different roles... Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Quick start guide to uprading to Devuan and configuring minimalism
...on Thu, Nov 05, 2015 at 11:10:49AM +0100, miro.ro...@croatiafidelis.hr wrote: > it is possible to use a testing kernel on the Devuan Stable Jessie 1.0, > to then compile and deploy grsecurity-hardened kernel, much like I was Didn't actually try that on Devuan yet, but I wouldn't expect any problems unless you forget to configure in something essential... I have Wheezy running on 4.2.x-grsec kernels, and besides the usual suspects that need some pax flags (java, iceweasel), everything works. Ah yes, /usr/sbin/grub-probe needs to have MPROTECT disabled, too. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
