Bug 1467436 - fedora-arm-image-installer fails on Fedora 26 due to partition mismatch of aarch64 .raw.xz
fedora-arm-image-installer fails on Fedora 26 due to partition mismatch of aa...
Status: NEW
Product: Fedora
Classification: Fedora
Component: fedora-arm-installer (Show other bugs)
25
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Whalen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-03 17:41 EDT by John Reiser
Modified: 2017-07-24 05:05 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2017-07-03 17:41:13 EDT
Description of problem: The partition format in Fedora-Workstation-26-1.3.aarch64.raw.xz cannot be processed by fedora-arm-installer-1.99.16-1.fc25.noarch, so the media preparation of uSDHC fails.


Version-Release number of selected component (if applicable):
fedora-arm-installer-1.99.16-1.fc25.noarch

How reproducible: every time


Steps to Reproduce:
1. fedora-arm-image-installer --image=Fedora-Workstation-26-1.3.aarch64.raw.xz --target=rpi3 --media=/dev/sdh --selinux=OFF --norootpass --resizefs --addconsole
2.
3.

Actual results:
Two instances of:
    /dev/sdh4: Failed to resize partition #4.

complete Terminal log: 
=====================================================
= Selected Image:                                 
= Fedora-Workstation-26-1.3.aarch64.raw.xz
= Selected Media : /dev/sdh
= U-Boot Target : rpi3
= SELINUX = OFF
= Root Password will be removed.
= Root partition will be resized
= Console for rpi3 will be added.
=====================================================
 
*****************************************************
*****************************************************
******** WARNING! ALL DATA WILL BE DESTROYED ********
*****************************************************
*****************************************************
 
 Type 'YES' to proceed, anything else to exit now 
 
= Proceed? YES
= Writing: 
= Fedora-Workstation-26-1.3.aarch64.raw.xz 
= To: /dev/sdh ....
0+961139 records in
0+961139 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 471.943 s, 18.2 MB/s
= Writing image complete!
= Resizing /dev/sdh ....
Checking that no-one is using this disk right now ... OK

Disk /dev/sdh: 29.6 GiB, 31724666880 bytes, 61962240 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: dos
Disk identifier: 0x79a4cfef

Old situation:

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdh1  *       2048   411647   409600  200M  6 FAT16
/dev/sdh2        411648  2508799  2097152    1G 83 Linux
/dev/sdh3       2508800  4188159  1679360  820M 82 Linux swap / Solaris
/dev/sdh4       4188160 16777215 12589056    6G  5 Extended
/dev/sdh5       4190208 16777215 12587008    6G 83 Linux

/dev/sdh4: Failed to resize partition #4.
Leaving.

Checking that no-one is using this disk right now ... OK

Disk /dev/sdh: 29.6 GiB, 31724666880 bytes, 61962240 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: dos
Disk identifier: 0x79a4cfef

Old situation:

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdh1  *       2048   411647   409600  200M  6 FAT16
/dev/sdh2        411648  2508799  2097152    1G 83 Linux
/dev/sdh3       2508800  4188159  1679360  820M 82 Linux swap / Solaris
/dev/sdh4       4188160 16777215 12589056    6G  5 Extended
/dev/sdh5       4190208 16777215 12587008    6G 83 Linux

/dev/sdh4: Failed to resize partition #4.
Leaving.

e2fsck 1.43.3 (04-Sep-2016)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdh4
Could this be a zero-length partition?
resize2fs 1.43.3 (04-Sep-2016)
resize2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdh4
Couldn't find valid filesystem superblock.
= Turning SELinux off ...
sed: can't read /tmp/boot/extlinux/extlinux.conf: No such file or directory
= Removing the root password.
sed: can't read /tmp/root/etc/passwd: No such file or directory
= No U-Boot will be installed.

= Installation Complete! Insert into the rpi3 and boot.
==============================================================================


Expected results: No failure.


Additional info: The actual image layout is:
=====
# parted /dev/sdh
GNU Parted 3.2
Using /dev/sdh
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit MiB                                                         
(parted) p                                                                
Model:  Multi-Reader -3 (scsi)
Disk /dev/sdh: 30255MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start    End      Size     Type      File system     Flags
 1      1.00MiB  201MiB   200MiB   primary   fat16           boot
 2      201MiB   1225MiB  1024MiB  primary   ext4
 3      1225MiB  2045MiB  820MiB   primary   linux-swap(v1)
 4      2045MiB  8192MiB  6147MiB  extended
 5      2046MiB  8192MiB  6146MiB  logical   ext4
=====
where the root partition is #5; but fedora-arm-image-installer expects root as partition #4, and cannot cope.



The bug is in this code from /usr/bin/fedora-arm-image-installer,
which does not recognized that partition #4 is the Extended partition,
and that the root partition actually is partition #5:
=====
# check to see how many partitions on the image
partprobe "$MEDIA"
sleep 1
case $MEDIA in
        "/dev/mmcblk"*)
                if [ -e "$MEDIA"p4 ]; then
                        export FIRMPART="${MEDIA}p1"
                        BOOTPART="${MEDIA}p2"
                        ROOTPART="${MEDIA}p4"
                        PARTNUM=4
                else
                        BOOTPART="${MEDIA}p1"
                        ROOTPART="${MEDIA}p3"
                        PARTNUM=3
                fi
                ;;
        *)
                if [ -e "$MEDIA"4 ]; then     ####  WRONG
                        export FIRMPART="${MEDIA}1"
                        BOOTPART="${MEDIA}2"
                        ROOTPART="${MEDIA}4"
                        PARTNUM=4
                else
                        BOOTPART="${MEDIA}1"
                        ROOTPART="${MEDIA}3"
                        PARTNUM=3
                fi
                ;;
esac

=====
Comment 1 Peter Robinson 2017-07-03 17:51:02 EDT
> Steps to Reproduce:
> 1. fedora-arm-image-installer
> --image=Fedora-Workstation-26-1.3.aarch64.raw.xz --target=rpi3
> --media=/dev/sdh --selinux=OFF --norootpass --resizefs --addconsole

1) you can also use the documented dd process for RPi3 as it doesn't need a u-boot write out: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Manual

2) the aarch64 images are not generally supported, there are other issues with them in the auto boot process.
Comment 2 Christos Triantafyllidis 2017-07-23 19:56:42 EDT
The dd method also fails. The u-boot kernel is in the image so it doesn't matter you are using dd or fedora-arm-image-installer.

What seems to be missing from the image is the extlinux installation/configuration.
Comment 3 Peter Robinson 2017-07-24 05:05:12 EDT
(In reply to Christos Triantafyllidis from comment #2)
> The dd method also fails. The u-boot kernel is in the image so it doesn't
> matter you are using dd or fedora-arm-image-installer.
> 
> What seems to be missing from the image is the extlinux
> installation/configuration.

We don't use extlinux on aarch64, we use grub2/uefi for the boot on all devices (SBBA compliant or not). The images produced for aarch64 are currently unsupported and produced for people wishing to assist with fixing some of the low level boot issues. The u-boot not working is a known issue (and the reason they're not supported). Once we have the issue resolved there will be a documented means of getting the official F-26 images working, until then if you don't understand the low level boot process you'll need to wait.

Note You need to log in before you can comment on or make changes to this bug.