Loading ...
Sorry, an error occurred while loading the content.

updating kernel - /dev/mtdblock3 is not a block device

Expand Messages
  • e_zago
    Greetings - My NSLU2 has been running lenny for some time; this morning I changed my sources.list to squeeze - ran apt-get-update and apt-get dist-upgrade.
    Message 1 of 4 , Feb 20, 2011
    • 0 Attachment
      Greetings -

      My NSLU2 has been running lenny for some time; this morning I changed my sources.list to squeeze - ran apt-get-update and apt-get dist-upgrade. That went smoothly, except for the dependency-based services error, but I was able to correct that after the upgrade was done.

      However - as I noticed that no kernel upgrade was included in the upgrade. My currently installed kernel is: linux-image-2.6.26-2-ixp4xx

      However - as I noticed that the current version available from Debian is linux-image-2.6.32-5-ixp4xx - which is referred to by the meta-package linux-image-ixp4xx.

      So - I ran sudo apt-get install linux-image-ixp4xx - and the installation fails with the following error message:
      --------------Begin Copied Error Message-----------------

      eric@stowage:~$ sudo apt-get install linux-image-ixp4xx
      [sudo] password for eric:
      Reading package lists... Done
      Building dependency tree
      Reading state information... Done
      linux-image-ixp4xx is already the newest version.
      0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
      3 not fully installed or removed.
      After this operation, 0 B of additional disk space will be used.
      Do you want to continue [Y/n]? y
      Setting up linux-image-2.6.32-5-ixp4xx (2.6.32-30) ...
      Running depmod.
      Running update-initramfs.
      update-initramfs: Generating /boot/initrd.img-2.6.32-5-ixp4xx
      initrd.img(/boot/initrd.img-2.6.32-5-ixp4xx
      ) points to /boot/initrd.img-2.6.32-5-ixp4xx
      (/boot/initrd.img-2.6.32-5-ixp4xx) -- doing nothing at
      /var/lib/dpkg/info/linux-image-2.6.32-5-ixp4xx.postinst line 347.
      vmlinuz(/boot/vmlinuz-2.6.32-5-ixp4xx
      ) points to /boot/vmlinuz-2.6.32-5-ixp4xx
      (/boot/vmlinuz-2.6.32-5-ixp4xx) -- doing nothing at
      /var/lib/dpkg/info/linux-image-2.6.32-5-ixp4xx.postinst line 347.
      Running flash-kernel.
      /dev/mtdblock3 is not a block device
      User postinst hook script [flash-kernel] exited with value 1
      dpkg: error processing linux-image-2.6.32-5-ixp4xx (--configure):
      subprocess installed post-installation script returned error exit status 1
      configured to not write apport reports
      dpkg: dependency problems prevent
      configuration of linux-image-2.6-ixp4xx:
      linux-image-2.6-ixp4xx depends on linux-image-2.6.32-5-ixp4xx; however:
      Package linux-image-2.6.32-5-ixp4xx is not configured yet.
      dpkg: error processing linux-image-2.6-ixp4xx (--configure):
      dependency problems - leaving unconfigured
      dpkg: dependency problems prevent configuration of linux-image-ixp4xx:
      linux-image-ixp4xx depends on linux-image-2.6.32-5-ixp4xx; however:
      Package linux-image-2.6.32-5-ixp4xx is not configured yet.
      dpkg: error processing linux-image-ixp4xx (--configure):
      dependency problems - leaving unconfigured
      configured to not write apport reports
      configured to not write apport reports

      Errors were encountered while processing:
      linux-image-2.6.32-5-ixp4xx
      linux-image-2.6-ixp4xx
      linux-image-ixp4xx
      E: Sub-process /usr/bin/dpkg returned an error code (1)
      ----------End Copied Error Output-------------
      I've searched both here and on Debian's forums - but can't find any mention of this problem. For now - the device continues to boot the 2.6.26 kernel reliably - but seems to be in a broken state since it things the updated kernel package is installed.

      Thanks in advance for any suggestions!

      -Eric
    • nslu@pocketnix.org
      ... 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
      Message 2 of 4 , Feb 20, 2011
      • 0 Attachment
        On Sun, Feb 20, 2011 at 01:11:25PM -0000, e_zago wrote:
        > Greetings -
        >
        > My NSLU2 has been running lenny for some time; this morning I changed my sources.list to squeeze - ran apt-get-update and apt-get dist-upgrade. That went smoothly, except for the dependency-based services error, but I was able to correct that after the upgrade was done.
        >
        > However - as I noticed that no kernel upgrade was included in the upgrade. My currently installed kernel is: linux-image-2.6.26-2-ixp4xx
        >
        > However - as I noticed that the current version available from Debian is linux-image-2.6.32-5-ixp4xx - which is referred to by the meta-package linux-image-ixp4xx.
        >
        > So - I ran sudo apt-get install linux-image-ixp4xx - and the installation fails with the following error message:


        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 the
        error when a file is missing)
      • e_zago
        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
        Message 3 of 4 , Feb 20, 2011
        • 0 Attachment
          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)
          >
        • nslu@pocketnix.org
          ... 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
          Message 4 of 4 , Feb 20, 2011
          • 0 Attachment
            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!
          Your message has been successfully submitted and would be delivered to recipients shortly.