PDA

View Full Version : tivopart repartitioning tool + pdisk (was: Repartitioning to make a bigger hda7)



alldeadhomiez
06-16-2003, 01:09 AM
Updated 2004/05/30: new version posted here as tivopart-20040530.zip; release notes are posted at the end of the thread. The information on tivopart in this post is preserved for historical reasons but is (fortunately) not the way it works anymore.

Edit 2004/11/11: Here (http://www.dealdatabase.com/forum/showthread.php?p=187388&highlight=bootpage#post187388) is a link to the least annoying x86/multiplatform port of bootpage I am aware of.

---

Enclosed please find an archive containing two ready-to-use files plus source code:

minimal_31u5_root.img is a very minimal root partition that contains (AFAIK) only the files necessary to execute the BASH_ENV hack and mount an alternate root partition. This reduces the amount of checking that the initrd needs to do from roughly 36 megs to about 3.3, and has a noticeable impact on the speed of the boot process. This file is split into two pieces because of forum rules, so please reassemble it with 'cat'.

tivopart is a special-purpose repartitioning tool derived from the pdisk sources (included). It is designed to reduce hda4 to 4 megs so that it is just large enough to accommodate the minimal root image, create a 128 meg swap partition, and dedicate the rest of the space to hda7 (your new root). I have provided a(n incomplete) sample script, install.sh, which attempts to implement this configuration:



* original layout:
*
* hda3: 4096 ( 2M) Kernel 1
* hda4: 262144 (128M) Root 1
* hda5: 1 ( 512) Bootstrap 2
* hda6: 8192 ( 4M) Kernel 2
* hda7: 262144 (128M) Root 2
* hda8: ?????? (????) Linux swap (varies)
*
* new layout:
*
* hda3: 4096 ( 2M) Kernel 1 (signed but compromised kernel)
* hda4: 8192 ( 4M) Root 1 (decoy root to satisfy initrd checks)
* hda5: 1 ( 512) Bootstrap 2
* hda6: 8192 ( 4M) Kernel 2 (unsigned, monteable kernel)
* hda7: ?????? (????) Root 2 (uses all leftover space, >=64MB)
* hda8: 262144 (128M) Linux swap


If you like how this looks, the script works although there are a few files you will need to fill in. Please do not PM me asking for them.

Since mfsrestore does not allow you to specify the desired size for hda7, you may instead use "-s" to specify a larger swap space and then use tivopart to donate that space to hda7. This allows you to reserve extra room on / (even a gig or two if you need it) to install your favorite Linux distro, build kernels, set up a warez server, etc. At the very least you will have an easy way to store the monte code, a "hacks" boot script, and one or more alternative kernels on hda7.

tivopart does not back up or restore data. You will need to make a copy of your root partition, run tivopart, mke2fs the partition again, and restore the TiVo software in order to make your unit bootable. It is trivial to write a script that does this. (tivopart includes a "test" command that can be used to verify that the kernel has updated its internal copy of the disklabel, and I encourage you to use it to avoid extraneous rebooting or random failures.)

THIS SOFTWARE IS A PARTITIONING TOOL. IT CAN CAUSE DATA LOSS AND IS OFFERED WITH NO WARRANTY. Please keep recent backups of any important data on any drive that you touch with this thing. MFS and streams should not be affected but that is NOT a guarantee; anything can happen when you rewrite your partition table. The "undo" command is not foolproof.

Good luck, and please post your experiences here.

alldeadhomiez
06-16-2003, 01:10 AM
.

mrblack51
06-16-2003, 01:26 AM
thanks alldeadhomiez. i was thinking about doing exactly that...well sortof. i was planning on figuring out the minimal fileset for doing bash_env -> monte, but looks like you beat me to it. nice job

Hamsterman
06-19-2003, 02:02 AM
Hey, great work. Not only did you come up with the minimum set of files, and a customized pdisk, but also how to mount an ext2 partition using the BASH_ENV hack. I wasn't able to get the BASH_ENV hack to mount an ext2 partition before, but then I didn't try to mount it read-only, either (-n -oro). I had assumed, obviously incorrectly, that the -n parameter couldn't be used. That's what I get for reading the manuals...

Minimizing the boot time is also a good thing.

A few questions, if I may:

1. I take it that the 'test' command is akin to rebooting after using pdisk, only without the need to reboot? cool.

2. A while ago, I couldn't get the U5 kernel I took from Kernel 2 to boot from Kernel 1, after expanding the Kernel 1 partition to 4M using pdisk. However, I notice that you keep the Kernel 1 partition as 2M rather than enlarge it to 4M. I take it then that a U5 kernel image from the Kernel 2 partition can be partially copied over and still be acceptable to the PROM?

3. While this may be more appropriate in the 2 kernel monte thread, when the next software update comes, which set of partitions will it clobber?

The reason I ask #3 is that if enough U5 root is left to run the software update code, and most of the interesting modifications are done on another partition, then with a little bit of coding it would be possible to (manually) allow software updates without being unreasonably inconvenienced.

ie. make a reasonable sized ext2 on hda16, mount it to /mnt for the monte, create a /hack directory in the hda7 root partition and then mount hda16 to /hack in rc_sysinit after the monte. Then all 'nonstandard' files can go in /hack.

When a software update is available, by swapping the boot code ('chain', in your case) with a modified version of U5's software update code, the new version could be loaded, patched, etc, the /hack directory added, change rc.sysinit, fix the bootpage (or prevent it from being changed), and reboot.

Hamsterman

mrblack51
06-19-2003, 02:14 AM
Originally posted by Hamsterman
2. A while ago, I couldn't get the U5 kernel I took from Kernel 2 to boot from Kernel 1, after expanding the Kernel 1 partition to 4M using pdisk. However, I notice that you keep the Kernel 1 partition as 2M rather than enlarge it to 4M. I take it then that a U5 kernel image from the Kernel 2 partition can be partially copied over and still be acceptable to the PROM?

all tivo kernels are only 2M in size so far

alldeadhomiez
06-19-2003, 12:36 PM
Originally posted by Hamsterman
Hey, great work. Not only did you come up with the minimum set of files, and a customized pdisk, but also how to mount an ext2 partition using the BASH_ENV hack. I wasn't able to get the BASH_ENV hack to mount an ext2 partition before, but then I didn't try to mount it read-only, either (-n -oro). I had assumed, obviously incorrectly, that the -n parameter couldn't be used. That's what I get for reading the manuals...

I believe -n is necessary but -o ro is not. But -o ro is a pretty good idea, especially because the system will probably want to update atimes right before the equivalent of 'reboot -f' (monte).


1. I take it that the 'test' command is akin to rebooting after using pdisk, only without the need to reboot? cool.

Actually pdisk calls an ioctl to do this. The test command is just there for paranoia, because that ioctl usually fails if anything on the same physical drive is mounted. I really didn't want the script to keep going without verifying that the new partition boundaries were properly recognized by the kernel, because that would fail silently and waste a lot of the user's time.


3. While this may be more appropriate in the 2 kernel monte thread, when the next software update comes, which set of partitions will it clobber?

hda3 and hda4. :(

The scripts could be reworked to allow hda[34] to be used for software upgrades but I have not done so.

Making such a "transparent monte" setup would be beneficial for some users, but I have designed these scripts to accomodate a heavily customized installation, which pretty much means that upgrades are going to have to be done by hand anyway. Admittedly, keeping the inactive root and kernel partitions open might make this process easier too.

roach
10-14-2003, 12:18 AM
I'm trying to use this minimal filesystem with my (monte'd) machine. I cat the files together getting a ~4MB file. I dd this file to my tivo drive in the proper partition, but I get no love. The screen shows the Welcome... splash screen and I see the console goes through checks the kernel says its signed, but never gets any farther. As soon as I dd the full filesystem ~128MB back it works fine. Has anyone had success using this minimal filesystem? Do I need to go through the whole re-partitioning deal (I'm not worried about space, just like to boost the startup time if possible)?

Lost Dog
10-18-2003, 06:18 PM
Ok... Stupid, stupid, stupid newbie questions...

I feel like such a tool for even asking...

I'm trying to monte my system... The minimal root in this thread is in two pieces. To join them I'd:

cat part1 part2 > joinedfile

Is this correct? I could then use this resulting image for the u5 root for the monte?

I've tried this and am stuck on boot so I think I'll give it a shot again.

Thanks...

alldeadhomiez
10-28-2003, 10:25 PM
Contents of README.tivopart, 2003/10/28 posting:


Posting date: 2003/10/28

This is the README for the tivopart archive.

This archive contains the following source code:

- a slightly modified version of pdisk, adapted to work with the TiVo
"0x1492" partition tables

- the "tivopart" utility, an easy-to-use tool that repartitions your
TiVo hard drive in a fashion suitable for a monte setup

- the "lba48chk" utility, which allows your startup scripts to detect
if you are running a non-LBA48 kernel but your disk contains partitions
that extend past the LBA28 mark

- the "getkey" utility, a simple tool that allows your startup scripts to
solicit a keypress from the user at startup

- the "cvt_pt" utility, a partition type converter. I have never used it
but it came with pdisk so it was included for completeness

This archive also contains IA32, MIPS, and PPC binaries for all of these
programs, with the exception of tivopart for PPC. None have been heavily
tested but they worked for me.

Usage notes: pdisk / cvt_pt

pdisk documentation is included in the src/ directory.

I did not write it so I will not attempt to document it.

Usage notes: tivopart

tivopart has three main functions:

c[onsolidate]:

This operation has been completely changed, and the "unconsolidate"
option is no longer available.

(from src/tivopart.c)

/* consolidate(): rearranges the partition layout
*
* original layout:
*
* hda1: 63 ( 32K) Apple (partition map)
* hda2: 4096 ( 2M) Bootstrap 1
* hda3: 4096 ( 2M) Kernel 1
* hda4: 262144 (128M) Root 1
* hda5: 1 ( 512) Bootstrap 2
* hda6: 8192 ( 4M) Kernel 2
* hda7: 262144 (128M) Root 2
* hda8: ?????? (????) Linux swap (varies)
* ...
* hda?: ?????? (????) Extra
*
* new layout:
*
* hda1: 63 ( 32K) Apple (partition map)
* hda2: 4096 ( 2M) Decoy kernel (signed but compromised kernel)
* hda3: 4096 ( 2M) Kernel 1
* hda4: 262144 (128M) Root 1
* hda5: 8192 ( 4M) Decoy root (decoy root to satisfy initrd checks)
* hda6: 8192 ( 4M) Kernel 2
* hda7: 262144 (128M) Root 2
* hda8: ?????? (????) Linux swap (custom size)
* hda?: ?????? (????) Main root (the root fs that actually boots)
*
* by varying the size of the -s parameter to mfsrestore, the amount of
* free space in the user's custom root partition may be increased
*/

The idea is to use the "-s" switch in mfstools to allocate a swap
area that is much larger than what you really need, and then carve
a root partition (hda14/hda16) out of the extra space. For instance,
I typically ask mfstools for 2048 megs of swap, and then have tivopart
allocate 1920 megs or so to hda16 and 128 to swap.

On a monte setup, I use the minimal root filesystem to satisfy the
initrd, placing the small root in hda5 and the 3.1U5 kernel in hda2.
The BASH_ENV variable in the kernel command line is updated to
contain commands to mount /dev/hda1[46] and execute a small startup
script on that partition.

The minimal root filesystem can be found here:

http://www.dealdatabase.com/forum/showthread.php?s=&threadid=25219

You will need to initialize the following partitions by hand or by script
after repartitioning (tivopart does not preserve the data in them):

hda2, hda5 (monte only)
hda4/hda3 or hda7/hda6: active root and kernel partitions
hda8: swap
hda14/hda16: new root filesystem

d[ump]:

This dumps the current partition layout to standard output.

r[evalidate]:

This uses the "blkpg" functions in modern (2.4) Linux kernels to
update the in-memory partition table with the contents of the on-disk
partition table. Obviously this does not involve writing anything to
the disk.

THIS SHOULD ONLY BE USED ON DRIVES THAT CONTAIN A TIVO PARTITION TABLE.

With this feature you can write a new partition table to your TiVo
drive (with mfstools, tivopart, pdisk, or something else) and then
immediately ask the kernel to revalidate it without rebooting.

This implies that you no longer need to patch the kernel on your desktop
PC to recognize a TiVo partition table, as you can use tivopart to
dynamically adjust the in-memory partition table after you have booted.
However if you are dealing with an S1 drive you will still need to
install the byteswap patch to mount TiVo partitions.

The blkpg ioctls will NOT revalidate any partitions that are mounted or
in use. However, they will gracefully skip over in-use partitions and
revalidate the rest of them, unlike the old BLKRRPART interface.

Usage notes: lba48chk

(snipped here because of message size limit)

Hamsterman
11-05-2003, 01:52 AM
First, thanks again for all your work.

I remember reading that the PROM will only allow hda3 or hda6 to be the kernel boot partitions. Also, that a kernel can only mount and run a root on hda1 thru hda9. The BASH_ENV hack which runs a script on hda14 or hda16 is run when BASH is run from a root on hda1 thru hda9.

If you've gotten this hda2 kernel/hda16 root setup to work, then I'd say both my preconceptions are wrong. In that case, I'd recommend resizing hda3 to 4M since a future kernel could grow that large, breaking the setup and requiring a repartition. It also begs the question as to how to get the PROM to look at hda2.

Otherwise, putting the U5 (or 3.0) kernel in hda2 will have no effect, and the Main root could not be booted from a monte'd kernel. However, I think an effective partition would look like:

* hda1: 63 ( 32K) Apple (partition map)
* hda2: 8192 ( 4M) Decoy root (decoy root to satisfy initrd checks)
* hda3: 4096 ( 2M) Kernel 1 (signed but compromised kernel)
* hda4: 262144 (128M) Root 1
* hda5: ?????? (????) Main root (the root fs that actually boots)
* hda6: 8192 ( 4M) Kernel 2 (only kernel that can be updated)
* hda7: 262144 (128M) Root 2
* hda8: ?????? (????) Linux swap (custom size)

While I modified your old tivopart.c source code to do this, I couldn't get it to compile right (couldn't find some .h files. Operator headspace error, I'm sure.) I was able to manually use pdisk, but so far I'm still figuring out how to get the Main root to boot. I followed Embeem's S1 example, but was confused about his piping stuff to /var/logs when /var isn't mounted yet. At least I'm learning how a Linux system boots...

Hamsterman

alldeadhomiez
11-05-2003, 01:10 PM
Originally posted by Hamsterman
I remember reading that the PROM will only allow hda3 or hda6 to be the kernel boot partitions. Also, that a kernel can only mount and run a root on hda1 thru hda9. The BASH_ENV hack which runs a script on hda14 or hda16 is run when BASH is run from a root on hda1 thru hda9.

If you've gotten this hda2 kernel/hda16 root setup to work, then I'd say both my preconceptions are wrong.

A few days ago I took a new unit out of the box (virgin unsocketed PROM) and reimaged it this way. Here is a snippet from the current bootpage:


0000000: 1492 0203 726f 6f74 3d2f 6465 762f 6864 ....root=/dev/hd
0000010: 6135 2063 6f6e 736f 6c65 3d32 2c31 3135 a5 console=2,115
0000020: 3230 3020 6473 7363 6f6e 3d74 7275 6520 200 dsscon=true
0000030: 4241 5348 5f45 4e56 3d60 6d6f 756e 7424 BASH_ENV=`mount$
0000040: 4946 532d 6e24 4946 532d 6f72 6f24 4946 IFS-n$IFS-oro$IF
0000050: 532f 6465 762f 6864 6131 3624 4946 532f S/dev/hda16$IFS/
0000060: 6d6e 743b 6563 686f 2449 4653 2f6d 6e74 mnt;echo$IFS/mnt
0000070: 2f62 6f6f 742f 7374 6167 6531 6000 0000 /boot/stage1`...

As you can see, the active (decoy) root is hda5 and the active (3.1U5) kernel is hda2. hda5 contains a minimal root filesystem which obviously has all of the device nodes, and the initrd in the hda2 kernel image has the required hda5 device node.

There is nothing in hda3 or hda6 (I have zeroed them out and the unit still boots).


In that case, I'd recommend resizing hda3 to 4M since a future kernel could grow that large, breaking the setup and requiring a repartition.

If TiVo is shipping boxes with 3.1.1 on hda6/hda7, they will not be able to easily send down a kernel image that is >2M anyway because hda3 out of the box is only 2M. They could take a chunk out of hda4 but I just don't forsee that happening.

But you're always welcome to post a patch...


It also begs the question as to how to get the PROM to look at hda2.

In the "81dc0000 section" (see my post on the prom), around 81dc17c4, I see it inspecting the partition numbers and setting vars to the boot and alternate partitions. However it does not seem to be checking to make sure these numbers are 3 or 6, and I have never had trouble booting off hda2. I think these variables are just for the prom service menu but I was not able to quickly find where they are referenced again.

There are some constraints on the kernel partition you are allowed to use, but I did not take the time to track down the prom code that caused the problem. For instance, when I tried to use hda16, the PROM complained that the 'RPO' signature was missing, so either it was overriding the partition number (ORing it with 0x0f??) or it was misreading the disklabel. The sector numbers were reasonably small so it was not an LBA28 issue or anything.


Otherwise, putting the U5 (or 3.0) kernel in hda2 will have no effect, and the Main root could not be booted from a monte'd kernel. However, I think an effective partition would look like:

* hda1: 63 ( 32K) Apple (partition map)
* hda2: 8192 ( 4M) Decoy root (decoy root to satisfy initrd checks)
* hda3: 4096 ( 2M) Kernel 1 (signed but compromised kernel)
* hda4: 262144 (128M) Root 1
* hda5: ?????? (????) Main root (the root fs that actually boots)
* hda6: 8192 ( 4M) Kernel 2 (only kernel that can be updated)
* hda7: 262144 (128M) Root 2
* hda8: ?????? (????) Linux swap (custom size)

While I modified your old tivopart.c source code to do this, I couldn't get it to compile right (couldn't find some .h files. Operator headspace error, I'm sure.) I was able to manually use pdisk, but so far I'm still figuring out how to get the Main root to boot. I followed Embeem's S1 example, but was confused about his piping stuff to /var/logs when /var isn't mounted yet. At least I'm learning how a Linux system boots...

In my case I just pass the main root parameter on the monte'd kernel command line.

The problem I found with using hda3 for the 3.1u5 kernel is that upgrades flow less naturally. It is easier to protect/spoof the bootpage during the upgrade process than to mess with its choice of partitions.

Sleeper
11-05-2003, 03:20 PM
Is there any way to use this tool and/or pdisk to rearrange a mfsrestored drive so that the AppleFree partition is under the 137 GB barrier so that a drive larger that 137 GB could be monte'd?

alldeadhomiez
11-05-2003, 05:26 PM
Originally posted by Sleeper
Is there any way to use this tool and/or pdisk to rearrange a mfsrestored drive so that the AppleFree partition is under the 137 GB barrier so that a drive larger that 137 GB could be monte'd?

I have been using it like that for a long time. With the new version, everything except the large MFS partitions fit within LBA28 addressible space. hda14/hda16 comes from the same "pool" of low-numbered sectors as hda2-hda8.

If you look at the partition table in the release notes, though, you will see that the "Apple_Free" partition can be converted into something considerably more useful than a romfs partition. Since you can allocate a lot of space to it - several gigs if you want - it makes an ideal Debian root filesystem, giving you quick and easy access to thousands of precompiled packages - applications, dev tools, libraries, etc. (I posted instructions several months ago.) And to start the TiVo software, just chroot to hda7/hda4's mount point and start rc.sysinit.

Or, ignore hda4/hda7 altogether, block writes to the boot sector, store the TiVo root partition in a subdirectory in hda16, and you may be able to block upgrades even if the installer script somehow gets run.

Sleeper
11-08-2003, 03:06 AM
Suggesting that this thread be made sticky.

Sleeper
11-23-2003, 12:12 AM
Originally posted by alldeadhomiez
A few days ago I took a new unit out of the box (virgin unsocketed PROM) and reimaged it this way.

As you can see, the active (decoy) root is hda5 and the active (3.1U5) kernel is hda2

OK, I'm missing something here. How does the prom know to boot the kernel on hda2? There must be some way to set the boot flag on part 2.

alldeadhomiez
11-23-2003, 02:51 AM
Originally posted by Sleeper
OK, I'm missing something here. How does the prom know to boot the kernel on hda2? There must be some way to set the boot flag on part 2.

"bootpage -B 3" sets the boot (active) kernel to hda2.

I'd recommend finding the source to bootpage or writing your own replacement, as the x86 binary I have seems flaky at best wrt updating the bootpage after you have changed it to use an "invalid" kernel partition.

BTW here is a very minor revision to tivopart, changes are as follows:


- Fixed a few corner cases in tivopart/consolidate which previously
required the -f flag

- Adjusted tivopart to work correctly with drives which have fewer than
16 total partitions

- Changed tivopart/consolidate to standardize hda2/3/5/6 on 8192 blocks =
4MB each

Sleeper
11-23-2003, 12:17 PM
Originally posted by alldeadhomiez
"bootpage -B 3" sets the boot (active) kernel to hda2.

I always wondered about that goofy way that you use the root partition number as the parameter to bootpage. What a weard way of doing things. It just never clicked that they are subtracting 1

Since mfsrestore does not allow you to specify the desired size for hda7, you may instead use "-s" to specify a larger swap space and then use tivopart to donate that space to hda7.

I thought that mfsrestore could not create swap > 128 M

I'm writing new backup/restore scripts. I would like to be able to backup and restore monte'd drives and ones that have been repartitioned too.

What I intend to on the backup is to create several files:
backup.bootpage-p
backup.bootpabe-b
backup.pmap (Basically contains output from pdisk -l )

Partitions 3,4 6,7,9
backup.p3 (dd'd to file)
backup.p4 (mount through loop and store fs to file)
backup.p6 (dd'd to file)
backup.p7 (mount through loop and store fs to file)
backup.p9 (mount through loop and store fs to file)

Any other partition that is ext2 (Possibly 5/14/16)
backup.pX (mount through loop and store fs to file)

If partitions 2 and 5 are not ext2 back them up with dd.

THAT'S THE EASY PART!

The hard part is doing the restore. I'm guessing that mfsrestore always creates partitions 1 to 7 and 9 the same size. So I could figure out how much extra space I need and create the swap that much larger. Then I have to repartition according to what was stored in the backup.pmap on a partiton by partion basis. Can the repartition tool handle this in its current form. So can I say resize partition X to Y Meg and steal it from swap?

Thanks

alldeadhomiez
11-23-2003, 01:08 PM
Originally posted by Sleeper
I thought that mfsrestore could not create swap > 128 M

It can create the partition but it can't initialize it properly.

This point is moot because: a) an extra "mkswap" is the least of your worries when you're using mfstool for an S2 image, as you know, and b) you need to reinitialize the kernel, root, and swap filesystems regardless if you use tivopart/consolidate because it does not automatically move those partitions for you.


The hard part is doing the restore. I'm guessing that mfsrestore always creates partitions 1 to 7 and 9 the same size.

Those partitions sizes are not all constant, but hopefully they will be recreated as the original size by mfstool.


So I could figure out how much extra space I need and create the swap that much larger. Then I have to repartition according to what was stored in the backup.pmap on a partiton by partion basis. Can the repartition tool handle this in its current form. So can I say resize partition X to Y Meg and steal it from swap?

I believe you would need to find a way to do this with pdisk, or change the source code.

RUBiK
01-06-2004, 04:06 AM
Sorry to bring back an old thread but I think it's a great one and I'm doing my first S2 DTiVo (will do monte.. manually...)

I assume the minimal U5 root image provided by alldeadhomiez here does indeed work with a proper corresponding U5 kernel image/partition? Others have used it successfully, right?

I'm thinking of using it (to cut down on boot speed) and wanted to hear what kind of luck others had with it before I get to doing it myself here one of these days.

TIA for any feedback.

Sleeper
01-06-2004, 06:33 PM
Yes, I have used a slightly modified version on my TivoScripts ISO.

alldeadhomiez
05-30-2004, 06:29 PM
I have attached the 2004-05-30 release to the first post of this thread. Release notes follow:


Posting date: 2004/05/30

This is the README for the tivopart archive.

Changes from last time:

- Removed some of the "sanity" checking that caused inappropriate failures
on some restored images

- Yet another new layout in "consolidate":

* hda1: ?????? (????) Main root (the root fs that actually boots)
* hda2: 8192 ( 4M) Decoy kernel (signed but compromised kernel)
* hda3: 8192 ( 4M) Kernel 1
* hda4: 262144 (256M) Root 1
* hda5: 8192 ( 4M) Decoy root (decoy root to satisfy initrd checks)
* hda6: 8192 ( 4M) Kernel 2
* hda7: 262144 (256M) Root 2
* hda8: ?????? (????) Linux swap (custom size)

Improvements include:

- always uses hda1 for the large root partition, so installation and
startup scripts do not need to guess at which of 12/14/16 it resides
in (unfortunately, this breaks the standard and puts the partition
map in unallocated space - but it's not half as bad as putting a
romfs there)

- root filesystems have been enlarged to 256MB for 3.1.5/HD TiVo
compatibility

- everything else is 4MB, because, well, disk space is cheap.

- attempts to reclaim space in the Apple_Free partition and from other
odd places where previous versions of tivopart put it. The end
result of this strategy is that tivopart should be able to convert
you to the "new" layout without a restore (leaving MFS intact).

- Added automagic r/w support for byteswapped (Series 1) drives.

NOTE:

This will NOT allow you to mount byteswapped partitions from Linux,
since it applies only to r/w operations within pdisk/tivopart
themselves. With a few small fixups, though, the vplay-based utilities
can easily handle working with byteswapped drives directly after you
have used this tivopart release to revalidate the partition table.

- Known bugs:

- if you build it on a Macintosh or other PPC arch, it will assume
you're on a TiVo. Same for MIPS.

- the old revalidate code is still used when the pdisk code writes out
the partition map

- still a bunch of silly compiler warnings

- all binaries in the package are untested

Juppers
09-05-2004, 02:20 PM
What would it take to get tivopart to allow custom partition maps? I would really like a setup like this.

* hda1: 63 ( 32k) Apple (partition map)
* hda2: 8192 ( 4M) User kernel (signed but compromised kernel)
* hda3: 8192 ( 4M) Kernel 1
* hda4: 262144 (256M) Root 1
* hda5: ?????? (????) User root (root to boot/monte from)
* hda6: 8192 ( 4M) Kernel 2
* hda7: 262144 (256M) Root 2
* hda8: ?????? (????) Linux swap (custom size)

Moving around the partitions is simple enough, I just would rather leave the partition map in it's original location. With the advent of killhdinitrd, a decoy fs is no longer important. Also, it would avoid the breaking of the standard as you mentioned in the last release notes.



(unfortunately, this breaks the standard and puts the partition
map in unallocated space - but it's not half as bad as putting a
romfs there)

EvilJack
09-18-2004, 10:07 AM
I want a larger / root area.... somethings not working...

mfsrestore -s 127 -r4 -xzpi /backup.img /dev/hdc
works....

mfsrestore -s 2048 -r4 -xzpi /backup.img /dev/hdc
does the restore and then says
"Cleaning up restore. Please wait"
and it just hangs there... I assume forever... more than
20 minutes so far... If I kill it and do a pdisk /dev/hdc,
I only have hdc1 - hdc14 defined.

This is a 250GB Drive.... I an using a MFSTOOLS disk
from weakneas that has LBA48 support.

/dev/hdc shows up as a 250Gig drive when I do
dmesg | grep hd after the boot cd boots...

Anyone have any sugestions for getting past this?

Also... when I do the restore and it expands the MFS areas... I end up with 3 MFS
areas and 3 MFS 'blocks'... so there are 6 of the 16 possible
partitions taken by MFS.... is there a way to have only 2
or 4 partions for MFS and leave 2 free for something
else... I'd like to have a /usr partition for testing.

Thanks - jack

alldeadhomiez
09-19-2004, 04:00 AM
-z on a 2GB partition isn't very fast. I don't use it.

MFS partitions can be independent of MFS zones. You can merge adjacent MFS partitions and then update the MFS superblocks. This isn't necessarily recommended because moving the application region to the center of the disk ("optimize partition layout") can speed things up, and you lose the ability to move it independently of the media regions if you merge them all into the same partition.

compwiz312
09-19-2004, 11:45 PM
-z on a 2GB partition isn't very fast. I don't use it.

MFS partitions can be independent of MFS zones. You can merge adjacent MFS partitions and then update the MFS superblocks. This isn't necessarily recommended because moving the application region to the center of the disk ("optimize partition layout") can speed things up, and you lose the ability to move it independently of the media regions if you merge them all into the same partition.

Hate to ask the stupid questions, but would you mind explaining how to merge the MFS partitions? I can handle the merging part, but how would you update the superblocks to resemble the change?

Justin

Homer S
11-25-2004, 03:18 PM
SNIP...

* hda6: 8192 ( 4M) Kernel 2
* hda7: 262144 (128M) Root 2

SNIP...

* hda4: 262144 (256M) Root 1
* hda5: 8192 ( 4M) Decoy root (decoy root to satisfy initrd checks)

SNIP...

- root filesystems have been enlarged to 256MB for 3.1.5/HD TiVo
compatibility

- everything else is 4MB, because, well, disk space is cheap.



I have a question.... The length in one case looks like 512 bytes (hda6 & hda7 from the first map and hda5 from the second map) but is it different for hda4 in the second map? or did I miss something?

I want to reassign some space from a large swap file: length = 1040384 and size = 508.0M to make a larger hda2 for persistent hacks. I am trying to see how to do this using pdisk and/or tivopart and keep the partition map standard.

Thanks!
Homer Out

AlphaWolf
07-23-2009, 03:54 AM
Has anybody been able to get this to compile under cygwin? Or is there perhaps any other way to be able to mount the rootfs partitions and manipulate the bootpage in cygwin?

unitron
03-30-2010, 05:58 AM
I want a larger / root area.... somethings not working...

mfsrestore -s 127 -r4 -xzpi /backup.img /dev/hdc
works....

mfsrestore -s 2048 -r4 -xzpi /backup.img /dev/hdc
does the restore and then says
"Cleaning up restore. Please wait"
and it just hangs there... I assume forever... more than
20 minutes so far... If I kill it and do a pdisk /dev/hdc,
I only have hdc1 - hdc14 defined.

This is a 250GB Drive.... I an using a MFSTOOLS disk
from weakneas that has LBA48 support.

/dev/hdc shows up as a 250Gig drive when I do
dmesg | grep hd after the boot cd boots...

Anyone have any sugestions for getting past this?

Also... when I do the restore and it expands the MFS areas... I end up with 3 MFS
areas and 3 MFS 'blocks'... so there are 6 of the 16 possible
partitions taken by MFS.... is there a way to have only 2
or 4 partions for MFS and leave 2 free for something
else... I'd like to have a /usr partition for testing.

Thanks - jack


" mfsrestore -s 127 "

As I understand it this gives you a 127 MB swap partition.

so I'm guessing this

" mfsrestore -s 2048 "

would give you a 2 GB swap partition.

Standard rule of thumb seems to be "...that you need 1/2MiB for each GiB of storage space", so ' -s 127 ' would give you all you need for a 250 GB hard drive with 2 MB left over.


The above quote comes from --

http://www.courtesan.com/tivo/bigdisk.html --

which has some interesting things to say about swap partitions larger than 127 MB, such as "...If you created a swap partition larger than 127MiB you will need to write a swap header to it or your TiVo will not have any swap space."


I hope that in the nearly 6 years between your post and mine you figured out that this might have been part of your problem. I only responded at this late date because apparently no one else caught the huge increase in the 's' number.

Also, if I'm not mistaken you seem to be creating a backup file on ' hdc ' (Secondary Master) and then restoring that file to the same drive on which it resides -' hdc '. I suppose if all of your backup file is loaded into ram before it starts getting written back to that same drive it might work (and would be an interesting experiment), but it seems risky all the same.

Jamie
03-30-2010, 12:45 PM
" mfsrestore -s 127 "

As I understand it this gives you a 127 MB swap partition.

...It seems that you are missing the point of this whole thread.

Go back to the first post and review this paragraph:

...
Since mfsrestore does not allow you to specify the desired size for hda7, you may instead use "-s" to specify a larger swap space and then use tivopart to donate that space to hda7. This allows you to reserve extra room on / (even a gig or two if you need it) to install your favorite Linux distro, build kernels, set up a warez server, etc. At the very least you will have an easy way to store the monte code, a "hacks" boot script, and one or more alternative kernels on hda7.
...