I'm getting 11MB/s with rsync or sftp on the local network, Cat6 with gigabit router.

USB is faster, but that requires getting out of the chair.

Refracta uses only Devuan repositories. Refracta IS Devuan, just with a different name and some different configurations. Your boot menu might say Devuan after the upgrade. You can change that in /etc/default/grub if you want.

Use upgrade instructions for Devuan. Do not use instructions for migration from Debian.

Refracta tracks Debian version numbers because it started out as a Debian re-spin with Debian Lenny (5). It was switched to Devuan with Jessie, and it didn't make sense to go from version 7 to version 1.

Ah, I did just think of one package that isn't in the repo. refracta2usb. The newest version of that is here: https://sourceforge.net/projects/refrac … -2.4.3.deb
It will work with beowulf, chimaera, and probably daedalus, too.

There's no support for lvm in refractainstaller. If you do full disk encryption, you would need to enter the luks passphrase once for grub and then once for the root partition. In that case, /boot is in the root partition. If you made a separate partition for /home, you would need to enter the passphrase for that partition, too.

The only filesystem that refractainstaller knows about is ext[2,3,4].

OK, now here's the part where I tell you about going past the limits.

You could make luks keyfiles to avoid or reduce passphrase entries after the install.
You can use other filesystems if you use the cli installer and set the config file to no_format=yes. Partition and format as you want, then run the installer. You might need to install something in the live system to do this. I don't know what xfs needs.

You can also use the cli installer and manually create lvm or raid. I left some notes about that here: https://dev1galaxy.org/viewtopic.php?id=2323  One thing that's changed is that you don't have to end the /dev/mapper/name with a digit.

ForgeOS (Formerly Michael's Devuan Edition) uses a modified version of the cli refractainstaller that does support lvm. I've only had a couple of brief looks at it and haven't had a chance to dive into the code. The other notable difference is that you make all your selections at the beginning instead of waiting for questions to pop up.

Glad you got it fixed. For future reference, those GDBus errors complaining about missing .service files are just noise from programs that expect you to be running systemd, even though they may not require it. I see them often when I start programs from a terminal.

The watermark is barely visible in the gray field. It's the round peppermint candy. (And now I want one. Or a candy cane, but they're all gone.)

I bumped the request up to our traveling guru at dyne.org. Be patient. He moves faster than email.

The *.d directories are a place for the administrator to put customized configurations that will not be wiped out if a new version of the config file is installed/upgraded. Something is programmed to check for files in that directory, and it's letting you know that there's nothing there.

It should be safe to ignore. I don't have that directory on my chimaera or daedalus installations.

There's no metapackage for backports kernels like there is for the main kernel. The only updates you would get would be if the kernel version didn't change. I don't know if that happens with backports kernels.

I vote for staying in this thread. These things may all be related, and someone else might run into similar problems.

Is it a laptop? (Do we need to deal with lid switch and power-manager?)

Look in /var/log/pm-suspend.log to see information related to entering and leaving suspend state.
Look in /var/log/syslog for info about leaving suspend state. Find where it says PM: suspend entry (deep) to see what's happening when you leave suspend. I could not find anytihing in syslog to show when it went into suspend. (And I started with an empty syslog, so there's no way I missed it.)

If you're still having trouble with suspend after you get the packages all straightened out, you might take a look at this page: https://wiki.ubuntu.com/DebuggingKernelSuspend

Someone in IRC gave me the link. I haven't had a chance to read it, and I will be busy with other things today.

If you use apt or apt-get to install elogind and the others, it will put a lot of packages on the autoremove list, but it won't actually remove them. I'm pretty sure once you do that and libelogind0 is in the system, those packages will be taken off the autoremove list.

To see the autoremove list without removing anything.

apt -s autoremove

If it doesn't clear after libelogind0 is installed, you can reinstall consolekit, libpam-ck-connector and libelogind0. Then we can talk about setting up sudo for only shutdown/reboot.

If you use aptitude to install, then the packages will be automatically removed during the install. Don't do that here.

I'm glad you waited. Install libelogind0 first to replace libsystemd0, and that should prevent all those removals from happening. Then install elogind and the others.