[ale] changes to fstab in fedora 20
Jim Kinney
jim.kinney at gmail.com
Wed Mar 12 08:26:31 EDT 2014
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> 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> 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
>>
>>
>
> _______________________________________________
> Ale mailing listAle at ale.orghttp://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists athttp://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/7262d98f/attachment-0001.html>
More information about the Ale
mailing list