Sunday, February 20, 2011

[nslu2-linux] Re: updating kernel - /dev/mtdblock3 is not a block device

 

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*

-----------Begin Output-------------
eric@stowage:~$ ls -lah /dev/mtd*
crw------- 1 root root 90, 0 Feb 20 07:10 /dev/mtd0
crw------- 1 root root 90, 1 Feb 20 07:10 /dev/mtd0ro
crw------- 1 root root 90, 2 Feb 20 07:10 /dev/mtd1
crw------- 1 root root 90, 3 Feb 20 07:10 /dev/mtd1ro
crw------- 1 root root 90, 4 Feb 20 07:10 /dev/mtd2
crw------- 1 root root 90, 5 Feb 20 07:10 /dev/mtd2ro
crw------- 1 root root 90, 6 Feb 20 07:10 /dev/mtd3
crw------- 1 root root 90, 7 Feb 20 07:10 /dev/mtd3ro
crw------- 1 root root 90, 8 Feb 20 07:10 /dev/mtd4
crw------- 1 root root 90, 9 Feb 20 07:10 /dev/mtd4ro
crw------- 1 root root 90, 10 Feb 20 07:10 /dev/mtd5
crw------- 1 root root 90, 11 Feb 20 07:10 /dev/mtd5ro
------------End Output------------

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

--- In nslu2-linux@yahoogroups.com, nslu@... wrote:
> can you do an ls -lah /dev/mtd* it would from the message above
> indicate that /dev/mtdblock3 is not a black device (could be a file)
> or does not exist (seen enough programs that misreport what caused > error when a file is missing)
>

__._,_.___
Recent Activity:
MARKETPLACE

Stay on top of your group activity without leaving the page you're on - Get the Yahoo! Toolbar now.


Get great advice about dogs and cats. Visit the Dog & Cat Answers Center.

.

__,_._,___

No comments:

Post a Comment