[ale] changes to fstab in fedora 20

Scott Castaline skotchman at gmail.com
Wed Mar 12 09:50:30 EDT 2014


Jim, I had just run badblocks on all 3 drives with no errors. I had run 
it also on my boot drive a couple of days earlier, also no errors. The 
one drive that did have errors out of the original five is already 
pulled out of the loop.

I had originally ran on all five drives:

smartctl test both short & long (with the expected one failure and the 
other four passed)
badblocks (again had the one drive expected failure the other four were 
fine)
dd if=/dev/urandom of=/dev/sda-d (I did the boot drive first separately, 
the remaining 3 I ran simultaneously)
Then the 2 LUKS commands on each drive (Format & Open)
The 3 LVM commands on each drive (pvcreate, vgcreate & lvcreate)

This morning I had commented out the mounting of the LVs in fstab. Once 
booted I did an fsck on one of the LVs in question which completed as 
fast as I hit enter, but then I have no data on this LV just an empty 
lost+found, and I've never ran fsck on an empty fs before so I'm not 
sure how fast it can be. As I said before the mkfs.ext4 time was much 
faster than what I'm used to particularly on a 931G LV.

Paul, in answer to your question, no I don't set the partition table 
before doing any of this. I haven't since I started using LUKS/LVM and 
haven't had any problems. I don't however span VGs over multiple PVs 
currently, so I don't know if not setting the table (using fdisk, gdisk, 
etc) will create problem when spanning VGs across multiple PVs.

Scott C.

On 03/12/2014 08:26 AM, Jim Kinney wrote:
>
> Try running badblocks on that drive from a live CD.
> A sector error at a partition boundary is a mess like this.
>
> On Mar 11, 2014 11:37 PM, "Scott Castaline" <skotchman at gmail.com 
> <mailto:skotchman at gmail.com>> wrote:
>
>     Okay, so now I have noticed an error message which indicates to
>     use systemctl status pub-Downloads.mount, to see more info. It's
>     complaining about the ext4 fs and the superblock is bad. I've done
>     this about 6 times and get the same results. I have always just
>     created the fs by "mkfs.ext4 </path/to/device>" which for this one
>     would be /dev/mapper/ncc1701_02-pub_dnlds. I always thought that
>     fs type was specified in the .ext4 part of mkfs. I've never used
>     any other options except on occasion I used -L for labeling the fs
>     for whatever reasons. I did notice that it seemed to do the fs
>     rather quick, other than that I didn't notice any problems with
>     the initialization process.
>
>     Below is excerpt of system log:
>
>     Mar 11 22:53:51 ncc1701 mount: mount: wrong fs type, bad option,
>     bad superblock on /dev/mapper/ncc1701_02-pub_dnlds,
>     Mar 11 22:53:51 ncc1701 mount: missing codepage or helper program,
>     or other error
>     Mar 11 22:53:51 ncc1701 mount: In some cases useful info is found
>     in syslog - try
>     Mar 11 22:53:51 ncc1701 mount: dmesg | tail or so.
>
>     Mar 11 22:53:51 ncc1701 systemd: pub-Downloads.mount mount process
>     exited, code=exited status=32
>     Mar 11 22:53:51 ncc1701 systemd: Failed to mount /pub/Downloads.
>     Mar 11 22:53:51 ncc1701 systemd: Dependency failed for Local File
>     Systems.
>     Mar 11 22:53:51 ncc1701 systemd: Dependency failed for Mark the
>     need to relabel after reboot.
>
>     the gap between the mount and the systemd entries had stuff not
>     related to the problem.
>
>     Aside from scrapping the system and doing a full re-install
>     anything else that I should try? Are their new options that I
>     should be using that I'm not seeing in the man pages? I don't want
>     to re-install as what will I do when I replace the drive that lead
>     to this mess, re-install again?
>
>     Scott C.
>
>     On 03/11/2014 11:00 PM, Jim Kinney wrote:
>>
>>     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
>>     <mailto: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
>>         <mailto:jim.kinney at gmail.com>>
>>         To: "Atlanta Linux Enthusiasts" <ale at ale.org
>>         <mailto: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 <mailto: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
>>             <mailto:jim.kinney at gmail.com>>
>>             To: "Atlanta Linux Enthusiasts" <ale at ale.org
>>             <mailto: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 <mailto: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 <mailto: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/
>>             ////
>>
>>             _______________________________________________
>>             Ale mailing list
>>             Ale at ale.org <mailto: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/
>>         ////
>>
>>         _______________________________________________
>>         Ale mailing list
>>         Ale at ale.org <mailto:Ale at ale.org>
>>         http://mail.ale.org/mailman/listinfo/ale
>>         See JOBS, ANNOUNCE and SCHOOLS lists at
>>         http://mail.ale.org/mailman/listinfo
>>
>>
>>
>>     _______________________________________________
>>     Ale mailing list
>>     Ale at ale.org  <mailto:Ale at ale.org>
>>     http://mail.ale.org/mailman/listinfo/ale
>>     See JOBS, ANNOUNCE and SCHOOLS lists at
>>     http://mail.ale.org/mailman/listinfo
>
>
>     _______________________________________________
>     Ale mailing list
>     Ale at ale.org <mailto:Ale at ale.org>
>     http://mail.ale.org/mailman/listinfo/ale
>     See JOBS, ANNOUNCE and SCHOOLS lists at
>     http://mail.ale.org/mailman/listinfo
>
>
>
> _______________________________________________
> 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/20140312/08b33d28/attachment-0001.html>


More information about the Ale mailing list