Re: expand-on-first-boot failure

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

On Thu, 2022-12-08 at 16:35 +0100, Henning Schild wrote:
> 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

This is a very good summary.
I got lost in the back and forth of the discussion.

Thanks Henning!

> 
> 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
> > >  
> > 
>