Just checked - that is the grub2 script that works. Posting from Lubuntu 18.04.1 now.

lubuntu@lubuntu:~$ uname -a
Linux lubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
lubuntu@lubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic

To my mind, that means that there probably ought to be a script that works for Devuan, I just haven't got it right yet. On the other hand, the Devuan startup might be different to (L)ubuntu in a way that is significant. It's this need to tweak scripts that made me wish for loopback.cfg.

What I'm aiming on doing is building a USB memory drive with multiple ISOs on it so that I can invoke DBAN, SuperGrub2, rEFInd, SystemResueCD, and others, including Devuan, (and possibly even a Puppy Linux setup) to use as a 'Swiss Army Knife' when installing Linux on recalcitrant laptops (like the Infamous Acer ES1-132 series), and rescuing other people's data (or deleting data before disposal of hardware). At the moment, I have a resealable freezer bag with 'a number' of USB memory drives in it.

As I said in the previous posting, installing Devuan would likely not be a problem, this was triggered by me wishing to do a quick suck-it-and-see to see if Devuan booted nicely on my hardware. It would have been faster for me to walk to the nearest store selling USB memory drives, buy one, and write the ISO out to that, but there's no challenge in that, and it costs money. :-)

Simplicio

Thank-you PeteGozz. I'm not new to this, but I was last up to speed when I was running both Debian and OpenBSD on some Motorola 68k processors. That was 'a while' ago, so I'm rather rusty. I remember the frustrations of starting X-windows and having a grey screen with a centred black 'X', and no response to keyboard or mouse. I've run K/L/Ubuntu on Intel kit for the last <mumble> years, so haven't needed to fiddle/play much.

Short answer: I don't know. And, I don't immediately know how to find out.

Foolish optimist that I am, I would have expected the installation process to have determined that it needed that package. I have this unrealistic expectation that the

apt install task-desktop

would have pulled in the relevant packages if they were absent, as it includes Wicd, and there is a Wi-Fi chipset visible on lspci.

Unfortunately, I have several major family events (some good, some bad) to deal with, so I don't have time to play right now.

Thank-you for the helpful follow-up - I do appreciate it, even if I can't act on it immediately.

Thank-you PeteGozz - I shall try your suggestions 'when I get the time', which might not be for a while. I very much appreciate your reply.

OK, so I finally had the time to work my way through the issues I encountered.

The task I had set myself was to install Devuan onto an SSD that itself was installed as a replacement for the original hard disk in laptop with 4 Gbytes of memory, a 64-bit capable AMD processor, and UEFI boot firmware.

By the way, I'm lazy. All this was done while logged in as root, not using sudo.

Writing the net-install ISO to a USB flash memory drive and doing a minimal install worked fine, as documented above, so I had an SSD with two partitions: /dev/sda1 and /dev/sda2

/dev/sda1 is the EFI system partition, vFAT formatted
/dev/sda2 is a single, encrypted partition, which is opened at boot by GRUB2

It's probably a good idea to make sure the system is nicely up-to-date

apt-get update
apt-get upgrade

(Reboot if necessary if a new kernel has appeared)

