Hi Axel, On Wed, Apr 22, 2020 at 04:35:08PM +0200, Axel Braun wrote:

Am Mittwoch, 22. April 2020, 16:33:03 CEST schrieb Guillaume Gardet:

...

...

Is this an issue of the used image?

The resize of the partition should happen on first boot. Would you have serial traces of the boot?

How can I get those?

I've created a wiki page how to connect to the Raspberry Pi via serial console. Hope that helps... ;) https://en.opensuse.org/HCL:Raspberry_Pi3_Serial_Console Inside the full output you should see the resize operation. [ 23.823172] dracut-pre-mount[413]: Created symlink /etc/systemd/system/systemd-fsck-root.service → /dev/null. [ 30.737235] dracut-pre-mount[413]: resize2fs 1.43.8 (1-Jan-2018) [ 94.026953] dracut-pre-mount[413]: Removed /etc/systemd/system/systemd-fsck-root.service. Ciao, Alex~ -- Alexander Bergmann Security Engineer, GPG: E30A 65A4 0F50 0066 B2B5 F614 DE54 E875 9FFA 4886 SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

-----Original Message----- From: Axel Braun Sent: 24 April 2020 17:33 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] Raspi4/Leap 15.2/wrong disk size

Hello Fabian,

Am Donnerstag, 23. April 2020, 11:13:34 CEST schrieb Fabian Vogt:

...

Am Mittwoch, 22. April 2020, 16:22:03 CEST schrieb Axel Braun:

...

Hi, I'm trying the Raspi 4 image (openSUSE-Leap-15.2-ARM-LXQT- raspberrypi4.aarch64-2020.02.26-Build1.63.raw.xz) updated to the latest patch level, and encounter an issue with the reported disk size: ...

...

Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 2048 133119 131072 64M c W95 FAT32 (LBA) /dev/mmcblk1p2 133120 1157119 1024000 500M 82 Linux swap / Solaris /dev/mmcblk1p3 1157120 61978769 60821650 29G 83 Linux

-> so far so good, 29G available for /

...

But: ...

...

-> only 4G for / in the running system, ext4 file system. (I fixed this with resize2fs)

Is this an issue of the used image?

Sounds like kiwi didn't resize the filesystem on the first boot. Can you reproduce this? Add "rd.kiwi.debug=1" to the kernel cmdline and you'll get a log file in /run/initramfs/log.

Just tried this, but keyboard is not reacting at that stage (means: 'E' at the grub screen does not work, interruption of autoboot does not work either) ... although I used the keyboard with the Raspi3 before

U-boot for RPi4 does not have USB support yet, so you cannot use USB keyboard for u-boot, nor grub! Guillaume

@Alexander - thanks for the Wiki-Page! I would need to get some hardware for this first....

Cheers Axel

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi, Am Freitag, 24. April 2020, 18:10:14 CEST schrieb Axel Braun:

Am Freitag, 24. April 2020, 17:42:29 CEST schrieb Guillaume Gardet:

...

...

-----Original Message----- From: Axel Braun Sent: 24 April 2020 17:33 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] Raspi4/Leap 15.2/wrong disk size

Hello Fabian,

Am Donnerstag, 23. April 2020, 11:13:34 CEST schrieb Fabian Vogt:

...

Am Mittwoch, 22. April 2020, 16:22:03 CEST schrieb Axel Braun:

...

Hi, I'm trying the Raspi 4 image (openSUSE-Leap-15.2-ARM-LXQT- raspberrypi4.aarch64-2020.02.26-Build1.63.raw.xz) updated to the latest patch level, and encounter an issue with the reported disk

...

size: ...

...

Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 2048 133119 131072 64M c W95 FAT32 (LBA) /dev/mmcblk1p2 133120 1157119 1024000 500M 82 Linux swap / Solaris /dev/mmcblk1p3 1157120 61978769 60821650 29G 83 Linux

-> so far so good, 29G available for /

...

But: ...

...

