Richard W.M. Jones wrote:
On Fri, Apr 27, 2012 at 09:42:22AM -0500, David A. Marlin wrote:
Richard W.M. Jones wrote:
In general pretty good - they work well. However there are a few
problems I encountered:
(1) There's no source for the boot scripts. I think you should put
the source along side the binaries, in /boot/uboot. I ended up using
'strings' and reconstructing them.
Agreed, the source for the script should be added.
(2) The sda boot script works fine, however the mmc boot script fails.
'fatload mmc 0:1 ...' should be 'fatload mmc 1:1 ...' (in both places).
It worked as provided for me (fatload mmc 0:1). Could this be
device dependent?
Possibly. I replaced the supplied no-brand micro SD card (4G) because
it failed, with a branded Samsung 32GB card. I've no idea if this
would change the numbering.
Ah, I see the difference. I used the external (front) SDCard slot, and
not the internal micro-SD. I think this image was intended for the
external (front) slot.
(3) If you have both images installed, then it boots one of them at
random, because it boots from 'root=LABEL=rootfs' which picks one of
the labelled root devices at random.
This is not a completely stupid configuration: you need to do this if
you're booting from a USB key and copying the mmc image to the
internal drive. At some point you'll have a trimslice with both the
sda image and the mmc image. Probably better to use UUIDs, or to have
different labels.
I think he was going for consistency across images (change as little
as possible) and to support copying the image to an internal drive,
as you mentioned. Would using UUIDs work in this scenario?
If the UUIDs are different, or changed to be different
(tune2fs -U ...)
If so,
what would need to be done (if anything) besides transferring the
image (via 'dd')?
The problem is I was using the sda image for my external (sda) drive,
and the mmc image for my internal drive. The main issue was confusion
-- why rebooting would randomly choose a different root device.
Yes, that would be confusing, and not desirable. :(
I'm working on creating disk images using lorax/anaconda, and have
modeled much of the configuration from Brendan's scripts, so any
tips are appreciated.
Standard advice is to use UUIDs instead of labels or (worst of all)
device paths. However if we're copying images around at all, then
there's the danger of having duplicate UUIDs which is really bad.
I wonder if the normal Fedora live CD generates a new random UUID
after resizing the minimized image? It must do.
I don't know how that works, but since it does I think it would be good
to leverage that approach (whatever it is).
d.marlin
========
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
