System copy on other USB keys and cursor blinking at startup

English Install/Boot/Login
#1

Hello,

First of all, let me tell you my final goal before to describe the situation for which I require your help.

The ultimate goal is to have an encrypted USB key on two system, a key containing the boot that will be unencrypted and one USB key that will be encrypted and will contain the root, knowing that contrary to what the OpenSuse documentation indicates, it refuses to encrypt partitions like /.

To achieve this I developed my project in phases:

[ol]
[li]Install OpensSuse on two USB keys as needed for the final goal.[/li]To this point, everything is working properly, this means in particular that /boot is on a key, the / on the second key and the system can be used as a “basic” system.

[li]Use two other keys by copying all the original keys (/boot and /) on the new keys and modifying the necessary parameters (see tests below).[/li]At this point, I’m stuck.

[li]Last phase, encrypt the key that will contain /, copy the system and change the necessary settings.[/li]Of course, as you can see, before beginning this step, already I have to be able to boot a system on new keys, without encryption.
[/ol]

Used versions and configurations:

[ol]
[li]BIOS: drive order.[/li]
[LIST=1]
[li]hd0: /boot.[/li]
[li]hd1: /.[/li][/ol]

[li]OS: OpensSuse 13.1.[/li]
[li]File system: ext4 for all keys.[/li]
[li]Partitions: use UUID instead of traditionnal notation /dev/sdxx.[/li]
[li]GRUB: the one included in OpensSuse 13.1, GRUB2.[/li]
[li]Terminal: Super user mode.[/li]
[li]File Manager: Super user mode.[/li][/LIST]

Tests already done for Phase 2, unsuccessfully, of course:

[ol]
[li]Copy all the content of the original keys in the directories:[/li]
[LIST=1]
[li]/mnt/00_Orig/boot for the key containing /boot.[/li]
[li]/mnt/00_Orig/root for the key containing /.[/li]
[li]Information: rsync -aHAXP order is used to make these copies.[/li]
[LIST=1]
[li]N.B.: this command is used with these options for all copies below.[/li][/ol]

[/LIST]

[li]Formatting of two new USB keys in ext4.[/li]
[li]Mount of the news keys in folders:[/li]
[ol]
[li]/mnt/01_New/boot.[/li]
[li]/mnt/01_New/root.[/li][/ol]

[li]Copy the entire contents of:[/li]
[ol]
[li]/mnt/00_Orig/boot in /mnt/01_New/boot.[/li]
[li]/mnt/00_Orig/root in /mnt/01_New/root.[/li][/ol]

[li]Unmount of /mnt/01_New/boot.[/li]
[li]Mount of /mnt/01_New/boot in /mnt/01_New/root/boot.[/li]
[li]Chroot (chroot . /bin/bash) on /mnt/01_New/root.[/li]
[li]Yast execution.[/li]
[li]Adaptation and configuration control of the boot loader (GRUB) (System → Boot loader).[/li]
[ol]
[li]Boot from boot partion only option selected: Ok.[/li]
[li]Probe foreign OS off: Ok.[/li]
[li]Disk order :[/li]
[LIST=1]
[li]hd0: key contaning /boot.[/li]
[li]hd1: key contaning /.[/li][/ol]

[li]Removal of internal HDD: Ok.[/li][/LIST]

[li]Adaptation and control of configuration files:[/li]
[ol]
[li]etc/fstab : change the UUIDs of the original keys by the UUIDs of the key new keys.[/li]
[li]Files check:[/li]
[LIST=1]
[li]/boot/grub2/grub.cfg: the UUIDs of the original keys have been replaced with the UUIDs of the new keys → Ok[/li]
[li]/boot/grub2/device.map.new:new references hd0 drives for /boot and hd1 for / have been modified with those of the new USB keys→ Ok.[/li]
[li]Checking the /etc/default/grub file: no change (same as the original file) → Ok. [/li]
[li]Checking /etc/sysconfig/bootloader file: no change (same as the original file) → Ok. [/li][/ol]

[/LIST]

[li]As the above steps have remained ineffective, I tried to regenerate the /boot/initrd file with dracut --regenerate-all –force.[/li][/LIST]

Problem currently encountered: when the computer start, of course after the BIOS sequence, it appears the blinking cursor at the top left of the screen, but the “Grub loading” and “Welcome to grub” messages never appear.

By advance I thank those who take the time to read this message and will be able to answer, even it would be only for a part, to this situation.

