> From: Chris Tapp > > This should end > of=/dev/sdb > > The hddimg file includes the partition info and both > partitions, so you don't need any of the other steps.
Actually, the .hddimg is a single FAT16 volume, with no partition table, which contains files for creating a couple of different RAM disk images, which are part of the live-image mechanism. I am leaning toward using this live-image mechanism in my project permanently, because it almost eliminates the possibility of anything corrupting the OS in any persistent way. My application does have a small amount of persistent data, and I don't want to use the union or overlay file system as a way of adding persistence to the live image, because that sort of defeats the security of the live image. So I do indeed want to use a truly partitioned flash drive, and put my application data on a separate small partition. What's going wrong is that the code in the MBR created by gparted (and I assume by parted) unconditionally uses drive number 0x80 (the first hard disk) when it tries to load the zeroth sector from the bootable partition. The BIOS, however, is treating this eUSB SSD as a removable drive, and calling it drive zero. So it's crashing at the point where the MBR code jumps to what is supposed to be the zeroth sector of the partition. The code in the boot sector for the FAT16 volume uses whatever drive number is in the DL register on entry, and this works fine when booting directly from the BIOS into this code with no intervening MBR, so the solution is to modify the MBR boot code to do the same thing. This simply involves NOP-ing out the MOV DL, 80H instruction. Then, it should successfully boot a partitioned flash drive as though it were a hard disk. -- Ciao, Paul D. DeRocco Paul mailto:[email protected] _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
