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