From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id sCvgFt52jl9ZdwAA0tVLHw (envelope-from ) for ; Tue, 20 Oct 2020 05:34:22 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id YHKiEt52jl9PQQAAB5/wlQ (envelope-from ) for ; Tue, 20 Oct 2020 05:34:22 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 86B7F9402A0 for ; Tue, 20 Oct 2020 05:34:21 +0000 (UTC) Received: from localhost ([::1]:52088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUkHr-0001Bj-Fk for larch@yhetil.org; Tue, 20 Oct 2020 01:34:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37556) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUkHb-0001Au-7K for bug-guix@gnu.org; Tue, 20 Oct 2020 01:34:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:59817) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kUkHa-0005Bb-Gr for bug-guix@gnu.org; Tue, 20 Oct 2020 01:34:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kUkHa-00013d-Ct for bug-guix@gnu.org; Tue, 20 Oct 2020 01:34:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#44027: [PATCH] installer: Create bios_grub partition when it is needed. Resent-From: Bengt Richter Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 20 Oct 2020 05:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44027 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Brendan Tildesley Received: via spool by 44027-submit@debbugs.gnu.org id=B44027.16031720174032 (code B ref 44027); Tue, 20 Oct 2020 05:34:02 +0000 Received: (at 44027) by debbugs.gnu.org; 20 Oct 2020 05:33:37 +0000 Received: from localhost ([127.0.0.1]:43130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUkHB-00012x-El for submit@debbugs.gnu.org; Tue, 20 Oct 2020 01:33:37 -0400 Received: from imta-38.everyone.net ([216.200.145.38]:53990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUkH9-00012p-GS for 44027@debbugs.gnu.org; Tue, 20 Oct 2020 01:33:36 -0400 Received: from pps.filterd (omta003.sj2.proofpoint.com [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 09K5RO3Z000408; Mon, 19 Oct 2020 22:33:24 -0700 X-Eon-Originating-Account: NH4qd7BbqBsUhQZUsk95ZhiRD8TbowL7KidtJW4Qe7I X-Eon-Dm: m0116953.ppops.net Received: by m0116953.mta.everyone.net (EON-AUTHRELAY2 - 5a81d795) id m0116953.5f8a0276.3aa63; Mon, 19 Oct 2020 22:33:23 -0700 X-Eon-Sig: AQMHrIJfjnajsrG4MgIAAAAE,9bbb9fbe0f80653671d14bb34407afe0 X-Eip: ntbvHxrw-_yGV_V_miQgY9uAzxEnM__Ojq_bYNJ81p8 Date: Tue, 20 Oct 2020 07:33:13 +0200 From: Bengt Richter Message-ID: <20201020053313.GA2516@LionPure> References: <76f35a63-62e8-4653-865b-b14bb273db34@brendan.scot> <87lfg65jho.fsf@gnu.org> <878sc5wzld.fsf@debian> <87pn5hq9rs.fsf_-_@gmail.com> <87mu0jpm5b.fsf@gmail.com> <87imb7zctc.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-20_03:2020-10-16, 2020-10-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 priorityscore=1501 malwarescore=0 spamscore=0 suspectscore=0 clxscore=1034 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010200037 X-Spam-Score: -0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.4 (-) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bengt Richter Cc: Mathieu Othacehe , Miguel =?UTF-8?Q?=C3=81ngel?= Arruga Vivas , 44027@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Spam-Score: -0.51 X-TUID: gGmvaDZe9UOX Hi, On +2020-10-19 16:57:49 +1100, Brendan Tildesley wrote: > On 19/10/20 3:03 am, Mathieu Othacehe wrote: > > Hello Miguel & Brendan, > > > > > AFAIU from the code, the first partition should not be created by the > > > installer but it won't be removed if it was found on the disk > > > beforehand. Tomorrow I'll give a try at the full installation process, > > > I must have overlooked something if it still being created in that > > > case... > > Thanks for your help on this topic! Brendan is probably using a GPT > > partitionned disk on a non-UEFI compatible machine. Hence, as you > > noticed, the installer does not create a bios_grub partition. > > > > This is a problem as this partition is necessary for GRUB and I think > > that your patch is fixing the problem. The "auto-partition!" procedure > > is also leaving a probably pre-existing ESP partition, but I don't > > really understand how it appeared in the first place. > > > > Brendan, did you use "manual partitioning" to create an ESP partition? > Hmm I forget what was on this drive. I used to have Windows 10 on it, then I > can't > remember. I may have installed Arch Linux on it. What ever was on it, I just > ran the > installer letting it do it's thing selecting Encrypted root with LVM because > I wanted to > see if that worked. it didn't, then I tried the default, before posting the > bug report. > Finally I went though with Miguel's patch selecting all the defaults and > that was > the result. > I feel the installer should not care what was on the drive to begin with, it > should just > format the drive how it sees fit. Why should the existing contents of the > drive > affect the outcome when we are reformatting everything anyway? > > > > Thanks, > > > > Mathieu > I agree that existing contents should not matter, UNLESS: You are about to shoot yourself in the foot by overwriting the wrong disk. I think it is risky to target disks just by /dev/, so if doing that, with e.g. /dev/sdb, I would like a safe confirmation dialog displaying the output of $ lsblk -o mountpoint,type,kname,model,serial /dev/sdb MOUNTPOINT TYPE KNAME MODEL SERIAL disk sdb SanDisk_3.2Gen1 xxxxxx... with automatic verification that it is not mounted, is type disk, and asking me if the model and serial number look right. The nice thing about the serial number is (AFAIK) that it persists for selection even after zapping GPT/MBR UUIDs. Similar checks before overwriting any pre-existing disk or partition, please. Maybe also have a target-disk-serial parameter that can be part of my-system.scm to lock in the right target disk? Similary for partitions for /boot and / and any others. (Hm, BTW, how are stable disk type, model and serial number lsblk outputs above provided for virtual disks? ) [later] Hm, I decided to test the serial number persistence, and the brand new Sandisk_3.2Gen1 made lsblk show a whopping 120-character string for that xxxxxx... serial, but after zapping it fully with gdisk, the output was the first 39 characters, Presumably gdisk enforced a 40-byte buffer size with a null in the last byte. BUT: Waitaminit -- how could it do that if that buffer was manufactured read-only?? I'll try dd-ing zeroes over the front end, and seeing if there's a serial after that... So it that a bug in lsblk, or in SanDisk manufacturing? Well, the confirmation dialog would work either way, but the target-disk-serial parameter would have to do a prefix-match or something, until all parties get their acts together ;-) [later] zapped the first 1GiB of /dev/sdb with dd, and lsblk returned 39 chars like after gdisk zap, BUT: now it's back to the same long number, which also shows up at /dev/disk/by-id/* Meanwhile, did: apt install sdparm (mentioned at [1]), and then sdparm got me the first 20 characters of lsblk's version: --8<---------------cut here---------------start------------->8--- sudo sdparm --page=sn /dev/sdb [sudo] password for bokr: /dev/sdb: USB SanDisk 3.2Gen1 1.00 Unit serial number VPD page: xxxxxxxxxxxxxxxxxxxx --8<---------------cut here---------------end--------------->8--- and lsblk and /dev/disk/by-id both show the original long serial, which suggests they share some code, since they agree and both disagree with the 20-char version from sdparm. Per [1], the serial number isn't stored in the data writeable part, it's in the scsi controller innards, retrieved by saying the right thing to the controller, unlike other ways of serializing storage. But is sdparm right? 20 characters seems stingy. ┌──────────────────────────────────┐ │ ISTM there's a bug somewhere ;-) │ └──────────────────────────────────┘ I'm mCurrently running (per uname -a): Linux LionPure 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux ...without guix though, sorry, I like guix :/ (though there's lots of scraps around, until I can install one with absolute minimal use of sudo :) [1] https://stackoverflow.com/questions/2432759/usb-drive-serial-number-under-linux-c HTH make things better (at least with the confirmation dialog part :) And maybe a clue to a bug. -- Regards, Bengt Richter