Re: expand-on-first-boot failure

[Jan Kiszka <jan.kiszka@siemens.com>]

On 05.12.22 02:06, Moessbauer, Felix (T CED INW-CN) wrote:
> 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.

It was more complicated than that, see the discussion around it.

First of all, we quickly need to restore to the working state now - or
fix this new issue.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux