From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6836626675367673856 X-Received: by 2002:a2e:5c47:: with SMTP id q68mr1884971ljb.30.1591793444227; Wed, 10 Jun 2020 05:50:44 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:998a:: with SMTP id w10ls3079106lji.0.gmail; Wed, 10 Jun 2020 05:50:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfTf8YsXRDJPLuly1hHEknLmK2N/wVTOzPmFOfy2M+KqOxFD00CSaQP61+kN4TS2sQf5aN X-Received: by 2002:a05:651c:231:: with SMTP id z17mr1772415ljn.237.1591793443416; Wed, 10 Jun 2020 05:50:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591793443; cv=none; d=google.com; s=arc-20160816; b=aJ0HEywLQ4+CQaO0xla0xJko8RZrdK0hvKoagl66J0r80RF25W9jjqdBr6pCFjaBZ9 1ATzWbqPOnw7XdjD0Feg5ppdDeWic+PEQmmfwz5N0+5wA5J2di7qeSZ5LQg02io4D8km wEIShA1sLO08ut0CFn5uIwDjFE+MDxUo5YPGAUL8DSW5qQQK9fTDUeitTO0+UJ9qmDjV 8iprKKAo/nw2ir1ObwDfs42o1hjZGaewDTqNGUnbhSFAEWVOhQRaSv8GDIeUROybQ2yy 3X4OIIrIUjVc+NIxyyiJZXKwSZe7c45tyYqCG8R5nlzZfQaKBarZuAU3G9ka5vij4zMl PUVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=CSazylhF8CU6vO4OBz+BtJXeV1wfdl+dxw9BZ3IKcRE=; b=jQAqTZCFecj9Pz9KXxN/INSPkenoXDAHi9b4VO3xd0x2CHIAx9MgW93pWufnqRZgNJ jzYBRcR0m1M49oHPabf0CJu3OeUR/W8U7oZBpHRx4Lk+2TZ29lZfn2op1H50Goopbujx Q1ANZE+PITzZ6SYTgaBsW3hrXwaPSW+HhIrkGuFhPsdvXvpRAhgwAquvVZ+r94VZci8e aVvLavc+JvLcQvtgYYM1E3q77Ti4zHTniwPhFndkECO1DT3avLgC5785HHc3s42cWWCV pESkSMRS7Ntz/sIUtGgIwGwv6AcPUdKTbsNoUGyJ1tDOTgDCJr2rx+4D3YkblDFmcyNq 1oPg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id v16si835385ljg.4.2020.06.10.05.50.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2020 05:50:43 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 05ACoeK2009695 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Jun 2020 14:50:40 +0200 Received: from [139.22.36.66] ([139.22.36.66]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05ACodTk025125; Wed, 10 Jun 2020 14:50:40 +0200 Subject: Re: [PATCH] expand-on-first-boot: Allow expanding extended MBR partitions To: Harald Seiler , isar-users References: <20200610080247.385697-1-hws@denx.de> From: Jan Kiszka Message-ID: Date: Wed, 10 Jun 2020 14:50:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610080247.385697-1-hws@denx.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: mqG6AdgwGqF+ 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. > > 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? > 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