On Mon, Feb 21, 2011 at 03:04:16AM -0000, e_zago wrote:
> Thanks for the push in the right direction - I've always ignored the dark voodoo that is the /dev filesystem ... to help others who may find themselves as characters in a similar story - here's what happened next:
>
> Before I touched anything else, here's the output of ls -lah /dev/mtd*
>
> Interestingly enough there is mtd3 - but not mtdblock3. Some quick searching around the net reveals that there should be matching set of mtdX/mtdblockX in order to properly write to flash.
>
> A bit more use of my Google-fu, and I stumbled upon:
> http://www.nslu2-linux.org/wiki/HowTo/RecoverBrokenDebianKernel
>
> Though that wasn't exactly my problem - it seemed to be close. I saw the use of mknod to create the block device files: (sudo mknod mtdblock0 b 31 0, etc. - all the way up to mtdblock5).
>
> Being a curious one, after creating them - I tried rebooting; and they disappeared. I then re-created them - and immediately ran:
> sudo apt-get install linux-image-ixp4xx
>
> That completed successfully - flashed both the kernel and initramfs - and then returned me to the command line. I then rebooted the box, and hurrah, the box is now running 2.6.32-5-ixp4xx.
>
> I then did another ls -lah /dev/mtd* - and sure enough, there are now both mtdX and mtdblockX entries there. So - the problem appears to now be resolved. If there is any insight that can be shared for why the mtdblockX entries in /dev were not created under the other kernel - I'd be interested in learning a bit more of the /dev magic sauce.
>
> Thanks,
> -Eric
as i suspected, the mtd device was missing, most likley a bug in the
udev package ( no support for detecting mtd partions) that may have
been resolved after the update
the way to check this is to look under /sys/block and see if the
kernel sees the block device and compare that with /dev to see if udev
recignises the device
wont be able to do it now but thats what i suspect
good luck!
No comments:
Post a Comment