Hey folks,
A few issues with the RC2 image running on PandaBoard (ES):
1). It doesn't boot at all. This is because the image contains a weird partition layout, not aligned, etc. MLO never has a chance. The SD Card had this as the first partition:
/dev/sdb1 1953 1001953 500000+ 83 Linux
Which I fixed to look as it should:
/dev/sdb1 * 2048 411647 204800 6 FAT16
At which point the MLO actually loads, as does u-boot.img, etc.
2). Unless I am missing something, there is nothing within boot/boot.scr on the root ext4 filesystem for ext4load to pull in, but that could be pilot error. So let me know about that one.
If it's just the first item, then there's no need to make an RC4 because the instructions (that have to be run anyway) can include making a correctly aligned filesystem with the correct constraints on size, filesystem type, etc. required for MLO. I did note this on IRC yesterday that MLO is finnicky and I did have a reason (as you see).
Jon.
Semi-pilot error. I should be using the -VFAT images, which I just figured out after two hours spent trying to fix the other one. This is not documented on the wiki obviously and is a post-beta change, so it will urgently require attention as anyone following the instructions from beta will fall into the same trap (and not know how to fix it).
I've pulled down the VFAT images onto a fast remote box and confirmed with kpartx that they look better. Since it's go-no-go I will stay up now and do some testing once they come down on ES. Assume that the below is not a problem because the images do contain boot.scr and partitioning looks more reasonable in the VFAT ones.
Jon.
On 06/28/2013 02:48 AM, Jon Masters wrote:
Hey folks,
A few issues with the RC2 image running on PandaBoard (ES):
1). It doesn't boot at all. This is because the image contains a weird partition layout, not aligned, etc. MLO never has a chance. The SD Card had this as the first partition:
/dev/sdb1 1953 1001953 500000+ 83 Linux
Which I fixed to look as it should:
/dev/sdb1 * 2048 411647 204800 6 FAT16
At which point the MLO actually loads, as does u-boot.img, etc.
2). Unless I am missing something, there is nothing within boot/boot.scr on the root ext4 filesystem for ext4load to pull in, but that could be pilot error. So let me know about that one.
If it's just the first item, then there's no need to make an RC4 because the instructions (that have to be run anyway) can include making a correctly aligned filesystem with the correct constraints on size, filesystem type, etc. required for MLO. I did note this on IRC yesterday that MLO is finnicky and I did have a reason (as you see).
Jon. _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Fri, Jun 28, 2013 at 03:06:24AM -0400, Jon Masters wrote:
Semi-pilot error. I should be using the -VFAT images, which I just figured out after two hours spent trying to fix the other one.
On 06/28/2013 02:48 AM, Jon Masters wrote:
The SD Card had this as the first partition:
/dev/sdb1 1953 1001953 500000+ 83 Linux
I see the same problem with the Minimal VFAT RC3 images starting on sector 1953 instead of 2048. Also, shouldn't the type of the second filesystem be 82 for Linux Swap?
# fdisk -l Fedora-Minimal-VFAT-armhfp-19-1-sda.raw
Disk /scratch/pandaboard/f19-rc3/Fedora-Minimal-VFAT-armhfp-19-1-sda.raw: 7373 MB, 7373586432 bytes, 14401536 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 Disk label type: dos Disk identifier: 0x000c5b49
Device Boot Start End Blocks Id System Fedora-Minimal-VFAT-armhfp-19-1-sda.raw1 * 1953 41015 19531+ c W95 FAT32 (LBA) Fedora-Minimal-VFAT-armhfp-19-1-sda.raw2 41016 1041015 500000 c W95 FAT32 (LBA) Fedora-Minimal-VFAT-armhfp-19-1-sda.raw3 1041016 13736328 6347656+ 83 Linux
Jeff
On 06/28/2013 11:51 AM, Jeffrey Bastian wrote:
I see the same problem with the Minimal VFAT RC3 images starting on sector 1953 instead of 2048. Also, shouldn't the type of the second filesystem be 82 for Linux Swap?
Yes to both, but since it doesn't prevent booting I was going to mention right after we said "yes" to shipping F19 :)
Jon.
On Fri, Jun 28, 2013 at 12:14:34PM -0400, Jon Masters wrote:
On 06/28/2013 11:51 AM, Jeffrey Bastian wrote:
I see the same problem with the Minimal VFAT RC3 images starting on sector 1953 instead of 2048. Also, shouldn't the type of the second filesystem be 82 for Linux Swap?
Yes to both, but since it doesn't prevent booting I was going to mention right after we said "yes" to shipping F19 :)
Actually, it doesn't seem to matter since it's using UUIDs to find the swap partition.
Short version: I approached it slightly differently and I've got F19 RC3 running on my Pandaboard!
Long version: I'm using a combination of SD card for uboot and USB flash drive for the root filesystem, so rather than writing the raw image directly to the devices, I just mounted the F19 RC3 image and copied the files over to my SD card and USB drive which were already partitioned for Fedora 18.
First, mount the F19 RC3 image:
# kpartx -av Fedora-Minimal-VFAT-armhfp-19-1-sda.raw add map loop0p1 (253:8): 0 39063 linear /dev/loop0 1953 add map loop0p2 (253:9): 0 1000000 linear /dev/loop0 41016 add map loop0p3 (253:10): 0 12695313 linear /dev/loop0 1041016 # mkdir /tmp/p1 /tmp/p3 # mount -o ro /dev/mapper/loop0p1 /tmp/p1 # mount -o ro /dev/mapper/loop0p3 /tmp/p3
Then rsync the root filesystem to my USB flash drive:
# rsync -avHAX --delete /tmp/p3/ /run/media/jbastian/__/
And manually set up the boot partition (where mmcblk0p1 is mounted on /run/media/jbastian/uboot). I'm using cat and overwriting the existing files to keep them in the same spot on the partition since the Pandaboard is picky about finding the MLO file.
# cd /tmp/p3/usr/share/uboot-panda # cat MLO > /run/media/jbastian/uboot/MLO # cat u-boot.bin > /run/media/jbastian/uboot/u-boot.bin # cat u-boot.img > /run/media/jbastian/uboot/u-boot.img # cat uEnv.txt.panda > /run/media/jbastian/uboot/uEnv.txt # rm -rf /run/media/jbastian/uboot/{uI*,vmlinuz*,System*,klist.txt,initr*,config*,dtb*,grub*} # rsync -r /tmp/p3/boot/ /run/media/jbastian/uboot/
Finally, I changed the UUID on the root filesystems to match that from boot.scr, and updated /etc/fstab on the root filesystem to use the UUIDs of my swap and uboot partitions.
I then moved the SD card and USB flash drive over the Pandaboard and it booted! Full transcript is attached.
Jeff
-
Jeffrey Bastian -
Jon Masters