-> only 4G for / in the running system, ext4 file system. (I fixed this with resize2fs)

Is this an issue of the used image?

Sounds like kiwi didn't resize the filesystem on the first boot. Can you reproduce this? Add "rd.kiwi.debug=1" to the kernel cmdline and you'll get a log file in /run/initramfs/log.

Just tried this, but keyboard is not reacting at that stage (means: 'E' at the grub screen does not work, interruption of autoboot does not work either) ... although I used the keyboard with the Raspi3 before

U-boot for RPi4 does not have USB support yet, so you cannot use USB keyboard for u-boot, nor grub!

So serial console is the only chance at the moment?

You could simply edit grub.cfg and shrink the partition again before rebooting. As long as you don't run mkinitrd or something like that the kiwi code for resizing is still active. Cheers, Fabian

Cheers Axel

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Alex,

-----Original Message----- From: Axel Braun Sent: 27 April 2020 22:12 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] Raspi4/Leap 15.2/wrong disk size

Hi,

Am Freitag, 24. April 2020, 21:39:55 CEST schrieb Fabian Vogt:

...

...

...

...

Just tried this, but keyboard is not reacting at that stage (means: 'E' at the grub screen does not work, interruption of autoboot does not work either) ... although I used the keyboard with the Raspi3 before

U-boot for RPi4 does not have USB support yet, so you cannot use USB keyboard for u-boot, nor grub!

So serial console is the only chance at the moment?

You could simply edit grub.cfg and shrink the partition again before rebooting. As long as you don't run mkinitrd or something like that the kiwi code for resizing is still active.

I did various tests today, with the original image and the updated as well, but could not reproduce the issue. File system was always grown to partition size. Thats good on the one hand, but somewhat unsatisfying on the other hand...

It could be due to a problem when the image was copied to uSD card. Some software checks what was written to uSD card once copied. This has been useful for me in the past as the check sometimes fail. Cheers, Guillaume

Thanks to all for your support! Axel

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-----Original Message----- From: Axel Braun Sent: 28 April 2020 09:26 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] Raspi4/Leap 15.2/wrong disk size

Hello Guillaume,

Am Dienstag, 28. April 2020, 08:30:12 CEST schrieb Guillaume Gardet:

...

Hi Alex,

...

-----Original Message----- From: Axel Braun Sent: 27 April 2020 22:12 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] Raspi4/Leap 15.2/wrong disk size

Hi,

Am Freitag, 24. April 2020, 21:39:55 CEST schrieb Fabian Vogt:

...

...

...

> Just tried this, but keyboard is not reacting at that stage > (means: > 'E' at > the grub screen does not work, interruption of autoboot does > not work > either) ... although I used the keyboard with the Raspi3 > before

U-boot for RPi4 does not have USB support yet, so you cannot use USB keyboard for u-boot, nor grub!

So serial console is the only chance at the moment?

You could simply edit grub.cfg and shrink the partition again before rebooting. As long as you don't run mkinitrd or something like that the kiwi code for resizing is still active.

I did various tests today, with the original image and the updated as well, but could not reproduce the issue. File system was always grown to partition size. Thats good on the one hand, but somewhat unsatisfying on the other hand... It could be due to a problem when the image was copied to uSD card. Some software checks what was written to uSD card once copied. This has been useful for me in the past as the check sometimes fail.

I was using: xzcat openSUSE-Leap-15.2-ARM-LXQT-raspberrypi4.aarch64-2020.02.26- Build1.63.raw.xz | dd bs=4M of=/dev/mmcblk0 iflag=fullblock oflag=direct status=progress; sync

Nowadays, I tend to avoid dd as you can copy to the wrong disk and break your system very easily. I prefer to use tools which perform a filtering and expose only removable devices. I know that Etcher [0] performs a check after the copy. I guess other tools would do it as well. Not sure about imagewriter. Maybe people here have suggestions of other software? Cheers, Guillaume [0]: https://www.balena.io/etcher/

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org