Building S2 Drive with Large Root Partitions, killhdinitrd'd kernel & ext3 support

[fantmn]

First let me say thanks to everyone that post all the great information here.
Also sorry for the long post, but I wanted to try and be complete. I want to try and save a few brain cells by asking for y'all to comment before I head off down a merry path that is doomed to failure.

After much reading and quite a bit of testing I now have 4 S2 RCA DTivos hacked and running very nicely thanks to the info here. On a couple of the Tivos the root disk partition is getting nearly full. df -h yields:

Filesystem Size Used Avail Capacity Mounted on
/dev/hda4 124M 107M 11M 91% /
/dev/hda9 124M 17M 101M 14% /var

I have looked around but cannot find any "extra" stuff laying around on hda4, but I am sure it must be there somewhere.

What I would like to do is build a new disk with a much larger hda4 and hda7. I want to use hda7 as the last good working image as I continue to hack so I have a easy recover point. So I want both partitions to be the same size to make dd easy. I found several threads one is here that seem to get me close.

If there is a better place to look please point me there. I have used the search button and have googled with the site: parm (and without it) and have arrived here.

I have AlphaWolfs small 6.2 image to use as a seed point.
I do not have the cabling required to add a second drive in a tivo to use the tools from the bash prompt.
My PC I am using to hack with has SuSE SLES 9 SP2 loaded. I also have the PTVUpgrade $5 CD with the killhdinitrd kernels. I also downloaded tivopart (May 2004 version).

EDIT: CHANGED PLAN to reflect what I did:

Rather than increasing the root partitions I increased partition 5 to hold stuff as recommended by Jamie)

