From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Ochi <ochi@arcor.de>, lists@colorremedies.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Creating btrfs RAID on LUKS devs makes devices disappear
Date: Fri, 12 May 2017 07:25:16 -0400 [thread overview]
Message-ID: <ba7f8443-6031-6658-d63b-e09dd3f2259e@gmail.com> (raw)
In-Reply-To: <4b7809e0-7329-62b0-c488-51bd4f0318a6@arcor.de>
On 2017-05-11 19:24, Ochi wrote:
> Hello,
>
> here is the journal.log (I hope). It's quite interesting. I rebooted the
> machine, performed a mkfs.btrfs on dm-{2,3,4} and dm-3 was missing
> afterwards (around timestamp 66.*). However, I then logged into the
> machine from another terminal (around timestamp 118.*) which triggered
> something to make the device appear again :O Indeed, dm-3 was once again
> there after logging in. Does systemd mix something up?
>
> Hmm, I just did another mkfs once the devices where back, devices were
> missing, but they re-appeared a few seconds later, without logging into
> a terminal. After another mkfs, they were gone again and are now still
> gone after waiting a few minutes. It's really weird, I can't really tell
> what triggers this yet. Will test more tomorrow, let me know if you have
> any more ideas what to try.
It looks like something made systemd think that it should tear down the
LUKS volumes, but it somehow only got /dev/dm-3 and not the others, and
then you logging in and triggering the creation of the associated user
slice somehow made it regain it's senses. Next time you see it
disappear, try checking `systemctl status` for the unit you have set up
for the LUKS volume and see what that says. I doubt it will give much
more info, but I suspect it will say it's stopped, which will solidify
that systemd is either misconfigured or doing something stupid (and
based on past experience, I'm willing to bet it's the latter).
next prev parent reply other threads:[~2017-05-12 11:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 20:17 Creating btrfs RAID on LUKS devs makes devices disappear Ochi
2017-05-11 20:36 ` Ochi
2017-05-11 22:24 ` Chris Murphy
2017-05-11 23:24 ` Ochi
2017-05-12 11:25 ` Austin S. Hemmelgarn [this message]
2017-05-12 13:54 ` Ochi
2017-05-12 14:11 ` Austin S. Hemmelgarn
2017-05-12 17:07 ` Chris Murphy
2017-05-13 7:29 ` Andrei Borzenkov
2017-05-13 15:28 ` Ochi
2017-05-13 18:51 ` Andrei Borzenkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba7f8443-6031-6658-d63b-e09dd3f2259e@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=ochi@arcor.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox