Re: [leaf-devel] Howto Create Bering4 diskimage for emulator use
On 30 November 2010 21:07, Martin Hejl mar...@hejl.de wrote: Hi Per, Booted OK but stuck on /dev/sda1 does not exist as no partition exist. Tried several ways of creating a partition with no . Linux host does not recognize a filesystem. I also tried making a disk.img with qemu-img and from qemu -cdrom sysrecover.iso -hda disk.img -boot order=d fdisk /dev/sda mkfs.vfat /dev/sda1 syslinux /dev/sda Back in host i tried mount -o loop offset=nnn + losetup method With losetup on disk.img, fdisk can see the partition. BUT don't seem to be able to mount and get a reconisabel filesystem Can someone provide a real Image from a 64 M CF-card. For analysing and comparing of structure David I belive the subject needs a wiki-page, where do you want it in the structure user/installation or development? I can write it. (please enable talk page for taspts) I don't know if things might have changed (I haven't tried Bering uClibc 4.0 yet, due to lack of time) - but I wrote down the aproach that has worked for me countless times (setting up both VMs as well as real boxes with a CF) in the help section of the hdsupp package: http://leaf.cvs.sourceforge.net/viewvc/leaf/src/bering-uclibc/apps/hdsupp/buildtool.cfg?revision=1.25content-type=text%2Fplain As long as you get the box to boot (via CD-Rom, PXE or some other means), and have access to the additional LRPs, it should work (IMHO - as I said, untested on Bering uClibc 4.0). Hi Martin, Your logic is good. I tried booting qemu from the CD-ROM image and with a (blank) hard drive image this morning, with a view to using the hdsupp tools to fix up the hard drive image and then copy the files from the CD-ROM. 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 :-( 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). 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. 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. dMb 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
Re: [leaf-devel] Bering-uClibc4: module options for auto-loading
On 14 November 2010 21:29, Andrew ni...@seti.kr.ua wrote: 14.11.2010 23:15, davidMbrooke пишет: On Sat, 2010-11-13 at 20:50 +0200, Andrew wrote: 13.11.2010 12:24, davidMbrooke пишет: On Sat, 2010-11-13 at 11:11 +0200, Andrew wrote: 12.11.2010 20:24, davidMbrooke пишет: I see that we are using CONFIG_MODPROBE_SMALL rather than CONFIG_MODPROBE for BusyBox. Is there a good reason for that? Would switching to CONFIG_MODPROBE be a practical option? From comparing the source code (modprobe.c versus modprobe-small.c) it seems to me that modprobe.c would give us (more) standard Debian behaviour... dMb As I remembered, standard modprobe requires presence of System.map (file with kernel symbols) which has huge size. But I can mistake. Hi Andrew, Is it fairly easy to check on that? I will soon be off-line until tomorrow, and I know you wanted a quick answer on this, so my thinking is: - If CONFIG_MODPROBE is a practical option (e.g. no need for System.map) then I would prefer to change to that. - If CONFIG_MODPROBE is *not* a practical option I am OK with patching BusyBox - kp convinced me :-) Best way - to look in code, or to assemble bb, copy it somewhere on running distro, and run in's modprobe. I finally got chance to try this. I rebuilt everything from scratch (I was due a rebuild anyway) and changed the BusyBox .config to select CONFIG_MODPROBE rather than CONFIG_MODPROBE_SMALL. Everything seems to work fine, and no need for System.map. If it works good and nothing is broken - you can commit it into main tree :) Hi Andrew, I won't promise that *nothing* is broken, but everything I tried works OK. I will commit when I get home from work (+6 hours from now). I have been reading some more. Seems that _SMALL saves 14KB. I think we can spare 14KB to use non-SMALL... :-) I think I will turn *off* FEATURE_LSMOD_PRETTY_2_6_OUTPUT because that says it makes the code bigger; I don't think we need it. Same for CHECK_TAINTED_MODULE. dMb CONFIG_FEATURE_CHECK_TAINTED_MODULE=y CONFIG_FEATURE_MODUTILS_ALIAS=y CONFIG_FEATURE_MODUTILS_SYMBOLS=y I didn't realize that these last three common options were not set before. They seemed like a good idea when I was answering the config prompts. Perhaps we can leave these as they are. They are available only for full-weight modutils; simplified modutils act like with enabled 2 last options. I have not investigated the module options handling but comments in modprobe.c indicate that /etc/modprobe.conf (or /etc/modules.conf) are searched for module option settings, e.g. options tulip2 irq=4 io=0x308 Does that let us do what we need with module options? dMb Yes, IMHO it'll be enough. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Bering-uClibc4: NIC Firmware Loading
Hi Team, I am getting an error testing v4 with an e100 NIC: Failed to load firmware and referencing file e100/d101s_ucode.bin I understand that such files are normally located under /lib/firmware and sure enough in buildtool/staging/ the files are there. I am considering creating a new package firmware.lrp so that these can be loaded. Does that seem sensible or should they be included in an existing .lrp? The total size of the lib/firmware/ directory is about 500K though it may be smaller when compressed in a .lrp file. Thanks, davidMbrooke -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
