You are not logged in.
Blender runs on my daedalus with LXDE and it is not asking for (non-existing) libraries, like libavformat.so.58.
Maybe an apt dist-upgrade was missing during the last upgrade?
$ apt list --installed | grep -e libavf -e blender -e libsws
blender-data/stable,stable,now 3.4.1+dfsg-2 all [installed,automatic]
blender/stable,now 3.4.1+dfsg-2+b1 amd64 [installed]
libavfilter8/stable,stable-security,now 7:5.1.4-0+deb12u1 amd64 [installed,automatic]
libavformat-dev/stable,stable-security,now 7:5.1.4-0+deb12u1 amd64 [installed,automatic]
libavformat59/stable,stable-security,now 7:5.1.4-0+deb12u1 amd64 [installed,automatic]
libswscale-dev/stable,stable-security,now 7:5.1.4-0+deb12u1 amd64 [installed,automatic]
libswscale6/stable,stable-security,now 7:5.1.4-0+deb12u1 amd64 [installed,automatic]
Auto-mount is usually done by gvfs.
apt install gvfs should do it. Maybe the package gvfs-backends is needed too.
My "mother of all apt pins" is
$ cat /etc/apt/preferences.d/systemd.pref
# not anymore # Package: systemd
Package: *systemd*:*
Pin: release *
Pin-Priority: -1
Not sure about the exact syntax, lets say it works so far.
Cases: On debian 12/13 to prevent re-installation of some systemd-stuff. On excalibur, just to be sure. And some "purge systemd in debian"-experiments as a preparation for a controlled devuan-migration.
Variants: On machines with multiarch, it's sometimes "Package: systemd:*"
Compared to @nixer's post: No wild card in the package name. Just mentioning, no clue about the consequences.
Edit: Not good enough anymore without wild cards
Edit2: Never realized the possibility to have multiple package names in one line, which will simplify some .*pref files
Edit2: Stumbled upon the package "systemd-dev"
Can this [i386] installation be easily upgraded to 64-bit with some gimmick?
Intresting problem. Google found
https://wiki.debian.org/CrossGrading
One of the steps is adding amd64 architecture, which should allow installing the wanted (64-bit-)program.
# dpkg --add-architecture amd64
The title is "Beowuf to Chimaera", but you mean to Daedalus, right?
Otherwise, Chimaera has wicd.
I do not know Peppermint OS.
@delgado . . . Peppermint OS Devuan Release is on the Devuan derivatives list
I did not ment to be disrespectful, just that I'm not aware of differences to devuan.
Back to topic.
Just to mention (since I don't like to re-install): It is possible to clean-up an installation using apt-pinning. The wanted release should have a priority of at least 1001 to allow downgrading (apt policy). The steps are in short: adjust /etc/apt/preferences, then apt update; apt upgrage; apt dist-upgrade.
I do not know Peppermint OS.
Are the deb-multimedia.org keys installed?
Did you copy an old sources.list, still pointing to debian-multimedia.org?
chrony is a possible choice for a ntp daemon. Just install it and you're good to go.
Remarks:
The meta-package ntp (or ntpd) will installs the default time-sync daemon.
I do not know timedatectl. In general, it's a bad idea to install two services for one issue.
In case of a VM: The time comes from the host, so ntp is probably not needed.
@#1
In case the partition is mounted read-only (ro):
Altering the permissiion of the directory to read-write is not enough. The partition must be re-mounted read-write (rw) as well.
First check the output of mount to see whether this applies at all. (sticking to /dev/sdb1 as example)
$ mount
$ sudo mount -o remount,rw /dev/sdb1
Open question to answer is still: Why was the partiton mounted read-only at all?
Re-mounting the partition rw manually is curing a sympotom - if the real reason allows this at all.
(No solution, sorry)
Depending on the time you want to sink in this topic ... something to read.
Detailed information on disk layouts and booting can be found in the install instructions of (e.g.) Archlinux and Gentoo.
Philosophy is: "There is no install program, you do anything by yourself". Instructions and information are corresponding.
In short: There is no way around UEFI boot for a gpt disk.
gpt disk and non-uefi boot are mutally exclusive. This can not boot by design - it's not an error.
gpt partion table -> UEFI boot
mbr partiion table -> BIOS boot
Modern x86 PC's are all UEFI. Addionally they have a BIOS emulation, which allows them to boot mbr disks.
An "UEFI emulated BIOS" counts as BIOS.
"apt pinning" is a possibility. A priority of at least 1001 allows package downgrade.
In your case, It would be pinning the daedalus packages to 1001 and then doing the usual upgrade.
I've done that a few times, it usually just works.
# cat /etc/apt/preferences
Package: *
Pin: release n=daedalus
Pin-Priority: 1001
# apt update
# apt upgrade
# apt dist-upgrade
In a terminal: Both commands will extract the archive's content in the current directory
$ 7z /path/to/arch.zip
$ unzip /path/to/arch.zip
Multitasking in compression is a trick that zst does.
I don't use it very often, since the command-line switches and defaults are sick, but (de-)compression works nicely.
Did you skip Chimaera?
dist-upgrade works fine form one version to the next release.
I would check that sysvinit is installed (and running if booted):
apt list --installed | grep sysvinit-core
apt list --installed | grep systemd
Obviously, there should be sysvinit-core and no systemd. Then:
apt update
apt -s upgrade
apt upgrade
apt -s dist-upgrade
apt dist-upgrade
usually did it (without forcing or expicit de-installs).
The apt -s lines are optional. They do a simulation to spot problems. It might be tricky to solve dependencies in an interrupted migration.
Some programs will be de-installed during migration, so there is stuff to re-install.
And optional clean-up at the end: apt clean and/or apt autoremove
--
PS: Booted installtion with sysvinit:
$ ps ax | head -2
PID TTY STAT TIME COMMAND
1 ? Ss 0:00 init [2]
In case of systemd: PID 1 is "/sbin/init"
Continuing the migration in a chroot should work. I would do so too.
Network-manager most likely needs updated configuration after migration (see below).
--
Remembering the migration of my notebook to chimaera:
One thing that happens during migration is: The network-device's name changes (from forgotten) to "wlan0" in case of wifi.
The network-manager's config files were still pointing to the prior device name. This was the reason for "no network connection".
The alternative to reconfigure network-manager was to restore the prior network device names:
# echo 'GRUB_CMDLINE_LINUX="net.ifnames=1"' >>/etc/default/grub
# update-grub
# reboot
Using update-grub may or may not be a bad idea in your multi-boot case.
A quick boot-up was impossible - the default time-out is 60 seconds until isc-dhcp-client skips waiting for an IP address. I would not mind if this happens in the background, but it is blocking the boot process.
The fix / config file is:
cat /etc/dhcp/dhclient.conf | grep timeout
#timeout 60;
timeout 10;
I know, it's not rocket science, but it took me ages to finally do it.
Just thinking: The confirm-paste add-on may have been useful in former times, where "paste something with a newline character" lead to direct execution. But this is not the case anymore; pressing the [ENTER] key seems mandatory in bash.
Do you have a specific need for openjdk-8?
Maybe a newer version is already installed.
apt list --installed | grep openjdk
maybe
$ pstree
gives a hint?
# apt dist-upgrade
works too in such cases.
Are there files in "$HOME/.wine/drive_c/windows/system32" ?
I would proabaly start with a fresh wine setup.
$ mv .wine .wine_old # backup
$ winecfg
It looks like a firefox (variant), which is good form my point of view.
What is midoris selling point?
Is the mouse's batterie charged?
Can't remember haveing mouse problems the past decade or so. Would you mind sharing the manufacturer?
Are you looking for a local DNS cache or DNS resolver?
Like e.g. dnsmasq or unbound. Most likely these can be configured to use encrypted connections.
Edit: Just the colour.