Posts by tlathm

tlathm · Other Issues

Thanks for the reply! I'll have to figure out how to best handle this one.

What I was hoping to use ld for was to see if there are any other missing libraries in the executable. That's something I'd always done in the past. Is that no longer possible?

Thanks!
Tom

tlathm · Other Issues

On a related topic, I've installed binutils to get the ld command, but ls doesn't work on anything I try. It always fails with an error like this:

ld: cannot use executable file '<filename>' as input to a link

I've read some things about that though I can't make any sense out of it. I've seen suggestions to use "-r" but that doesn't help.

Any clue on that would be appreciated as well.

Thanks!
Tom

tlathm · Other Issues

I'm trying to use an executable under Daedalus that needs the missing library libhcrypto.so.4.

Does anyone know if any package provides that? I'm seeing things about a "libhcrypto4" package in Bookworm but that doesn't appear to be available. Currently I have the daedalus, daedalus-security, and daedalus-updates repos enabled.

Thanks in advance!

Tom

tlathm · Installation

I've just done an install of Daedalus on a VM running from within VMware Workstation Player. It currently is headless and has almost nothing except the base system installed. I'm getting these during the boot:

[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short
[Wed Apr  3 14:52:23 2024] udevd[409]: 'dmi_memory_id' ressize 16384 too short

Any clue what that means or what might be causing it?

Thanks!
Tom

tlathm · Installation

Thanks for that! If I decide to even do this I might try that.

You're correct that this really isn't really an issue. When a customer of ours ends up needing that much space we have them add a new disk and just add it to our LVM logical volume as a raw disk with no partitions at all. We did however have one customer that increased the existing disk to well over 2 TB which we were not able to fully use due to the DOS partitions, and VM doesn't let you get it back.

I was hoping to avoid that but I'm starting to think it's not worth it...especially if it gets into changing stuff to use EFI etc. That could even end up causing worse issues.

Thanks again!
Tom

tlathm · Installation

Actually that gets into several things that get very confusing about all this.

For example, if I'm creating a new VM that I plan on installing Devuan, I'm actually unclear as to how I even could partition it ahead of time. On real hardware I'd just boot from some removable drive, mount the disk, and format it. I have no idea how to do that in this case.

Things get even more confusing regarding the boot. I'm unclear as to what VM even does for a new VM regarding legacy BIOS boot vs EFI. Maybe there are some options there though I don't recall any. Very confusing.

I may just try the approach in that link and see if it works.

Tom

tlathm · Installation

I'm looking to create a VM using VMware workstation player that initially will have a 250 GB disk, but I'd like to force it to use GPT partitions. The reason is that there can be cases where at some point there's a need to increase a partition to more than 2 TB. From what I've read I don't think that GPT partitions would get used in that case by default(?).

I found an interesting post related to Debian here:

https://unix.stackexchange.com/question … mbr-vs-gpt

That is, to add this to the end of the boot command line:

d-i:partman-partitioning/default_label=gpt

Can anyone confirm whether or not that works, and most importantly, if the resulting install would actually boot correctly?

Thanks in advance!
Tom

tlathm · Other Issues

In addition to purging the unattended-upgrades package, I also just moved the apt-compat script out of /etc/cron-daily altogether. That appears to be installed by the apt package and seems to do that random sleep (up to 30 minutes) regardless of whether any of that is enabled. Still seems odd to me.

Tom

tlathm · Other Issues

What also bothers me is that, unless I'm misreading it, the /etc/cron.daily/apt-compat script appears to do that random sleep regardless of whether or not any of this is enabled. That seems odd to me.

Again, this was from a rackspace Buster VM and they apparently had the unattended upgrade stuff installed. I've never installed that on Devuan installs I've done from scratch.

Tom

tlathm · Other Issues

Head_on_a_Stick wrote:

tlathm wrote:
I'm assuming (hoping) that's not enabled by default
Is the unattended-upgrades package installed and if so is the service enabled?

Wow...apparently yes and yes. Looking at the logs in /var/log/apt it certainly doesn't appear that any upgrades have run on their own. I'm assuming they'd log there(?). I have to confess I knew nothing about this one at all.

Tom

tlathm · Other Issues

I have a rackspace server that's been converted from Debian Buster to Beowulf. I just spent a lot of time trying to figure out why my daily cron jobs appeared to be running much later than intended. I have the daily crons set up to run at 4:02 AM and it appeared that the jobs I care about ran at about 4:30 this morning.

Looking at /var/log/syslog I can see that the daily jobs did in fact start at 4:02, but my jobs appear to be getting delayed by /etc/cron.daily/apt-compat.

It appears that it does a random sleep and I think that's what delayed things. From what I read it appears that has something to do with unattended updates(??). If so I'm assuming (hoping) that's not enabled by default.

Thanks in advance for any clarification!

Tom

tlathm · Installation

Head_on_a_Stick wrote:

tlathm wrote:
That failed at first because I had /bin/sh as the users shell and needed to change that to /usr/bin/bash
/bin/sh is linked to dash in Debian and Devuan. The usr merge does not break /bin/sh in any way — all of the system scripts have a /bin/sh shebang so nothing would work if the usr merge broke that.

To clarify what actually happened to me there: I have a script that copies the minimum of executable programs and libraries I need in a users home to allow rsync to work in that chroot...and because of the nature of the usr merge and the way my script works I didn't have any /bin/sh in that chroot home.

Thanks for the replies! I don't think I'll attempt any conversion to the separate usr here, as the server's already in use and serving it's purpose just fine. Thanks!

Tom

tlathm · Installation

Thanks! I'm sure you're correct, and given that this was starting with a rackspace server I really have no option to do an install from scratch. Having said that, it's actually a rather simple LAMP server for the most part and I seriously doubt it would ever cause me any problems.

The only reason I noticed was that I set up a user specifically for rsync backups that's restricted to a chroot in it's home. That requires having a few binaries and libraries installed in the home. That failed at first because I had /bin/sh as the users shell and needed to change that to /usr/bin/bash.

Only the systemd and freedesktop.org asshats could manage to make such an asinine decision to screw with shit that's been in place as long as that. I use Gentoo on my own machines which, by default, doesn't do that BS either. Thank God for distros like that, and for the wonderful maintainers of Devuan!

Thanks
Tom

tlathm · Installation

I recently converted a Rackspace server from Buster to Beowulf mostly based on this:

https://www.devuan.org/os/documentation … owulf.html

Worked really well. One thing I noticed is that this ends up with a usr merged system:

ls -l /bin
lrwxrwxrwx 1 root root 7 Feb  6 05:30 /bin -> usr/bin

Two questions about this:

1. I'm assuming there's probably no way to change that...or at least nothing I'd want to attempt(?).

2. Are there any possible issues going forward because of that?...for example with updates etc.

Thanks!
Tom

tlathm · Documentation

I figured I'd add to this old post to report my recent experience with this. I've been able to convert a Rackspace Debian Buster to Devuan Beowulf successfully, and wanted to outline what I did. For the most part is mostly just involved converting the original VM based on this:

https://www.devuan.org/os/documentation … owulf.html

For the nova-agent I used your init script above and enabled it with update-rc.d...thanks for that! Seems to be fine and, given my understanding of what that does I really doubt that it's lack of any "stop" functionality makes any difference. I also disabled those cloud services.

One additional thing I did was to get the Rackspace driveclient working. We downloaded and installed that, but just as with the nova-agent, they had no traditional init script. I was able to come up with this one which seems to work fine, and it appears that backups are working OK:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          Rackspace Backup Agent
# Required-Start:    networking
# Required-Stop:     networking
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Rackspace Backup Agent
# Description:       Rackspace Backup Agent
### END INIT INFO

# Using the lsb functions to perform the operations.
. /lib/lsb/init-functions

export HOME=/root

PIDFILE=/var/run/driveclient.pid

case "$1" in
    start)
        log_begin_msg "Starting Rackspace Backup Agent..."
        start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --exec /usr/local/bin/driveclient -- --daemon
        log_end_msg $?
        ;;
    stop)
        log_begin_msg "Stopping Rackspace Backup Agent..."
        start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
        log_end_msg $?
        ;;
    restart)
        $0 stop
        sleep 1
        $0 start
        ;;
    status)
        if [ -e $PIDFILE ]; then
            status_of_proc -p $PIDFILE driveclient "Rackspace Backup Agent Service" && exit 0 || exit $?
        else
            log_success_msg "Rackspace Backup Agent Service is stopped"
            exit 3
        fi
        ;;
    *)
        log_success_msg "Usage: /etc/init.d/driveclient {start|stop|restart|status}"
        exit 1