Last question: Is this a mistake from me or just OpenSuse which does not support this type of “manipulation” by contrast, seems other distributions like Debian?

#2

What is the security benefit of this compared to using LVM with an encrypted LVM group?

#3

I’m new to Linux world.
I began to test some distributions at begin of June 2014, so I think it’s better for me to begin with the most simple and go step by step after understanding what I did.
So I guess, to begin with “simple” partions is more easier as to begin with logical.

In summary, of course LVM could be another solution but presently I would like to study and understand what I do in order to not do all with some automatic tools and if once a problem appear not be able to solve it because I don’t understand what happen.

I hope you understand my approach and be able to help me for this step ?

Thanks by advance

#4

On 2014-09-09 09:56, Miuku wrote:
>
> What is the security benefit of this compared to using LVM with an
> encrypted LVM group?

I would also prefer a normal encrypted root partition setup, without
LVM. I don’t like LVM, that’s all. It is possible to setup such a
system, the hurdle is YaST not supporting it.

There is not security benefit as such (nor dis-benefit), that’s the
wrong question :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#5

On 2014-09-09 09:46, chrissuse wrote:
>
> Hello,
>
>
> First of all, let me tell you my final goal before to describe the
> situation for which I require your help.
>
>
> The ultimate goal is to have an encrypted USB key on two system, a key
> containing the boot that will be unencrypted and one USB key that will
> be encrypted and will contain the root, knowing that contrary to what
> the OpenSuse documentation indicates, it refuses to encrypt partitions
> like /.
>
>
> To achieve this I developed my project in phases:
>
>
> - Install OpensSuse on two USB keys as needed for the final goal.
> To this point, everything is working properly, this means in
> particular that /boot is on a key, the / on the second key and the
> system can be used as a “basic” system.
> - Use two other keys by copying all the original keys (/boot and /)
> on the new keys and modifying the necessary parameters (see tests
> below).
> At this point, I’m stuck.

And me, I’m confused by your terminology and “writeup layout” :slight_smile:

  1. What is “key” above? You refer to usb “sticks”? Or to encryption
    “keys”, which you want to store on a usb stick, instead of as a typed
    password?

Why are all your paragraphs broken in two columns? It is distracting.

…

> - Copy all the content of the original keys in the directories:
>
>
> - /mnt/00_Orig/boot for the key containing /boot.
> - /mnt/00_Orig/root for the key containing /.
> - Information: rsync -aHAXP order is used to make these copies.
>
>
> - N.B.: this command is used with these options for all copies
> below.

See? Why the two columns? :-?

> - As the above steps have remained ineffective, I tried to regenerate
> the /boot/initrd file with dracut --regenerate-all –force.

WHOA! Dracut? Are you using Factory? You said you were using 13.1, but
13.1 does not support dracut… Factory is switching to dracut instead.

If you are trying to use dracut on 13.1, that’s plain wrong: you mix two
difficult and uncharted issues on one essay…

(someone is investigating this very issue on the mail list currently)

> Problem currently encountered: when the computer start, of course after
> the BIOS sequence, it appears the blinking cursor at the top left of
> the screen, but the “Grub loading” and “Welcome to grub” messages never
> appear.
>
>
> By advance I thank those who take the time to read this message and
> will be able to answer, even it would be only for a part, to this
> situation.

I tried, but I’m confused.

I don’t see the encryption step, for instance.

> Last question: Is this a mistake from me or just OpenSuse which does
> not support this type of “manipulation” by contrast, seems other
> distributions like Debian?

It what I understand you try is what Miuku hints at, no, it is not
supported. It can be done, manually without YaST, but you can not
upgrade the system. On release change it is reinstall fresh with all the
rigmarole.

I even have doubts about normal updates (mkinitrd)…

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#6

Hello,

