You are not logged in.
Addition: Devuan pulls in all Debian packages on a regular basis, filters out the systemd related stuff, adds the replacements where applicable. They end up in a "merged" repo which must be used to update any Devuan system.
I regularly see this "Stopping early crypto disks" during system shutdown. But I consequently use encryption. Tells me the system is mostly down, and now cryptodisks are being closed as one of the last steps in the shutdown process.
Maybe this is a step that happens all the time? I don't know.
How should messages been logged when the system is going down already? Disks have been unmounted already? No way.
I have just raised a bug report against Debian:
Bug#1117664: lightdm: Per default it is possible to login as user root graphically
nvme drives are no different from spinning rust or SSDs. On some older mainboards the bios must be prepared to support nmve's.
I do my partitioning before installation with gparted live. In a VM I use the installer but manual partitioning. I do not like the automatisms build in, in my eyes they are outdated in terms to size allowed. Usually too little. I want to determine size, order etc. myself based on a long time experience.
I have done that since the first tools came up on DOS like Partition Magic.
@greenjeans: Why do I consider graphical root login as security risk?
Here is my answer: I am on Daedalus with Lightdm/Cinnamon. I log in as user, the root account exists and has a password. I do not use sudo except for Veracrypt.
For root access I can either call up graphical programs like gparted where root access is granted by policykit, start a root terminal, or perform file copy/paste activities in Nemo via "Open as admin" if required. I do get along with these features very well. These features support everything I ever needed to do with root privilegues. Running root on the desktop is not required in my opinion.
BTW: everything started because a beginner in the German Debian forum complained about not being able to easily work as root despite the access being possible, something with LXDE and Lightdm.
The naive standard user who logs in as root has all possibilities to damage and wreck his system. Maybe "security" is not a perfect term for these risks. Well, somebody with deep knowledge and experience will easily get a long with root on the desktop. Me too.
In the IRC chat somebody said that root on the desktop isn't forbidden, just discouraged.
In my opinion lightdm shouldn't allow root access per default. It should be locked, and the experienced user may open this gate.
PS: other DMs like sddm and gdm inhibit root login.
Definitely lightdm has a leak. lightdm allows root login. Since I do not use other DM's, I can't speak for their performance.
Based on a web research and a chat on the Devuan Developers IRC, I have identified two possible fixes.
1.) Add a line to /etc/pam.d/lightdm
auth required pam_succeed_if.so user != root quiet
2.) Set up a group that is allowed to login:
# groupadd dmlogin
# usermod -aG dmlogin urmel # urmel is a dummy. Replace with real usernames. Repeat for all other users that shall be permitted
Change /etc/pam.d/lightdm and add:
auth required pam_succeed_if.so user ingroup dmlogin
In both cases trying to login as root returns "wrong password".
Hi kapqa, I think it makes sense to open a new thread for your topic. I don't see any relation to the old thread.
I suppose I could move the data to a hard drive, encrypt the USB, then move the data back?
Thats the way to go.
Another possibility: compress all the content in a zip file protected with password and copy that file to the USB. I did not test it myself.
To my experience, this only works between Linux and Linux, not from Linux to Windows. There is some incompatibility.
Its not limited to Devuan.
Raised the topic in the German Debian forum too: https://debianforum.de/forum/viewtopic.php?t=192885
The firmware that is loaded by the kernel is located in /usr/lib/firmware/mediatek. Check what you got in there. The dat file is something else but firmware.
Thanks, that line already is present. Seems to be ignored.
I have here:
[UserList]
minimum-uid=500
hidden-users=nobody nobody4 noaccess
hidden-shells=/bin/false /usr/sbin/nologin /sbin/nologin
Edit: Just saw:
# NOTE: If you have AccountsService installed on your system, then LightDM will
# use this instead and these settings will be ignored
Does this AccountsService relate to PAM?
My sshd is configured for no root login.
Now I am looking for the same feature in lightdm. I failed to find something, also in the greeter.
I consider a graphical root login as a security risk.
Daedalus with Lightdm and Cinnamon installed from a netinstall: I can login as root on my desktop. Why is this possible? I thought this is a nogo and disabled.
Tested also a VM with Excalibur and Cinnamon, Trixie with LXDE: same picture.
I don't know how new this adapter is. The firmware is from 2023, two years old. In any case installing the backports firmware is worth a try.
Veracrypt
All distros will use the build by Mozilla. Nobody will compile without SSE3 nowadays.
If you can't use one of the alternatives, the only way is to buy a more recent laptop or PC.
If you use a desktop like Mate, Cinnamon, XFCE or like, install pipewire to switch between sources and sinks.
Alsa is not userfriendly and lacks everything required to easily control Audio hardware.
greenjeans wrote:
... do you have an /etc/machine-id file?
Of course, I say so in one of my last posts.
I wrote:Machine-id is set thus:
$ cat /var/lib/dbus/machine-id
26a708d3d7dc6778fc6ff9f55921b024
$
That means your machine-id is fixed. The patch changing the machine-id works fine if that file does not exist. I don't have this file on my Daedalus and changing ids.
Same on my Daedalus: 340 files since installation.
New installation, the files do not take very much space. New machine ID on every boot.
That will be needed to maintain older pcb Hardware.
Under debian the new versions kick out the old versions.
The debian maintainer answered, that he does not intend to change this behavior.
Commercial use with debian/devuan is such not possible. You do not want to migrate old projects forcefully to new versions, for small changes in a maintenance phase. Migration is not backwards compatible.
I think all Linux distributions will do the same: kick out the old versions.
The kicad documentation states that a project once modified can no more be read by an older version of kicad. But does that mean the design data is screwed up?
If you are very conservative and precautios, make up a VM with the older kicad version.
Anyhow: on the kicad home page I can't find any support for downloading older versions either.
That N100 is a quite weak CPU. Everything requiring CPU performance will delay the response.