Grub2 and luks filesystems in older systems.

Hi,

It is time to upgrade several laptops and desktops to OpenSuSE 12.2 but I have a problem.
All my PC’s were installed with previous version of OS and also with LUKS filesystem encryption.
For example one of my laptops has the following filesystem (fs) structure:

/dev/sda1 swap Encrypted
/dev/sda2 / ext3 Encrypted
/dev/sda3 /home ext3 Encrypted
/dev/sda4 /var

/dev/sdb1 (flash usb ) /boot

During the install process I want to leave /home intact.
And I have tried several partitioning ways to generate the file system I want (not the proposed one) on the instal but there is no way to make the installer accept my current setup, specially because using suggesting / on an encrypted fs is not accepted by the installer.

Hence I would like to know how to make GRUB2 accept the Luks encrypted partitions.
That is How To Add those filesystems in GRUB2

In grub it was very very easy:
a simple kernel line on menu.lst like the following:

kernel /vmlinuz-2.6.37.6-0.7-desktop root=/dev/mapper/root luks_root=/dev/sda2 luks_swap=/dev/sda1 luks_home=/dev/sda3 luks=“root swap home” splash=silent quiet showopts vga=0x31a

This solves the problem on grub …
Is there a solution like this for grub2 ?

I must confess my complete ignorance over grub2 and reading the net quite frankly I did not find anything that could help my specific problem …

In case I risk too much with this move can I simply go to yast and make the booloader grub ?
In this manner all the previous menu.lst would be available and thing could go as before …
Is this a wise, meaning prudent, move ?

Regards.

I found a couple of interesting posts on the subject:

Booting from LUKS Physical Volume using Grub 2
ode


insmod gzio
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_twofish
insmod gcry_sha256
cryptomount -u
insmod lvm
insmod ext2
set root=‘lvm/-’

