You are not logged in.
greenjeans, the boot device menu lets me choose "USB" or "USB UEFI". F11 on this box.
I'm sure it's available because I've made a few excalibur i386 live-isos and included xfe.
2.0.1-1 is installed on my EEE and 2.0.1-2 is available in excalibur and ceres.
If you want it on chimaera, there's a chance that the excal deb will install. If not, you'd need to download the source from salsa.debian and backport it to chimaera. But if you want 2.1, you'll probably have to get the upstream non-debianized source and either package it or compile it behind your package manager's back.
Thanks for the reminder. I just tried it with an excalibur desktop-live iso and memtest86+x64.efi works here on two computers in legacy boot mode and two computers in uefi mode. (That's a total of three computers - one of them can be switched easily between uefi and legacy at boot).
The .bin file doesn't boot for me on any of them.
I think I'll make two boot menu entries - one for .efi and one for .bin. Excalibur preview live-isos will be posted soon.
Start with df -h which will show your mounted partitions with their size and amount used. Pay particular attention to the percentage used on your root filesystem. If it goes beyond 95% you're likely to have problems. If anything is too full, find some big files to delete.
You might run apt-cache autoclean to get rid of old deb packages in /var/cache/apt/archives or even apt-cache clean to get rid of all the deb packages in that directory. Note that this will not uninstall any programs. It just remove the .deb packages, so if you needed to reinstall something, you'd need to pull it from the repository. (i.e. the way most people install packages most of the time.)
It's probably thunar-volman that does this (or doesn't). We don't fork that package, so any bug reports should go to bugs.debian.org. It's also a good idea to find out if the same behavior exists in debian before filing a bug report. Before you do that, consider that the two most recent bug reports on thunar-volman are from 2021 and 2013 and neither one got a response. I also didn't see any bugs on thunar that were relevant and recent.
Altoid,
dd to the whole device, /dev/sdg, not to the partition.
USB 2.0.
It also booted with a refracta excalibur iso (with libre kernel).
Works ok on 1101HA, bios version 0317
I'm using a cheap, no-name giveaway usb stick dd'd with devuan_chimaera_4.0.2_i386_desktop-live.iso.
Is desktop-base installed? Check in synaptic package manager or run dpkg -l desktop-base. If it's not there, then install it.
apt install desktop-base
dpkg -L desktop-base # This will show you all the files in that package.
patch-initrd works
patch-initrd with encrypted loopback file on first partition works.
loopback file on second partition works with and without encryption
reinstall syslinux works. It hung for a long time running mmove using 100% cpu, and I ended up killing that process, but it worked anyway. I suspect the problem was my usb stick that was already having booting problems. Seems to be fixed now.
There were a couple of times I tried to make a loopback file on the second partition, but it never asked which partition to use, and it wanted to put it on the first. I closed refracta2usb and restarted it, and it did what I wanted after that.
All testing done on excalibur host with a devuan excalibur desktop-live iso. (i.e. with microcode)
Looks good in meld. I haven't tried it yet.
Don't know if this helps, but refractasnapshot now uses unmkinitramfs to extract initrd. It's simpler code. Here's the relevant commit.
https://git.devuan.org/devuan/refractas … 7d53f7d9d8
Thank you! I've been dreading touching that script to make any changes. I can test it. I'm using it frequently now that I'm making excalibur isos. Maybe we should both put what we have on git.devuan.org for merging the changes.
xfe - lightweight file manager that also includes xfw text editor. They each use about 9 MB RAM.
qlipper - simple clipboard similar to parcellite. Uses about 20 MB and works without dbus-bin or dbus-daemon installed.
links2 or dillo for graphical web browsers. Any of the big ones are too painful when you only have 2 GB RAM and 1.33 GHz Atom CPU. Sometimes lynx or w3m will suffice.
claws-mail - 49 MB compared to thunderbird's 307 MB.
What is /root/dev? Why is it trying to mount there?
Code for forked packages is here:
https://git.devuan.org/devuan/policykit-1
You can also get devuan package information from here:
https://pkginfo.devuan.org/cgi-bin/policy-query.html
If you can't find an associated package on our git, check salsa.debian.org.
I was probably root when I ran the installer.
Some packages are missing in that last iso. They're the ones that were excluded in the debootstrap command, and I forgot to add them back in. If you do install from that iso, make sure you install logrotate and rsyslog. That will also pull in cron.
The other issue is that "username=devuan" isn't on the command line, and /etc/sudoers.d/live gives sudo nopasswd permissions to the non-existent user named "user". If you install the system, edit or delete that file.
I left out the section of the build that edits initrd to remove unnecessary stuff to make it smaller. Seems to be 47mb either way. With all the software bloat, the "minimal" live iso no longer fits on a CD. It's more than 47mb over the limit, so trimming initrd isn't going to help.
New iso:
https://get.refracta.org/files/experime … l-live.iso
sha256sum
https://get.refracta.org/files/experime … iso.sha256
8278bc1c1af87d538d73efb64534c076bdd3ecaeba27a1eb20cdc49e5b701660 devuan_excalibur_6.0-preview-2025-04-15_0923_amd64_minimal-live.iso
It was the rootfs_overlay that had lib/live/config/ and two custom scripts that was interfering with the symlink. I changed it to usr/lib/live/config and it's all better. Uploading new iso to the same directory now. Release docs and motd need refreshing, but other than that, I think it's good to go. If you happen to have a braille display, please test.
It finally finished uploading and the sha256sum is good.
248b64b2bca77de3a2d1f8582049d604d007004fa31487409fb8fe3bfc00e15d devuan_excalibur_6.0-preview-2025-04-14_2142_amd64_minimal-live.iso
Making encrypted partitions in d-i is a confusing process. For reference, here's a video of making an unencrypted boot partition and an encrypted root partition. The "-4" at the end of the filename is the number of attempts I made until I did it right. I screw it up about half the times I do it.
I added the usrmerge part incorrectly the first time. The option is "--merged-usr" - but doing that correctly didn't help.
Running the build functions manually one at a time worked except for the xorriso part, but running xorriso manually did work, and I got a bootable iso. All the live-* scripts are there, but the efi part didn't get made. And it seems like the espeak stuff isn't working, but I'll need to boot it on hardware to be sure. I'll compare the build scripts for the desktop-live and minimal-live and see if I can cobble one that works.
If your mate install includes desktop-base, you'll need to wait for version 5.9 to move down to excalibur. (Or pull it from ceres)
Thanks. I looked for the usrmerge links quickly and missed that. I'm not sure why it didn't work when the desktop live did. Both builds use the same library for the debootstrap command.
Looking again...
Update: Adding usrmerge to the debootstrap includes did not help. Also, the date on /lib is Dec 31 2020. That seems very weird.
My 32-bit netbook thinks it's a good idea. It already has convinced me to work on a similar project. I merged it with my project to update my nodbus build, which turned out to be more difficult than expected. A bunch of stuff that used to install without dbus will no longer comply with such a restriction. That includes spacefm. I think xfe is the only graphical file manager that doesn't want dbus.
Anyway, if you want to look at any of what I've done, we can talk. If you do make one, I'm sure it'll be leaner than mine.
The real issue is the web browser. None of the big ones are fun to use with only 2G of memory. Falkon uses more than firefox which uses more than chromium. Hundreds of megabytes with one page open. Leave that out and you just eliminated a huge security risk.
Also regarding security - encrypted filesystems only work when the computer is turned off.
I don't know what. First isos had some things missing. All the live-boot* and live-config* packages were installed, but /lib/live/boot didn't exist and /lib/live/config/ only had the custom scripts that get added during the build.
Two minimal-live amd64 isos:
https://get.refracta.org/files/experimental/
2025-04-08-5 In this one the build was hacked to reinstall the live-* packages at the end. It populated /lib/live/config but not /lib/live/boot.
2025-04-10 I disabled the reinstall of the live-* packages to have an example. Also in this one (and one before that didn't get uploaded) I disabled the surgical procedures on the initramfs to see if that would help. It didn't.
No hostname with or without the live-config scripts, and even though /etc/hostname is correct.
I was able to get to the xfce backgrounds dir. You can't select a file from that settings dialog. It only lets you choose a directory, then it shows thumbnails.
Wow, I didn't notice the inird. I looked inside and it's around 90mb of firmware, 60 of which are nvidia.