[ale] changes to fstab in fedora 20

Jim Kinney jim.kinney at gmail.com
Tue Mar 11 23:00:27 EDT 2014


I do believe you are correct. A F20 encrypted laptop shows a pair of
partitions, one is boot the other is a type 83 . Pvscan shows the source as
being inside a container called luks-<long string UUID type> with lvms
inside it. Fstab shows / as type ext4 with options default,
x-systemd.device-timeout=0

The /dev/mapper/ luks-* links to ../dm0. The lvms links to dm1,dm2, etc.

It would not make sense to force lvm to understand encryption so it must be
the lvm container. Um. Duh.
On Mar 11, 2014 5:49 PM, "Derek Atkins" <derek at ihtfp.com> wrote:

> Sorry, your thinking is faulty.
>
> When you install a system with encrypted disk the installer creates a
> /boot partition and a crypt partition. Then creates / and swap inside an
> lvm inside the crypt.  When I get back to my laptop I can show you all the
> partition info that shows this.
>
> -derek
>
> Sent from my HTC smartphone
>
>
> ----- Reply message -----
> From: "Jim Kinney" <jim.kinney at gmail.com>
> To: "Atlanta Linux Enthusiasts" <ale at ale.org>
> Subject: [ale] changes to fstab in fedora 20
> Date: Tue, Mar 11, 2014 5:37 PM
>
>
> I'll have to double check my laptop at home. I know the installer will do
> the RightThing automagically so that's the easiest way to fix it.
>
> Seems like the PV has to be outside the crypt container at the least as
> individual LVs can be crypted. Usuall routine is to crypt everything but
> /boot so even swap get protected. In Fedora, default setup is a /boot, a PV
> with a single LV that contains / and swap and /home partitions. Thus my
> (probably faulty) thinking that the encryption occurs inside the LV itself.
>
>
> On Tue, Mar 11, 2014 at 5:19 PM, Derek Atkins <derek at ihtfp.com> wrote:
>
>> I think you have those commands backwards. If you want to create an
>> encrypted drive ala the installer I think you need to cryptsetup, then
>> pvcreate, then lvcreate, then mkfs.  This mirrors what my encrypted system
>> looks like.  The lvm is inside the crypto.
>>
>> -derek
>>
>> Sent from my HTC smartphone
>>
>>
>>
>> ----- Reply message -----
>> From: "Jim Kinney" <jim.kinney at gmail.com>
>> To: "Atlanta Linux Enthusiasts" <ale at ale.org>
>> Subject: [ale] changes to fstab in fedora 20
>> Date: Tue, Mar 11, 2014 5:03 PM
>>
>>
>> I know the encrypt drives process JustWorks during _installation_ of F20.
>> I'm 90% certain it encrypts the contents of an LVM and not the other way
>> around. If you encrypt a container that holds PVM/LVM IDs, the kernel will
>> not know how to use it (I think - still digging in systemd as well). Also,
>> F20 is using grub2 which is also a vertical learning curve.
>>
>> I think you need to go the following order:
>>
>> pvcreate
>> lvcreate
>> cryptsetup
>> mkfs
>>
>>
>> On Tue, Mar 11, 2014 at 4:36 PM, Scott Castaline <skotchman at gmail.com>wrote:
>>
>>> Anyone understand the changes made to filesystem mounting at boot-time
>>> in Fedora 20? Apparently systemd now controls it all? The reason i ask is
>>> that when I had originally upgraded to F 20 I had setup all 5 drives in the
>>> installer. Since then everytime the door leading to the garage, under the
>>> room my systems are in, slams shut it causes the floor to pop up and my
>>> system will sometimes jump. Normally everyone is careful about opening and
>>> closing this door and I had also moved the computers over to the other side
>>> of the room the last time I went through the hassle of crashed drives. This
>>> one day was exceptionally windy and the door really slammed hard.
>>> Immediately I started getting warnings of read/write errors, bad sectors,
>>> etc., etc. on one drive then 2 more drives suddenly unmounted. The system
>>> then rebooted itself and never came back up.
>>>
>>> Since it was toast I went ahead and ran smartctl tests followed by
>>> badblocks which pointed to my 4th drive (hmm not the 5th or 3rd drives). I
>>> then ran dd if=/dev/urandom of=/dev/sd? on the remaining 4 drives. I did
>>> the boot drive seperately so that I could get my system at least partially
>>> back up. I reinstalled F 20 with just the one hdd figuring that the
>>> remaining 3 drive I could manually add back in. By the way I don't use raid
>>> so that is not to be figured into my problem, I do however setup LUKS on
>>> the raw device followed by LVM. My steps are:
>>>
>>> 1. cryptsetup luksFormat /dev/sd? (exact syntax maybe wrong as I'm doing
>>> this by memory which admittedly has gone downhill lately).
>>>
>>> 2. blkid /dev/sd? (to get the luks UUID of the drive for the next 2
>>> steps)
>>>
>>> 3. cryptsetup luksOpen /dev/sd? luks-<Block UUID >
>>>
>>> 4. pvcreate /dev/mapper/luks-<Block UUID >
>>>
>>> 5. vgcreate <name used for vg> /dev/mapper/luks-<Block UUID >
>>>
>>> 6. lvcreate -L <size of lv> -n <name of lv> <name of vg>
>>>
>>> 7. mkfs.ext4 /dev/mapper/vg-name/lv-name
>>>
>>> 8. I'll go ahead and mount it where I plan to mount it in fstab and
>>> verify that all is well.
>>>
>>> 9. Add the luks UUID in /etc/crypttab and enter the mounting info of the
>>> lv in fstab. (This is where it is different. I noticed that the mount
>>> options part is different from the past in that it'll have
>>> "defaults;x-systemd.device-timeout=0 1 2" on lvs that were created by
>>> the installer. So I duplicated this for the lvs that I added.
>>>
>>> 10. Unmount lvs, close luks volume and reboot.
>>>
>>> The system will then either hang on boot or dump out to maintenance mode
>>> when trying to mount my lv. I can however manually mount the lv and the
>>> boot will continue. So what's the deal? Anyone know? This is the way I've
>>> done it in the past with NFP. I found the docs on this very confusing in
>>> that it keeps on referring to something else which will refer to something
>>> else again, so on & so on, eventually it goes around in a circle.
>>>
>>> Hellllppp Meeeeeeeeeeee (in my best human-fly imitation from the spider
>>> web).
>>>
>>> Scott C.
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>
>>
>>
>> --
>> --
>> James P. Kinney III
>>
>> Every time you stop a school, you will have to build a jail. What you
>> gain at one end you lose at the other. It's like feeding a dog on his own
>> tail. It won't fatten the dog.
>> - Speech 11/23/1900 Mark Twain
>>
>>
>> *http://heretothereideas.blogspot.com/
>> <http://heretothereideas.blogspot.com/>*
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
>
>
> --
> --
> James P. Kinney III
>
> Every time you stop a school, you will have to build a jail. What you gain
> at one end you lose at the other. It's like feeding a dog on his own tail.
> It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
>
>
> *http://heretothereideas.blogspot.com/
> <http://heretothereideas.blogspot.com/>*
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140311/3d655fd3/attachment-0001.html>


More information about the Ale mailing list