Note
To be done when information will be available. That menu entry was generated with sys-boot/grub-2.00 things changed with the beta releases. cryptomount can be use like `cryptomount hd0,gpt1’ for example as well. This should be able to decrypt the cyphertext. I have a LVM stack on top of LUKS which could be a supplementary difficulty. I could not finish mount cyphertext(s) and finish my test with qemu-kvm. Other contributor(s) without a supplementary LVM stack are encouraged to complete this section.

And

I could not encrypt root, “/var” “/usr” or “/boot” using openSUSE 12.2. I did have a separate “/boot” configured, and was not trying to configure that. So the documentation does not match what happens. If you want an encrypted root file system, it will be easier to use an encrypted LVM which is supported by the installer.

If you want to know what I would do is to copy out your full /home folder as a backup and start over with everything unencrypted and then re-encrypt it when you are done. In any event, you could just keep your /home encrypted and start over in everything else. Normally, if I want to retain my old settings, but reload all new software ware, I just keep my /home folder and all of my personnel settings are maintained and you only need to reinstall your original applications your had before.

Thank You,

If the question is how to add luks* parameters to kernel command line, editing /etc/default/grub should do it. Add them to GRUB_CMDLINE_LINUX variable. Then run “update-bootloader refresh” to regenerate GRUB2 configuration. Verify that options were added correctly in /boot/grub2/grub.cfg

Hi,

Thanks for the replies.
My problem is that those older systems do not have LVM they are plain primary partitions with no LVM filesystems.
There is some info on the web about dealing with older lvm, not plain primary non-lvm fs.

I am trying to do exactly that, but it would be perfect if I did not even had to backup /home. Actually /home is a huge 250GB filesystem … bigger then all others on disk.
I will try any other solutions and report the results.
The change for grub would be actually very fine … but grub is no longer supported unfortunately.

Regards

On 2012-11-08 13:26, keyb user wrote:
> The change for grub would be actually very fine … but grub is no
> longer supported unfortunately.

That is not true. Actually, if you do an upgrade you will keep your
current grub 1 setup.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

Hi,

That up-date-bootloader --refresh does not work it gives a error message:

I added the new kernel parameters

GRUB_CMDLINE_LINUX="root=/dev/mapper/root luks_root=/dev/sda2 luks_swap=/dev/sda1 luks_home=/dev/sda3 luks="root swap home" "

and the error was:

ERROR: Command /usr/sbin/grub2-mkconfig - o /boot/grub2/grub.cfg > /var/log/YaST2/y2log_bootloader 2>&1 failed with code 32512 and output /etc/default/grub : line 16: swap command not found

This means that somehow I can not make a line with the characters “root swap home” !
If I remove the first the “” from that “root swap home” text and then insert it on the grub.cfg file.
But the kernel line seems to me completely wrong.
So quite frankly I think this is not even well supported in command line under grub2 … meaning comand-line compatibility with previous grub …

Regards.

/erc/default/grub is actually a shell script, so just use standard shell quoting:

bor@opensuse:~> grep GRUB_CMDLINE_LINUX= /etc/default/grub
GRUB_CMDLINE_LINUX="foo=\"jsdfk fjdlsk jdlfs\""
bor@opensuse:~> sudo /usr/sbin/grub2-mkconfig 2> /dev/null | grep jsdfk | head -1
    linux    /vmlinuz-3.4.11-2.16-desktop root=/dev/mapper/virt-SuSE--root foo="jsdfk fjdlsk jdlfs" quiet splash=silent

I’m not sure that even matters, since you presumably plan on a clean install.

Boot from a live CD. Run Yast partitioner. There, setup /dev/sda to be an encrypted LVM, and create exactly one volume inside that LVM, which you will use for root in a new install.

With that done, go back to install. Choose advanced partitioning, and put your root partition in that volume inside the encrypted LVM that you still have. You should be able to use your existing home and swap partitions. This will lose a small amount of space due to the LVM overhead, but you are probably not that tight for space. Since the installer does allow use of an encrypted LVM containing the root file system, this should work.

If you run into problems with that, an alternative would be to install all in that encrypted LVM, with no separate root and no swap. And then you can later edit “/etc/fstab” and “/etc/crypttab” to allow you to start using the existing encrypted swap and /home

Hi Carlos,

I meant Grub is no longer being developed …

from Grub GNU GRUB - GNU Project - Free Software Foundation (FSF) home page:

GRUB 2 has replaced what was formerly known as GRUB (i.e. version 0.9x), which has, in turn, become GRUB Legacy. Enhancements to GRUB are still being made, but the current released versions are quite usable for normal operation.

  **[GRUB Legacy](https://www.gnu.org/software/grub/grub-legacy.html) is no longer being   developed**. For the differences between [GRUB Legacy](https://www.gnu.org/software/grub/grub-legacy.html) and GRUB, see the [Grub   Legacy Documentation](http://www.gnu.org/software/grub/grub-legacy-support.html).

And that is really really sad to said the least.
One of Linux major advantages is support for the Legacy software.

Regards.

Hi,

An up-date is never a good solution. One always end up with problems and system instability we can not control.
A Clean instal is always the right way to make an up-grade.
And I actually doubt an up-grade with a encrypted / would even be possible …

  • And I do not want to use LVM, because of the overhead and because of my stronger filesystem encryption.

  • Why is it so difficult to change GRub2 setups ? Something so basic and fundamental to any system ?

Also why all this backup/restore when everything is already on disk ?
There should be a Simple way, a Linux Way to do this … there used to be …

Regards.

On 2012-11-09 13:06, keyb user wrote:

> I meant Grub is no longer being developed …

So what? That is not new, it’s been that way for a long time. openSUSE
maintains is for the moment the same as it did for previous openSUSE
releases. You can use grub1 perfectly safe in 12.2 and report problems
in grub2 so that 12.3 solves them.

> And that is really really sad to said the least.
> One of Linux major advantages is support for the Legacy software.

Indeed.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

On 2012-11-09 13:36, keyb user wrote:
> An up-date is never a good solution. One always end up with problems
> and system instability we can not control.
> A Clean instal is always the right way to make an up-grade.

I do not agree.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

Never say “never”. :slight_smile:

Hi,

Thanks, i actually deduced that once I looked at the entire grub.cfg that resulted from the new editing.
Also the main problem is that other options on the generating script added a root fs with UUID so the kernel command line was always wrong and I ended up by editing manually the grub.cfg file (just for testing purposes).
But the problem remains the same! Hugely un-necessary complexity on something that should be as Simple Basic and straight-forward as a bootloader.

Regards.

:slight_smile:

Apparently I have to surrender to the circumstances.

Regards.

Hi,

hhhummmm we have a problem then :slight_smile: :slight_smile:
But I notice Carlos that you, like me, use a … cof coff … 11.4 OS ?

I will rephrase for the purpose of clarity on my sentence: Going from 11.4 to 12.2 is not a good idea with a up-grade … a clean install is a much more safe install, specially because I hava a / encrypted fs …

Regards.

Why? What’s wrong with using UUID? Once encrypted deice is set up, mounting by UUID will work. Otherwise grub2-mkconfig would not use in the first place. In any case, if you want to disable it:

echo GRUB_DISABLE_LINUX_UUID=true >> /etc/default/grub

.

On 2012-11-09 14:26, keyb user wrote:
>
> arvidjaar;2502514 Wrote:
>> Never say “never”. :slight_smile:
>
> :slight_smile:
>
> Apparently I have to surrender to the circumstances.

For example, a method to recover a badly broken system, that sometimes
works (depends on the exact problem) is to try a DVD upgrade to the same
version.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

Hi,

Because like I mentioned if there would be Two root= … lines on the kernel command line, and because if one places a UUID root line on the kernel cmd line there will be no decryption … nothing would decode the partition map.
Hence when using a encrypted fs it can not be name by UUID … it must be stated has /dev/mapper/<fs>

Regards,
Pedro

So do not put your own root= there :slight_smile: let it handle it.

and because if one places a UUID root line on the kernel cmd line there will be no decryption … nothing would decode the partition map

It is possible that there is a bug, although for all I can tell it is luks_root, luks_swap etc that is triggering decryption, not root= line. Also, the following comment in boot-luks.sh suggests that mounting by UUID works …

# Encrypted volume groups mounted by label or uuid will not
# get recognized otherwise (bnc#722916)