Re: expand-on-first-boot failure

[Henning Schild <henning.schild@siemens.com>]

Am Mon, 5 Dec 2022 02:06:33 +0100
schrieb "Moessbauer, Felix (T CED INW-CN)"
<felix.moessbauer@siemens.com>:

> On Sun, 2022-12-04 at 17:35 +0100, Jan Kiszka wrote:
> > Hi all,
> >
> > this is with current master:
> >
> > Aug 07 13:25:35 iot2050-debian systemd[1]: Starting Expand last
> > partition...
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: GPT
> > PMBR size mismatch (5407157 != 33554431) will be corrected by write.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: The
> > backup GPT table is not on the end of the device. This problem will
> > be corrected by write.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]:
> > Checking that no-one is using this disk right now ... FAILED
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: This
> > disk is currently in use - repartitioning is probably a bad idea.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Umount
> > all file systems, and swapoff all swap partitions on this disk.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Use
> > the --no-reread flag to suppress this check.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Disk
> > /dev/sda: 16 GiB, 17179869184 bytes, 33554432 sectors
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Disk
> > model: File-Stor Gadget
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Units:
> > sectors of 1 * 512 = 512 bytes
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Sector
> > size (logical/physical): 512 bytes / 512 bytes
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: I/O
> > size (minimum/optimal): 512 bytes / 512 bytes
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]:
> > Disklabel type: gpt
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Disk
> > identifier: 69D3FE47-A859-42D9-B04E-D26BFE6121C6
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: Old
> > situation:
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]:
> > Device     Start     End Sectors  Size Type
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]:
> > /dev/sda1   2048 5407123 5405076  2.6G Linux filesystem
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: >>>
> > Script header accepted.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: >>>
> > Script header accepted.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: >>>
> > Script header accepted.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: >>>
> > Script header accepted.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: >>>
> > Script header accepted.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: >>>
> > Script header accepted.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]: >>>
> > Created a new GPT disklabel (GUID: 69D3FE47-A859-42D9-B04E-
> > D26BFE6121C6).
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]:
> > /dev/sda1: Created a new partition 1 of type 'Linux filesystem' and
> > of size 16 GiB.
> > Aug 07 13:25:36 iot2050-debian expand-last-partition.sh[272]:
> > Partition #1 contains a ext4 signature.
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]:
> > /dev/sda2: Done.
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]: New
> > situation:
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]:
> > Disklabel type: gpt
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]: Disk
> > identifier: 69D3FE47-A859-42D9-B04E-D26BFE6121C6
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]:
> > Device     Start      End  Sectors Size Type
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]:
> > /dev/sda1   2048 33554398 33552351  16G Linux filesystem
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]: The
> > partition table has been altered.
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]:
> > Calling ioctl() to re-read partition table.
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]: Re-
> > reading the partition table failed.: Device or resource busy
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]: The
> > kernel still uses the old table. The new table will be used at the
> > next reboot or after you run partprobe(8) or partx(8).
> > Aug 07 13:25:37 iot2050-debian expand-last-partition.sh[272]:
> > Syncing disks.
> > Aug 07 13:25:37 iot2050-debian systemd-growfs[296]: Failed to open
> > "/dev/block/8:1": No such file or directory
> > Aug 07 13:25:37 iot2050-debian systemd[1]: expand-on-first-
> > boot.service: Main process exited, code=exited, status=1/FAILURE
> > Aug 07 13:25:37 iot2050-debian systemd[1]: expand-on-first-
> > boot.service: Failed with result 'exit-code'.
> > Aug 07 13:25:37 iot2050-debian systemd[1]: Failed to start Expand
> > last partition.
> >
> > Is the downstream layer lacking something to make things work again?
> > Or
> > is the slow, emulated storage device triggering a bug in the new
> > script?  
> 
> Hi, I recently discovered the same problem on an IoT2050.
> I'm really asking my self if we should continue with our own
> implementation of expand-on-first-boot. We almost always had bugs in
> this recipe which shows that this is definitely not something trivial.
> But it is still a critical part of the infrastructure.
> 
> IIRC the only reason for not using systemd-repart was the lack of
> backward compatibility for Debian stretch. Why not simply split the
> recipe into the old version for old distros and systemd-repart for new
> ones.

No it was more complex than that and there should be summary mails
somewhere.

You can use it but it will be pretty specific and not as generic.

You need to drop some bits into fstab, wks and rootfs.

rootfs:
  a snippet that says what you want "grow 100%" and which partition
  "partition uuid" (the first hit ... )
wks:
  give your funny partition a funny part uuid and make sure it is the
  first, maybe a label would work as well
fstab:
  put in the x-systemd.growfs

Now you do everything with systemd and simply do not install the isar
package. That all seems very powerful and maybe worth trying for a
layer. (mdadm ... lvm2 ... what have you)

With repart it seems you can not put all into one nice place/package
and can not make it generic. That is why we have what we have, you do
not have to use it.

Henning

> Felix
> 
> >
> > Jan
> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
> >  
>