You are not logged in.
Did it work?
I have xscreensaver disabled and let xfce4-power-manager handle suspend and lock when lid is closed.
The point-release numbers refer to the isos. If you update/upgrade your system, your system is much newer than 3.1.
Install libpam-elogind and remove consolekit and libpam-ck-connector.
Oops! Try it without the 'ck' at the end.
dpkg -l | egrep "consolekit|logind|policykit|polkit|libpam"
<snip>
...installed, but these don't count toward that, correct?And why might my initrd.img_pre-snapshot be missing?
Correct. No live-tools package in your system.
Check the error log to see what happened with initramfs. If you run the cli version of refractasnapshot, add '-d' option to get a move verbose log. If you start the gui version from the menu, it's already in debug mode. (/var/log/refractasnapshot.log)
Check this, too:
dpkg -l | egrep "consolekit|logind|policykit|polkit|libpam|ck"
Please use deb.devuan.org so that the load gets spread out over all the mirrors in the round-robin.
the way i see it is i dont believe the update-initramfs will update/ugrade a live read only root file system, so you will be stuck with an initrd that is always going to use ascii authorization tools. I could be wrong here but that is my take on it unless refracta-snapshot can bypass this hurdle?
im going to test this myself with a live iso upgrade, im intrigued by it now.
If the live-tools package is installed, update-initramfs gets diverted. You could run 'update-initramfs.orig.initramfs-tools...' instead. I prefer to remove or not install live-tools. I could never figure out what it was good for.
su was moved from the shadow source package to util-linux, and the behavior changed at that time. To revert to the old behavior (from man su):
echo 'ALWAYS_SET_PATH yes' >> /etc/default/su
To give user permission to run ping in chimaera:
dpkg-reconfigure iputils-ping
fsmithred wrote:If this is running in ram from an iso, then it's a read-only system that can't be upgraded.
Here you used the word "upgrade" and not "update". Are you saying that for a live system, packages can be updated - as I said I've successfully done - but a full system upgrade is impossible? This is a known thing? If so, how not?
I'm saying you can't upgrade the packages in a live-iso because it's read-only. But you found the way around that. You can upgrade packages in the running system if you have enough ram, and you can also make a snapshot directly from a running live system.
I've never tried upgrading a live system to the next release. I did try upgrading ascii to chimaera installed on a virtual hard disk, and it was very ugly. Problems were mostly around loss of python2 and loss of network connection when wicd went away. I don't think I even tried the desktop after the upgrade.
To test root's path, as root:
echo $PATH
and see if it contains /sbin and /usr/sbin.
I'm not good with all that 'kit stuff, and I haven't had good luck with consolekit. I use elogind instead. But before messing with any of that, there's a more important question.
Possibly further complicating matters is that this is an install *always* run from ram. It is only installed on disc/iso. It has never existed as a hdd install.
If this is running in ram from an iso, then it's a read-only system that can't be upgraded. If all the upgrades are happening in a persistent volume, then I think it's way past time to make a new iso. Please explain your setup a little more, because I don't really understand what you did. Thanks.
Probably these two:
policykit-1-gnome
libpam-elogind
But if I point the Desktop-Settings dialog to that directory (it's on another drive BTW) all the *.png files are ghosted and unselectable (no permissions issues that I can see)
That's where you select the directory and then the thumbnails appear and you can select one.
@hevidevi
I think the isos have to be in the same partition that has the /boot directory.
As far I can remember, it is possible to have more than one caspers system but only one unique Debian system with "live" on the hard disk...
You can have more than one debian/devuan live iso bootable on hard disk or usb. It depends on how you lay out the disk. I make multiboot live-usb devuan or debian systems all the time using refracta2usb.
https://refracta.org/docs/readme.refracta2usb.txt
https://sourceforge.net/projects/refrac … -2.4.3.deb
I did today realize, that Refracta live use did hide some content of /home/user etc. I have to continue to experiment that problem probably solving through links and sub dir's in /home/user...
See the extensive rsync excludes file at /usr/lib/refractasnapshot/snapshot_exclude.list and edit the file to suit your needs. If you want to keep a file that is excluded, just comment out that line in the list.
A question more: I don't like USB hardware stick outside from my laptops because danger (one more) for the computer itself. I assume other users are also afraid about the same danger and did try to use refracta snapshot iso's directly out the internal hard disk?
What seems to be the best way to do that?
Please start a new topic for this question. Maybe call it "boot iso from hard disk" or something similar.
Or search the forum for 'isofile loop findiso' to see past discussions.
Thanks.
Try restarting any network manager that you're running. (wicd, network-manager, connman or other.)
Or log out of desktop and log in again.
Or cycle through runlevel 1. As root:
init 1
and then ctrl-d to get back to runlevel 2.
It looks like it's taking around 30 seconds for the system to figure out that it can't load the i915 firmware. You could install firmware-misc-nonfree and see if that helps.
Maybe gigolo or avahi would be helpful. I don't use either, so this is just a guess.
Install bootlogd and look in /var/log/boot.
https://wiki.debian.org/bootlogd
There used to be a way to make that into a nice graph, but I can't find it.
Make sure gvfs is installed, including gvfs-backends. That's my first guess.
Also, if you don't want to type ip addresses, you could use hostnames, if you list the address/hostname pairs in /etc/hosts.
From the Beowulf release notes. I just tested the second method in daedalus, and it still works.
### Starting X from a terminal
In Devuan 3 Beowulf, the X server can now be run without root
privileges. As a result, some additional requirements must be met when
launching X directly from a TTY (e.g., with 'xinit' or 'startx')
especially on systems upgraded from Devuan Jessie.In Devuan 3 Beowulf it is sufficient to install 'elogind' and
'libpam-elogind', and then use either 'startx' or 'xinit' as usual
from a regular user account. In this case, the Xorg log file will be
available under '~/.local/share/xorg/'.The system still needs to support Kernel Mode Setting (KMS).
Therefore, this solution may not work in some virtualization
environments (e.g., virtualbox) or if the kernel has no driver that
supports your GPU.Alternatively, it is still possible to run X with setuid root. In this
case, you need to install `xserver-xorg-legacy` and ensure that the
file '/etc/X11/Xwrapper.config' contains the (uncommented) line:needs_root_rights=yes
To turn off mdadm:
# update-rc.d mdadm defaults-disabled
or get rid of it:
apt purge mdadm
I think someone would have to get brave and clone the heads git repo to build it with live-sdk.
Wasn't someone else complaining about the new firefox being broken? It's still possible to go back to the older one.
apt install firefox-esr=78.15.0esr-1~deb11u1