From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6836626675367673856 X-Received: by 2002:a5d:5084:: with SMTP id a4mr14414507wrt.416.1591955625321; Fri, 12 Jun 2020 02:53:45 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:aace:: with SMTP id i14ls3588317wrc.3.gmail; Fri, 12 Jun 2020 02:53:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+ymGeCSSGEq2n7BucyKeY2SLvR2GRMzRCW2QLj06x6uPTjrk+saT1Gi+JBjMbe0jJgRNe X-Received: by 2002:adf:f74e:: with SMTP id z14mr14561255wrp.338.1591955624839; Fri, 12 Jun 2020 02:53:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591955624; cv=none; d=google.com; s=arc-20160816; b=kpkb6Z9X//48dyhNTpzog3E0fH7+vm1W06VZSFVGdrjXpZg2i5i3JSHoofnJQ1D5PY LFr7kl+6GQJhvgDFHCIrELWBMG3iRFD09lBTGtp8hlSmPt7qAoip58bCv+bEBkU2g4LL B0tM603S8klI4pilfdqVIFcw+D+JhU3fj3qtIpptbEqnWtTN0ftlHt3VXlvfben2hBjq /gvH6X5IPOYMtaxbDrj6+PovizW/ll6+g1J/wFQB3s0GkRvesqVOEgVHS75TCGCrOmoM mMobxACfmHUndGPq/wV8vZqJ+9C0a2oxqFTq3GNk0W3qCvv5hlTpo2vlOuwRfEALEUoP GFqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:to:from:subject:message-id; bh=wKiuwhWJ4gBO4ZAjAqiVYdBT4gHbUgANwcJb92TeNu0=; b=IRyPDZfYfQoXUOyBeSGuIwJWoxvFUkuGpc4Zhib+LCj9xhvCDaGFNdTr5BzRdcye8P RxXFkOgA+g6cVGJMlNxr9Lyh7sxmMcwRBf5wh9HFYUzJ4iggsKorwqqYAOgRxM96OrkQ 9dUoHAgetltLbVSlLsaGXfVjE2ktNB8o6Z3nAIDVpkL/N3WfIGmBvxhyhTrZ/gkftApR e6mnjpDvojPThlO9duoqMktWaC9XGUDLg6cyYiAspyS9H6QB2xih0sl8O8ZVuP1wtaas MBCItsxwbOEYtelfFBo1sqcwc1TjtkXZqnsEVgX7O3yTEbzzPsdUMg4U79eKmAzzHIgX 78Qw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 2001:a60:0:28:0:1:25:1 is neither permitted nor denied by best guess record for domain of hws@denx.de) smtp.mailfrom=hws@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [2001:a60:0:28:0:1:25:1]) by gmr-mx.google.com with ESMTPS id g7si317549wma.1.2020.06.12.02.53.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 02:53:44 -0700 (PDT) Received-SPF: neutral (google.com: 2001:a60:0:28:0:1:25:1 is neither permitted nor denied by best guess record for domain of hws@denx.de) client-ip=2001:a60:0:28:0:1:25:1; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 2001:a60:0:28:0:1:25:1 is neither permitted nor denied by best guess record for domain of hws@denx.de) smtp.mailfrom=hws@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 49jwzD4LxRz1rtMh; Fri, 12 Jun 2020 11:53:44 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 49jwzD48Wgz1sPMm; Fri, 12 Jun 2020 11:53:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id 9MM54mNymNwD; Fri, 12 Jun 2020 11:53:43 +0200 (CEST) X-Auth-Info: Ij+Vb18mk2yAvMYAnnTbW4lbyCc4coVelZzk3sROFj4= Received: from maia.denx.de (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 12 Jun 2020 11:53:43 +0200 (CEST) Message-ID: <323b50f39ca1ce6ac21a705bcbf6f24e4e6e5c0d.camel@denx.de> Subject: Re: [PATCH] expand-on-first-boot: Allow expanding extended MBR partitions From: Harald Seiler To: Jan Kiszka , isar-users Date: Fri, 12 Jun 2020 11:53:43 +0200 In-Reply-To: References: <20200610080247.385697-1-hws@denx.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUID: XH3QLDuoH6id Hello Jan, On Wed, 2020-06-10 at 14:50 +0200, Jan Kiszka wrote: > On 10.06.20 10:02, Harald Seiler wrote: > > Extended partitions cannot be resized like primary partitions because > > both the last logical partition and the EBR primary partition containing > > it need to be expanded. > > > > To do this, add a second SED directive for removing the parition size of > > the EBR partition. This part is detected by having either type `f` (Win > > 95 Ext') or `5` (Extended). > > > > Signed-off-by: Harald Seiler > > --- > > > > Notes: > > I have tested this in an ongoing project and it seems to work > > reliably. For some reason WIC creates an extended partition of > > type `f` but this can't be kept because while fdisk can read it, > > it is only happy about writing the EBR with type `5`. > > Wikipedia says about 0x5: > > "Extended partition with CHS addressing. It must reside within the first > physical 8 GB of disk, else use 0Fh instead" > > So we likely need to account for that case as well. > Hm, this is getting quite complicated ... And I suppose this is only one of many corner cases. I'm not sure how much effort is worth here: This change is only relevant to legacy systems that (have to) use MBR *and* deal with more than 4 partitions which is most likely not too many. What do you think? Is it likely that other projects would benefit from a general solution or would it make more sense to keep this a) project specific or b) detect one supported case and only do EBR expansion for that one. > > > > While probably a very uncommon layout, I am not sure how this > > would behave when the EBR is not the last partition, but > > somewhere in between. I am a bit worried it would silently wreak > > havoc ... > > We should probably throw some test patterns at that. Could be done > against a disk image file as well, I suppose. > > > .../expand-on-first-boot/files/expand-last-partition.sh | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > index 08c69db30529..ddf1a089e87d 100755 > > --- a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > +++ b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > @@ -17,12 +17,13 @@ if [ "${ROOT_DEV}" = "${BOOT_DEV}" ]; then > > exit 1 > > fi > > > > -LAST_PART="$(sfdisk -d ${BOOT_DEV} 2>/dev/null | tail -1 | cut -d ' ' -f 1)" > > +LAST_PART="$(sfdisk -d "${BOOT_DEV}" 2>/dev/null | tail -1 | cut -d ' ' -f 1)" > > > > # Remove all hints to the current medium (last-lba) and last partition size, > > # then ask sfdisk to recreate the partitioning > > The comment should likely be updated as well. > > > sfdisk -d "${BOOT_DEV}" 2>/dev/null | grep -v last-lba | \ > > - sed 's|\('"${LAST_PART}"' .*, \)size=[^,]*, |\1|' | \ > > + sed 's|^\(.*, \)size=[^,]*, type=[f5]$|\1type=5|' | \ > > + sed 's|^\('"${LAST_PART}"' .*, \)size=[^,]*, |\1|' | \ > > Would it make things worse or better to combine both sed expressions > into the same sed call? > I don't think either option would make this prettier. I think the most reasonable way forward is documenting what exactly is done with those expressions. > > sfdisk --force "${BOOT_DEV}" > > > > # Inform the kernel about the partitioning change > > > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux > -- Harald DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de