Bug 1075094 - Tumbleweed image for Raspberry Pi 2 contains a corrupt ext4 partition after first boot
Tumbleweed image for Raspberry Pi 2 contains a corrupt ext4 partition after f...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other
Current
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-08 21:22 UTC by Freek de Kruijf
Modified: 2018-01-13 14:41 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
boot log using 16 GB card which succeeded in a bootable system (13.32 KB, text/plain)
2018-01-12 20:23 UTC, Freek de Kruijf
Details
boot log using 8 GB card which did not succeed in a bootable system (13.38 KB, text/plain)
2018-01-12 20:24 UTC, Freek de Kruijf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Freek de Kruijf 2018-01-08 21:22:11 UTC
Using the Tumbleweed image for the Raspberry Pi 2 (not the upstream one) mentioned on the page https://en.opensuse.org/HCL:Raspberry_Pi2 on a micro-SD card of 8GB, this image boots OK. However a reboot is not possible. The reason is that after the initial boot "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

In the above there should only be three partitions, a FAT32 partition, an ext4 partition and a swap partition.

After putting the image on the micro-SD "fdisk -l /dev/sdg" shows:
Schijf /dev/sdg: 7,5 GiB, 8068792320 bytes, 15759360 sectoren
Eenheid: sectoren van 1 * 512 = 512 bytes
Sectorgrootte (logisch/fysiek): 512 bytes / 512 bytes
In-/uitvoergrootte (minimaal/optimaal): 512 bytes / 512 bytes
Schijflabeltype: dos
Schijf-ID: 0x87c36787

Apparaat   Op.  Begin   Einde Sectoren Grootte ID Type
/dev/sdg1        2048  411651   409604    200M  c W95 FAT32 (LBA)
/dev/sdg2      413696 3118976  2705281    1,3G 83 Linux
Comment 1 Freek de Kruijf 2018-01-09 12:52:56 UTC
The command "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

again partition table is gpt. Two partitions (2,3) that should one.
However "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]

Still a reboot is not possible, it tries to load an image from the network.
It get an error from /boot/boot.scr that it is reading outside limits.
Comment 2 Freek de Kruijf 2018-01-10 12:05:31 UTC
The above is with image
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.9.raw.xz
Image openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.10.raw.xz
does not even start properly after the first boot. It shows a lot of error messages about services not properly starting.
A reboot of that image show the same behavior as Build1.9.
Comment 3 Freek de Kruijf 2018-01-12 20:20:03 UTC
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 logs are attached, named RPi2-16GBOK.txt and RPi2-16GBnotOK.txt.
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 card.
Comment 4 Freek de Kruijf 2018-01-12 20:23:28 UTC
Created attachment 755931 [details]
boot log using 16 GB card which succeeded in a bootable system

boot using 16 GB card
Comment 5 Freek de Kruijf 2018-01-12 20:24:24 UTC
Created attachment 755932 [details]
boot log using 8 GB card which did not succeed in a bootable system
Comment 6 Freek de Kruijf 2018-01-13 14:41:15 UTC
The solution is to clear the 1024 bytes at the end of the SD card. This can be done using the following script before you perform the xzcat command:

# 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