* expand-on-first-boot failure
@ 2022-12-04 16:35 Jan Kiszka
2022-12-05 1:06 ` Moessbauer, Felix
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2022-12-04 16:35 UTC (permalink / raw)
To: isar-users, Schaffner, Tobias (T CED SES-DE), Henning Schild
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?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: expand-on-first-boot failure
2022-12-04 16:35 expand-on-first-boot failure Jan Kiszka
@ 2022-12-05 1:06 ` Moessbauer, Felix
2022-12-05 7:36 ` Jan Kiszka
2022-12-08 15:35 ` Henning Schild
0 siblings, 2 replies; 6+ messages in thread
From: Moessbauer, Felix @ 2022-12-05 1:06 UTC (permalink / raw)
To: Schaffner, Tobias, isar-users, Kiszka, Jan, Schild, Henning
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.
Felix
>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: expand-on-first-boot failure
2022-12-05 1:06 ` Moessbauer, Felix
@ 2022-12-05 7:36 ` Jan Kiszka
2022-12-08 15:37 ` Henning Schild
2022-12-08 15:35 ` Henning Schild
1 sibling, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2022-12-05 7:36 UTC (permalink / raw)
To: Moessbauer, Felix (T CED INW-CN),
Schaffner, Tobias (T CED SES-DE),
isar-users, Schild, Henning (T CED SES-DE)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: expand-on-first-boot failure
2022-12-05 1:06 ` Moessbauer, Felix
2022-12-05 7:36 ` Jan Kiszka
@ 2022-12-08 15:35 ` Henning Schild
2022-12-09 3:10 ` Moessbauer, Felix
1 sibling, 1 reply; 6+ messages in thread
From: Henning Schild @ 2022-12-08 15:35 UTC (permalink / raw)
To: Moessbauer, Felix (T CED INW-CN)
Cc: Schaffner, Tobias (T CED SES-DE), isar-users, Kiszka, Jan (T CED)
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
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: expand-on-first-boot failure
2022-12-05 7:36 ` Jan Kiszka
@ 2022-12-08 15:37 ` Henning Schild
0 siblings, 0 replies; 6+ messages in thread
From: Henning Schild @ 2022-12-08 15:37 UTC (permalink / raw)
To: Jan Kiszka
Cc: Moessbauer, Felix (T CED INW-CN),
Schaffner, Tobias (T CED SES-DE),
isar-users
Am Mon, 5 Dec 2022 08:36:46 +0100
schrieb 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.
Fix is on the way. Tobias Schaffner has a fix and we already did
a first "talking about it" review round.
I could repro on a raspbi as well, but seems Tobias was faster. Stay
tuned.
Henning
> Jan
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: expand-on-first-boot failure
2022-12-08 15:35 ` Henning Schild
@ 2022-12-09 3:10 ` Moessbauer, Felix
0 siblings, 0 replies; 6+ messages in thread
From: Moessbauer, Felix @ 2022-12-09 3:10 UTC (permalink / raw)
To: Schild, Henning; +Cc: Schaffner, Tobias, isar-users, Kiszka, Jan
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
> > >
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-12-09 3:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-04 16:35 expand-on-first-boot failure Jan Kiszka
2022-12-05 1:06 ` Moessbauer, Felix
2022-12-05 7:36 ` Jan Kiszka
2022-12-08 15:37 ` Henning Schild
2022-12-08 15:35 ` Henning Schild
2022-12-09 3:10 ` Moessbauer, Felix
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox