From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRidL-0005NV-Fd for guix-patches@gnu.org; Sun, 02 Jul 2017 13:26:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRidG-0006qY-4q for guix-patches@gnu.org; Sun, 02 Jul 2017 13:26:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:46286) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dRidF-0006qF-Q2 for guix-patches@gnu.org; Sun, 02 Jul 2017 13:26:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dRidF-0008LI-KM for guix-patches@gnu.org; Sun, 02 Jul 2017 13:26:01 -0400 Subject: [bug#27520] Booting by UUID - UUID types and bootloader Resent-Message-ID: Date: Sun, 2 Jul 2017 19:25:36 +0200 From: Danny Milosavljevic Message-ID: <20170702192536.536672d3@scratchpost.org> In-Reply-To: <20170702120557.07355db9@scratchpost.org> References: <20170628213841.28774-1-dannym@scratchpost.org> <20170628220117.GA15943@jasmine.lan> <20170629001701.26b5f427@scratchpost.org> <20170628224709.GA30324@jasmine.lan> <20170629015414.521e7f0c@scratchpost.org> <878tkalqdg.fsf@gnu.org> <20170702120557.07355db9@scratchpost.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27520@debbugs.gnu.org Hi Ludo, > That said, the right fix would be to use the UUID instead of the label for finding the root filesystem. Using the label isn't really safe anyway - whereas a random UUID should be preeeeeeetty safe. > > I'm testing passing the UUID now. Let's see... Doesn't work. The main reason is that the root-device stored into "/gnu/store/*system*/parameters" for UUIDs is (sometimes) a bytevector. That means that if it is then later on we won't know what kind of uuid it is - and gnu/system.scm operating-system-bootcfg will just use uuid->string (in order to add it to argv) and it will break. Also, gnu/bootloader/grub.scm grub-root-search assumes the UUID is a non-iso9660 UUID and thus grub will be very confused. Also, it doesn't (and shouldn't need to) know the root filesystem type either - that means that it can't select the right kind of UUID. We get a warning about it on bootup (after a long time) but it still tries to boot to the kernel successfully. read-boot-parameters-file also converts bytevector UUIDs (read from disk, file "parameters") to string UUIDs (using uuid->string, so no support for ISO9660 or FAT) and uses those in order to build up the kernel argument list "--root=" and so on. It doesn't (and shouldn't need to) know the filesystem type. (There are more places where I added a special-case for iso9660 UUIDs - I can dig them up from my git repo clone) I would like to ask again that we just store UUIDs as strings and stop this. If we want to verify UUIDs, we can verify them as strings. We can even distinguish UUID types then. We could just have string->*-uuid do the verification but then return the string after all. uuid->string could be a no-op. And the uuid readers could return the readable representation in the first place. Or, alternatively, we could add a uuid type field as the first byte of the bytevector (making them longer by 1 Byte). That way, we would intrinsically know which kind of UUID it is. That would still mean that the user would have to specify which it is by calling string->...-uuid - and that we'd have to adapt the on-disk "parameters" format - but I think it would work fine and not suck. uuid->string would then just do the right thing depending on the first Byte. The latter alternative would mean that the user has to know what kind of uuid it is - and what kind of filesystem it is. Not so with the former alternative.