Hello:

Indeed.  8^D
And a just reward for your volunteer work too.

Best,

A.

Hello:

Yes.
A non-zero chance of there being extra obstacles is to be expected with a testing Suite.
ie: Maintained but Not Released status

+1

Best,

A.

Hello:

Same for my Daedalus installation with the exception of it not being a VM.

$ uname -a
Linux devuan 6.1.0-40-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.153-1 (2025-09-20) x86_64 GNU/Linux
$ 

For whatever reason, I have quite a few of those packages ...

$ apt list '~o' 
--- snip ---
libssl1.1/now 1.1.1w-0+deb11u1 amd64 [installed,local]
libswresample3/now 7:4.3.6-0+deb11u1 amd64 [installed,local]
######  <--- would have been listed here
libvpx6/now 1.9.0-1+deb11u2 amd64 [installed,local]
libwebp6/now 0.6.1-2.1+deb11u2 amd64 [installed,local]
--- snip ---
$ 

...  but libupower-glib1 is not one of them.

$ apt list '~o' | grep libupower-glib1
--- snip ---
$ 

That said, I do have libupower-glib3 installed ...

$ apt list | grep installed | grep libupower
--- snip ---
libupower-glib3/stable,now 0.99.20-2 amd64 [installed,automatic]
$ 

$ aptitude why libupower-glib3
i   task-desktop   Depends    xorg                                                              
i A xorg           Depends    xinit                                                             
i A xinit          Recommends xterm | x-session-manager | x-window-manager | x-terminal-emulator
i A xfce4-session  Provides   x-session-manager                                                 
i A xfce4-session  Depends    xfce4-settings                                                    
i A xfce4-settings Depends    libupower-glib3 (>= 0.99.0)                                       
$ 

... but no upower:

$ apt list | grep installed | grep upower
--- snip ---
libcpupower1/stable-security,now 6.1.153-1 amd64 [installed,automatic]
libupower-glib3/stable,now 0.99.20-2 amd64 [installed,automatic]
linux-cpupower/stable-security,now 6.1.153-1 amd64 [installed]
$ 

$ apt-cache policy upower
upower:
  Installed: (none)
  Candidate: 0.99.20-2
  Version table:
     0.99.20-2 500
        500 http://deb.devuan.org/merged daedalus/main amd64 Packages
$ 

That upower package is a recommends from the hw-probe package which I do have installed ...

$ apt list | grep installed | grep hw-probe
--- snip ---
hw-probe/stable,stable,now 1.6.5-1 all [installed]
$ 

$ aptitude why upower
i   hw-probe Recommends upower
$ 

... but I do not allow recommends in my system.

Unless I am mistaken, your 'Installed' version is the same as your 'Candidate' version:
ie: apt says that is the correct version to have in your system.

Installed: 1:0.9.23-2+devuan1.3
Candidate: 1:0.9.23-2+devuan1.3

Being a recommends and not a hard dependency, you probably don't need it.
You may want to try purging the upower package and see if the obsolete package gets purged along with it.

Then if you get complaints from the system, just reinstall it and see what gets dragged in along with it.

Please let us know how you fared.

Best,

A.

Hello:

Yes.
As the OP, I was the one that posted a link to this thread on that one.  8^D

Best,

A.

Hello:

Is this how it came 'out-of-the-box' or did you format it?

You may want to run a read-only check on it with dosfsck and/or have a look at it with the gnome-disk-utility
It shows things that Gparted will not.

Best,

A.

Hello:

Yes, depending on your box and hardware, they can be very useful.

See:
https://wiki.debian.org/ZRam
https://dev1galaxy.org/viewtopic.php?id=4800
https://linuxblog.io/running-out-of-ram-linux-add-zram/

That's a more difficult question which requires some research on your part.

First you need to check and see what modules are being loaded by your system.
Then check if you are actually using them.
Done that, evaluate the convenience of removing them or not.
ie: just what is the upside to doing it.

It is not hard to do: just needs work but you will learn quite a bit in the process.

See:
https://www.tecmint.com/remove-unwanted … rom-linux/

Make sure to search Dev1 on how to unload/remove* modules in a Devuan (sysvinit) system.
Debian (systemd) based installations do it according to how their installation works.

Best,

A.

* do remember to back up your system first and also make notes. ie: log your actions

Hello:

Really?

Well ...
The numbers will undoubtedly be stacked against us.
But should it actually come to that, I know how to use a 12 gauge well enough.

I will not go quietly.

But when all is said and done and the dust settles down, those who waited and voted in favour will ultimately perish.
They will not know how to survive in the world they created.

The irony is that it will be a world which we actually enabled them to create.
Among other things, through our generation's lack of values, empathy, education and basic common sense.

Right ...
Enough OT* for today.

Time to step off my box, take my pill and go for a walk.

Best,

A.

* not entirely, you know what I mean.

Hello:

There was a bug marked as done some days ago:

https://lists.dyne.org/lurker/message/2 … 5d.en.html

Maybe not competely squashed or [?] but not a problem, it is just RC1.

Exactly.  8^D

Best,

A.

Hello:

In a normal and properly configured non-systemd Linux installation, log files are your best friends.

Check your /var/log/daemon.log, /var/log/messages, /var/log/syslog and /var/log/user.log files for that specific string.
ie: 'early crypto disks' or 'starting' and 'stopping'

The data you need is there.

eg: the user.log printout on the activity of my local headless VM reads:

Oct 10 23:00:09 devuan vboxdrv.sh: Stopping VirtualBox services. 
--- snip ---
Oct 11 06:32:23 devuan vboxdrv.sh: Starting VirtualBox services.
Oct 11 06:32:24 devuan vboxautostart-service.sh: Starting VirtualBox VMs configured for autostart.

As you can see, it informs me of what went on at boot, shutdown and which script was responsible.
vboxdrv.sh and vboxautostart-service.sh.

I can find the same in messages and syslog.
Once you know which script is generating the start / stop sequence for the 'crypto disks' bit, Bob's your uncle.

Like I wrote early on, I don't use any disk encryption and would not expect to see that string anywhere in my system logs.
I think that whatever is going on in your system is indeed related to some full disk encryption setup of which you are not aware of.

Let us know what you discover.

Best,

A.

Hello:

Yes.

Every time I see someone wanting to run Linux on a Mac[whatever] I try to pitch in.
To me, it's personal and after all, hardware is just hardware but the BIOS has to be able to access it.

But thanks to crappy BIOS / DSDTs encouraged by the usual suspects, many notebooks/netbooks/laptops of various brands / CPUs have needed tweaking. Apple hardware is a prime example.

@deviate
Try adding this stanza to the kernel command line: ACPI_OSI=Darwin 
See here: https://wiki.archlinux.org/title/MacBookPro11,x

Just in case, test this first by editing the grub configuration at boot so that the edit will not be permanent.
ie. it will apply to only that boot.

If it boots properly, carefully check the dmesg printout to see what is going on.
Save it to a *.txt file and compare the printout with / without the edit.

There may be useful data there.

Best,

A.

Hello:

Maybe this page could sort the OP out?
https://help.ubuntu.com/community/Macte … stallation

Have a look at the Single-Boot: Ubuntu Only bit.

Best,

A.

Hello:

Just curious ...

It is not clear to me what device was used.
ie: a USB SSD of no specified capacity (as you wrote in your OP) or a 128Gb USB stick.
Could you let us know which?

And as a bonus, brand and model of the device you used?

Best,

A.