esac

All seems to be working great. Rackspace without systemd lives!

Tom

tlathm · Other Issues

Yea, that's what I ended up doing in out stuff. Odd though...I have no idea what dpkg-reconfigure with the noninteractive frontend is doing as compared to what it used to do. It seems to be basing it on the existing /etc/localtime link instead of the timezone in /etc/timezone.

Tom

tlathm · Other Issues

Wow...did this one have me going nuts. Writing the timezone to /etc/timezone and then using dpkg-reconfigure seems wildly broken in Beowulf. This definitely worked in Jessie:

# date
Thu 27 Aug 2020 04:44:20 PM EDT
# cat /etc/timezone 
America/New_York
# ll /etc/localtime 
lrwxrwxrwx 1 root root 36 Aug 27 16:43 /etc/localtime -> /usr/share/zoneinfo/America/New_York
# echo America/Chicago > /etc/timezone 
# dpkg-reconfigure -f noninteractive tzdata

Current default time zone: 'America/New_York'
Local time is now:      Thu Aug 27 16:44:53 EDT 2020.
Universal Time is now:  Thu Aug 27 20:44:53 UTC 2020.

# date
Thu 27 Aug 2020 04:44:56 PM EDT
# cat /etc/timezone 
America/New_York

So it's rewriting /etc/timezone to the old timezone and apparently using that? Anyone else run into this? Again, under Jessie this would have configured it to central time correctly.

