I have just installed the latest nightly snapshot that I can find (17
September) of Fedora 18 on one of my Dreamplugs. Once I had discovered
that the orion_nand driver had to be blacklisted, that seemed fine(ish).
It certainly was enough for the system to come up.
One thing I did notice was that the rootfs-resize service failed due
to /usr/sbin/rootfs-resize being missing (it appears that it is
in /usr/bin instead), so as a consequence the system was running without
a resized rootfs. That nightly snapshot has rootfs-resize version 0.4-1.
I then did a yum update followed by a reboot. Part way through
rebooting, the system shut itself down and rebooted. After this, the
system failed to start, reporting that it could not find the rootfs. I
went through this whole process (starting from the nightly snapshot) 3
more times, always with exactly the same result.
Finally, I did the yum update but excluded the rootfs-resize package
from the update. This time the system restarted successfully after the
yum update.
It appears that the problem is in rootfs-resize's use of fdisk, when
rootfs-resize resizes the partition.
Manually doing the same as the rootfs-resize script, I get the
following:
Running fdisk /dev/sdb:
Command (m for help): p
Disk /dev/sdb: 4102 MB, 4102029312 bytes, 8011776 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 identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 * 63 1044224 522081 c W95 FAT32 (LBA)
/dev/sdb2 1044225 8011775 3483775+ 83 Linux
(this has already been resized, so ignore the end block for sdb2).
I now delete the second partition, and recreate it:
Command (m for help): d
Partition number (1-4): 2
Partition 2 is deleted
Command (m for help): n
Partition type:
p primary (1 primary, 0 extended, 3 free)
e extended
Select (default p): p
Partition number (1-4, default 2): 2
First sector (1044225-8011775, default 1044480):
Using default value 1044480
Last sector, +sectors or +size{K,M,G} (1044480-8011775, default 8011775):
Using default value 8011775
Partition 2 of type Linux and of size 3.3 GiB is set
The problem here is that although the first sector can be from 1044225
upwards, the default is 1044480, which is what the rootfs-resize script
selects. Since the new partition is created starting at a different
sector from the original partition, no filesystem can be found in that
partition.
Instead of letting the rootfs-resize script do the resize, I have done
it manually, entering 1044225 as the start sector, and that works fine.
Does the rootfs-resize script need to be modified to read the start
sector of the partition before it deletes it, and force the new
partition to have the same start sector? I have attached a patch to the
rootfs-resize script that does that.
Quentin Armitage
P.S. My plan is to update my two Dreamplugs and my 2 Sheevaplugs to F18
as soon as possible. I will also install Fedora on my Raspberry Pi(s).
I'm happy to do any testing that would help the project if someone can
point me in the most useful direction.