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:
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:
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 ?
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.
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.
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
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.
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 …
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
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.
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 …
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.
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))
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.
hhhummmm we have a problem then
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 …
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>
So do not put your own root= there 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)