On thing that may be related: In Beowulf /etc/localtime is a symbolic link to the actual file in /usr/share/zoneinfo and under Jessie it was a physical copy of the file. I always thought that links for that were not advised, because in cases where /usr is not part of / it might not be available during boot(???).

We do this in a setup wizard for our product and started getting burned really bad by this. For the time being I may just work around it by doing an "ln -snf <zonefile> /etc/localtime.

Thanks in advance.

Tom

tlathm · Other Issues

So in other words by default everything under /etc are considered conffiles and are protected. Thanks!

Tom

tlathm · Other Issues

I just wanted to verify something: If I modify a file such as /etc/mysql/debian-start, am I correct that updates will NOT overwrite my change? I just wanted to make sure. Thanks!

Tom

tlathm · Other Issues

minusfroot wrote:

I've certainly had this sort of error when there was a proxy set up (e.g. in /etc/apt/apt.conf.d/... or similar). Or NOT set up, and you're using one for wget.

Didn't see this until today. Thanks for the details...that gives us several things to check.

Tom

tlathm · Other Issues

Thanks for the clarification! Given that that's set up correctly in this case, I still can't imagine what's going on where apt fails while wget using either the name or the failed IP addresses works. They've clearly got something really strange going on. I'll post back if/when we figure out what's going on there.

Tom

tlathm · Other Issues

rolfie wrote:

According to this page https://devuan.org/os/ you should use:
deb http://auto.mirror.devuan.org/merged jessie          main
Give it a try.
rolfie

Whoa...Not according to this:

https://dev1galaxy.org/viewtopic.php?id=3276

That also mentions jessie in addition to the others. All our other jessie installs are using deb.devuan.org and are working perfectly. If I recall I believe I tried the auto.mirror URLs and had issues. That configuration does in fact work...this customer clearly has something else configured in a very odd manner.

Tom

tlathm · Other Issues

On a Devuan Jessie server at a customer they have an issue that has me stumped:

The apt command is failing with "Connection failed", yet wget against the same IPs works fine. For example:

apt update
Ign http://deb.devuan.org jessie InRelease
Ign http://deb.devuan.org jessie-security InRelease
Err http://deb.devuan.org jessie Release.gpg
  Connection failed [IP: 5.196.38.18 80]
Err http://deb.devuan.org jessie-security Release.gpg
  Connection failed [IP: 46.4.50.2 80]
Ign http://deb.devuan.org jessie Release
Ign http://deb.devuan.org jessie-security Release
Err http://deb.devuan.org jessie/main amd64 Packages
  Connection failed [IP: 5.196.38.18 80]
Err http://deb.devuan.org jessie/non-free amd64 Packages
  Connection failed [IP: 46.4.50.2 80]

...etc. However using those failed IPs thing like the following all work:

