You are not logged in.
It kind of reminds me of something microsoft would do.
Microso~1 uploads and stores your passwords in its cloud - without asking of course. Just try the new outlook, it's great!
Edit:
I don't see a problem at all. The full feature version is still existing; beside a more secure, minimal version.
The guitar intro in the first ~90 seconds is Ted Nugent's Stranglehold, isn't it?
There is no general dependency between a "desktop environment" and permissions.
Please be more speciffic or rephrase. What do you mean with "adm user PERMISSIONS"?
Installed twice before - once with User as admin and root
This is a really really really bad idea. Don't do it again. Never ever. As said a thousand times before.
For starters:
Just install and use it!
There is no need to do something special. Do not repair, when it's not broken!
lxqt uses the Qt librarys like kde, but it is neither kde nor gnome.
Anyone one can write nonsense in forums - including me of course.
Search: try "adduser", "usermod", "chown", "chgrp" . Adding "linux" or "debian" may improve results. A simple sudo adduser fred is usually sufficient.
Doku:
"devuan" is "debian" without systemd.
General linux: The archlinux wiki is a good source (wiki.archlinux.org), also gentoo.
Search results on "stackexchange" are often helpful for specific questions (it has several sites with different names to sort topics, but the same visual style).
Change DM on debian (e.g.):
sudo update-alternatives --config x-window-manager or
sudo dpkg-reconfigure slim or sddm, depending on you preferences.
Maybe re-set or re-install lxqt ?
user:
delete or move lxqt-stuff in "$HOME/.config/". Subdir "lxqt", but maybe there is more.
system:
sudo apt purge task-lxqt-desktop
sudo apt install task-lxqt-desktop --install-recommends
Update:
Yesterday's re-switch to excalibur went flawless. The t64 library issue seems settled so far - at least for the programs in this particular installation.
Since excalibur is testing, there are issues to solve. In my case: LXDE
lxpannel-gtk3 is still broken. Therefore dadalus' version (gtk2-based) is preserved through the following pinning:
$ cat /etc/apt/preferences.d/lxde.pref
Package: lxde*
Pin: release n=daedalus
Pin-Priority: 1011
Package: pcmanfm libfm4 libfm-gtk4 libfm-modules libfm-tools
Pin: release n=daedalus
Pin-Priority: 1011
Package: libfm-d* libfm-extra* libfm-gtk-*
# Package: libfm-doc libfm-dev libfm-extra-dev libfm-gtk-dev libfm-data libfm-gtk-data libfm-extra4
Pin: release n=daedalus
Pin-Priority: 1011
Package: lxappearance* lxpanel* lxhotkey*
Pin: release n=daedalus
Pin-Priority: 1011
#Package: libfm4t64
#Pin: release *
#Pin-Priority: -1
################################################################################
# daedalus' lxde is gtk2-based
# excalibur's lxde is gtk3-based
# Q: Why?
# A: "lxpannel-gtk3" is not working ... so "lxde-gtk2" it is.
#
# apt pinning
# Package: libfm-* # matches "gtk3" and "qt" versions too
#
# -gtk3 # we want to avoid these!
# -qt # lxqt - don't touch.
#
# "menu-cache" program: packages not pinned!
# lxmenu-data libmenu-cache3 libmenu-cache-bin # libfm-extra4t64 libfm-extra4
#
# Remarks:
# "libfm-gtk4": Does NOT refer to "gtk version 4"
# "lxappearance-gtk3": seems to work meanwhile (May 2024), still lxpannel to fix
#
#
# lxde-gtk2 and lxde-gtk3 do not mixed-up
# possible exception: The "menu-cache" program
#
It is a moving target, notes are included.
Murphy's law in action!
Good to hear.
excalibur seems quite settled by now. I thing I'll give it another try as main system and convert my daedalus again.
Welcome!
I saw a little something: Files in "/etc/apt/preferences.d/" need to have the extension ".pref". Otherwise apt ignores them and complains.
Had that issue on my excalibur (test-)installation.
After a few weeks, I just purged it, which caused deinstallation of about 5 other packages.
From Lorenzo's bug report:
Note that recently debhelper started to chmod -x initscripts when a package is
removed but not purged, (...)
That sounds terrible!
Is the consequence, that any sysv initscript needs to be updated to fix this behavior?
(Or: If you have such a "helper" you don't need enemies.)
Back to main topic:
Unused stuff can be removed - sorry purged - too apt purge openrc.
I installed Devuan Daedalus on the virtual machine and tried to upgrade it to Ceres, but it was bricked
One possible reason might be the package 'usrmerge'. These days it should be installed before changing to ceres.
There is the "Packages"-link in the upper-right-corner, https://pkginfo.devuan.org/ . The search pattern is: "PackageName":"Architecture".
Search for e.g.: "network-manager:arm64".
(next page) Select the link matching your devuan-version.
(next page) A bit down the page is a download link to the package. ( https://pkginfo.devuan.org/cgi-bin/pack … 4-1devuan1 )
Hope this helps, but not sure whether this is understandable.
And TDE KPackage for variety sometimes.
This thing is pure apt. Best GUI ever
Thanks for the info.
The last years with devuan/debian testing were quite convincing, but I'm going back to daedalus by now.
The day before yesterday I switched my main installation to excalibur. A lot of package names seems to have suddenly a "t64"-string appended, e.g.: "SomePackageName" vs. "SomePackageNamet64". Most of them seem to be libraries, but not sure.
What's the matter with that?
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