From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Wed, 10 Feb 2016 16:39:05 +0100 (CET) Received: by mail-wm0-x231.google.com with SMTP id p63so34354182wmp.1 for ; Wed, 10 Feb 2016 07:39:05 -0800 (PST) Received: from [147.251.42.24] (hector.fi.muni.cz. [147.251.42.24]) by smtp.gmail.com with ESMTPSA id ka7sm3481058wjb.8.2016.02.10.07.39.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Feb 2016 07:39:04 -0800 (PST) References: <56B20C05.7080307@gmail.com> <56B90DDD.1080107@gmail.com> <56BA6353.7080207@tu-ilmenau.de> <20160209233532.GB21086@tansi.org> <56BAF6B5.4060300@gmail.com> <56BB3FC0.5020409@whgl.uni-frankfurt.de> <56BB5294.8040407@whgl.uni-frankfurt.de> From: Milan Broz Message-ID: <56BB5997.6020009@gmail.com> Date: Wed, 10 Feb 2016 16:39:03 +0100 MIME-Version: 1.0 In-Reply-To: <56BB5294.8040407@whgl.uni-frankfurt.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] The future of disk encryption with LUKS2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 02/10/2016 04:09 PM, Sven Eschenberg wrote: > Actually PARTUUID should have read PARTTYPE-GUID - So there's no reason > why moving it to a different partition should not work, updating the > PARTTYPE is a trivial step and part of a proper moving operation anyway. PARTTYPE GUID does not work properly for determining device type and never will. Hint: check what systemd does with it. There is a "home" GUID. What it says about device type? https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html And that's just one example because the reality is not what you would like to see... For checking device type we have to use blkid (IOW the real device scan). I know it is not nice academic design but it is reality and, surprise, it works. > Just imagine the network's linklayer had no idea which upper layer to > call, because there's no information on that. TCP/IP again does not have > that type of information. > > So either the layering order is fixed and determined, or you actually > will need intra-layer relationships for proper operation. As an > alternative, leave it to the user's knowledge and handling. But then we > don't need partition tables, LUKS-headers or anything else either, > afterall you can tell each layer the geometry and parameters manually > and use dmsetup for all your tasks. It is not just black and white. (Could we avoid these logical fallacies here please?) Milan