wget http://5.196.38.18

That works perfectly and will download an index.html file.

I'm thinking they've reconfigured something that they're not telling us about. The only things I can think of that could cause this might include:

1. Some global proxy was configured(?) that wget is using, but apt isn't, or

2. Someone broke the apt configuration somehow...maybe by incorrectly adding some proxy configuration.

Is anyone aware of any other scario that could cause this? Thanks!

Tom

tlathm · Off-topic

Just noticed this today. We currently use Jessie with the PHP 7.2 from sury.org but luckily we don't use php fpm at all and everything appears to be OK.

Note however that we've been leaving the sury.org repo commented out of /etc/apt/sources.list.d/php.list, and uncommenting only to update php. That is a) uncomment the sury repo, b) apt-update, and c) apt-get install --only-upgrade "php7*", d) comment out the repo, and e) apt-update.

The original reason for that was the fact that sury.org wanted to pull in a different version of openssl. I have no idea why, but we wanted to avoid that. As far as we can tell it wasn't necessary, so we went with the above for php only.

Tom

tlathm · News & Announcements

rolfie wrote:

Head_on_a_Stick wrote:
Note that the apt-transport-https package is needed to take advantage of https sources.
Tried this and it didn't work. I think I discussed this in a thread a while ago, but I couldn't find it.

Maybe I'm off base here, but this may mean that apt-transport-https may allow use of https sources that come from the round robin, but NOT https used directly in sources.list(??). That was sort of how I'd interpreted it.

Tom

The officially official Devuan Forum!

#26 Re: Other Issues » [SOLVED] libhcrypto.so.4 in Devuan Daedalus? » 2024-04-05 18:10:37

#27 Re: Other Issues » [SOLVED] libhcrypto.so.4 in Devuan Daedalus? » 2024-04-05 17:12:31

#28 Other Issues » [SOLVED] libhcrypto.so.4 in Devuan Daedalus? » 2024-04-05 16:37:15

#29 Installation » Odd udevd boot error on new install? » 2024-04-03 19:18:42

#30 Re: Installation » [SOLVED] Creating a VM using GPT partitions » 2023-11-28 20:01:03

#31 Re: Installation » [SOLVED] Creating a VM using GPT partitions » 2023-11-28 18:49:52

#32 Installation » [SOLVED] Creating a VM using GPT partitions » 2023-11-28 16:13:01

#33 Re: Other Issues » What is /etc/cron.daily/apt-compat? » 2021-03-05 21:53:22

#34 Re: Other Issues » What is /etc/cron.daily/apt-compat? » 2021-03-05 17:59:26

#35 Re: Other Issues » What is /etc/cron.daily/apt-compat? » 2021-03-05 17:50:36

#36 Other Issues » What is /etc/cron.daily/apt-compat? » 2021-03-05 16:40:33

#37 Re: Installation » Converting from Buster and usr merge » 2021-02-25 19:36:44

#38 Re: Installation » Converting from Buster and usr merge » 2021-02-24 15:21:45

#39 Installation » Converting from Buster and usr merge » 2021-02-24 13:19:08

#40 Re: Documentation » How to get Devuan running on Rackspace. » 2021-02-19 17:28:37

#41 Re: Other Issues » dpkg-reconfigure -f noninteractive tzdata not working in Beowulf? » 2020-08-29 11:03:39

#42 Other Issues » dpkg-reconfigure -f noninteractive tzdata not working in Beowulf? » 2020-08-27 21:06:33

#43 Re: Other Issues » Updates and files in /etc » 2020-07-17 16:36:44

#44 Other Issues » Updates and files in /etc » 2020-07-14 12:57:32

#45 Re: Other Issues » What would cause wget to work and apt to get "Connection failed"? » 2020-04-27 14:54:30

#46 Re: Other Issues » What would cause wget to work and apt to get "Connection failed"? » 2020-04-18 13:55:14

#47 Re: Other Issues » What would cause wget to work and apt to get "Connection failed"? » 2020-04-17 21:46:39

#48 Other Issues » What would cause wget to work and apt to get "Connection failed"? » 2020-04-17 18:40:18

#49 Re: Off-topic » deb.sury.org now requires systemd » 2020-03-02 14:47:45

#50 Re: News & Announcements » sources.list confusion. » 2020-01-27 16:57:26

Board footer