To answer some questions:

  1. I dont’ see 2 columns but of course space between lines. I did it in order to be more readable.
  2. Regarding the term keys, sorry for my poor english but your are right it’s better to say “stick” in place of “keys”, although I specified that presently I’m still at the step with no-encryption, so no keys in sense encryption are used :shame:.
  3. Concerning dracut, when I tried all I presently know on OpenSuse and Linux (manual configuration, automatic configuration with Yast), I though why not trying to regenerate initrd.
    BTW when I read documentation I understood that with version 13.1 you can not use anymore mkinitrd, but seems that is one error and in every way, this regenration didn’t give me the result I’m waiting for :’(.

BTW, do you have some answers to solve the step I try to go over ?

Thanks by advance.

#7

On 2014-09-09 17:16, chrissuse wrote:
>
> Hello,
>
> To answer some questions:
>
> - I dont’ see 2 columns but of course space between lines. I did it in
> order to be more readable.

There is a peculiarity of this forum. You read it on a web page, but
others read it via an nntp gateway. I use Thunderbird, a mail client.
For some strange reason, your post was corrupted in the conversion.

> - Regarding the term keys, sorry for my poor english but your are
> right it’s better to say “stick” in place of “keys”, although I
> specified that presently I’m still at the step with no-encryption, so
> no keys in sense encryption are used :shame:.

Ah, ok, so what you are trying now is simply to install openSUSE on a
USB stick? Or two? Why two? And it is currently booting? What’s the
problem then?

I suggest you do not use a different boot media for the encrypted
system, but the same one with a new entry in the menu. Hum, I’m, more
comfortable with grub 1, but it is doable.

The next step is to encrypt the destination stick for root, and copy the
system there (you can not encrypt “/boot”, anyway).

And no, forget YaST here, you are alone from here on.

After that, I’m unsure. I’m also trying it and stuck… I suggest you
read the current thread about the issue in the factory mail list, there
are ideas.

Basically:

encrypt root
keep /boot in clear and separate:
copy system on encrypted destination
make changes in fstab and crypttab to know about it.
ditto for grub configs or kernel lines.
maybe add a kernel option to boot line (dunno which).
run mkinitrd in a chroot, but tell it first to add the encryption modules.
adapt boot menu: one entry for normal system, another for the encrypted.
test boot.

And, I suggest to test using a virtual machine, easier than a real one
with usb sticks…

You will need to also keep the non-encrypted root, I think.

> - Concerning dracut, when I tried all I presently know on OpenSuse and
> Linux (manual configuration, automatic configuration with Yast), I
> though why not trying to regenerate initrd.
> BTW when I read documentation I understood that with version 13.1 you
> can not use anymore mkinitrd, but seems that is one error and in every
> way, this regenration didn’t give me the result I’m waiting for :’(.

Why not? Of course mkinitrd works in 13.1, it is dracut which does not.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#8

On 2014-09-09 22:48, Carlos E. R. wrote:

> Basically:
>
> encrypt root
> keep /boot in clear and separate:
> copy system on encrypted destination
> make changes in fstab and crypttab to know about it.
> ditto for grub configs or kernel lines.
> maybe add a kernel option to boot line (dunno which).
> run mkinitrd in a chroot, but tell it first to add the encryption modules.
> adapt boot menu: one entry for normal system, another for the encrypted.
> test boot.

If you start with this setup:

/boot unencrypted
/ unencrypted
/home encrypted

Then yast already adds the needed encryption modules to initrd, and adds
whatever is needed for the password to be requested at boot. The next
step is to switch to an encrypted root, but without using yast for this
step as it is not supported.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#9

Hello,

Thanks for your answers, but seems I was not clear enough, so I will try to be.

As I said I go step by step, so presently I don’t have an encryption problem but just the fact to try to copy a system on another drives with different UUIDs.

Regarding encryption I already read many threads and many of your suggestions are mentionned and I concluded that the better solution for me, once I will go into the encryption step, is to have two USB drives as I mentionned in my initial post.
Regarding the parts encrypted and not encrypted if you read the point 3. you can see that I said I will encrypt only the / and not the /boot partition.
The reason why I use two USB drives is not the goal of my request and everybody have different needs, so for me I think it will be the better way to do.
And even I will do that you suggest the problem will remain because with two different partitions, you will have two different UUID, so it’s not because you will have the two partitions on the same drive you will not experience the same problem.
Last point, the problem is not to work with two different USB drive because as I explained in the first point, this configuration work fine with and OpenSuse intrallation until I try to copy the system on partition with different UUIDs.

To finish on the encryption, I already tested the entire project, but I had to go back because I experienced the problem I presently experience and try to solve, reason why I repeat I have to go step by step and the step I’m now show me it’s not an encryption problem but, I think, an UUID problem. What do you think about?

So could you please answer to my initial request and don’t ask me why I don’t use another way to encrypt, because it’s not the present problem.

If I can summarize the present problem: imagine do you regulary do a copy of your system in order that if you have a crash of your drives you can restore quickly the system on new drives. The problem I experience is because you will have différent UUIDs you will not be able to restore. Of course, I guess there are other tools in order to do a backup and a restore of a linux system, but this remak don’t have the goal to speak about disk crashs but only to try illustrating my problem.

I hope my explantions are more clear now :).

#10

On 2014-09-10 08:06, chrissuse wrote:

> Last point, the problem is not to work with two different USB drive
> because as I explained in the first point, this configuration work fine
> with and OpenSuse intrallation until I try to copy the system on
> partition with different UUIDs.
>
> To finish on the encryption, I already tested the entire project, but I
> had to go back because I experienced the problem I presently experience
> and try to solve, reason why I repeat I have to go step by step and the
> step I’m now show me it’s not an encryption problem but, I think, an
> UUID problem. What do you think about?
>
> So could you please answer to my initial request and don’t ask me why I
> don’t use another way to encrypt, because it’s not the present problem.

Ah…

We also have a language barrier problem, I think :-))

