Op woensdag 10 januari 2018 13:42:27 CET schreef Freek de Kruijf:

Op woensdag 10 januari 2018 13:26:53 CET schreef Freek de Kruijf:

...

I used two images from repository: http://download.opensuse.org/ports/aarch64/tumbleweed/images/ namely: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.9.raw.x z openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.10.raw. xz

The first one comes up properly. However "fdisk -l /dev/mmcblk0" shows: Disk /dev/mmcblk0: 7,5 GiB, 8068792320 bytes, 15759360 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: FDA566EC-2187-40A0-8357-DCB2E5B6F63D

Device Start End Sectors Size Type /dev/mmcblk0p1 2048 411651 409604 200M Linux filesystem /dev/mmcblk0p2 413696 839683 425988 208M Linux filesystem /dev/mmcblk0p3 841728 14747670 13905943 6,6G Linux filesystem /dev/mmcblk0p4 14749696 15759326 1009631 493M Linux filesystem

Strangely, "lsblk" shows: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 14,9G 0 disk ├─mmcblk0p1 179:1 0 200M 0 part /boot/efi ├─mmcblk0p2 179:2 0 14,2G 0 part / └─mmcblk0p3 179:3 0 485,7M 0 part [SWAP]

While "parted -l" shows this: Model: SD 00000 (sd/mmc) Disk /dev/mmcblk0: 16,0GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:

Number Start End Size File system Name Flags

1 1049kB 211MB 210MB fat16 vcboot 2 212MB 413MB 201MB ext4 lxboot legacy_boot 3 414MB 15,5GB 15,1GB lxroot 4 15,5GB 16,0GB 516MB linux-swap(v1) lxswap

After the first boot the system behaves as if it has only three partitions, so like lsblk shows.

However a reboot of this system shows an error message from script /boot/boot.scr about accessing something outside limits, I assume outside the second partition, and starts to try to boot from the network.

The second image shows in the first boot lots of errors trying to start services. A reboot shows the same behavior as the first image.

It looks like these images are not properly formatting the micro-SD card, and leave a corrupt ext4 partion on this card.

I filed a bug report about this: https://bugzilla.opensuse.org/show_bug.cgi?id=1075094

I also tried the RPi2 image for Leap 42.3 from repository:

http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances /

image: openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz

which shows the same behavior.

Tried again with a new 16 GB microSD card, which succeeded. I collected on the console the boot output, logged in and typed "fdisk -l /dev/mmcblk0", both using this 16 GB card and an 8 GB card. The 8 GB card shows the above 4 partions, the 16 GB card shows the proper 3 partitions. During some experimentation with gparted I found that not all sizes of the ext4 partition are accepted. Maybe this is the cause of the wrong partitioning on the 8 GB card. I used another 16 GB card also, which behaved like the 8 GB card. So it seems to be related to the size of the micro SD card. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Freitag, 12. Januar 2018 22:43:16 CET Brüns, Stefan wrote:

On Freitag, 12. Januar 2018 21:30:48 CET Freek de Kruijf wrote:

...

...

which shows the same behavior.

Tried again with a new 16 GB microSD card, which succeeded. I collected on the console the boot output, logged in and typed "fdisk -l /dev/mmcblk0", both using this 16 GB card and an 8 GB card. The 8 GB card shows the above 4 partions, the 16 GB card shows the proper 3 partitions. During some experimentation with gparted I found that not all sizes of the ext4 partition are accepted. Maybe this is the cause of the wrong partitioning on the 8 GB card. I used another 16 GB card also, which behaved like the 8 GB card. So it seems to be related to the size of the micro SD card.

When a once used SD card gets "refilled" using dd, it will still have the GPT backup at the "end" of the card, which may confuse the kernel. Try erasing the last sector of the card, e.g.:

card=/dev/sdb size=`/usr/sbin/blockdev --getsize /dev/sda` dd if=/dev/zero of=/dev/sda obs=1 seek=$((size - 1024)) count=1024

should be size=`/usr/sbin/blockdev --getsize64 $card` dd if=/dev/zero of=$card obs=1 seek=$((size - 1024)) count=1024 Stefan -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi, On Fri, 12 Jan 2018, Brüns, Stefan wrote: [...]

On Freitag, 12. Januar 2018 22:43:16 CET Brüns, Stefan wrote:

...

When a once used SD card gets "refilled" using dd, it will still have the GPT backup at the "end" of the card, which may confuse the kernel. Try erasing the last sector of the card, e.g.:

card=/dev/sdb size=`/usr/sbin/blockdev --getsize /dev/sda` dd if=/dev/zero of=/dev/sda obs=1 seek=$((size - 1024)) count=1024

should be

size=`/usr/sbin/blockdev --getsize64 $card` dd if=/dev/zero of=$card obs=1 seek=$((size - 1024)) count=1024

or just --- wipefs --all /dev/sdX --- Although the above command removes the signatures only, it should have the desired effect for the case above. At least it always worked for me... Best regards, --D.B. --- Daniel Bischof

Am 12.01.2018 um 22:43 schrieb Brüns, Stefan:

When a once used SD card gets "refilled" using dd, it will still have the GPT backup at the "end" of the card, which may confuse the kernel. Try erasing the last sector of the card, e.g.:

card=/dev/sdb size=`/usr/sbin/blockdev --getsize /dev/sda` dd if=/dev/zero of=/dev/sda obs=1 seek=$((size - 1024)) count=1024

zypper in gptfdisk sgdisk -z $card -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org