#10019 NORM Not Tri: Activity Won't Start If EXT3 SD Card is Mounted at Boot-Up

[Zarro Boogs per Child]

#10019: Activity Won't Start If EXT3 SD Card is Mounted at Boot-Up
------------------------------------+---------------------------------------
           Reporter:  gypsymoth     |       Owner:               
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  Not Triaged  
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  never set     |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by mikus):

 * cc: mikus (added)


Comment:

 I believe the problem you have is that the SD with the EXT3 filesystem is
 messed up -- such that if it is present when you boot the XO, the boot
 process itself program checks.  The question then becomes - how to access
 that SD card without crashing the system.  I'm hoping that if you bring up
 the system without the SD card, and only insert that SD card once you have
 a command line - that the system will not crash when you do insert the
 card.  [The concern is that the system will look at that SD card to try to
 auto-mount its partitions.  I'm hoping that the auto-mount will give up -
 without taking down the system.  [I don't know how to disable auto-
 mounting.]

 Assuming you have a command line:  [I don't bother with 'sudo' for each
 privileged command - on the OLPC I issue 'su', and from then on all
 commands are run as user "root".]

   Note:  all data already on the SD card wil be lost

   If the SD card is in the slot in the OLPC, its device name will be
 /dev/mmcblk0.  [If you are doing this on another Linux system, the device
 name will likely be /dev/sd something.]

   Note:  If the auto-mount did succeed, you need to 'umount
 /dev/mmcblk0p1'

   I myself use the command 'cfdisk -z /dev/mmcblk0'.  That tells the
 program to ignore whatever is on the SD card now, and to assume an empty
 partition table instead.  Choose the 'Write' option to have that empty
 partition table written onto the SD card.  [I don't know what to do if the
 write does not work - for me the write *does* work, even if it says it had
 problems.]  'Quit' from the cfdisk program.

   Continue by defining the partitions on the SD card:  you could use
 cfdisk again - I prefer the command line, so I now issue 'fdisk
 /dev/mmcblk0'.  The program should show an empty partition table (as
 written by the initial use of the cfdisk program).  Use the 'n' subcommand
 (and following) to define the partition(s) you will use.  [You might have
 to use 't' to set the partition's type (e.g., if the partition is for
 swap).]  Use 'w' to write out the filled-in partition table you created.

   Then use 'mkfs' to create+format the filesystem on the (type 83)
 partition you defined in the preceding paragraph.  [As I said earlier, it
 is not a good idea to have an EXT3 filesystem on an SD card.]

 [[BR]]
 > /dev/mmcblk0p1 * 1 463 3719016 b W95 FAT32 [[BR]]
 > /dev/mmcblk0p2 464 491 224910 5 Extended   [[BR]]
 > /dev/mmcblk0p5 464 491 224878+ 82 Linux swap / Solaris

 I did not realize that you would have problems running 'fdisk' against the
 card with the bad EXT3 filesystem.  What you show above is a perfectly
 *normal* card, without any Linux-data filesystems on it (they would show
 up as '83').  If *this* is the card that causes the OLPC to crash, I
 myself can't understand why kjournald would be looking for EXT3
 filesystems on such a card.]

 [[BR]]By the way, if you do create an additional Linux-swap (type 82)
 partition on that card, it too needs formatting.  Do that with 'mkswap
 /dev/mmcblk0p5' (5 or whatever that partition's number is) before trying
 to boot with that card already inserted.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10019#comment:6>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system