PDA

View Full Version : Troubleshooting a Rebooting Directv Tivo


Markman07
12-04-2006, 07:21 PM
My HR10-250 with 6.3a appears to have been rebooting lately. Yesterday at 3PM it rebooted automatically while watching football. Today I was watching a little SammY Hagar concert and the program menu would show above the show in the background when I tried to get the menu up. (using TIVO button). A few seconds later it rebooted. I am pretty good when it comes to troubleshooting a Hard drive on a PC by Event Viewer, CHKDSK, and other utilities.

With Tivo (linux) my troubleshooting skills aren't to par.

The unit is zippered and then later on sliced to 6.3a.

I checked the Kernel log files after my most recent reboot.

Jan 2 00:00:22 (none) kernel: Checking for Kickstart panic signal
Jan 2 00:00:22 (none) kernel: Running boot Stage B_PostKickstart scripts
Jan 2 00:00:22 (none) kernel: Cleanup /dev/hda9 pass 1
Jan 2 00:00:22 (none) kernel: ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda9 is mounted.^M
Jan 2 00:00:22 (none) kernel: /dev/hda9 was not cleanly unmounted, check forced.
Jan 2 00:00:22 (none) kernel: Inode 2066, i_blocks wrong 16 (counted=12). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2067, i_blocks wrong 18 (counted=4). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2053, i_blocks wrong 80 (counted=76). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2051, i_blocks wrong 544 (counted=532). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2057, i_blocks wrong 4566 (counted=4560). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2063, i_blocks wrong 192 (counted=178). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2069, i_blocks wrong 80 (counted=66). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2060, i_blocks wrong 32 (counted=28). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Inode 2058, i_blocks wrong 384 (counted=376). Set i_blocks to counted? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Entry 'tmkpidmap' in /tmp (8193) has deleted/unused inode 8223.
Jan 2 00:00:22 (none) kernel: Clear? yes
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Unattached inode 8225
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: /dev/hda9: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Jan 2 00:00:22 (none) kernel: ^I(i.e., without -a or -p options)
Jan 2 00:00:22 (none) kernel: Cleanup /dev/hda9 pass 2
Jan 2 00:00:22 (none) kernel: ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda9 is mounted.^M
Jan 2 00:00:22 (none) kernel: /dev/hda9 contains a file system with errors, check forced.
Jan 2 00:00:22 (none) kernel: Unattached inode 8225
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: /dev/hda9: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Jan 2 00:00:22 (none) kernel: ^I(i.e., without -a or -p options)
Jan 2 00:00:22 (none) kernel: Can't clean /dev/hda9 - rebuilding
Jan 2 00:00:22 (none) kernel: mke2fs 1.06, 7-Oct-96 for EXT2 FS 0.5b, 95/08/09
Jan 2 00:00:22 (none) kernel: ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda9 is mounted.^M
Jan 2 00:00:22 (none) kernel: Linux ext2 filesystem format
Jan 2 00:00:22 (none) kernel: Filesystem label=
Jan 2 00:00:22 (none) kernel: 32768 inodes, 131072 blocks
Jan 2 00:00:22 (none) kernel: 6553 blocks (5.00%) reserved for the super user
Jan 2 00:00:22 (none) kernel: First data block=1
Jan 2 00:00:22 (none) kernel: Block size=1024 (log=0)
Jan 2 00:00:22 (none) kernel: Fragment size=1024 (log=0)
Jan 2 00:00:22 (none) kernel: 16 block groups
Jan 2 00:00:22 (none) kernel: 8192 blocks per group, 8192 fragments per group
Jan 2 00:00:22 (none) kernel: 2048 inodes per group
Jan 2 00:00:22 (none) kernel: Superblock backups stored on blocks:
Jan 2 00:00:22 (none) kernel: ^I8193, 16385, 24577, 32769, 40961, 49153, 57345, 65537, 73729,
Jan 2 00:00:22 (none) kernel: ^I81921, 90113, 98305, 106497, 114689, 122881
Jan 2 00:00:22 (none) kernel:
Jan 2 00:00:22 (none) kernel: Checking for bad blocks (read-only test): 0/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H 18320/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H 36848/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H 55424/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H 73920/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H 91280/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H 108816/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H 126352/ 131072^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hdone
Jan 2 00:00:22 (none) kernel: Writing inode tables: 0/ 16^H^H^H^H^H^H^H^H^H 1/ 16^H^H^H^H^H^H^H^H^H 2/ 16^H^H^H^H^H^H^H^H^H 3/ 16^H^H^H^H^H^H^H^H^H 4/ 16^H^H^H^H^H^H^H^H^H 5/ 16^H^H^H^H^H^H^H^H^H 6/ 16^H^H^H^H^H^H^H^H^H 7/ 16^H^H^H^H^H^H^H^H^H 8/ 16^H^H^H^H^H^H^H^H^H 9/ 16^H^H^H^H^H^H^H^H^H 10/ 16^H^H^H^H^H^H^H^H^H 11/ 16^H^H^H^H^H^H^H^H^H 12/ 16^H^H^H^H^H^H^H^H^H 13/ 16^H^H^H^H^H^H^H^H^H 14/ 16^H^H^H^H^H^H^H^H^H 15/ 16^H^H^H^H^H^H^H^H^Hdone
Jan 2 00:00:22 (none) kernel: Writing superblocks and filesystem accounting information: done

I have included a small chunk of the Kernal log here. It appears to have run some disk check after the reboot and fixed a few things.

Now my question is it mentions " fsck" a few times and it says to run it manually. So is this something I can kick off using Telnet to have it test the drive? Or was it run already by the system?

Of course I can pull the drive and use Spinrite for real testing but does anyone else have any suggestions for troubleshooting system crashes in TIVO? In other words are there any commands I can use via telnet to test the integrity of the drive.

Thanks

Mark

BTUx9
12-04-2006, 07:28 PM
those messages are fairly benign...
Because the tivo doesn't use a journalled filesystem, the /var partition (partition #9) is where all the linux-ish data is written (while root stays readonly) and if the filesystem is trashed because of an ill-timed reboot, the tivo just clobbers var and recreates it from scratch

This is unlikely to be what caused your reboot