I can only offer a data point - it's not happening here running daedalus on asus EEE with 686-pae kernel, minimal lxqt with no display manager. Tested before and after latest upgrade which gave me xserver-xorg-core and xserver-common.

*.dpkg-dist is the saved copy of a new config file when the old one was kept in place. I think if you have brightness.dpkg-dist but not brightness, then something is wrong. Converseley, *.dpkg-old is the old version that's saved when it gets replace with the new one. I think you only get that when you tell debconf to use the package maintainer's (new) version rather than the old version that you modified from the default.

Sorry, I have no other answers.

I can't read most of that, but I know what it's tellilng  you. Excalibur is still the Testing suite, so there is no -security or -updates repos. Those won't exist until excalibur is officially released as Stable. Comment them out for now.

I don't know if that's meant for making install lists.  Feeding the list to apt install is possible, but might not be the best way. In the past, I've used 'dpkg --get-selections' 'dpkg --clear-selections'  and 'dpkg --set-selections' to make an install list and use it on another machine.

The installer will recognize more than one existing efi partition and let you choose the one you want, so yes, you have to make it first.
In gparted, make a fat32 partition and give it the esp flag (it'll get the boot flag automatically).

Your motherboard might not let you be the one to decide which efi partition is the real one. And I don't know if having two and switching them by changing the drive order will work or is safe. The usual procedure is just to let linux use the same efi partition as windows and put itself in first place for booting. If you've looked at what's in the efi partition, you can see that there are several bootloaders. You can change the order or manage them otherwise with efibootmgr - depending on how much the motherboard manufacturer felt like following standards. see rodbooks.com for more info on uefi.

Of course, having someone who knows where to look is even better. Thanks, dzz.

I'm not sure what's up with ssh. In the excalibur isos I've made recently, live-config keeps turning off password authentication. I resorted to making a live-config script to look for 'SSH-ON' in the boot command.

Sorry I missed this thread when it was new. Running refractasnapshot without syslinux would result in the script failing because it looks for syslinux/isolinux files to put into the iso. It might be possible to run it and then chroot into the filesystem copy to make changes and then run the xorriso command manually to pack it into an iso file.

I don't have any arm hardware to play with this. If anyone figures out how to do it, please let me know. If someone feels competent enough to try, I can help with pointing where to look in the script so they don't have to follow every strand of spaghetti.

hello again, i386.

I replaced/updated the final debian kernel with linux-libre from FSFLA.
https://get.refracta.org/files/testing/ … 4_1613.iso

No kernel source or headers with this one. I selected the kernel that gets all the updates and changes (short term support) and that's probably fine while excalibur is in testing. If I continue with these builds, I'll probably change to the long term support kernel. Or you could do that yourself with 'apt install linux-libre-lts'.

edit: almost forgot this. it's also in the same dir as the iso along with a gpg sig file.     sha256sum

d03a863bfdf91425b6b6d640450b7bd2b67c7c9c94c68898b57f918b7ea63fe7  refracta_13_nox_libre_i386-20250304_1613.iso

Yes, a new thread for the post-installation issues would be good. That makes it easier to find the useful information in the discussion later.

Is there a way to boot the image in qemu or virtualbox? I tried but failed - what is the correct cpu type to use? pine64.org mentions Cortex A53, Allwinner A64/R18 but I don't see those in the qemu list of supported devices.

So instead, I mounted the image file and chrooted into it, installed xserver-xephyr and jwm, and I can get a graphical session. I also tried installing xfce4, but I couldn't get that to run. I also couldn't get gnome to run, but I don't know the command to start it.

I wish I had a pine phone to try it for real (and for other reasons). The mobian site talks about dd'ing the image to usb and booting it on x86 hardware. Is this possible with the movuan image? I did put it on a usb stick, but when I plug it into the laptop, fdisk doesn't see it. Syslog shows usb device, but it doesn't get a block device name. Is there some package I can install that will recognize the partitions on the usb?

git.devuan.org is free. You could put the code there. I don't know if there are any space constraints that would prevent storing images there, and I don't think you can build there.

I get the same error as nixer re: function check_chown. It seems like it's confused about where the logfile goes. I added set -x and tee'd the output. That didn't get the last of it, so I also made a screenshot. On re-read, I see that nixer was in ceres and I'm doing this in excalibur, but I don't think that should matter.

text output and screenshot
https://get.refracta.org/files/misc/alphautilz.out
https://get.refracta.org/files/misc/alp … output.png