So my plan is: (assume disk are moved into the hacking PC as needed)
1. mfsrestore -s 2560 -xpi /image/62small.mfs /dev/hdx
This should give me plenty of room for increasing partition 5.
2. Use pdisk -i to delete and create partitions 5-8. [Edited to reflect Jamie's Comments]
This also assumes that the 3/4 pair is the active partitions. You will need to modify this if 6/7 is active.

pdisk -i
e
d 8
d 7
d 6
d 5
C 5p 2048M "Work Area" Ext3
C 6p 4M "Kernel 2" Image
C 7p 128M "Root 2" Ext2
C 8p 1048575 "Linux swap" Swap <<---Use number of remaining blocks, you may need to do a p to determine value in free
p
w
y

3. dd the kernel into /dev/hda6
4. mk2efs /dev/hdx7
** edit ** just dd if=/dev/hdx4 of=/dev/hdx7 rather than 5. Assuming the mke2fs works ok, then I will mount the root partition from my currently hacked tivo at /hacked and use the command
cp -rfpd /hacked /mnt/hdx4
to copy all the hacked root file system from my currently working unit ***end edit***

6. Install new drive in Tivo and boot. I expect to find a working unit with no recording on it. I also expect the networking to work but since the network setting are stored in MFS somewhere I will have to run the network setup scripts and the network name script (I don't have the names handy, but know where to find them).

Somewhere along the way before I remove the drive from the Tivo I plan on using MRV to copy all the recorded shows to one of the other units.
That way if I really blow it I still have a happy family.

If all this works I should end up with a drive with a partition for hacks. MFSBACKUP WILL NOT BACKUP the large partition 5

So what have I messed and where should I look to find the rest of the answers.

After I get the "test" drive up and running I plan on modifying all 4 units. So any tips on replicating the units are welcomed. I think I read PlainBills comments that for multiple units he just repeats the process on each one. That is what I did to hack the units the first time and it was not all bad. I was thinking maybe a mfssave with a small mfs partition might work as a seed as well.

Thanks for taking the time to read and I hope comment.

==== Update ====

Based on input later in the thread I change the layout of the partitions.
I set up a 2GB work area space in ext3 format. The root partitions are still set to the standard size.
I left partitions 1-4 untouched.
Also note the mfsbackup and mfsrestore will not backup the stuff in workarea. I have not tryed -T option on the mfsbackup
Other standard hacking techniques apply.
More updates will follow.

Fant

[Jamie]

I have looked around but cannot find any "extra" stuff laying around on hda4, but I am sure it must be there somewhere.

128MB should be enough unless you are doing something unusually, like running debian-mips. I doubt you really need a larger root file system.

Run e2fsck on your root file system to recover any space tied up in orphaned inodes (files that were deleted while opened, followed by an unclean reboot). Remove any extra backup tivoapps in /tvbin. "cd /; du -sx * | sort -n" is a good way to find out where your space is tied up.

[fantmn]

Jamie, Thanks for the quick reply.
I ran the following:cd / then du -sxb *|sort -rn and got the summary list. I compared the output to one of the others sitting at 76% and it looked similar. So I am concluding that I do indeed have orphaned inodes. I did a e2fsck on /dev/hda4 (the current root file system) get the message:

/dev/hda4 is mounted. Do you really want to continue (y/n)? no

From my past Linux experience the answer is alway no. So I did a e2fsck -n /dev/hda4 to open the filesystem read only. Get a list of several Deleted inodes has zero dtime and then a large list of inodes. The list goes really fast and piping through more does not stop the list. I assume this is a list of orphans. In my regular Linux environment I would change to run level 1 unmount /dev/hda4 and do the e2fsck then. I did some searching for how to run e2fsck on a tivo but did not find anything so I figure it most be so obvious it does not need to be said and I am just dull. Only thing I can think of other than removing the drive and doing it on the PC is to dd it over to hda7 change everything up, boot from hda7 and then run e2fsck on hda4. There has got to be an easier way.

As to why a big root partition, well, I like to have space to experiment around and when the drive is 400 GB I figure I can spare a couple of Gig for fun. Maybe throw some web pages up there and other things. Also play around with some scripts etc. who knows maybe pop up a samba server. (I don't think so, but you never know ) And beside it looks like a good way to learn more about the environment too.

I started a low level format of a maxtor drive I have laying around to start the build too.

Thanks,
Fant

[Jamie]

Jamie, Thanks for the quick reply.
I ran the following:cd / then du -sxb *|sort -rn and got the summary list. I compared the output to one of the others sitting at 76% and it looked similar. So I am concluding that I do indeed have orphaned inodes. I did a e2fsck on /dev/hda4 (the current root file system) get the message:
From my past Linux experience the answer is alway no. So I did a e2fsck -n /dev/hda4 to open the filesystem read only.

You should not be running with a rw root. That's almost certain to cause orphan inodes. Remount readonly "mount -o remount,ro /dev/hda4" and e2fsck won't complain about the file system being mounted.

If you insist on a rw root, you should either run e2fsck on it in your startup scripts before mount rw, or switch to a journalled file system such as ext3. ext3 can be a tricky since none of the killhdinitrd compatible kernels include ext3 support. On a PROM mod'd box where you can boot the custom kernel directly, a root ext3 may be a good choice.

I prefer to use another partition for my working area. 1,2 or 5 are good choices. One way to setup a tivo with a large working partition is to use tivopart.

[fantmn]

OK, So I remounted ro and ran e2fsck -fp /dev/hda4 now usage is down to 46%. So that is much better. I did find backup_run.sh script in /var/hack/tivowebplus that does a backup of seasonspass to /seasonpass_backups. So that must be why root was mounted as rw. I changed the script to do a remount to rw, run the backup, then remount ro. This should leave root mounted ro most of the time and limit the exposure. backup_run.sh now looks like this:

mount -o remount,rw /
mkdir /seasonpass_backups &>/dev/null
export TIVOSH_POOLSIZE=3244032
tivosh backup_write_static.tcl $1 >&/dev/null
mv /seasonpass_backups/backup /seasonpass_backups/backup.$(date +\%m\%d_\%H:\%M)
mount -o remount,ro /

I used the mount point / in the remount so that it is device independent.
I'll give the tivopart a try and see if I can get it to work for me. So it if I understand what I have read, with the killhdinitrd method I should keep the tivo OS and all the stuff for that in /dev/hda3 (kernel) and /dev/hda4 (root) then just build a nice big work area on /dev/hda5 as an example. After I get that done I will move the /seasonpass_backups dir to the mount point on /dev/hda5.

Thanks again for the help,
Fant

[Jamie]

OK, So I remounted ro and ran e2fsck -fp /dev/hda4 now usage is down to 46%. So that is much better. I did find backup_run.sh script in /var/hack/tivowebplus that does a backup of seasonspass to /seasonpass_backups. So that must be why root was mounted as rw. I changed the script to do a remount to rw, run the backup, then remount ro. This should leave root mounted ro most of the time and limit the exposure. backup_run.sh now looks like this:

I used the mount point / in the remount so that it is device independent.
I'll give the tivopart a try and see if I can get it to work for me. So it if I understand what I have read, with the killhdinitrd method I should keep the tivo OS and all the stuff for that in /dev/hda3 (kernel) and /dev/hda4 (root) then just build a nice big work area on /dev/hda5 as an example. After I get that done I will move the /seasonpass_backups dir to the mount point on /dev/hda5.

Thanks again for the help,
Fant

tivopart is setup to create a large hda1. Since that's normally the slot used for the partition table, I prefer to use hda2. It's basically the same process you described earlier.

If you use an ext3 file system on this partition, you don't have to worry about unclean reboots leaving orphans or corupting the file system. Since it isn't the root filesystem, you don't have to worry about your initial kernel not having ext3 support -- you only will mount it after you've monte'd to an ext3 aware kernel or loaded the ext3.o kernel module.

[fantmn]

I like the idea of using ext3 on the "test/work" partition, but after searching I have not be able to locate an ext3.o kernel module for tivo S2. Any pointer or I am going to have to figure out how to build one. If so I will have to go find the cross compiler threads and look at the developer threads. If anyone has a ext3.o module that they would share, it would be very helpful.

Thanks

[Jamie]

I like the idea of using ext3 on the "test/work" partition, but after searching I have not be able to locate an ext3.o kernel module for tivo S2. Any pointer or I am going to have to figure out how to build one. If so I will have to go find the cross compiler threads and look at the developer threads. If anyone has a ext3.o module that they would share, it would be very helpful.

I always build it directly into the custom kernels I use. Shouldn't be hard to tweak the .config to build it as a module though. I'll do that, when I get a chance. If you want to try yourself, try starting here.

Edit: here it is. You'll want the modified e2fsprogs too, as the tivo versions will choke on ext3. I recommend you backup the original tivo versions in /sbin and replace them with the ones from this package.

[fantmn]

Well, I got the new test drive built and running. I have a 512M swap and a 2G work area on hda9. I did the build of the ext3 filesystem on the hack PC before I moved the drive. I then tryed the insmod ext3.o and got the following:

BedRoom-bash /lib/modules # insmod ext3.o
ext3.o: unresolved symbol journal_init_inode
ext3.o: unresolved symbol journal_init_dev
ext3.o: unresolved symbol journal_force_commit
ext3.o: unresolved symbol journal_create
ext3.o: unresolved symbol journal_dirty_data
ext3.o: unresolved symbol journal_flushpage
ext3.o: unresolved symbol log_wait_commit
ext3.o: unresolved symbol journal_restart
ext3.o: unresolved symbol journal_extend
ext3.o: unresolved symbol log_start_commit
ext3.o: unresolved symbol journal_update_format
ext3.o: unresolved symbol journal_get_undo_access
ext3.o: unresolved symbol journal_lock_updates
ext3.o: unresolved symbol journal_errno
ext3.o: unresolved symbol journal_flush
ext3.o: unresolved symbol journal_start
ext3.o: unresolved symbol journal_blocks_per_page
ext3.o: unresolved symbol journal_abort
ext3.o: unresolved symbol journal_clear_err
ext3.o: unresolved symbol journal_destroy
ext3.o: unresolved symbol journal_check_available_features
ext3.o: unresolved symbol journal_load
ext3.o: unresolved symbol journal_get_write_access
ext3.o: unresolved symbol journal_revoke
ext3.o: unresolved symbol journal_get_create_access
ext3.o: unresolved symbol journal_try_to_free_buffers
ext3.o: unresolved symbol journal_try_start
ext3.o: unresolved symbol journal_stop
ext3.o: unresolved symbol journal_wipe
ext3.o: unresolved symbol journal_unlock_updates
ext3.o: unresolved symbol journal_forget
ext3.o: unresolved symbol journal_dirty_metadata

I am guessing a missing library or maybe I need a static module.
Thanks again for the help.

[Jamie]

Well, I got the new test drive built and running. I have a 512M swap and a 2G work area on hda9. I did the build of the ext3 filesystem on the hack PC before I moved the drive. I then tryed the insmod ext3.o and got the following:


I am guessing a missing library or maybe I need a static module.
Thanks again for the help.

My bad. I forgot that the ext3.o module now depends on jbd.o. I'll updated the attachment above to include it. You need to insmod jbd.o before ext3.o. As I said, I always build these into the kernels I use.

[fantmn]

Got the mods loaded and mounted /dev/dha5 on /work. cd /work and ls showed lost+found. I did a touch test1 and at that point it just kind of locks up and never responds. ps shows the touch still out there. kill will not kill it. If I start another telnet session I can do other things but reboot will not reboot. unplug / replug (power on reset is required). I'll play around a little more to see if I can find the problem.
Right now it looks like a monte into a new kernel with ext3 support might me a good idea or maybe the partition (2GB) is too big.
Thanks for the help. I am learning a lot. I think I might need to buy one more tivo just to play with.

[Jamie]

Got the mods loaded and mounted /dev/dha5 on /work. cd /work and ls showed lost+found. I did a touch test1 and at that point it just kind of locks up and never responds. ps shows the touch still out there. kill will not kill it. If I start another telnet session I can do other things but reboot will not reboot. unplug / replug (power on reset is required). I'll play around a little more to see if I can find the problem.
Right now it looks like a monte into a new kernel with ext3 support might me a good idea or maybe the partition (2GB) is too big.
Thanks for the help. I am learning a lot. I think I might need to buy one more tivo just to play with.

Sorry. I built those as a one-off and didn't test them. A partition >2GB should not be a problem, so maybe something is wrong with the modules I built. I built them from the 7.2 sources using gcc 3.3.4. It's possible they don't get along with the kernel you are using.

[cheer]

My bad. I forgot that the ext3.o module now depends on jbd.o. I'll updated the attachment above to include it. You need to insmod jbd.o before ext3.o. As I said, I always build these into the kernels I use.

Jamie:

Can I take that to mean that the custom kernel you have floating around (with network tweaks) has ext3 support built in?

[Jamie]

Jamie:

Can I take that to mean that the custom kernel you have floating around (with network tweaks) has ext3 support built in?

The kernels I've built lately do. Older ones may not. I believe I always state what I included in the post with the kernel. If you are running the kernel, I think you can check by looking in /proc/filesystems.

[cheer]

Thanks...what little *nix background I have is from actual Unix; I always forget about /proc.