That eliminated the kernel panic, but when I try to boot the system using it, u boot still tries to do a tftp boot. With the working card, u boot fails to read the partition with the boot.scr and uImage files and reverts to booting from the kernel stored in firmware. So, back to the drawing board. It will probably be a few days before I can spend time with u boot again. In the meantime, I'll work on zfs. I have zfs loading at boot time, by executing the README.sh file in a .modules file in /etc/sysconfig/modules. A hack, to be sure. My pool still isn't persistent across reboots, but I am making progress
Thanks for the advice, Gordan. I'm learning as I go... On Thursday, July 19, 2012, Gordan Bobic wrote: > On 07/19/2012 03:31 AM, Ian Perkins wrote: > >> Got my new Sandisk Extreme micro-sd card today. Cloned my running card >> and swapped. Booted, but halted when attempting to read the rootfs. New >> card is slightly smaller (something like 7.96 GB versus 8.02 GB on >> working card). So, I manually set up a 20MB boot partition with the rest >> going for the rootfs. U boot likes this even less and tries to boot to a >> tftp server. I then look at both cards in fdisk and this is what I see: >> >> running card: >> >> /dev/mmcblk0p1 1 611 19544 83 Linux >> /dev/mmcblk0p2 612 245088 7823264 83 Linux >> >> Disk /dev/mmcblk0: 8031 MB, 8031043584 bytes >> 4 heads, 16 sectors/track, 245088 cylinders >> Units = cylinders of 64 * 512 = 32768 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disk identifier: 0x0007525e >> >> New card: >> >> /dev/sdc1 1 20 151869 83 Linux >> /dev/sdc2 21 1021 7602595 83 Linux >> >> Disk /dev/sdc: 7948 MB, 7948206080 bytes >> 111 heads, 3 sectors/track, 46618 cylinders >> Units = cylinders of 333 * 512 = 170496 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disk identifier: 0x00009359 >> >> Note the big difference in heads and sectors/track. I am thinking that I >> am going to have to juggle U boot memory addresses (which are given in >> hex) to make this card work. It may just be late and I am tired of >> fiddling with this card tonight. If I am missing something completely >> obvious, feel free to bonk me over the head. >> > > This has nothing to do with the uboot memory addresses. > > First thing to try would be to partition the new card first, before > cloning the partition. But the best option would be to partition the card > from scratch with the original geometry: > > # fdisk /dev/sdc -H4 -S16 > > mkfs it with whatever FS the original card has (ext3 or ext4?) > > # mkfs.ext[34] -b 4096 -E stripe-width=2048 /dev/sdc[12] > > and tar-copy the contents between them: > > # cd /path/to/mounted/dev/mmcblk0p[**12] > # tar -cf - . | tar -C /path/to/mounted/dev/sdc[12] -xf - > > and try that. It should rectify any issues arising from partitioning and > media inconsistencies. > > Gordan > ______________________________**_________________ > users mailing list > [email protected] > http://lists.redsleeve.org/**mailman/listinfo/users<http://lists.redsleeve.org/mailman/listinfo/users> > -- Thanks, Ian M Perkins
_______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
