You are not logged in.
xzcat: (stdin): File format not recognized
Looks like xz-utils got removed. I hope that's all it is.
Oh, man, that is weird. It'll start xfce even if xfce is already running. I was doing this on my second monitor, and when I ran startxfce4, I saw the panel on my first monitor flash like it was restarting.* I don't know what the deal is with xfce, but I can get it to work correctly with icewm, jwm or even openbox.
ssh -X user@remote
Xephyr :1 -screen 1024x768 -resizeable &
And then one of the following:
icewm --display=:1
jwm -display=:1
DISPLAY=:1 openbox-session
usernames are not the same on local and remote machines.
I didn't have to do anything with Xauthority or Forwarding settings.
Tested on second machine where I had to use :2 instead of :1.
* Just to be perfectly clear, I was in a terminal and logged into the remote with 'ssh -X' when I ran startxfce4, and it affected the local machine instead of the remote.
I cloned your repo, installed the build-deps and built packages in beowulf with no problems using dpkg-buildpackage -us -uc -b
I'm trying to install ceres in a chroot right now, and it's going to take an hour to install git. I don't know wtf the problem is. It normally would take about one minute. I'll get back to you on that.
Edit: The same works for me in chimaera.
Maybe this bug: https://bugs.devuan.org/cgi/bugreport.cgi?bug=483
You could try adding 'sleep 1' to /etc/init.d/eudev as indicated in message #10 or #20 or apply the patch in the last message.
I got an ubuntu iso (20.04.1-desktop)
Booted it in qemu and used unmkinitramfs to unpack it into an empty directory.
Re-packed it as gzip with find . -print0 | cpio -0 -H newc -o | gzip -c > ../initrd.img-custom
I then unpacked the custom initrd to verify that the amd64 microcode was still there. It was.
Note 1: I chose gzip because the command was easier to type than xz, and I did not attempt to figure out the correct lz4 command. I just wanted to make sure the microcode didn't get lost.
Note 2: Since it was a live session, there were only dead symlinks in /boot, so I used /cdrom/casper/initrd for the extraction.
You can try using mkinitramfs. I've never used it, but it looks like it would be easier than figuring out the right decompression commands. But I'd really like to know why it doesn't work with your rebuilt initrd. Did you verify that it's really in gzip format by running 'file' on it?
Edit: Yup. ^^^
So, you can either change the compression to a supported type as I mentioned above, or you can manually unpack the initrd, remove crypttab, repack it and replace /home/work/iso/live/initrd.img with the modified copy, then re-run refractasnapshot and just select the option to re-run xorriso. You must have set save_work=yes in the config file for this to work.
If you keep the lz4 and do the manual re-pack, your users may run into the same problem if they try to make a snapshot on an encrypted system.
Fixed the path, thanks.
According to the comments in the config file, the choices are:
# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz ]
The other way to find out which it is would be to remove the amd64-microcode package and then run 'file -L /boot/initrd.img' again.
Edit: Or maybe not. When I install amd64-microcode, checking the initrd with file tells me it's gzip compresses, same as if I did not install that microcode. But installing the intel-microcode does change it to ASCII cpio archive. And the commands to extract it work correctly.
The kernel does not get upgraded automatically unless you have the kernel metapackage installed - linux-image-amd64 (or other arch). Either install that or install the specific kernel package you want.
I have linux-image-5.6.0-2-amd64 in chimaera, and I think that's the latest.
You already have the only line for chimaera in your sources.list. There won't be any -updates or -security repos until after chimaera goes stable (or maybe after bullseye goes stable).
From the log:
gzip: stdin: not in gzip format
cpio: premature end of archive
xzcat: (stdin): File format not recognized
cpio: premature end of archive
It's not gzip and it's not xz compression, so it must be something else. If so, you can change the compression to gzip or xz and run 'update-initramfs -u', or else the script needs to be fixed to accommodate other types of compression.
Run this (or read the file, it's not long) to see what compression is used.
grep "COMPRESS=" /etc/initramfs-tools/initramfs.conf
Then do this...
file -L /boot/initrd.img
or run 'file' on whatever actual file you use for initramfs.
As I mentioned on Ubuntu everything works fine until I install cryptsetup.
Another thing... I did I try with initrd_crypt=yes in the .conf file.... and removed cryptsetup that allows Snapshot to complete successfully... but the calamaeres settings does not like that, because its looking for that specific cryptsetup file structure.
Setting initrd_crypt=yes without cryptsetup installed won't put cryptsetup in the initrramfs like it's meant to do.
What error messages are you getting and when?
Have you tried running snapshot with cryptsetup installed but calamares-settings removed?
If refractasnapshot is failing, I'd like to see the error log. If you're using the cli version, please run it in debug mode (sudo refractasnapshot -d). It'll be too big to post here. You can email it or paste it at paste.debian.net
apt install build-essential linux-headers-$(uname -r)
is what you normally need to compile anything other than a full kernel.
I am unable to reproduce the problem. I tried with and without calamares-settings-debian and refractasnapshot ran both times. I also tried with initrd_crypt=yes in refractasnapshot.conf. Are you using a custom kernel and initrd? Also tried with intel-microcode and then amd64-microcode installed.
Please post the output of this command.
file -L /initrd.img
You should be able to make a snapshot with cryptsetup installed. I do it all the time.
What does calamares-settings-debian do? Does it make changes to initrd.img?
I haven't tried making a snapshot with calamares installed. I can take a look at this tonight.
Sometimes questions about refracta tools appear in the Derivatives section, sometimes in DIY and sometimes in Installation. You have my attention, so right here will also work.
Here's the documentation for it:
https://refracta.org/docs/readme.refractasnapshot.txt
https://refracta.org/docs/refractasnapshot.conf.txt
https://refracta.org/docs/snapshot_exclude.list.txt
Not much to add to all the good advice that was given. If you choose to upgrade, here' the ascii to beowulf upgrade guide. It might help.
https://devuan.org/os/documentation/dev … to-beowulf
do you run it on ram by means of a dvd or usb?
what is the objective of using the firejail container? what is the risk difference compared against not using it?
You can load it to ram when you boot from dvd or usb. If you must run from dvd, I strongly suggest that you boot it to ram. It takes a lot longer to boot that way, but then it responds much faster while you are using it. Running from usb is almost as fast as running from hard drive, so you might not feel the need to boot to ram.
Running a program in firejail prevents the program from accessing any directories that are not specified in the profile for that program. For example, my firefox can only see the Downloads directory. I cannot access any other files in my home from within firefox, and neither can any of the websites I visit.
If this is beowulf, it might be a bug in eudev. It sounds like one I've encountered with live-isos. When it happens to you, is /dev/dri the only thing that's missing?
Instead of rebooting when it happens, try the following (as root):
/etc/init.d/eudev stop
/etc/init.d/eudev start
and see if that fixes it.
Another thing you could do to test is to run 'lsmod | wc -l' to see how many modules got loaded at boot. When eudev fails to find all the devices, it usually registers around half as many as when it works correctly.
And if this is the problem, I'll tell you how to fix it.
libgles2-mesa : Depends: libglapi-mesa (= 13.0.6-1+b2) but 18.3.6-2+deb10u1 is to be installed
deb10u1 in the version means first revision for debian 10, which is buster, which is also beowulf. Decide whether you're running ascii or beowulf and stick to one. Let us know what you put in sources.list.d, too.
The missing services menu was part of the mate system tools. Those were left out of refractra10, but I don't recall the exact reason. There was some incompatibility.
Run 'sysv-rc-conf' in a terminal as root (or sudo) and you can easily turn services on or off in selected runlevels. Navigate with arrow keys, select with space bar, then q to save and quit.
Please tell me more about the problem you're having with firefox-esr. I just upgraded it in a live-iso booted in qemu with no problems.
I will make new isos and release them some time probably in the next month or two. Let me know of any other problems so I can fix them.
I sometimes do the opposite and search for debian when I want devuan, because there's a better chance of getting useful hits on a lot of topics.
If they give you a choice between ubuntu and debian, take the package for debian.
Beowulf is Buster. Ascii is Stretch.
Avoid adding outside repos to sources.list.
I can't give you a time estimate on when or if s6 will be a choice during installation. I've heard nothing about it in months.
The point-release of beowulf will add runit to the init system selection in the installer. Maybe s6 can be added in time for Chimaera. That's a guess.
@devujan:
Sorry for the long delay. You can now install cryptsetup-modified-functions in beowulf to correct the problem. The package is now in beowulf-proposed-updates.
Download and install the package:
https://pkgmaster.devuan.org/devuan/poo … n1_all.deb
Or add beowulf-proposed-updates to sources.list:
deb http://deb.devuan.org/merged beowulf-proposed-updates main
Boot with live-iso, shrink the /boot partition and make a new partition. Do not format the new partition with a filesystem. (Unformatted is the last choice in gparted's dropdown list of formats.) Give it bios_grub flag (or type ef02 if you use gdisk).
You need at least 1MB for the bios_grub partition. I usually give it 2MB so I don't have to worry about what kind of MB I'm using.