[ale] changes to fstab in fedora 20

Jim Kinney jim.kinney at gmail.com
Tue Mar 11 17:03:18 EDT 2014


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/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140311/4b3ae7b2/attachment.html>


More information about the Ale mailing list