<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
I had originally ran on all five drives:<br>
<br>
smartctl test both short & long (with the expected one failure
and the other four passed)<br>
badblocks (again had the one drive expected failure the other four
were fine)<br>
dd if=/dev/urandom of=/dev/sda-d (I did the boot drive first
separately, the remaining 3 I ran simultaneously)<br>
Then the 2 LUKS commands on each drive (Format & Open)<br>
The 3 LVM commands on each drive (pvcreate, vgcreate &
lvcreate)<br>
<br>
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.<br>
<br>
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.<br>
<br>
Scott C.<br>
<br>
On 03/12/2014 08:26 AM, Jim Kinney wrote:<br>
</div>
<blockquote
cite="mid:CAEo=5PyhcitW8EJNLQ-57G7Eq-911Z4Nk0px1vawBm5z4pAUgw@mail.gmail.com"
type="cite">
<p dir="ltr">Try running badblocks on that drive from a live CD.<br>
A sector error at a partition boundary is a mess like this.<br>
</p>
<div class="gmail_quote">On Mar 11, 2014 11:37 PM, "Scott
Castaline" <<a moz-do-not-send="true"
href="mailto:skotchman@gmail.com">skotchman@gmail.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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.<br>
<br>
Below is excerpt of system log:<br>
<br>
Mar 11 22:53:51 ncc1701 mount: mount: wrong fs type, bad
option, bad superblock on
/dev/mapper/ncc1701_02-pub_dnlds,<br>
Mar 11 22:53:51 ncc1701 mount: missing codepage or helper
program, or other error<br>
Mar 11 22:53:51 ncc1701 mount: In some cases useful info
is found in syslog - try<br>
Mar 11 22:53:51 ncc1701 mount: dmesg | tail or so.<br>
<br>
Mar 11 22:53:51 ncc1701 systemd: pub-Downloads.mount mount
process exited, code=exited status=32<br>
Mar 11 22:53:51 ncc1701 systemd: Failed to mount
/pub/Downloads.<br>
Mar 11 22:53:51 ncc1701 systemd: Dependency failed for
Local File Systems.<br>
Mar 11 22:53:51 ncc1701 systemd: Dependency failed for
Mark the need to relabel after reboot.<br>
<br>
the gap between the mount and the systemd entries had
stuff not related to the problem.<br>
<br>
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?<br>
<br>
Scott C.<br>
<br>
On 03/11/2014 11:00 PM, Jim Kinney wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">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</p>
<p dir="ltr">The /dev/mapper/ luks-* links to ../dm0. The
lvms links to dm1,dm2, etc.</p>
<p dir="ltr">It would not make sense to force lvm to
understand encryption so it must be the lvm container.
Um. Duh.</p>
<div class="gmail_quote">On Mar 11, 2014 5:49 PM, "Derek
Atkins" <<a moz-do-not-send="true"
href="mailto:derek@ihtfp.com" target="_blank">derek@ihtfp.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <span
style="font-family:Arial">Sorry, your thinking is
faulty. <br>
<br>
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.<br>
<br>
-derek<br>
<br>
Sent from my HTC smartphone<br>
<br>
<br>
<div>----- Reply message -----<br>
From: "Jim Kinney" <<a moz-do-not-send="true"
href="mailto:jim.kinney@gmail.com"
target="_blank">jim.kinney@gmail.com</a>><br>
To: "Atlanta Linux Enthusiasts" <<a
moz-do-not-send="true" href="mailto:ale@ale.org"
target="_blank">ale@ale.org</a>><br>
Subject: [ale] changes to fstab in fedora 20<br>
Date: Tue, Mar 11, 2014 5:37 PM<br>
<br>
</div>
</span><br>
<div dir="ltr">
<div>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.<br>
<br>
</div>
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.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Mar 11, 2014 at
5:19 PM, Derek Atkins <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:derek@ihtfp.com" target="_blank">derek@ihtfp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"> <span
style="font-family:Arial">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.<br>
<br>
-derek<br>
<br>
Sent from my HTC smartphone
<div>
<div><br>
<br>
<br>
<div>----- Reply message -----<br>
From: "Jim Kinney" <<a
moz-do-not-send="true"
href="mailto:jim.kinney@gmail.com"
target="_blank">jim.kinney@gmail.com</a>><br>
To: "Atlanta Linux Enthusiasts" <<a
moz-do-not-send="true"
href="mailto:ale@ale.org"
target="_blank">ale@ale.org</a>><br>
Subject: [ale] changes to fstab in
fedora 20<br>
Date: Tue, Mar 11, 2014 5:03 PM<br>
<br>
</div>
</div>
</div>
</span>
<div>
<div><br>
<div dir="ltr">
<div>
<div>
<div>
<div>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.<br>
<br>
</div>
I think you need to go the following
order:<br>
<br>
</div>
pvcreate<br>
</div>
<div>lvcreate<br>
</div>
cryptsetup<br>
</div>
mkfs<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Mar 11,
2014 at 4:36 PM, Scott Castaline <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:skotchman@gmail.com"
target="_blank">skotchman@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">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.<br>
<br>
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:<br>
<br>
1. cryptsetup luksFormat /dev/sd?
(exact syntax maybe wrong as I'm doing
this by memory which admittedly has
gone downhill lately).<br>
<br>
2. blkid /dev/sd? (to get the luks
UUID of the drive for the next 2
steps)<br>
<br>
3. cryptsetup luksOpen /dev/sd?
luks-<Block UUID ><br>
<br>
4. pvcreate /dev/mapper/luks-<Block
UUID ><br>
<br>
5. vgcreate <name used for vg>
/dev/mapper/luks-<Block UUID ><br>
<br>
6. lvcreate -L <size of lv> -n
<name of lv> <name of vg><br>
<br>
7. mkfs.ext4
/dev/mapper/vg-name/lv-name<br>
<br>
8. I'll go ahead and mount it where I
plan to mount it in fstab and verify
that all is well.<br>
<br>
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.<br>
<br>
10. Unmount lvs, close luks volume and
reboot.<br>
<br>
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.<br>
<br>
Hellllppp Meeeeeeeeeeee (in my best
human-fly imitation from the spider
web).<br>
<br>
Scott C.<br>
_______________________________________________<br>
Ale mailing list<br>
<a moz-do-not-send="true"
href="mailto:Ale@ale.org"
target="_blank">Ale@ale.org</a><br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo/ale"
target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists
at<br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo"
target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div dir="ltr">-- <br>
James P. Kinney III<br>
<i><i><i><i><br>
</i></i></i></i>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.<br>
- Speech 11/23/1900 Mark Twain<br>
<i><i><i><i><br>
<a moz-do-not-send="true"
href="http://heretothereideas.blogspot.com/"
target="_blank">http://heretothereideas.blogspot.com/</a><br>
</i></i></i></i></div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a moz-do-not-send="true"
href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo/ale"
target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo"
target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div dir="ltr">-- <br>
James P. Kinney III<br>
<i><i><i><i><br>
</i></i></i></i>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.<br>
- Speech 11/23/1900 Mark Twain<br>
<i><i><i><i><br>
<a moz-do-not-send="true"
href="http://heretothereideas.blogspot.com/"
target="_blank">http://heretothereideas.blogspot.com/</a><br>
</i></i></i></i></div>
</div>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a moz-do-not-send="true" href="mailto:Ale@ale.org"
target="_blank">Ale@ale.org</a><br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo/ale"
target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo"
target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Ale mailing list
<a moz-do-not-send="true" href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a>
<a moz-do-not-send="true" href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a moz-do-not-send="true" href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a moz-do-not-send="true" href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo/ale"
target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a moz-do-not-send="true"
href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Ale mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ale@ale.org">Ale@ale.org</a>
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</pre>
</blockquote>
<br>
</body>
</html>