Grub unlocks it, that was fine. I think I needed to give the password twice. And it took time, maybe because the system is old, but it was much slower than normal; this system does not boot so slow normally.

But when other partitions were mounted, and from the settings in my /etec/crypttab, which holds /, swap and another partition, the system couldn't mount the /boot!

Grub unlocked it and ran the kernel and the initramfs, but then all of a sudden, it couldn't anymore mount what it unlocked!

But all that was needed was to put also the settings for /dev/sda1 luks partition in /etec/crypttab and now my system boots, completely encrypted.

I mean, it was a little cryptic (sic!)... Because it said nothing about the luksUUID, no! It complained it couldn't find the ext2 partition's UUID! But it couldn't find it because it does need to be unlocked for a third time (see above for the first two times, IIUC) to become visible! See?

Regards!

I just booted into full-encrypted /boot, / and all (all the rest of the) HDD. And my /boot and entire HDD are on an only MBR-BIOS (some 15yrs old Award6.0 BIO, IIRC, Abit AT832 is the MBO), so HDD (which is just some Seagate 250GB, is MBR-formatted.

It's just the MBR that is but a little exposed to maids (the maids from the attack), and the base Grub in it. And of course the firmware, anywhere in this system, MBO, HDD, is not-completely protectable, because it's the usual NDA stuff, not FOSS like Coreboot...

But encryption is protection in many ways, even on a running system with all unlocked...

Aaarghh... Minor glitches to solve only.

miroR, I'm sorry to say that, as far as I can tell, you can't do the same with MBR disks as I believe there is not enough room in the MBR for GRUB code installed to the MBR to have the capability of opening encrypted partitions. So on MBR-based systems, you will need to have a non-encrypted boot partition.

I'm very happy to be proved wrong.

I think you'll be very happy!

I studied this matter over in a few places, starting from links available in this topic. The most important:

https://wiki.archlinux.org/index.php/GR … _partition

and I ended up convinced that encrypted boot is not a dependency of EFI, but a feature of Grub for long by now, after reading:

https://wiki.debian.org/Grub2

# apt-cache policy grub2

grub2:
  Installed: (none)
  Candidate: 2.02~beta3-5
  Version table:
     2.02~beta3-5 500
        500 http://packages.devuan.org/merged ascii/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged ascii/main amd64 Packages

#
but:
# apt-cache policy grub2-common

grub2-common:
  Installed: 2.02~beta3-5
  Candidate: 2.02~beta3-5
  Version table:
 *** 2.02~beta3-5 500
        500 http://packages.devuan.org/merged ascii/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged ascii/main amd64 Packages
        100 /var/lib/dpkg/status

#
---
Important to note is only that the version is higher than 2.02~beta2-29, reason follows.

I think it should work both in this old MBR based system of mine, as well as in my GPT based newer (but not so new) system of mine.

Will report how I fared.

miroR, I'm sorry to say that, as far as I can tell, you can't do the same with MBR disks as I believe there is not enough room in the MBR for GRUB code installed to the MBR to have the capability of opening encrypted partitions. So on MBR-based systems, you will need to have a non-encrypted boot partition.

I'm very happy to be proved wrong.

I see. Well, I have a couple of systems (fit for my Air-Gapping method, same hardware more than two MBO), and I'll be back to apply full encryption like you made here. But that is later.
Regards!

I'm very happy to be proved wrong.

Yes, I encrypt even /boot.

If you read my earlier posts carefully,

I wish I could have, but haven't yet gone through carefully. Out of time. And also I work terribly slow...

But, I now know where to look for information! Thanks!

Not in this setup that I am currently using, such as for online (only Devuan for online since a month ago, be it Devuan proper or Heads).
In this setup, this --old-- MBO, it's MBR, not EFI.

I hope when I study some day, that there is options for MBR as well... in the links (and maybe in your own posts?)...

Thanks! I will use your info some day, but it remains undefined how soon.
===========================================================================

Yes there was, but I don't remember any details of it now... My mind has started shedding info that I have prepared (and have some in writing) for the Air-Gapped Devuan Install, Tentative topic (linked in my previous post in this topic), and what happeded more exactly with Refracta is lost information here at this time... Sorry!

But I will try again, only really don't know how soon or less soon it will be...

Yes, I checked (that's quick, the try and run update-initramfs with Refracta is the --unknown how soon-- next time)... That's the DVD I used.

You should... Ah, a private PM is due.

Thanks!

Everything worked fine until writing out the GRUB2 loader, which reported failure.
I couldn't get Refracta to, after regularly chroot'ing into a working distro cloned onto another hard disk to put it into another machine [I couldn't get Refracta to]:

# update-initramfs -u -k <the-kernel-version>

so I am wondering now, maybe there is an issue with Refracta?

Of course, it is (pasting, except to the ellipsis):
http://linux.softpedia.com/get/System/O … 2636.shtml
Refracta [...] 8.3 Beta 20170305

That should have worked. Was there an error message?

It seems odd that softpedia labels that iso as beta. It's 8.3.

sha256sum

2b9a39c0e4bbee600607ef24053a65685282d4b47c8a6b76418020e59646ad8e  refracta8.3_xfce_amd64-20170305_0250.iso

Here's where I put my isos (and .asc files if you want to check the signature.)
https://sourceforge.net/projects/refrac … isohybrid/

If you read my earlier posts carefully, you should be able to do it, especially if you follow the link to Pavel Kogan's post:

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

Set up two partitions on the disk:

First: EFI System Partition
Second: Luks encrypted

Inside the LUKS encrypted partition run the Logical Volume Manager (lvm) and create as many volumes as you need.

Set up your chosen filesystem on each volume.

Make sure that GRUB2 includes the relevant encryption modules.
Make sure that the GRUB setup follows the recommendations given by Pavel Kogan above.

What Pavel goes on to do is give a set-up that allows you to enter the encryption password/phrase once, rather than twice when booting. I've not done that, as I don't mind typing in the passphrase twice. For now, at least.

So /boot and swap are encrypted, as well as everything else, apart from the EFI System Partition.

I couldn't get Refracta to, after regularly chroot'ing into a working distro cloned onto another hard disk to put it into another machine [I couldn't get Refracta to]:

# update-initramfs -u -k <the-kernel-version>

so I am wondering now, maybe there is an issue with Refracta?

Because I could, on the last Gentoo instance that I still have for use, arrange for, and mount the new system partitions and all, and chroot into it, from that Gentoo, and perfectly and successfully run the:

# update-initramfs -u -k <the-kernel-version>

Actually I am now running that new machine (new by way of all cloned anew onto the HDD; but MBO was already previously in use), as I am writing this.

Of course, it is (pasting, except to the ellipsis):
http://linux.softpedia.com/get/System/O … 2636.shtml
Refracta [...] 8.3 Beta 20170305

And just a remark:
I don't want (nor need) to use this one (used it in the past a lot, also a few times the Super GRUB2):

on principle. It's SystemDestruction-contaminated...

I do have all (and I mean all) encrypted except the /boot. If you Simplicio really manage it to encrypt even /boot, pls. teach us.

But I have to go now and update my topic over at:

Air-Gapped Devuan Install, Tentative
https://dev1galaxy.org/viewtopic.php?id=746

Regards!

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]

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.

By using Super GRUB2 disk to boot into the new installation, I can run grub-install. This fails with an error, which was roughly:

Anyway, there is a slight misfeature in that you need to edit /etc/default/grub with -

(This bug refers: https://savannah.gnu.org/bugs/?41524 ) The GRUB manual documents the actual behaviour: https://www.gnu.org/software/grub/manual/grub.html

Having done that, and added in GRUB_PRELOAD_MODULES="lvm" for good measure (probably not necessary, but I haven't checked to find out), I then re-run grub-install, this time with no errors.

Then, when I boot, I get presented with a prompt for the password for the encrypted partition. Yay!

But I subsequently get dumped into a GRUB> prompt (not Grub rescue). Boo.

However, if I look at the devices

GRUB> ls

I see all the lvm volumes.

so I set up the linux and initrd

GRUB> linux (lvm/vg1-root)/vmlinuz
GRUB> initrd (lvm/vg1-root)/initrd.img
GRUB> boot

And the boot fails, saying -

error: no suitable video mode found
Booting in blind mode.

However, after a bit of looking, if you add the following command in GRUB before booting

GRUB> insmod all_video

it boots successfully, asking (for the second time, as expected) for the password to the encrypted partition as part of the linux boot sequence.

So all I need to do now is automate the manual fix above. Which I know is possible, because Super GRUB2 disk works fine.

Which means I am one step closer to having Devuan with an unencrypted EFI System Partition, and one encrypted partition that holds LVM volumes providing swap, root, home, etc...

Simplicio

[edited to add BBCode quote and code markup]

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.

I'm not sure I'm up to remastering yet.

The current Jessie rc installer is not LVM2 aware.

That is not exaclty right. You must have downloaded a live iso. The live installer does not do lvm. The installer in the regular installer isos is the debian-installer. It'll do lvm, raid, and all the other stuff you would expect. (It might be possible to get it to install to your prepared lvm with a little bit of hacking. I can't give that a lot of thought at the moment, but I'm not dismissing the idea.) 

For the regular installer, try one of these:
https://files.devuan.org/devuan_jessie_ … aller-iso/

Regarding encrypted boot: I've heard of it. Don't know much about it.

Edit: for the remastering tools, you need refractasnapshot and refractainstaller. (-base packages for cli-only, both -base and -gui for gui) either from devuan experimental repo or download debs from here - https://sourceforge.net/projects/refracta/files/tools/