[opensuse-arm] Tumbleweed image for Raspberry Pi 2 contains a corrupt ext4 partition after first boot
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.xz 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 -- 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
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.xz 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-${OS}-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz which shows the same behavior. -- 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
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 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 Kind regards, Stefan-- 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
Op vrijdag 12 januari 2018 22:47:16 CET schreef Brüns, Stefan:
size=`/usr/sbin/blockdev --getsize64 $card` dd if=/dev/zero of=$card obs=1 seek=$((size - 1024)) count=1024
Indeed that's the solution. I will document it on en.opensuse.org after some experimatation with sector as unit, because this gives an exit code of 1. -- 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
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 <suse-bugz@bischof.org>
Op vrijdag 12 januari 2018 22:47:16 CET schreef Brüns, Stefan:
should be
size=`/usr/sbin/blockdev --getsize64 $card` dd if=/dev/zero of=$card obs=1 seek=$((size - 1024)) count=1024
better # change X to the letter of the device with the SD card card=/dev/sdX ssize=$(/usr/sbin/blockdev --getss $card) [ $ssize -ne 512 ] && echo "sectorsize not equal 512" && exit 1 size=$(/usr/sbin/blockdev --getsz $card) dd if=/dev/zero of=/dev/sdg obs=$ssize seek=$(($size-2)) count=2 This does not give a warning/error message. Most likely this was caused by omitting the $ in front of size in the last line you showed. -- 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
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
participants (4)
-
Brüns, Stefan
-
Daniel Bischof
-
Freek de Kruijf
-
Stefan Seyfried