From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 26 09:15:47 2023 Received: (at submit) by debbugs.gnu.org; 26 Jan 2023 14:15:47 +0000 Received: from localhost ([127.0.0.1]:32827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pL32Y-00042m-LK for submit@debbugs.gnu.org; Thu, 26 Jan 2023 09:15:47 -0500 Received: from lists.gnu.org ([209.51.188.17]:50110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKzse-0004gb-Hf for submit@debbugs.gnu.org; Thu, 26 Jan 2023 05:53:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKzsY-0000RR-3a for bug-parted@gnu.org; Thu, 26 Jan 2023 05:53:14 -0500 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pKzsP-0007ae-3a for bug-parted@gnu.org; Thu, 26 Jan 2023 05:53:06 -0500 Received: by mail-lf1-x135.google.com with SMTP id cf42so2472730lfb.1 for ; Thu, 26 Jan 2023 02:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=AdODtarc0ZH/8GZlVdRVCeDEvSEGfVQjn28cpQfKh5Y=; b=EwEW6jsSDkpxF31S+Ze5vK8t4WYcv7bTfzeHH1yUzB91GhO3NIW1BmtkZqxWYt4tkf RvTC1WVWGbHtFzeQAKZ+48MvWszyyQ3aA3iY6EhqAuWytTDbQO75l53rHfORlWCT0BK3 A4zsf/xPxFcinAtSwhFrv4dfE5n4N6Jde+VJW1pX53pPNY9JyinJvPkLkOZpR0lxrjyG msgKXaoAhwTNHAwrUoitjKPgwqeuxD4U+naj8GVVgVT9oNdp+m3J4gmlbyIzm0UsbiLG 1Q9ZkRFzKT/62idHM5/1cygDGiOFQMWL1p8Dq0hH29bLtEpzJG059PpM9DswKCgCYT32 zULw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AdODtarc0ZH/8GZlVdRVCeDEvSEGfVQjn28cpQfKh5Y=; b=PpvcQgBIMRs5TLAgy2DzD6o+VzN7YXGi5H9nHgu5VxTwcYOvThr08OCcNaXgQtRNZQ uAoofGYTVWm41wZhQ6ZOr9ldSVWQYp1QqOTjsC+FnxcpPzk4xs+zEfZCnAywQM6W7MGF AWi2RGbgaOGncw06hIiQqMnfNRZ+OErq2MwblENSwoLzm6hkLAky1acLmD94w/g6Lnpu 6n8zDd6o6E9SQvh+r/UyOSZoCUcu/lcO7dDe2OyDu82YBqPwA8ZLEIbFSSTjIgPLoPS0 hbcJG6R+tyihfbjHlvxqZIpEpjQhELrOhMGPqGD0GgUv6jv0bU5YWACkzOTRep36VRmA KCrw== X-Gm-Message-State: AFqh2kpJ5sow1D1KHWVIjms1d5UQjG0yZm+T0tV/LlpmMJqkH7LMaTP7 8deSOpwPVa1eWMDaVVt3CalJO04e8LQkN3wTHH74CLAWe6Q= X-Google-Smtp-Source: AMrXdXtKC7qzZXCwHkPAJ+/tQ86Nu7At+9rfW9jHNZEBH1Zmc2DKh2abaq60abpQlC6hjKO1oWAUwzm5eVFvb846cL0= X-Received: by 2002:a05:6512:159:b0:4b5:2958:bd06 with SMTP id m25-20020a056512015900b004b52958bd06mr2237511lfo.26.1674730367519; Thu, 26 Jan 2023 02:52:47 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?RnLDqWTDqXJpYyBNYXJ0aW5zb25z?= Date: Thu, 26 Jan 2023 11:52:36 +0100 Message-ID: Subject: Change in MBR between parted 3.2 and 3.3 To: bug-parted@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::135; envelope-from=frederic.martinsons@gmail.com; helo=mail-lf1-x135.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 26 Jan 2023 09:15:45 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hello, I have an arm based board with an eMMC card for storage. I cross compil an GNU/Linux OS (with yocto) for this boardand and I came across an issue after updating parted to 3.3 and above. Below are my commands to partition the 4GB storage (2 partitions of 1.8GB, 1 bootable partition of 400MB) : :~# parted /dev/mmcblk0 mklabel msdos :~# parted -a none /dev/mmcblk0 unit s mkpart primary ext4 2048 3474431 :~# parted -a none /dev/mmcblk0 unit s mkpart primary ext4 3474432 6946815 :~# parted -a none /dev/mmcblk0 unit s mkpart primary ext4 6946816 7733247 :~# parted /dev/mmcblk0 set 3 boot on With parted 3.2, I have the following MBR: :~# hexdump -n 1024 -C /dev/mmcblk0 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |................| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..| 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 34 15 3b 6e 00 00 00 20 |........4.;n... | 000001c0 21 00 83 45 2d d8 00 08 00 00 00 fc 34 00 00 45 |!..E-.......4..E| 000001d0 2e d8 83 6a 7a b0 00 04 35 00 00 fc 34 00 80 6a |...jz...5...4..j| 000001e0 7b b0 83 5e 7d e1 00 00 6a 00 00 00 0c 00 00 00 |{..^}...j.......| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 With parted 3.3, I have that: :~# hexdump -n 1024 -C /dev/mmcblk0 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |................| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..| 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 85 1a 7c 02 00 00 00 04 |..........|.....| 000001c0 01 04 83 fe c2 ff 00 08 00 00 00 fc 34 00 00 fe |............4...| 000001d0 c2 ff 83 fe c2 ff 00 04 35 00 00 fc 34 00 80 fe |........5...4...| 000001e0 c2 ff 83 fe c2 ff 00 00 6a 00 00 00 0c 00 00 00 |........j.......| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 The first and last CHS address of the partition entries are completely different and for the entry 2 and 3, first address is equal to the last ! Below is more information by parted 3.2: :~# parted /dev/mmcblk0 print unit s print unit chs print Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 3959MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1779MB 1778MB primary 2 1779MB 3557MB 1778MB primary 3 3557MB 3959MB 403MB primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 7733248s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 2048s 3474431s 3472384s primary 2 3474432s 6946815s 3472384s primary 3 6946816s 7733247s 786432s primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 481,94,60 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 481,255,63. Each cylinder is 8225kB. Partition Table: msdos Disk Flags: Number Start End Type File system Flags 1 0,32,32 216,69,44 primary 2 216,69,45 432,106,57 primary 3 432,106,58 481,94,60 primary ext4 boot And the same with parted 3.3: :~# parted /dev/mmcblk0 print unit s print unit chs print Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 3959MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1779MB 1778MB primary 2 1779MB 3557MB 1778MB primary 3 3557MB 3959MB 403MB primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 7733248s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 2048s 3474431s 3472384s primary 2 3474432s 6946815s 3472384s primary 3 6946816s 7733247s 786432s primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 15163,58,1 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 15163,255,2. Each cylinder is 261kB. Partition Table: msdos Disk Flags: Number Start End Type File system Flags 1 4,4,0 6812,155,1 primary 2 6812,156,0 13621,52,1 primary 3 13621,53,0 15163,58,1 primary ext4 boot The main difference I spotted is the BIOS geometry: - parted 3.2: 481 cylinder, 255 head, 63 sector (cylinder size 8225 kB) - parted 3.3: 15163 cylinder, 255 head, 2 sector (cylinder size 261 kB) I also tested parted 3.4 and parted 3.5 with the same result. Nevertheless, the partition table created by parted 3.3 and above is perfectly usable from what I see. Long story short, do you know the origin of this discrepancy (I didn't see nothing in release not that could explain that though I obviously don't understan all the mechanics) and if it is possible to come back to the same kind of MBR generated by parted 3.2 ? One additional question arises for my understanding though, how come a partition with CHS address of the first sector equal to the last one is usable ? Thanks in advance for all insights/advices you can bring to my issue. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 26 11:28:27 2023 Received: (at 61076-close) by debbugs.gnu.org; 26 Jan 2023 16:28:27 +0000 Received: from localhost ([127.0.0.1]:35959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pL56x-00027G-Bg for submit@debbugs.gnu.org; Thu, 26 Jan 2023 11:28:27 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:58662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pL56v-000276-2S for 61076-close@debbugs.gnu.org; Thu, 26 Jan 2023 11:28:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674750504; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bqniHLng3LQLibBrIdUoG1p8zvwyRcdiVJui8POMRLM=; b=YjesUNKxdW6LnvDQFtdmJ1swJLzIX/Axd/w0i2RjNn7/3N2A1HhR3o/LjGTug6NbhLb1J0 io5qzqB63BA5XksD9romY0h3S9aX9JieqvRfNl3Sss3CI9iXG55BxgniGl8dvUV/EFgmjG 2fZSo+lci+UcjKufBOqm0Y7R+txlG3c= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-327-4vzXCeS0OKGQnjK7IFVsrw-1; Thu, 26 Jan 2023 11:28:21 -0500 X-MC-Unique: 4vzXCeS0OKGQnjK7IFVsrw-1 Received: by mail-pf1-f198.google.com with SMTP id j1-20020aa78001000000b0057d28e11cb6so1134826pfi.11 for <61076-close@debbugs.gnu.org>; Thu, 26 Jan 2023 08:28:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bqniHLng3LQLibBrIdUoG1p8zvwyRcdiVJui8POMRLM=; b=Avzia2ImdYBPv00ujdd3C3LIepcid6j21Iw3d1pU2A8q1LkxMFOi60s2VXbSxJcip4 OxfG4elRHtpoNhGmQRFNpAXZFxAJnbFTzPvKElRDLg+FGEDTmFoyEveOzDLiGktbMh8H 5Jntx+R+WQgeNiCzvoqN2ReomzPZpIGiZgNeol3vYS2CzEhHI5vRTTnXG9H/nRUoTFab +gwRolnZ8olA8pFEI7vgMQeqVKBfIRumbNyX8q+sYEpD+j/K1keKUaRIpjFHswDEop6i Yq4Ny7W2PszFGW1+FaVia+kEG2Z7anAgwETcnQke1Qe5QRexkpT9/4vzsoOG/x2lhvr6 v2yg== X-Gm-Message-State: AFqh2kpalxCyzAzxDsBrlY9Hkr9pibB6oU+YYakORREFMnypYNmi8YVK roX9S5voyQcHJIqaK84/xLdLDWHJWEfF7gKdMwIDHUv4pGysg2X4jRJqiUQM8PUfp8A9fmyQTdy oDPUbxz3Dy7/ehh8w8yGzv8U= X-Received: by 2002:a17:902:cccb:b0:192:b927:39d1 with SMTP id z11-20020a170902cccb00b00192b92739d1mr38503818ple.3.1674750500647; Thu, 26 Jan 2023 08:28:20 -0800 (PST) X-Google-Smtp-Source: AMrXdXu7KUA4h4WiylM60UF9UtvW67eBOXv6c5wXtDW5Ytu33WB5Q2j3g29FoqMx1hZln8QEkN1A0Q== X-Received: by 2002:a17:902:cccb:b0:192:b927:39d1 with SMTP id z11-20020a170902cccb00b00192b92739d1mr38503805ple.3.1674750500330; Thu, 26 Jan 2023 08:28:20 -0800 (PST) Received: from ohop.brianlane.com ([2601:603:5000:afe:52e5:49ff:fe52:c5be]) by smtp.gmail.com with ESMTPSA id m5-20020a170902db8500b00186b3c3e2dasm1188063pld.155.2023.01.26.08.28.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Jan 2023 08:28:19 -0800 (PST) Date: Thu, 26 Jan 2023 08:28:18 -0800 From: "Brian C. Lane" To: =?iso-8859-1?Q?Fr=E9d=E9ric?= Martinsons Subject: Re: bug#61076: Change in MBR between parted 3.2 and 3.3 Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61076-close Cc: 61076-close@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Jan 26, 2023 at 11:52:36AM +0100, Frédéric Martinsons wrote: > Hello, > > I have an arm based board with an eMMC card for storage. > I cross compil an GNU/Linux OS (with yocto) for this boardand and I came > across an issue after updating parted to 3.3 and above. [snip] > > The main difference I spotted is the BIOS geometry: > - parted 3.2: 481 cylinder, 255 head, 63 sector (cylinder size 8225 kB) > - parted 3.3: 15163 cylinder, 255 head, 2 sector (cylinder size 261 kB) > > I also tested parted 3.4 and parted 3.5 with the same result. > Nevertheless, the partition table created by parted 3.3 and above is > perfectly usable from what I see. > > Long story short, do you know the origin of this discrepancy (I didn't > see nothing > in release not that could explain that though I obviously don't understan all > the mechanics) and if it is possible to come back to the same kind of > MBR generated > by parted 3.2 ? This change was introduced by commit 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix problems growing partitions when using SD cards on the Raspberry Pi. > One additional question arises for my understanding though, how come a partition > with CHS address of the first sector equal to the last one is usable ? Well, nothing should be actually using the CHS values these days. So it's possible that's a bug that doesn't matter in practice, but I'll have to look into that. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 26 11:53:52 2023 Received: (at 61076) by debbugs.gnu.org; 26 Jan 2023 16:53:52 +0000 Received: from localhost ([127.0.0.1]:36040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pL5VX-0005BY-R4 for submit@debbugs.gnu.org; Thu, 26 Jan 2023 11:53:52 -0500 Received: from mail-lj1-f175.google.com ([209.85.208.175]:37740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pL5Hq-0002Qm-Nv for 61076@debbugs.gnu.org; Thu, 26 Jan 2023 11:39:43 -0500 Received: by mail-lj1-f175.google.com with SMTP id h17so2521847ljq.4 for <61076@debbugs.gnu.org>; Thu, 26 Jan 2023 08:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=b8fFkHk8+SiToxLVwcv6ZJA3duUkOvAXSdFlPxlaIbQ=; b=ICQJ99PCWDlDyb/9eox1EK10qiUSeScYvKA+lMVfLGuYfe7XtU6fU658jN3jM4O9lX MQuMjrDrdqwKaiptJvpvzPOvUyDkufVpACnh6IOdviEfRHgCPCRbb5Zr8UgMY77VnkKt bBBuR4kUzso5c+Tt8kqmv9TkPf3OYRnov3vGtqCYRTRKwKoFRVK5OvUGHf7VHUNUYIa4 jt9Zbr5tk63my3kVBGPN9ffmqCjOrWV6LkNaCmqfjIg5oTwKumzdW//8wYneCKP1PYLi EVZOE9pBu0Nw+HuaGxvFJtENnNIYYk1KlCN67JtZtqR0tzMid11wVYpJxiDuMUwdU8dy uvEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=b8fFkHk8+SiToxLVwcv6ZJA3duUkOvAXSdFlPxlaIbQ=; b=OlZLTBlpvm2TghtSO2632NEd2xBnaamZIEM3YzodttydBYaE4LdAlNMueb6mwv2yzt VD1XZn5qTiczqCy/VPf2fVYCzSj+HUA4ur22FUPABNtG4c32rWc1HVI/Fz2Htq4t/fF9 vpp5CWBJFkkXbOYAXoMzzM/ZcQRA/Fh0LwA6KIG8F5XhJyMF+E5Jk3dyQLnQa10ODT9z VGzL8kP7GXQM1JhD31sQbM9Lq8nRDg47zL7BIY2H6T//5+uK9S4sFVXp15m5BCwf4uAL I9E89aHaVqaNfNOIABCG3hqZgTyE8OeInW/3aGENONtIFaXcvaHVY5CDG+ODjHwE+CKw 7upw== X-Gm-Message-State: AFqh2kqXLOjqu/APRb+6Cw/m50X0J8JLL+LmQijrHBhQyYwM+vwAZ+J2 fbrDlqkamACtVvokoN8Bh7ncd/1llkCobhi9sSLA4AHa9Jg= X-Google-Smtp-Source: AMrXdXsDi33FOgj7FFMDEZ4nJ1he1gaHQfoHT0c3vHE3nw6fPf3Xd/Cfz1mtc3+P0m9WOXVHkLWdRA0uDwjx59VxmY8= X-Received: by 2002:a2e:7208:0:b0:28b:761d:6594 with SMTP id n8-20020a2e7208000000b0028b761d6594mr2636889ljc.52.1674751175878; Thu, 26 Jan 2023 08:39:35 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?RnLDqWTDqXJpYyBNYXJ0aW5zb25z?= Date: Thu, 26 Jan 2023 17:39:24 +0100 Message-ID: Subject: Re: Change in MBR between parted 3.2 and 3.3 To: 61076@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61076 X-Mailman-Approved-At: Thu, 26 Jan 2023 11:53:50 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > This change was introduced by commit > 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix problems > growing partitions when using SD cards on the Raspberry Pi. OK , thank you very much for the explanation. Since I don't use raspberry Pi among my targets, do you think I can safely run a custom parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > Well, nothing should be actually using the CHS values these days. So > it's possible that's a bug that doesn't matter in practice, but I'll > have to look into that. OK I understand, since you close the present bug, do you know where I can have your conclusion when you'll have time to look at it ? Thanks again for the quick answer by the way. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 27 04:53:26 2023 Received: (at 61076) by debbugs.gnu.org; 27 Jan 2023 09:53:26 +0000 Received: from localhost ([127.0.0.1]:36762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLLQE-0000rl-5y for submit@debbugs.gnu.org; Fri, 27 Jan 2023 04:53:26 -0500 Received: from mail-lf1-f43.google.com ([209.85.167.43]:34427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLJsJ-0006Rz-Q7 for 61076@debbugs.gnu.org; Fri, 27 Jan 2023 03:14:20 -0500 Received: by mail-lf1-f43.google.com with SMTP id cf42so6990164lfb.1 for <61076@debbugs.gnu.org>; Fri, 27 Jan 2023 00:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=wl5dGMsKq2M+0JoA+p/mXCICjKPfx2mFM9c0Mjkehq0=; b=W/5d0VIinhxAI0C0KpA/1NcAG3APlAYQZx1C9OtTvumn+tr8vqMNxRvItki6WSr21P oeVRm0Vp43wBLU0Z9/PfygW3tzJ9avkC6kIJfAwvhxJG28gviMk8FhceB6COojVimXXm VcGFdB2g+A0IOYhTC+RUuP2neyWzFF9hs332xwoWMGfNrcpvHkyYFs70Ioj20x6TeeRa r9zbgKdj2uNmgeQhT9PtE4OJgomk0vZOfIisMFwOOmhKlJ/2pAwdb/7Sbg4fWa6ldrpW NH1oi6Ljh46ugbITYs1/Y9UquJmkCW+jNX3Jd0mBujmA75LR0NzsEHPk/M8P/Br2vXCR CRSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wl5dGMsKq2M+0JoA+p/mXCICjKPfx2mFM9c0Mjkehq0=; b=Rje2dB3SmM9XapAy3uzPQW3lgiYdAfsalcNkTuK/z32UHN58QT+Bom+f4OWp8pdDjI md+Vku1vF6T0Pg3bCUS9Oh4qfxVejQ1K/y+fW/P8uN3+lu3OX6au49AmEJGPFDguEbLT cf0e/6bILiJFuv8dT5ytFWOWa4QHCPVTeyaLQCZ2eJ9HZO6/HNifiSUJqVI9kB39x2kE Mu+lyrpBJWjJ0ZiOpQX+kJXCNHSj+qVp8G5j/wDE5qrgFzNDgZofORBk4ltnqfForhuT khCVQRKbQ89UFvq8lt0qfklesCJrM+Qa5ZeSSF43JFT7KQueWj9yvlrOctm1vga/gMNU uPIw== X-Gm-Message-State: AFqh2kqBibbeuKenKDCsGp5lKdE0eWZhcRjqGrW3scWYBZS0T+OZIc1t 6mgOYpSEvFeXRIedaQ9qD6geh1UgXZNOQtLbAn4= X-Google-Smtp-Source: AMrXdXtosIL8EwYvIs15NaFz55qKR9F5DXfrW6727/gRjIOzoW4qqPGEC0WDn4FnrstsvHYhX+ARPgX/pcy9/kmUOFk= X-Received: by 2002:a05:6512:3b0a:b0:4cc:9438:3b71 with SMTP id f10-20020a0565123b0a00b004cc94383b71mr3631692lfv.239.1674807253453; Fri, 27 Jan 2023 00:14:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?RnLDqWTDqXJpYyBNYXJ0aW5zb25z?= Date: Fri, 27 Jan 2023 09:14:01 +0100 Message-ID: Subject: Re: bug#61076: Change in MBR between parted 3.2 and 3.3 To: "Brian C. Lane" , 61076@debbugs.gnu.org Content-Type: multipart/mixed; boundary="00000000000068fd3a05f33a738f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61076 X-Mailman-Approved-At: Fri, 27 Jan 2023 04:53:25 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000068fd3a05f33a738f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > OK , thank you very much for the explanation. Since I don't use > > raspberry Pi among my targets, do you think I can safely run a custom > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > That's probably fine, as long as you know what you are doing ;) Ok I'll go this way, thanks. > > OK I understand, since you close the present bug, do you know where I > > can have your conclusion when you'll have time to look at it ? > > > > Thanks again for the quick answer by the way. > I'm *hoping* to get a new parted release ready sometime soon, but I'm > not yet sure when. I have a few other things to review and I'll take a > look at this at the same time to make sure it's not a bug. Fine, I'll keep a look to the parted release then ;) By the way, I come up with a patch (joined) which is a mix of revert 61dd3d4c5eb782eb43caa95342e63727db3f8281 and taken into account 52360db2f5397b7842d2ed90bf946c5e8fa91750 (which mention some kind of regression too): Have a nice day On Thu, 26 Jan 2023 at 19:50, Brian C. Lane wrote: > > On Thu, Jan 26, 2023 at 05:39:24PM +0100, Fr=C3=A9d=C3=A9ric Martinsons w= rote: > > > This change was introduced by commit > > > 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix proble= ms > > > growing partitions when using SD cards on the Raspberry Pi. > > > > OK , thank you very much for the explanation. Since I don't use > > raspberry Pi among my targets, do you think I can safely run a custom > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > > That's probably fine, as long as you know what you are doing ;) > > > > > > Well, nothing should be actually using the CHS values these days. So > > > it's possible that's a bug that doesn't matter in practice, but I'll > > > have to look into that. > > > > OK I understand, since you close the present bug, do you know where I > > can have your conclusion when you'll have time to look at it ? > > > > Thanks again for the quick answer by the way. > > I'm *hoping* to get a new parted release ready sometime soon, but I'm > not yet sure when. I have a few other things to review and I'll take a > look at this at the same time to make sure it's not a bug. > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > --00000000000068fd3a05f33a738f Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Get-back-the-old-way-of-getting-device-geometry-info.patch" Content-Disposition: attachment; filename="0001-Get-back-the-old-way-of-getting-device-geometry-info.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lde8yhj80 RnJvbSAwMDg1MWY5YjVjMDQ5ZDE4YTZkNDlkNjllYzJkNWQxMzU0NGY1NjE2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBGcmVkZXJpYyBNYXJ0aW5zb25zIDxmcmVkZXJpYy5tYXJ0aW5z b25zQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyNyBKYW4gMjAyMyAwNjozODoxNSArMDEwMApTdWJq ZWN0OiBbUEFUQ0hdIEdldCBiYWNrIHRoZSBvbGQgd2F5IG9mIGdldHRpbmcgZGV2aWNlIGdlb21l dHJ5IGluZm8KClRoaXMgaXMgYSBtaXggYmV0d2VlbiBhIHJldmVydCBvZiA2MWRkM2Q0YzVlYjc4 MmViNDNjYWE5NTM0MmU2MzcyN2RiM2Y4MjgxCmFuZCBhbiBhZGFwdGF0aW9uIGZvciA1MjM2MGRi MmY1Mzk3Yjc4NDJkMmVkOTBiZjk0NmM1ZThmYTkxNzUwCgpTZWUgbW9yZSBpbmZvIGF0IGh0dHBz Oi8vbGlzdHMuZ251Lm9yZy9hcmNoaXZlL2h0bWwvYnVnLXBhcnRlZC8yMDIzLTAxL21zZzAwMDAy Lmh0bWwKClNpZ25lZC1vZmYtYnk6IEZyZWRlcmljIE1hcnRpbnNvbnMgPGZyZWRlcmljLm1hcnRp bnNvbnNAZ21haWwuY29tPgotLS0KIGxpYnBhcnRlZC9hcmNoL2xpbnV4LmMgfCAxMCAtLS0tLS0t LS0tCiAxIGZpbGUgY2hhbmdlZCwgMTAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlicGFy dGVkL2FyY2gvbGludXguYyBiL2xpYnBhcnRlZC9hcmNoL2xpbnV4LmMKaW5kZXggMDllYzc4MS4u ZTMzN2FhZSAxMDA2NDQKLS0tIGEvbGlicGFydGVkL2FyY2gvbGludXguYworKysgYi9saWJwYXJ0 ZWQvYXJjaC9saW51eC5jCkBAIC04NjgsNyArODY4LDYgQEAgX2RldmljZV9wcm9iZV9nZW9tZXRy eSAoUGVkRGV2aWNlKiBkZXYpCiAgICAgICAgIHN0cnVjdCBzdGF0ICAgICAgICAgICAgIGRldl9z dGF0OwogICAgICAgICBzdHJ1Y3QgaGRfZ2VvbWV0cnkgICAgICBnZW9tZXRyeTsKICAgICAgICAg aW50ICAgICAgICAgICAgICAgICAgICAgZ2VvbWV0cnlfaXNfdmFsaWQgPSAwOwotICAgICAgICBp bnQgICAgICAgICAgICAgICAgICAgICBzZWN0b3Jfc2l6ZSA9IDA7CiAKICAgICAgICAgaWYgKCFf ZGV2aWNlX3N0YXQgKGRldiwgJmRldl9zdGF0KSkKICAgICAgICAgICAgICAgICByZXR1cm4gMDsK QEAgLTg4OCwxNiArODg3LDcgQEAgX2RldmljZV9wcm9iZV9nZW9tZXRyeSAoUGVkRGV2aWNlKiBk ZXYpCiAgICAgICAgIGdlb21ldHJ5X2lzX3ZhbGlkID0gIWlvY3RsIChhcmNoX3NwZWNpZmljLT5m ZCwgSERJT19HRVRHRU8sICZnZW9tZXRyeSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm JiBnZW9tZXRyeS5zZWN0b3JzICYmIGdlb21ldHJ5LmhlYWRzOwogCi0jaWYgZGVmaW5lZCBfX3Mz OTBfXyB8fCBkZWZpbmVkIF9fczM5MHhfXwogICAgICAgICBpZiAoZ2VvbWV0cnlfaXNfdmFsaWQp IHsKLSNlbHNlCi0gICAgICAgIGlmICghaW9jdGwgKGFyY2hfc3BlY2lmaWMtPmZkLCBCTEtTU1pH RVQsICZzZWN0b3Jfc2l6ZSkpIHsKLSAgICAgICAgICAgICAgICAvKiBnZXQgdGhlIHNlY3RvciBj b3VudCBmaXJzdCAqLwotICAgICAgICAgICAgICAgIGRldi0+Ymlvc19nZW9tLnNlY3RvcnMgPSAx ICsgKHNlY3Rvcl9zaXplIC8gUEVEX1NFQ1RPUl9TSVpFX0RFRkFVTFQpOwotICAgICAgICAgICAg ICAgIGRldi0+Ymlvc19nZW9tLmhlYWRzID0gMjU1OwotICAgICAgICB9IGVsc2UgaWYgKGdlb21l dHJ5X2lzX3ZhbGlkKSB7Ci0gICAgICAgICAgICAgICAgLyogaWYgQkxLU1NaR0VUIGZhaWxlZCwg dXNlIGRlcHJlY2F0ZWQgSERJT19HRVRHRU8gcmVzdWx0ICovCi0jZW5kaWYKICAgICAgICAgICAg ICAgICBkZXYtPmJpb3NfZ2VvbS5zZWN0b3JzID0gZ2VvbWV0cnkuc2VjdG9yczsKICAgICAgICAg ICAgICAgICBkZXYtPmJpb3NfZ2VvbS5oZWFkcyA9IGdlb21ldHJ5LmhlYWRzOwogICAgICAgICB9 IGVsc2UgewotLSAKMi4zNC4xCgo= --00000000000068fd3a05f33a738f-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 27 09:28:46 2023 Received: (at 61076) by debbugs.gnu.org; 27 Jan 2023 14:28:46 +0000 Received: from localhost ([127.0.0.1]:36963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLPif-0004nD-55 for submit@debbugs.gnu.org; Fri, 27 Jan 2023 09:28:46 -0500 Received: from mail-lf1-f43.google.com ([209.85.167.43]:33329) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLMRL-0002iK-SK for 61076@debbugs.gnu.org; Fri, 27 Jan 2023 05:58:40 -0500 Received: by mail-lf1-f43.google.com with SMTP id a11so7648158lfg.0 for <61076@debbugs.gnu.org>; Fri, 27 Jan 2023 02:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l14z/VPUbUUaHu3xN1pR2fq672qkQ8A8gCGRQxrgcA0=; b=Rw+Y8OgnGktTmzmgiN9JpAT3pJ7p5R+gnIm1YN87Axl+LXz//0+2eR2OKawzo1ov90 ylvft4Kd9lLeoHbu+0N9FJzG2PvPaJYXP3Bds6PiSltgYUfVQqwclfr0TzMGY41RCmat muHQH5LmSJ0Ob/w2NNp84eYjN14XDrS60rot/1fTzlqYsu7/MF7YCs6FjGL5WyYszZL4 mxKqf+xHAhN9qgNR1LTrT3bTPAP/Scm+WvnmiIYmLeengZa7Po82eikfT6HGMpYIoBiC oqYoEI0pXX0p1PtndKYdcI4Gth7KUayo92CmD3WZd/ciemzYKVVriPVZ30H/hHlHtAQx tKXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l14z/VPUbUUaHu3xN1pR2fq672qkQ8A8gCGRQxrgcA0=; b=eTMqn0V2SWqxF+kRymZJDb7ymrSsto4AfgxkdO4U3/NCzr5tR9M5WDF1ApAkF2hRG8 jqQ0WJdH8yJBeNHkef0oPXszre3B3KYbosqoV+1FzqW9iwf+0DL/AvTwCJDmrDtayoGl OjPb5jgGAhwocfVBQfYpXEYjEya/E6AqQ7NxCuQVC0FRPNR+IpfbHUvEcO4vmiNX8mgp S9UCpArWvQzN28ZEAPGk7DeeZdkHktKieMY178OY5Z8POUBVUSI8061dWYkSkHOWa/PD oW8boVoYABjqZnnVvhQsku3IuHtotp1epMmSOdhf4sk8+4KnrQIOeeud1DHKhZb4Gomb tsBg== X-Gm-Message-State: AFqh2koVMp69FmTVdu0YyEEBnSNA+L/kmcvXveyJ3tDti+FOHlSTuP53 EZurL+3BkbzdS3iRzqi7Zmtn5OIT3kwGhumCwYc= X-Google-Smtp-Source: AMrXdXsB3VmGujw8zD1DVuo3iCl+rA4AFLCo90d676ZdRzjCqNILDlt7XonQj1BWYqWCQlqJy06Rt93NFLGTSN3mWJs= X-Received: by 2002:a05:6512:3416:b0:4d5:a94a:f40f with SMTP id i22-20020a056512341600b004d5a94af40fmr1510389lfr.300.1674817113604; Fri, 27 Jan 2023 02:58:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?RnLDqWTDqXJpYyBNYXJ0aW5zb25z?= Date: Fri, 27 Jan 2023 11:58:22 +0100 Message-ID: Subject: Re: bug#61076: Change in MBR between parted 3.2 and 3.3 To: "Brian C. Lane" , 61076@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61076 X-Mailman-Approved-At: Fri, 27 Jan 2023 09:28:44 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) After more testing with the mentioned patch applied on parted 3.3, I still have differences on the MBR toward parted 3.2, below is what I got now: :~# hexdump -n 1024 -C /dev/mmcblk0 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |..............= ..| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!= ..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u.......= .u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t= ..| 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.......= ..| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..............= ..| * 000001b0 00 00 00 00 00 00 00 00 11 95 8b 42 00 00 00 00 |...........B..= ..| 000001c0 01 20 83 03 d0 ff 00 08 00 00 00 fc 34 00 00 03 |. ..........4.= ..| 000001d0 d0 ff 83 03 d0 ff 00 04 35 00 00 fc 34 00 80 03 |........5...4.= ..| 000001e0 d0 ff 83 03 d0 ff 00 00 6a 00 00 00 0c 00 00 00 |........j.....= ..| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............= U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..............= ..| And the partition table info: :~# parted /dev/mmcblk0 print unit s print unit chs print Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 3959MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1779MB 1778MB primary 2 1779MB 3557MB 1778MB primary 3 3557MB 3959MB 403MB primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 7733248s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 2048s 3474431s 3472384s primary 2 3474432s 6946815s 3472384s primary 3 6946816s 7733247s 786432s primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 120831,3,15 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 120832,4,16. Each cylinder is 32.8kB. Partition Table: msdos Disk Flags: Number Start End Type File system Flags 1 32,0,0 54287,3,15 primary 2 54288,0,0 108543,3,15 primary 3 108544,0,0 120831,3,15 primary ext4 boot In parted 3.2, I had the following geometry: BIOS cylinder,head,sector geometry: 481,255,63. Each cylinder is 8225kB. In 3.3 vanilla: BIOS cylinder,head,sector geometry: 15163,255,2. Each cylinder is 261kB. In 3.3 patched: BIOS cylinder,head,sector geometry: 120832,4,16. Each cylinder is 32.8kB. Like you said earlier "nothing should be actually using the CHS values these days", and indeed my system could be bootable with these changes, but my problem is that I have a TPM chip which check the content of the MBR and refuses to continue booting process if the content of it is not what is expected. Do you see other changes that have been made in parted 3.3 which impact the= MBR content in such a way ? On Fri, 27 Jan 2023 at 09:14, Fr=C3=A9d=C3=A9ric Martinsons wrote: > > > > OK , thank you very much for the explanation. Since I don't use > > > raspberry Pi among my targets, do you think I can safely run a custom > > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > > > That's probably fine, as long as you know what you are doing ;) > > Ok I'll go this way, thanks. > > > > OK I understand, since you close the present bug, do you know where I > > > can have your conclusion when you'll have time to look at it ? > > > > > > Thanks again for the quick answer by the way. > > > I'm *hoping* to get a new parted release ready sometime soon, but I'm > > not yet sure when. I have a few other things to review and I'll take a > > look at this at the same time to make sure it's not a bug. > > Fine, I'll keep a look to the parted release then ;) > By the way, I come up with a patch (joined) which is a mix of revert > 61dd3d4c5eb782eb43caa95342e63727db3f8281 and > taken into account 52360db2f5397b7842d2ed90bf946c5e8fa91750 > (which mention some kind of regression too): > > Have a nice day > > On Thu, 26 Jan 2023 at 19:50, Brian C. Lane wrote: > > > > On Thu, Jan 26, 2023 at 05:39:24PM +0100, Fr=C3=A9d=C3=A9ric Martinsons= wrote: > > > > This change was introduced by commit > > > > 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix prob= lems > > > > growing partitions when using SD cards on the Raspberry Pi. > > > > > > OK , thank you very much for the explanation. Since I don't use > > > raspberry Pi among my targets, do you think I can safely run a custom > > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > > > > That's probably fine, as long as you know what you are doing ;) > > > > > > > > > Well, nothing should be actually using the CHS values these days. S= o > > > > it's possible that's a bug that doesn't matter in practice, but I'l= l > > > > have to look into that. > > > > > > OK I understand, since you close the present bug, do you know where I > > > can have your conclusion when you'll have time to look at it ? > > > > > > Thanks again for the quick answer by the way. > > > > I'm *hoping* to get a new parted release ready sometime soon, but I'm > > not yet sure when. I have a few other things to review and I'll take a > > look at this at the same time to make sure it's not a bug. > > > > Brian > > > > -- > > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > > From unknown Sat Aug 16 10:43:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 25 Feb 2023 12:24:13 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator