Hi dMb,
Am 30.11.2010 22:51, schrieb e-mail dmb.leaf-devel:
> It *should* work but right now we have a problem with
> /sbin/fdisk from hdsupp.lrp which I have just confirmed - See
> http://sourceforge.net/apps/trac/leaf/ticket/11 :-(
Well, if all else fails, you might try booting with Bering uClinc 3.x,
using the hdsupp that from that distro to set things up, and then copy
the files for Bering uClinc onto the target drive. I'm not sure if it
will work, but there's a good chance that syslinux from Bering uClibc
3.x will boot 4.0 as well (just as a workaround for the time being,
until the hdsupp package of 4.x is fixed).
> If I understand correctly what Per is trying to achieve, he also wants
> to be able to copy (as in "dd") the configured image to a real CF card
> or similar, so for that we need to crack the problem of what a CF
> image looks like (I think the issue is disk geometry).
I'm afraid that approach is likely to fail - varying disk geometries as
seen by different controllers usually are the biggest issue. I tried
that approach years ago, and it failed big time (what worked on the CF
adapter on my devel box, didn't work on my Soekris 4501, what worked on
my Soekris, didn't work on my PCEngines box, what worked with VMWare
didn't work with qemu (and so on)). So, as far as I'm concerned, the
"build it once and dd it to the target medium" approach is difficult at
best (or maybe I just did something wrong every time I tried).
That's why I went with the approach of booting via PXE/CDRom, setting up
the target disk, and copying the files needed.
> Not sure it is possible to fix this in a generic way... Floppy disks
> are standard, so a floppy disk image is standard, but I get the
> impression that USB and CF flash drives are much more variable.
From my experience, it surely appears to be that way. Maybe the 2.6
kernel makes a difference, but with Bering uClibc 3.x, I never managed
to get things to work reliably on different platforms.
> Still,
> if someone can start with their own real flash drive, partition and
> format it, then "image' it it should be possible to mess with the
> image using qemu or similar and copy it back to the physical flash
> drive later.
It might be worth a try - to me, after failing several times, the
approach never seemed promising enough to spend hours of trying, when
booting via PXE (or from a CD image) and setting things up directly on
the target platform was a matter of 15 to 30 minutes. If I'd had to
deploy tens or hundreds of boxes, I would have spent more time on that
issue, but since it always was about only 2 or 3 boxes for me, my
approach seemed to be more sensible, for the amount of time I was
willing to spend.
I'm not saying it can't be done - I just never managed to get that
approach to work reliably. Maybe I simply overlooked something, and it
actually works if done correctly.
Martin
--
He will win who knows when to fight and when not to fight.
Sun Tzu, The Art of War
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