> If I can summarize the present problem: imagine do you regulary do a
> copy of your system in order that if you have a crash of your drives you
> can restore quickly the system on new drives. The problem I experience
> is because you will have différent UUIDs you will not be able to
> restore. Of course, I guess there are other tools in order to do a
> backup and a restore of a linux system, but this remak don’t have the
> goal to speak about disk crashs but only to try illustrating my problem.
>
> I hope my explantions are more clear now :).

Ok, so you want simply to clone an existing system into another set of
disks and that it boots. The uuids are cloned together with the
partitions, if you use “dd”, but certainly not with file-copy. You have
to manually change them when making the destination filesystem, or to
edit the files that reference them. fstab is the main one. Grub 2, I
don’t know very well about it.

I think that you need to reinstall grub 2 on the destination of the file
clone.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#11

Hello,

Thank you again for your answer and I know my initial message is long, but if you read the points 7. to 10. of my tests (by example 10. 1. specify that etc/fstab is ok) I try to explain that I modifiy the files in order the UUIDs correspond with the UUIDs of the news partitions.

I of course tried to modify the file manualy, but as I said doesn’t work, reason why I had the idea to do a chroot on the new system and use Yast that seems recreate the initrd file, grub2 configuration files and after the controls I specified all the files had change the UUIDs with the new partitions.

So or I miss some configuration file or OpenSuse doesn’t support a UUID change, reason why when I will have enough time I will try my project with Debian but hope someone could answer me if some error are so big that I’m not able to see:nerd:.

#12

OK cloning is tricky If you want easy cloning mount the partitions by label. Then all the UUID and sdX# problems go away. Down side is that if you use labels you can not mount two partitions with the same labels at the same time. Well you can but you have to take special actions.

As to editing you can simply edit the /etc/fstbl file as root to any new mounts . You do have to use actual true partition IDs. Note that UUID is just a link to the underling sdX# device. look in /dev and you will see how it works.

#13

Hello,

Thanks for this proposition, I will try it and will let you know if go better or not, but presently as specified I think I will allow time to test my project with Debian because I feel it’s an OpenSuse problem same as which you can not encrypt the / opposite as the documentation of the version 13.1.

Of course if I have more time to test again with OpenSuses I will see if the label could be an answer to my problem.

#14

On 2014-09-10 13:46, chrissuse wrote:
>
> Hello,
>
> Thank you again for your answer and I know my initial message is long,
> but if you read the points 7. to 10. of my tests (by example 10. 1.
> specify that etc/fstab is ok) I try to explain that I modifiy the files
> in order the UUIDs correspond with the UUIDs of the news partitions.
>
> I of course tried to modify the file manualy, but as I said doesn’t
> work, reason why I had the idea to do a chroot on the new system and use
> Yast that seems recreate the initrd file, grub2 configuration files and
> after the controls I specified all the files had change the UUIDs with
> the new partitions.
>
> So or I miss some configuration file or OpenSuse doesn’t support a UUID
> change,

Of course it does, but not “automatically”. Meaning “hey, I have changed
the uuid, adapt it all” command.

But I have not seen a description of the symptoms you get, why you think
it does not work. Like exact error messages you get, exact procedure you
did to reinstall grub… maybe you did say, but then I did not
understand it.

Because basically, depending on where and how grub is installed, you
have to reinstall it… not just change a file.

Or use clonezilla. Perhaps it handles this part. I’m unsure.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)