You are not logged in.
Head_on_a_Stick wrote:... The default Xfce desktop for Devuan uses SLiM or LightDM and both run X under the root user so both are vulnerable to this exploit.
Starting the desktop via GDM or startx will cause X to be run under the normal user and so avoid this vulnerability completely. ... )
Perhaps I have not understood the problem correctly. SLiM or LightDM is clear. But I am thinking about it:
How is it with SDDM?
When I start Plasma Wayland, that is o.k.
But if I start e.g. LXDE with SDDM, how is that.
lxdm and sddm both run X as root. To check that, run
ps aux |grep XI thought reportbug was fixed, but I don't know for sure. I always use email to report bugs.
Send email to bugs@devuan.org
Subject line should be descriptive
First line of bug should have:
Package: <packagename>And then the body of the email with explanation of the problem.
It's also not a bad idea to report the problem here first, in case it's not really a bug.
Instructions are here: https://bugs.devuan.org/Reporting.html
New cryptsetup-modified-functions is now in ceres. It'll migrate down to daedalus next week. I know that it installs correctly, but I can't test to see if it does what it's supposed to do. Please test and let me know. Thanks.
$ apt policy cryptsetup-modified-functions
cryptsetup-modified-functions:
Installed: 2023.02.12
Candidate: 2023.02.12
Version table:
*** 2023.02.12 100
100 /var/lib/dpkg/status
23.02.12 10
10 http://deb.devuan.org/merged ceres/main amd64 PackagesAlso, I noticed that this section still has a long timeout loop. In the past, I reduced the timeout to 1, I think. Is it still a problem?
_do_stop_remove() {
local name="$1" i rv=0
for i in 1 2 4 8 16 32; do
remove_mapping "$name" 3<&- && break || rv=$?
if [ $rv -eq 1 ] || [ $rv -eq 2 -a $i -gt 16 ]; then
log_action_end_msg $rv
break
fi
log_action_cont_msg "$name busy..."
sleep $i
done
}I did two installs today with devuan_daedalus_5.0.preview-20230206_amd64_netinstall.iso.
One had an encrypted root partition and unencrypted /boot partition.
The other had encrypted lvm with unencrypted /boot partition, via Guided Partitioning in the installer.
I see no delay in shutdown with either system.
I can still update cryptsetup-modified-functions and build it for ceres/daedalus if there are cases where it's needed.
@devujan: Please put the final version you want me to use in a code box to make it easy for me. (so I don't screw it up.) Thanks.
Thank you!
I guess I will be reviving the cryptsetup-modified-functions package for daedalus.
rolfie wrote:Outlook to Chimaera: there the issue is fixed.
rolfie
In Daedalus the problem is back....
--------------------------patch-----------------------------------------------
--- /lib/cryptsetup/cryptdisks-functions.orig 2023-01-31 21:00:09.967829315 +0100
+++ /lib/cryptsetup/cryptdisks-functions 2023-01-31 21:10:31.023816298 +0100
@@ -184,8 +184,16 @@
# Removes all mappings in crypttab, except the ones holding the root
# file system or /usr
do_stop() {
- local devno_rootfs devno_usr
+ local devno_rootfs devno_usr vgs vg
dmsetup mknodes
+ if [ -x /sbin/lvm ]; then
+ vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
+ if [ -n "${vgs}" ]; then
+ for vg in ${vgs}; do
+ /sbin/lvm vgchange -a n ${vg} >/dev/null 2>&1
+ done
+ fi
+ fi
log_action_begin_msg "Stopping $INITSTATE crypto disks"devno_rootfs="$(get_mnt_devno /)" || devno_rootfs=""
--------------------------patch/----------------------------------------------Above patch mitigates the problem for me (Daedalus FDE && LVM).
Best wishes
Jan
What is this about?
I'm not aware of any "cooldown time between searches" here?
I see it if I'm not logged in. Do a search, try to do another search immediately and it says I have to wait 30 seconds. When I'm logged in, there is no delay for the second search.
Note: I poked around the admin section looking for that setting, but I couldn't find it.
What would be the benefit of a Devuan-specific community repository, as opposed to a Debian-wide one?
Unless you're not intending it to be Devuan-specific, in which case I amend the above to: what would you consider to be the benefits of a Debian-wide community repository?
I imagine that a Debian-wide community repository would not exclude software that requires systemd. One for Devuan would need to exclude things that won't install on Devuan. If you're running Debian, you will probably be able to use anything that's in the crapton repo.
fsmithred wrote:The version of live-boot in daedalus/ceres is still broken. Use the deb packages for live-boot and live-boot-initramfs-tools in the same sourceforge directory I linked in my last post.
Make sure you dd the iso to the whole device, not to a partition. ( to /dev/sdb and not to /dev/sdb1 for example.)
So qemu-system-x86_64 isn't a way to do so?
Aka, with the command parameters from earlier in this thread only slightly different.
Btw, if it doesn't work properly installing via qemu on a vm, that's usually a sign of somrthing needs to be fixed.
If live-boot is broken (can't find the mount command) then it doesn't matter if you install to VM or hardware.
However... the fixed version of live-boot is now in sid/ceres and will soon be in daedalus.
$ apt policy live-boot
...
Version table:
1:20230131 10
10 http://deb.devuan.org/merged ceres/main amd64 Packages
10 http://debian.csail.mit.edu/debian sid/main amd64 Packages
There does not seem to be a metapackage in debian for the ukui desktop. It looks like you have to install the parts separately. I tried a few that I thought would pull in the main parts of the desktop, but they did not. (ukui-session-manager, ukui-sessionserver, ukui-desktopserver).
I would expect to see a package called ukui, or ukui-desktop and probably task-ukui-desktop, too. Didn't find them in sid or at salsa.debian.org.
You could install the ukui parts after an install of the base system without a desktop, or you could install the base system and drop to a shell before exiting the installer, and install the parts in a chroot. (the installer makes this easy). My preference is to reboot into the installed base system first, and then add other things. Seems to be safer and easier in the long run.
Well, the order was the same for 11 years, across several versions of several distributions, including Devuan. Is there a chance that this was only coincidence?
Yes, there's a chance it's coincidence. I've gotten away with using device names instead of uuids many times, even though the recommendation to use uuids in fstab goes back to some older version of debian that pre-dates devuan. I forget which one. (squeeze? wheezy?)
Another helpful tip - you can avoid installing Recommends with:
apt --no-install-recommends install <package>Redshift will install without geoclue this way. (Edit: and without avahi-daemon.)
I wonder if there's a way to scan the whole Debian/Devuan package information database to filter the packages that list zeitgeist (or its libraries) as a suggests or depends.
.
apt rdepends zeitgeistwill show packages that depend on zeitgeist. I don't know an easy way to get Recommends or Suggests.
Maybe some good tips here: https://dev1galaxy.org/viewtopic.php?id=511
Why don’t you tell me?
"I'm sorry, Dave. I'm afraid I can't do that."
I read through this thread quickly and may have missed something, but it sounds like you're trying to make changes in a running live session. Or maybe you're surgically modifying the iso file and then booting the result. Those ways sound difficult to me. Easier is to install devuan into a spare partition or into a virtual machine, configure it the way you want, and then run refractasnapshot.
To boot the live isos without autologin, add the word noautologin to the boot command.
To boot the live isos without sudo, add nocomponents=sudo to the boot command.
Read man live-config for more.
You'll also need to recompile the kernel to support aufs. (or use one that does support it)
Maybe I'm dense, but I don't understand what you're trying to do.
I was wrong. That package is gone and consolekit was rebuilt without the dep on libcgmanager0.
If you refuse aptitude's first suggestion, it should give you other possible solutions.
Edit: if that doesn't work, whatever is wrong will get fixed tomorrow or so.
This post intentionally left blank.
After update, it's gone.
$ apt policy libcgmanager0
libcgmanager0:
Installed: (none)
Candidate: (none)Look:
empty@P14s:~ $ pgrep -a dbus 1|empty@P14s:~ $^ This is not possible with the other init systems.
I guess I'm not understanding what you're saying here. It is possible to run sysvinit without dbus. This is in a daedalus live-iso made last May.
user@refracta-nodbus:~$ pgrep -a dbus
user@refracta-nodbus:~$
user@refracta-nodbus:~$ dpkg -l |grep sysvinit
ii live-config-sysvinit 11.0.3+devuan2 all Live System Configuration Components (sysvinit backend)
ii sysvinit-core 3.03-1devuan1 amd64 System-V-like init
ii sysvinit-utils 3.03-1devuan1 amd64 System-V-like utilities1. During installation, formatting is mandatory for the "/" partition and is not allowed without a direct user selection for the /home partition.
I don't understand what you are saying here, but it sounds wrong.
It is not mandatory for the installer to format the chosen partition(s) but it is mandatory for them to have a filesystem if you want them to contain files, and formatting is the default setting.
You can partition and format before running the installer and tell the installer not to format. That's a checkbox in the options menu of the graphical installer and it's a config file setting in the cli installer.
You have the choice to install the entire system to one partition, or you could optionally have separate partitions for /boot and/or /home.
The installer doesn't know what to do with your old home or the user configs it contains. It's up to you to figure out any conflicts caused by mismatched or missing config files caused by sharing a home between two different operating systems.
deepforest, I would like to see the installation log (refractainstaller.log) that should be in the user's home directory. You can post it here or paste.debian.net or email it to me through the forum. Thanks.
It shouldn't matter that your partition was mounted, because you should not be selecting that pre-existing home partition during the installation. Please be aware that the default action is to format any partitions you select. If you select a partition with data you want to keep, you will lose it.
Camtaf's diagnosis is probably correct. I've sometimes seen remnant /target_home and /target_boot directories that didn't get cleaned up correctly, but they are just mountpoints and are always empty on reboot.
Also, that first option in the live installer, "Create new, separate /home partition" is not the same thing as "Re-use an existing /home partition that already has files on it." That latter option doesn't exist. If you want to re-use an existing home, just let the installer put /home in the root partition and edit your fstab afterward. I recommend keeping the user configs from the live install in case you need to use them. Just rename /home to /home.live or something like that.
I built live-boot packages with the fix and put them here for people to use until debian builds them. I really hope we don't have to fork live-boot for this.
https://sourceforge.net/projects/refracta/files/tools/
live-boot, live-boot-initramfs-tools and live-boot doc all from 2022-12-16.
Fluxbox-1.4 is not in sid/ceres yet, so I guess you'd have to compile it yourself. That might be easy or not. I don't know. It may not make it into sid in time for bookworm/daedalus.