You are not logged in.
There are alternate color schemes for geany. Check out the screenshots directory to see examples.
https://github.com/codebrainz/geany-themes
I used the default highlighting for geany for years, but it's become harder to read the orange on white, so I switched to gedit colors, and sometimes I switch to a dark background and use himbere.
https://github.com/codebrainz/geany-the … /gedit.png
https://github.com/codebrainz/geany-the … mbeere.png
You could drop to console and use the cli version of the installer.
# Press ctrl-alt-F2 to get to a command prompt.
sudo refractainstaller
Note that refractainstaller does not do any automatic partitioning. If you boot in uefi mode and you don't have an efi partition, the installer will complain.
selecting a folder of images is impossible in the dialog, all the filenames
remain ghosted and clicking them does nothing
You cannot select files in that window. You can only select folders.
Select the folder, and then the thumbnails will be displayed.
Folder, Other, highlight the folder you want, Open.
I think you might have an easier time if you were working on an installed system. Install to a partition on hard drive or on a usb stick or in a virtual hard disk, and then you will be able to reboot during the upgrade.
I don't know if this is helpful:
$ dpkg -l |grep input
ii libinput-bin 1.16.4-3 amd64 input device management and event handling library - udev quirks
ii libinput10:amd64 1.16.4-3 amd64 input device management and event handling library - shared library
ii libxcb-xinput0:amd64 1.14-3 amd64 X C Binding, xinput extension
ii xinput 1.6.3-1 amd64 Runtime configuration and test of XInput devices
ii xserver-xorg-input-libinput 0.30.0-1 amd64 X.Org X server -- libinput input driver
$ dpkg -l |grep evdev
ii libevdev2:amd64 1.11.0+dfsg-1 amd64 wrapper library for evdev devices
xscreensaver is installed and set to run in the desktop's startup applications. It is disabled in the Screensaver settings.
xfce4-power-manager is set to suspend on lid closing. It is not set to lock the screen.
Closing lid puts computer into suspend and locks the screen. When I raise the lid, I get the xscreensaver login screen.
This is in Chimaera.
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.