Quote:
Originally Posted by hawhill
- another partition for the user store, which is mounted to /mnt/base-us in normal use which is again mounted as /mnt/us (using a passthrough filesystem that's able to "cut" the bounds to the underlying file system when it needs to be accessed via USB)
- another partition for the kernel, I think
- another partition for bootloader "environment", i.e. configuration variables.
The latter don't carry filesystems. The root file system is ext2, I think, might also been ext3. The user store is VFAT.
|
As described in the kernel messages:
Quote:
|
Originally Posted by Post 31
INFO:Partition table verified for /dev/mmcblk0
INFO:Checking for updates... (auto-pilot mode)
dev/mmcblk0p4:
- - - Finds media holding FAT file system image - - -
- - - The "offset" is to skip the reserved MBR / Partition area - - -
INFO:Setup loop device /dev/loop0 for /dev/mmcblk0p4 + 8192
- - - A.K.A: USB Storage to user, /mnt/us to system once booted - - -
INFO:No update*.bin found; no update needed.
- - - That is one way to get out of this problem - - -
- - - See later messages cut from a different boot attempt - - -
|
and later:
Quote:
|
Originally Posted by Post 33
kinit: do_mounts
kinit: name_to_dev_t(/dev/mmcblk0p1) = dev(179,1)
kinit: root_dev = dev(179,1)
kinit: failed to identify filesystem /dev/root, trying all
- - - This will become "/" once system is booted - - -
kinit: Unable to mount root fs on device dev(179,1)
- - - Kernel should have panic'd here, can't run without a root filesystem - - -
Checking for init: /sbin/init
Checking for init: /bin/init
Checking for init: /etc/init
Checking for init: /sbin/init.sysvinit
Checking for init: /bin/sh
kinit: init not found!
- - - Actually a bit misleading previous error is the problem - - -
- - - No valid file system on /dev/mmcblk0p1 - - -
- - - Error when trying to re-load mmcblk0p1 likely cause - - -
Kernel panic - not syncing: Attempted to kill init!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = cfab0000
|
The kernel initialization messages try their best to tell what is happening, but it still takes some experience to understand what they have to say.
If unable to put an update*.bin file on the user store to fix the main system image, then the next thing to try is to load over the serial port a kernel+initramfs that can run memory resident and re-load mmcblk0p1 with the root file system for you.
I am not sure if anyone has made such a serial port loadable image for the K3 - it will take YOU some research to learn if it exists.