From unknown Tue Sep 23 07:29:05 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#53138 <53138@debbugs.gnu.org> To: bug#53138 <53138@debbugs.gnu.org> Subject: Status: Handling of shrinked GPT disks Reply-To: bug#53138 <53138@debbugs.gnu.org> Date: Tue, 23 Sep 2025 14:29:05 +0000 retitle 53138 Handling of shrinked GPT disks reassign 53138 parted submitter 53138 Davis severity 53138 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 09 04:02:32 2022 Received: (at submit) by debbugs.gnu.org; 9 Jan 2022 09:02:32 +0000 Received: from localhost ([127.0.0.1]:49185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6U5v-0006tW-PL for submit@debbugs.gnu.org; Sun, 09 Jan 2022 04:02:32 -0500 Received: from lists.gnu.org ([209.51.188.17]:57096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6TFW-0005Ts-MM for submit@debbugs.gnu.org; Sun, 09 Jan 2022 03:08:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47536) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6TFV-00024n-FU for bug-parted@gnu.org; Sun, 09 Jan 2022 03:08:22 -0500 Received: from [2607:f8b0:4864:20::62f] (port=40826 helo=mail-pl1-x62f.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6TFU-00050L-0D for bug-parted@gnu.org; Sun, 09 Jan 2022 03:08:21 -0500 Received: by mail-pl1-x62f.google.com with SMTP id l15so9575660pls.7 for ; Sun, 09 Jan 2022 00:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=oScav/g1cjPyrgbgG8Sr1/WLLgyepvLYYS2aTEcpcf8=; b=cKapZ2Wtec+hd2IIvL0kWBxRMf96HPqfAfzQXVdNhBLhPDFx3HWOSHL1doYaTVc3W4 ECSEWBYA9Uh/h6XA429CQ8jqSDYkHO6o4cDwDefTsUrGp1+F+5wGcHOs4JLTr0GVp9Yq tccJ98XTMW4V7t9ZUukDtMaWA205/MuDOU3aQkBuW64NFc7LmO/wKnb7uHyz/MzUr/l7 5kyd57X6TaresItOUcziy1fzI48TlhlM6UY/Y+N9/dcvo5zXkXasJwBqeIUm+T+ieyL9 E5a7VKgQL+w0S7L6HDxuRH8Y0pJfhmf+O91i2ihAL+da2erTJ4J9sng5IXGLDtTrszty SnRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oScav/g1cjPyrgbgG8Sr1/WLLgyepvLYYS2aTEcpcf8=; b=kj+Vras+VHJGAJTPRgyzubTJBU9+sojM9P9omOgkrxcEiGwit1lAxOIfbyg0vTMTSt QoohKhGQ5lfX254prD5iEZK4yaxSmoBg82R40u0NyvL0gAZoVZT3vISOREOik796QIHn hYnDUYfFiBhDVKZMjZRDVBoNoucslv7jVxc3ig9lm69YquNdWxal1tBjJlnKjNv/0DH1 bo9654iQGbSBn87ZRj3ZHfXmCyIt16gr9E9Gc27LzWKWTWBk69AGpd818aDRunAG1rQ1 K4dnT+vLt5BDQNSp7fPGaOl3XWDRGxfjOtVt4XGCHVMO7cKiRPdjtNmBPclPQDHKJpCT KgEg== X-Gm-Message-State: AOAM5302r8oIBsaFG52XWD65XTWr683lMWnLkuSL+XWujzyZ2n4omdOq zrmZGjyDMwTuvAkB4NF/nERYUFpWmWHqLm/vtLxKz8AO X-Google-Smtp-Source: ABdhPJxr9+a6xrFxpu8rbE8UrLZ8IihYJ/fjduRFTtNLTNg2iylsrStFUE+BXBZBSc5RxN20gbzHVIqAHPGHyYLoyQg= X-Received: by 2002:a17:903:3015:b0:14a:2206:8cdc with SMTP id o21-20020a170903301500b0014a22068cdcmr3680031pla.55.1641715696866; Sun, 09 Jan 2022 00:08:16 -0800 (PST) MIME-Version: 1.0 From: Davis Date: Sun, 9 Jan 2022 10:08:00 +0200 Message-ID: Subject: Handling of shrinked GPT disks To: bug-parted@gnu.org Content-Type: text/plain; charset="UTF-8" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::62f (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::62f; envelope-from=davikovs@gmail.com; helo=mail-pl1-x62f.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 09 Jan 2022 04:02:30 -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 (--) Hi, Looks like currently parted cannot handle GPT disks that have been shrunk (e.g. copied to a smaller physical disk (sometimes with the same rated capacity - disk capacity can vary a few KBs/MBs between manufacturers/models) or shrunk virtual/SAN disk). Instead of handling a shrunk GPT disk (with size that still fits all partitions) as valid, but needing some fixes (e.g. missing backup GPT, incorrect size of PMBR and a few values in GPT header), parted displays "Error: Invalid argument during seek for read on /dev/test_device_name" and shows no partitions. This can be reproduced by commands like these: dd if=/dev/zero of=testfile.img bs=100M count=1 sudo losetup -fP testfile.img sudo losetup -j testfile.img sudo parted /dev/loopX -s "mklabel gpt" sudo parted /dev/loopX -s "mkpart linux ext4 1 50%" sudo parted /dev/loopX -s "print" sudo losetup -d /dev/loopX sudo losetup -fP testfile.img --sizelimit 96M sudo losetup -j testfile.img # problem is visible here, there is additional prompt when run interactively sudo parted /dev/loopY -s "print" sudo losetup -d /dev/loopY rm testfile.img I think correct behavior would be assuming that Backup LBA and Last usable LBA fields need to be fixed if they point beyond last LBA of the disk (and last-33 LBA of the disk accordingly). I think this would be a safe thing to fix if no partitions point beyond last-33 LBA (the correct Last usable LBA value). And in case partitions are pointing beyond last-33 LBA, user might want to be able to delete those partitions. I have tested parted with GPT disks that have been extended and there GPT displays a message like "Warning: Not all of the space available to /dev/loop5 appears to be used, you can fix the GPT to use all of the space (an extra 40960 blocks) or continue with the current setting?" and, when running interactively, offers to fix the issue. Could it be possible to implement similar behavior for shrunk GPT disks? Best regards, Davis From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 10 17:20:10 2022 Received: (at submit) by debbugs.gnu.org; 10 Jan 2022 22:20:10 +0000 Received: from localhost ([127.0.0.1]:53462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n731O-0003Qp-2T for submit@debbugs.gnu.org; Mon, 10 Jan 2022 17:20:10 -0500 Received: from lists.gnu.org ([209.51.188.17]:46184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n731L-0003Qa-7T for submit@debbugs.gnu.org; Mon, 10 Jan 2022 17:20:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n731L-0000c5-2e for bug-parted@gnu.org; Mon, 10 Jan 2022 17:20:07 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:57528) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n731H-0006jF-JW for bug-parted@gnu.org; Mon, 10 Jan 2022 17:20:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641853201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wB8ghPByLS58bs3CBYLFX6z0IsUsd74VEiK1qFePvHA=; b=iLB8IGiEd8Os46DB0A+quQxXzETTso7hZOo2AbTL77jgqb/JHbb0wxyEMDL0baWKcG3eCq xXlWaKpNUTqQrg2ecIs2u9WHM+BxoR95ik7EMigzepsh9FhdTrhtMFGYwigCzPqAB7xXaE lquVMGbPxKKrVCtxOmhi1R9sw9DjX4k= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-367-DB5X1JkGO1melrQVYkmE7A-1; Mon, 10 Jan 2022 17:18:45 -0500 X-MC-Unique: DB5X1JkGO1melrQVYkmE7A-1 Received: by mail-pj1-f71.google.com with SMTP id k93-20020a17090a3ee600b001b32ec86e10so12746382pjc.3 for ; Mon, 10 Jan 2022 14:18:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wB8ghPByLS58bs3CBYLFX6z0IsUsd74VEiK1qFePvHA=; b=Lvvy+UtnusR2R+M4IwPKNHqTJ1mLTcY+g0yqYEHCbcpUM73jcRDl3wzJmE3zWTtrkg v4hXDHmgn/X+0KPstwaMD0q1YDKHosRnOSQiO/yTEDLpFNoJUBTZDUZAssXWbR/9pFEg fbAfKwBYboY84G4hQ3Qhdl2YRRVfpbIDYj9HAH48eeM5zwAuWbkL9ZIluqY+MlJm0LRP IHwi6ccRJovppTjuQ+A1gAC7x5GhK3V5cqqdJSkrADLrMn4FjBQaTyPaLEgIj7dB4ZrB 9iGIX3yPdxdqeFB9bTYbIf8cVhlYl4eH80Zv78FpAhKQcOrl3fKIRvlalQfxsrNaYQXO +Cgg== X-Gm-Message-State: AOAM530nvsh9DoHXVjCefimDx3PNms8n396qdesYHtyuYJ/IjBrYA69M 8C+uHbVs+zdf65I/PoHlr/OEKE2s2SIh6OPHtR0VHAOv9cLEzxR6csy+OrxZWPbq9clpnSY3OxS 8+3GT0+C4VmFm6WaK+wa0QOzDdJ4paA9CnaonUWzYNKSDpypaQL0mMgjr X-Received: by 2002:a63:2b94:: with SMTP id r142mr1574999pgr.288.1641853124380; Mon, 10 Jan 2022 14:18:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJyKuGfTa+wuTa2RGnq2rrUn7v2+r/5xDlQrghMw/cGC/oHtApKYafayQkC199hbXqebwygzdA== X-Received: by 2002:a63:2b94:: with SMTP id r142mr1574970pgr.288.1641853123845; Mon, 10 Jan 2022 14:18:43 -0800 (PST) Received: from ohop.brianlane.com ([2601:603:5000:3e9:52e5:49ff:fe52:c5be]) by smtp.gmail.com with ESMTPSA id t207sm7394680pfc.205.2022.01.10.14.18.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 14:18:43 -0800 (PST) Date: Mon, 10 Jan 2022 14:18:41 -0800 From: "Brian C. Lane" To: bug-parted@gnu.org Subject: Re: bug#53138: Handling of shrinked GPT disks Message-ID: References: MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=bcl@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=bcl@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -33 X-Spam_score: -3.4 X-Spam_bar: --- X-Spam_report: (-3.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.597, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit 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.4 (--) On Sun, Jan 09, 2022 at 10:08:00AM +0200, Davis wrote: > Hi, [snip] > I have tested parted with GPT disks that have been extended and there > GPT displays a message like "Warning: Not all of the space available > to /dev/loop5 appears to be used, you can fix the GPT to use all of > the space (an extra 40960 blocks) or continue with the current > setting?" and, when running interactively, offers to fix the issue. > Could it be possible to implement similar behavior for shrunk GPT disks? The question I have is, how common a problem is this? While it can happen, it is a pretty fine line between losing just the backup GPT and losing the end of the last partition (assuming it is fully utilized). I'm not sure it's worth adding extra code and the potential for new bugs if this isn't a common practice. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 13 03:18:31 2022 Received: (at submit) by debbugs.gnu.org; 13 Jan 2022 08:18:31 +0000 Received: from localhost ([127.0.0.1]:60024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7vJU-0005Up-8p for submit@debbugs.gnu.org; Thu, 13 Jan 2022 03:18:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:42740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7tFT-0000l7-Km for submit@debbugs.gnu.org; Thu, 13 Jan 2022 01:06:15 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7tFT-0006y3-BX for bug-parted@gnu.org; Thu, 13 Jan 2022 01:06:11 -0500 Received: from [2607:f8b0:4864:20::1036] (port=51799 helo=mail-pj1-x1036.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n7tFR-0002lN-A7 for bug-parted@gnu.org; Thu, 13 Jan 2022 01:06:10 -0500 Received: by mail-pj1-x1036.google.com with SMTP id o3so9302644pjs.1 for ; Wed, 12 Jan 2022 22:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=EbDk1QU4ZvJ0HfowQG+TqNb8A1zhgf4avw8zAMSOgzw=; b=f6McHVXnB2pTgWJVPwj5o4mE3O5ZQLb4HuMbJOLtKSLW1OfYmpIHsdJWyJm9Jf4UF2 CoFqrqZpMd0RUxGBzeut7YzphDoJq0c4SN7GIY/ym+bE1KTFmzNVMwpkbsiUD6Yw4Wos KeWeM7UbzifXR+VxFR7C1VSnqCg2fz/pyC3aAlXEWLYVruw+6z3wFdnrnqzELRK+pYLE kF50+1wnScPh75pg71/BRPkRXhRRlFvJrtYzbbGzNH65OOZgRqSWFx+Ke9TEYqvXsSMJ oqXgHTI14Sdo+iEDiHLhcVr1NLi3tx+eK2QPZsFSTn1eCg1NBrw8K3GTYNAICijR2NoD wMYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EbDk1QU4ZvJ0HfowQG+TqNb8A1zhgf4avw8zAMSOgzw=; b=HmQx4bMZVD4uv/BXCyIWkD2JsQ+eCvhSriJixxucgtx2Q4Tv0JMSZle+gscmFuUq/q WVxZ8n2F614zl0x0t/gojz4i35RL769rWHzbooRsGEY2hGqgt6U4c0xsCLp1QYTvg2rV SPc/CHpxmijUJ372os20erRuQH5aUtR7xtvRMGHGxJFnMZFdPVsYNBKg+6370ThMeIxZ MSavFE3ghubPQazkaRsWvyEuFe5WScJIWjXu+kNwJ77eOZk0ShCNPSt1lbS5t5wbydLE G+9aF2HCAbIR5kuTU0mNr82WvUh/nEYD5kFIETVUtLPru3HxO9zyk9BDkRiKNJTlXi+L VvPg== X-Gm-Message-State: AOAM532d/cL6U8JaTnqocTk7xZX2X/bO0Cxuw9UhFcfqH9DL7pMl06fr 5aqSrVwrjXrftfstleqTJ9Wqus4P5XvqY456uulY/a+5P0c= X-Google-Smtp-Source: ABdhPJwZy469VQUenFPazpeAqEIrR42cdGFzDW9VnJAFOzUBQR/gQTdRuD/lgpipEhzXrbfXIYg1bPvVm+1D4iWifoI= X-Received: by 2002:a63:470a:: with SMTP id u10mr2702491pga.346.1642053966705; Wed, 12 Jan 2022 22:06:06 -0800 (PST) MIME-Version: 1.0 From: Davis Date: Thu, 13 Jan 2022 08:05:55 +0200 Message-ID: Subject: bug#53138: Handling of shrinked GPT disks To: bug-parted@gnu.org Content-Type: text/plain; charset="UTF-8" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::1036 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::1036; envelope-from=davikovs@gmail.com; helo=mail-pj1-x1036.google.com X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.1 / 5.0 requ) BAYES_05=-0.5, 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 13 Jan 2022 03:18:27 -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 (--) > The question I have is, how common a problem is this? While it can > happen, it is a pretty fine line between losing just the backup GPT and > losing the end of the last partition (assuming it is fully utilized). > I'm not sure it's worth adding extra code and the potential for new bugs > if this isn't a common practice. I would guess that shrinking the last partition (e.g. using GParted) and cloning disk using dd is probably a quite common practice - this method preserves exotic boot loaders, disk/volume IDs and other things. Also in some situations the size difference between old and new drive could be less than the free slack space after the last partition on the old drive (making shrinking unnecessary). I am not sure how common are the cases when the last partition extends beyond the end of the drive as the result of copying data without resizing the partition (I can imagine this would be the case e.g. if copying data from a failing drive). However I think that even in those cases parted shouldn't display an empty partition table. Davis