After that interlude, once accessed through the device mapper, the encrypted sda2 (/dev/sda2_crypt) appears as a Linux Logical Volume Manager (lvm) physical device, in which I set up a single volume group (Volume Group Foo (vgf)), and a set of volumes. (If I had felt like it, I could have set up multiple Volume Groups, e.g. Volume Group Bar Volume Group Baz, but for now at least, it wasn't necessary). I chose to set up the following volumes (I'm sure there are different, better ways, but I had to start somewhere. I prefixed each name with an 'x' because I knew that later on I'd need a clearly different name for migration purposes).

Physical Volume
/dev/sda2_crypt
Volume Group: vgf
xroot
xboot
xhome
xtmp
xvar
xswap

If someone else is doing this, they could well have chosen a different name for their encrypted device. You can find out what encrypted devices are on your system by looking at the output of

dmsetup status --target crypt

which will list all of the devices where the device mapper is using encryption.

The logical volume manager also uses the device mapper, but rather than encryption it is doing some clever stuff that enables (for example) separate blocks of storage on different disks to looks as if they are a single device, and allows (relatively) easy expansion and contraction of those devices.

Anyway, you can list the physical devices being used by the logical volume manager by:

lvm pvs 

(physical device show)

You can see what volume groups are defined

lvm vgs 

(volume group show)

and you can see what volumes are define in each volume group

lvm lvs

(logical volume show)

Each logical volume can be treated as thought it were a disk partition. Expanding or contracting lvm volumes is a great deal easier than doing the same with partitions.

So, each lvm volume has its own filesystem. The Devuan installer does not support the NILFS2 filesystem, so what I did, as a temporary measure, is create an ext2 filesystem on each logical volume. I chose to use less than half of my available disk space for the logical volumes I created with ext2 filesystems, as I knew I would need to migrate them later, so I needed to leave space to migrate them into.

You can confirm this on your own system by looking at  /proc/mounts

cat /proc/mounts

or, in a slightly nicer format

findmnt

As I documented above, there were a couple of glitches to do with the way GRUB2 handles encrypted boot partitions, but I got that sorted out, so I had a system I could boot, GRUB would prompt me for the password/phrase for the encrypted partition which allowed it to access /boot and the initrd and initramfs, then the initial startup in the initramfs would re-prompt me for the password/phrase so the system could be brought up.

So, I then had to replace the ext2 filesystems with nilfs2 filesystems. I can't remember if the nilfs tools are included on the minimal net-install Devuan, but if they are not, it is a simple matter of

apt-get install nilfs-tools

I could then use the Logical Volume Manager to define some more volumes, which I put in the same volume group as the first set - they didn't need to be, but there was no pressing reason to define a new one.

yroot
yboot
yhome
ytmp
yvar
yswap

so I now had a whole new set of volumes defined with names that started with a 'y' instead of an 'x'. I could then format these volumes as NILFS2 filesystems as I wasn't using the installer: this was a normal system.

mkfs.nilfs2 /dev/mapper/vgf-yroot
mkfs.nilfs2 /dev/mapper/vgf-yboot
mkfs.nilfs2 /dev/mapper/vgf-yhome
mkfs.nilfs2 /dev/mapper/vgf-ytmp
mkfs.nilfs2 /dev/mapper/vgf-yvar

I left NILFS with all the defaults. Note that NILFS2 uses disk space in an unusual way, so you do NOT want to make the volume too small. This is especially true of the boot volume, which normally doesn't need to be very big at all. I used a sledgehammer to crack a nut and made yboot 4 Gbytes in size, which is probably way too big, but I should be able to reduce it down later, if necessary, as the NILFS2 filesystem is resizeable, and lvm volmes can be shrunk as well.

Now comes the fun bit: I needed to migrate (copy) all of the information from the ext2 volumes over to their corresponding nilfs volumes. If you try to do this on a running system, it probably wont work very well, so don't try it!

Instead, I got a copy of System Rescue CD and put it on a USB flash memory drive. I booted the laptop into System Rescue CD, so the root filesystem in use is on the USB drive. Then a 'fair amount' of typing is needed.

First of all, you need to connect the encrypted partition on the laptop to the device mapper. My laptop discovered the internal disk first, even when booted from the USB drive, so it remained as device /dev/sda, but other laptops may enumerate the USD drive first, so the internal disk might appear as /dev/sdb. The rest of this assumes it's /dev/sda.

cryptsetup luksOpen /dev/sda2  <your-chosen-cryptname>  #<-note, /dev/sda1 is the EFI system partition

You get prompted for the password/phrase, and assuming it's right, the device mapper swings into action, decrypting the partition on the fly/on demand as necessary. You can confirm this by

dmsetup status --target crypt

The logical volume manager will also have swung into action and discovered the volumes defined on the encrypted partiton - you can check this by

lvm pvs
lvm vgs
lvm lvs

We can now mount all the volumes and copy the data across. Because we booted from the USB drive, we don't have to worry about what happens if you copy a file system in use on a running system.

Create the mount points for the source (old) data

mkdir /mnt/old
mkdir /mnt/old/root
mkdir /mnt/old/boot
mkdir /mnt/old/home
mkdir /mnt/old/tmp
mkdir /mnt/old/var

mount the ext volumes (read-only, just for some pretence at safety - you do have backups, don't you?)

mount -o ro /dev/mapper/vgf-xroot  /mnt/old/root
mount -o ro /dev/mapper/vgf-xboot /mnt/old/boot
mount -o ro /dev/mapper/vgf-xhome /mnt/old/home
mount -o ro /dev/mapper/vgf-xtmp /mnt/old/tmp
mount -o ro /dev/mapper/vgf-xvar /mnt/old/var

Now do the destinations

mkdir /mnt/new
mkdir /mnt/new/root
mkdir /mnt/new/boot
mkdir /mnt/new/home
mkdir /mnt/new/tmp
mkdir /mnt/new/var

mount the nilfs2 volumes. These are the options I chose, they are probably not optimal. Shrug.

mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yroot  /mnt/new/root
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yboot /mnt/new/boot
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yhome /mnt/new/home
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-ytmp /mnt/new/tmp
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yvar /mnt/new/var

now do the copying

cp -ax /mnt/old/root/* /mnt/new/root
cp -ax /mnt/old/boot/* /mnt/new/boot
cp -ax /mnt/old/home/* /mnt/new/home
cp -ax /mnt/old/tmp/* /mnt/new/tmp
cp -ax /mnt/old/var/* /mnt/new/var

Now, the fstab we have copied across will still refer the OLD ext2 volumes, so we need to edit the fstab on the new nilfs2 volume

nano /mnt/new/root/etc/fstab

(I use nano, you can use whatever editor you are comfortable with)

The relevant entries will need to be modified to (a) point to the new lvm volumes (the ones prefixed by 'y') and (b) have mount options suitable for nilfs2 (as above).

You can't just reboot and have everything work now. The GRUB2 boot setup still points to all the old volumes, so we not only have to tell GRUB2 that we are using different lvm volumes, GRUB2 also has to understand nilfs2 and have the initial ram disk rebuilt, otherwise nothing will work. As I found out. Repeatedly.

Now, in principle, you can rebuild GRUB2 while you are booted from the System Rescue CD USB drive. In principle.

I ran out of patience, and used a chroot method instead.

So we shut down, and reboot back into Devuan on the ext2 volumes. This doesn't affect the data on the nilfs volumes.

We then set up the chroot environment which will allow us to run the GRUB2 setup for the changed environment.

First of all, create a mount point for the new volumes

mkdir /mnt/chr

now mount the nilfs volumes there

mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yroot  /mnt/chr/  #<-note difference to what we did above
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yboot /mnt/chr/boot
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yhome /mnt/chr/home
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-ytmp /mnt/chr/tmp
mount -o async,noatime,discard,order=strict /dev/mapper/vgf-yvar /mnt/chr/var

now you have a 'sort-of' copy of the familiar linux filesystem layout under /mnt/chr

We do some chroot setup magic

mount -t proc none /mnt/chr/proc
mount -t sysfs none /mnt/chr/sys #<-note sysfs, not sys
mount -o bind /dev /mnt/chr/dev
mount -o bind /run /mnt/chr/run

(The chroot environment wont work properly without the above. Depending on what you are doing, you can 'get away' without some of the above e.g. if you don't need network access while chrooted, but I'm documenting what worked for me. Wiser, better informed heads than me can improve things, I'm sure).

Now, finally we need to make the EFI system partition available while in the chroot environment. What I'm about to do is probably not recommended (Danger Will Robinson!), but it worked for me.
We unmount from it's proper place and remount it at /mnt/new, so we can access it later while chrooted. If a wiser head can advise a better way, please do tell me. (The uuid details can be found in /etc/fstab)

umount /boot/efi
mount -o umask=0077 UUID=<your-uuid> /mnt/chr/boot/efi

Now we chroot

chroot /mnt/chr /bin/bash

...and we are now in a chroot environment aka a chroot jail. In the context of this process, the filesystem layout has its root at /mnt/chr, not / . Wow.

Now, if we run the various GRUB utilities, they will update the new volumes, not the old ones.

There's a couple of things we need to do.
First of all, we need to tell GRUB that it should load the nilfs2 module so it can understand the filesystem on the new volumes. We do that by adding nilfs2 to /etc/initramfs-tools/modules. For good measure, I added lvm, crypto, and cryptodisk too.

nano /etc/initramfs-tools/modules

The other thing to check is that /etc/mtab is correct.

cat /etc/mtab

if it isn't (I didn't need to do this)  you can 'simply'

cat /proc/mounts > /etc/mtab  #<-this is another 'Danger Will Robinson! moment

This (apparently) is important, as GRUB gets some information from /etc/mtab when doing its setup fandango.

Now we can run grub-update, which will build a new initramfs, and rebuild the GRUB2 boot menu. As we are in the chroot environment which should be set up properly, and using the same kernel, we don't have to worry about passing target directories, or specifying processor architecture etc. It 'just works'

update-grub

Then we install it

grub-install

Don't reboot yet.

I'm told its a good idea to dismount volumes nicely, as what you've been doing in the chroot environment isn't visible to the normal system, so we leave the chroot

exit

Then we'd better put the EFI system partition back

umount /mnt/chr/boot/efi
mount -o umask=0077 UUID=<your-uuid> /boot/efi

unmount the pre-chroot magic

umount /mnt/chr/run
umount /mnt/chr/dev
umount /mnt/chr/sys 
umount /mnt/chr/proc

Now you can reboot.

And now, in theory, if I've documented my hurried scribblings properly, when the system comes back up again, it boots using the NILFS2 volumes, and I've achieved what I wanted to do. Use NILFS2 on my SSD, and have an encrypted boot, root and swap, as well as home and everything else.

Now to install/upgrade to a full desktop. Wish me luck...

[Note to self, will add BBCode formatting later, once I get sufficient time. I just wanted to get a rough draft out]

Just a quick update to say that reading Pavel Kogan's blog allowed me to get one baby step further.

http://www.pavelkogan.com/2014/05/23/lu … ncryption/

In it he points out that /etc/default/grub needs to be edited to pass the cryptdevice as a kernel parameter. Modifying it for a (reasonably) default Devuan Jessie install (I downloaded the actual release rather than release candidate and redid things from scratch)

you then need to update the grub installation (there's more to this than meets the eye, which I'll expand on when I have time).

My laptop now boots all the way into Devuan, with an encrypted boot/root  - the only unencrypted area of the disk is the EFI System Partition. The boot process requires you to type in the Luks password twice (Pavel Kogan provides a possible workaround for this).

Unfortunately, I couldn't install on the filesystem of my choice (NILFS), so as a temporary measure, I used ext2, but having got the encryption bit sorted, I'm pretty sure I can sort out creating some NILFS volumes in lvm, copy everything across, update fstab, do a chroot and a grub update (I've probably missed something) and get things set up the way I want. It's 'just' a question of finding the time.

I tried the installer, rather than the live iso, using the Expert option and manual partitioning. This allows me to:

a) Create an EFI System partition (/dev/sda1) and a partition encompassing the rest of the disk (/dev/sda2);
b) Devote the (/dev/sda2) partition to the encryption layer (creating /dev/mapper/sda2_crypt);
c) Build LVM on top the the block device presented by the device mapper (/dev/mapper/sda2_crypt) - creating Volume group 1 (vg1);
d) Create a swap partition within LVM (vg1-swap); BUT
e) NOT use NILFS2 as the filesystem for the root (vg1-root) and other partitions (vg1-<foo,bar,baz>). The installer doesn't offer NILFS as a filesystem which is surely because it does not have mkfs.nilfs2. This debian bug/wishlist item may be relevant ( https://bugs.debian.org/cgi-bin/bugrepo … bug=655438 ).

As a temporary measure, I used ext2, just to see if the installation would complete nicely...

Everything worked fine until writing out the GRUB2 loader, which reported failure.

Booting from a SystemRescueCD USB drive, I can see the encryption, lvm setup, ext2 filesystems on root and other mount points have all been successfully created and populated, but apparently nothing written into the devuan directory created on the EFI System partition.

By using a Super GRUB2 disk ( http://www.supergrubdisk.org/super-grub2-disk/ ) on a USB drive, I can boot the newly-installed Devuan system - this involves enabling the luks capability in GRUB2 to mount the encrypted partition, followed by enabling the lvm-aware capability, at which point SuperGRUB2 finds the initial ramdisk on the root volume and booting works without a problem. This demonstrates that encrypting all except the EFI System partition is achievable...there are 'just' a few details to be worked on.

Personally, I think that encrypting all but the EFI System Partition should be, if not the default, at least a standard option offered to everyone.

One thing I have learnt from this is that it is entirely possible to have your EFI System partition on a separate USB drive to the internal disk on a laptop, which might be useful to some people.