From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BE680138334 for ; Fri, 16 Nov 2018 13:16:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7938FE0A10; Fri, 16 Nov 2018 13:16:28 +0000 (UTC) Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 00BF5E092F for ; Fri, 16 Nov 2018 13:16:27 +0000 (UTC) Received: by mail-pl1-f195.google.com with SMTP id f12-v6so11189032plo.1 for ; Fri, 16 Nov 2018 05:16:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=J/080q5SJkZko6CxUgFOhGBJnpy9X0T/mq0devcH7ok=; b=U9knj80Z5OVlVSdGN6WNq5cSCOTUcaWDtTAdv+Ba87H9pzY6hR5Q5ABoeD8Lg12U2h hvwirrxvjyY0EAaSs9/w2t6bCf4gHaek6bDAAjsVMprHOAJgs+XMgQZTYE8ttQVDIK99 QSzITc9bw02w2hSErdaZZAyK6EM/5YVhnEEqm2mfau0M4FhHBKWMG7NAZFk4qdIPqrt3 vE7c+0ClQyi3lU7KXDtZPTYLkkw8Q7ZEvlZUdcSrkmIhh/MfKwldlPA7h2xXLYoJSzRs 1t7l7xSrX2Q9casyoputwET9Lowx3agITp5F77/ECl53Q0axZhLqT/8PpANF0rnBgxm+ UhgQ== X-Gm-Message-State: AGRZ1gLHEltfHqnTrIwVEP3UArGi9bDf/hIfIDp1so65KP1AcLDarE/b 1zGsin5PnT8H3UW2WUJizCOgq31Eajk3o8bEVNGtNQ== X-Google-Smtp-Source: AJdET5en1jMeiCFYP+UE1LSDZ1rjQUpQIKw4j+zcx2mBbChgOjPrplKQyARN8dA8vJV320CG5XWUnWwkvnkgFQRTGTw= X-Received: by 2002:a17:902:4481:: with SMTP id l1-v6mr10575976pld.123.1542374186333; Fri, 16 Nov 2018 05:16:26 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 References: In-Reply-To: From: Rich Freeman Date: Fri, 16 Nov 2018 08:16:15 -0500 Message-ID: Subject: Re: [gentoo-user] systemd/dracut: Correctly boot using flash drive with LUKS key? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 8337e613-1787-4081-9a8c-91347caa1957 X-Archives-Hash: b4819435ab2c95f6a11603cf6d5a2b60 On Fri, Nov 16, 2018 at 12:11 AM Andrew Udvare wrote: > > - use key to decrypt root partition (systemd job in the first systemd > launched within initramfs) > ... > Nov 16 00:01:52 limelight systemd[1]: Dependency failed for /mnt/chuan. > Nov 16 00:01:52 limelight systemd[1]: mnt-chuan.mount: Job > mnt-chuan.mount/start failed with result 'dependency'. So, I haven't messed around that much with systemd and removable media, but a few things I'd start by looking at: systemctl show mnt-chuan.mount systemctl list-dependencies --reverse --all mnt-chuan.mount I'd have to read up the manpages on how automounting works and what the appropriate flags are in fstab to trigger that. Obviously that is someplace else to check. Clearly you have things set up so that the usb drive is mounted before your script goes and reads the key off of it. If you're doing that in a service and have a dependency on the usb drive (or system somehow figured out that there should be a dependency on it), and that service is left in a running state after the decryption is done, that could be causing issues as systemd thinks that drive is still needed and is desperately trying to get it back. With systemd mountpoints are units, and can be started/stopped like any service and can be dependencies of services. This is usually a good thing, but services tend to be persistent and removable drives tend not to be, so you probably need to use some care when mixing the two. Note that due to generators system will create mount units automatically from fstab and other sources. Usually traditional commands like mount/umount and so on just do the right thing, but if you've inadvertently enabled some kind of automounting logic or systemd believes there is a dependency with another unit then you might be fighting the system. Here is another route you could take. When you want to remove that usb drive, instead of just pulling it out or manually unmounting it, try running: systemctl stop mnt-chuan.mount That is asking systemd to nicely unmount it. If systemd doesn't want to unmount it then it will nicely tell you take a hike, but perhaps the error output will give you some clues as to why. -- Rich