Tivo SA 2.5 + 7.1b kernel + 320Gig + mfsadd issues...

[Snake-Byte]

Okay, I'm having issues trying to use my 320 gig drive to its' full capacity.
(Swapping out the original drive with a new one)

I'm using PTVUpgrade's lba48 v4.01 iso in a computer that correctly recognizes the 320 gig drive (dmesg also shows the full capacity during boot).
http://www.ptvupgrade.com/downloads/ptvlba48-4.01.iso

When I issue the drive to drive copy commands WITHOUT expansion, the new 320 gig drive boots up fine in the Tivo. (SA 540040)
(hda contains the original drive, hdc is the new 320 gig drive)
mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -bzpi - /dev/hdc

But when I issue the mfsadd -x /dev/hdc to the new drive and attempt to boot in the tivo again, I get to the "Almost there, just a few more minutes..." and then the tivo reboots.

So where have I goofed? Does the 7.1b kernel not have lba48 support? Is there a limit that mfsadd will work on? Has anyone successfully upgraded a 2.5 SA tivo to use a 320 gig drive? Does mfsadd have any switches that can limit the amount of space on the drive I'm using to something like 127 gigs?

[Jamie]

Okay, I'm having issues trying to use my 320 gig drive to its' full capacity.
(Swapping out the original drive with a new one)

I'm using PTVUpgrade's lba48 v4.01 iso in a computer that correctly recognizes the 320 gig drive (dmesg also shows the full capacity during boot).
http://www.ptvupgrade.com/downloads/ptvlba48-4.01.iso

When I issue the drive to drive copy commands WITHOUT expansion, the new 320 gig drive boots up fine in the Tivo. (SA 540040)
(hda contains the original drive, hdc is the new 320 gig drive)
mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -bzpi - /dev/hdc

But when I issue the mfsadd -x /dev/hdc to the new drive and attempt to boot in the tivo again, I get to the "Almost there, just a few more minutes..." and then the tivo reboots.

So where have I goofed? Does the 7.1b kernel not have lba48 support? Is there a limit that mfsadd will work on? Has anyone successfully upgraded a 2.5 SA tivo to use a 320 gig drive? Does mfsadd have any switches that can limit the amount of space on the drive I'm using to something like 127 gigs?

Yes, there is a known issue with mfstools creating a partiton larger than 256GB. My first suggestion is to try using "mfsadd -r 4 -x /dev/hdc". The details about why I think this might help are here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=2651665&&#post2651665).

If that doesn't work, I'm told that you can use BlessTivo. There are some details here (http://www.dealdatabase.com/forum/showthread.php?p=199259#post199259).

Please report back either way. I'm particularly interested in whether the first approach works.

[PlainBill]

The scene changes, but the lyrics stay the same: What output do you get from the serial console? This may tell us EXACTLY what is going wrong; it certainly will give us some clues.

I will tell you frankly that I don't have hands on experience with your model TiVo, but I was under the impression that the kernel WAS LBA-48 capable. Or you MIGHT be getting bit by the (approximately) 270 Gig partition bug in MFS tools. Suggestion: This model has been fairly well documented here, how about YOU do a little research and verify the LBA-48 status of the kernel. (Search on the model number).

PlainBill

[Snake-Byte]

The scene changes, but the lyrics stay the same: What output do you get from the serial console? This may tell us EXACTLY what is going wrong; it certainly will give us some clues.


Bill,
Sorry for not including the serial console output. I was hoping to avoid getting a usb<->serial adapter for my portable if at all possible. I had a feeling you'd post something like that though... I've read it enough times in the other threads! I was hoping that by asking very specific questions, I would have avoided it. :)


I will tell you frankly that I don't have hands on experience with your model TiVo, but I was under the impression that the kernel WAS LBA-48 capable. Or you MIGHT be getting bit by the (approximately) 270 Gig partition bug in MFS tools. Suggestion: This model has been fairly well documented here, how about YOU do a little research and verify the LBA-48 status of the kernel. (Search on the model number).


I'm sorry that you thought that I was asking you directly for an answer... I was looking for someone who might have the same setup that I do so that there wouldn't be any question as to the cause. As you've said, the scene changes... Tivo is known to take features away with each new release of their software (By features, I mean ways to hack tivo), and I couldn't find any info on the 7.1b release as far as lba support goes in the forums. The last that I read was that the older 5.3 release DID have support, but when troubleshooting, I like to know for certain as much as possible to help rule out possibilities.

I'll give Jamie's suggestions a try and report back.. hopefully then you won't think I'm just another lazy leech. :)

[Snake-Byte]

Yes, there is a known issue with mfstools creating a partiton larger than 256GB. My first suggestion is to try using "mfsadd -r 4 -x /dev/hdc". The details about why I think this might help are here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=2651665&&#post2651665).

If that doesn't work, I'm told that you can use BlessTivo. There are some details here (http://www.dealdatabase.com/forum/showthread.php?p=199259#post199259).

Please report back either way. I'm particularly interested in whether the first approach works.

The first approach worked like a charm. Thanks!

[Jamie]

The first approach worked like a charm. Thanks!Thanks for reporting back. Nobody has confirmed that worked since I originally suggested it, and I couldn't bring myself to buy a 300GB drive just to find out, though I was tempted. Now we know what to tell people who run into the 256GB partition size problem.

Incidently 256 * 2^30 ~= 274 * 10^9, so you'll sometimes see this limit described as 256GB and sometimes as 274GB, depending on whether people are talking GB as powers of ten (10^9) or powers of two (2^30). The storage and telecom people tend to use the 10^9 definition for GB, while the rest of the computer industry uses 2^30.

[Snake-Byte]

Thanks for reporting back. Nobody has confirmed that worked since I originally suggested it, and I couldn't bring myself to buy a 300GB drive just to find out, though I was tempted. Now we know what to tell people who run into the 256GB partition size problem.

Yeah, and the cool thing is I didn't have to create two mfs partitions... I read one suggestion where you were supposed to run mfsadd from a non-lba48 cdrom first (to create a 127 gig partition), and then run it again from a lba48 cdrom in order to gain access to the rest of the drive. Your suggestion works perfectly right after running the standard drive to drive copy command, so:

mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -bzpi - /dev/hdc
mfsadd -r 4 -x /dev/hdc

DONE! :)

[mike_s]

The storage and telecom people tend to use the 10^9 definition for GB, while the rest of the computer industry uses 2^30.

Anyone who uses "giga-" (or "mega-," etc.) to refer to powers of 2 is, quite simply, incorrect. This despite that their use may be understood and commonly accepted within their area. These are internationally standardized SI prefixes, with specific, well defined meaning, and its powers of 10, NOT 2.

If you want to refer to powers of 2, the IEC has standardized appropriate prefixes, ex. "gibibyte." The US National Institute for Standards and Technology on prefixes. (http://physics.nist.gov/cuu/Units/binary.html)

[Jamie]

Anyone who uses "giga-" (or "mega-," etc.) to refer to powers of 2 is, quite simply, incorrect. This despite that their use may be understood and commonly accepted within their area. These are internationally standardized SI prefixes, with specific, well defined meaning, and its powers of 10, NOT 2.

If you want to refer to powers of 2, the IEC has standardized appropriate prefixes, ex. "gibibyte." The US National Institute for Standards and Technology on prefixes. (http://physics.nist.gov/cuu/Units/binary.html)
I stand corrected. I do note that the IEC standard is relatively new (1999) and defacto standards in the field long preceeded it. Old traditions die hard. Go shop for some memory and see if you see 2^30 referred to as GB or GiB. My comment was more in reference to common practice than to international standards.

[cheer]

Anyone who uses "giga-" (or "mega-," etc.) to refer to powers of 2 is, quite simply, incorrect. This despite that their use may be understood and commonly accepted within their area. These are internationally standardized SI prefixes, with specific, well defined meaning, and its powers of 10, NOT 2.

If you want to refer to powers of 2, the IEC has standardized appropriate prefixes, ex. "gibibyte." The US National Institute for Standards and Technology on prefixes. (http://physics.nist.gov/cuu/Units/binary.html)
That may be, but nobody will use it. The use of kilo/mega/giga etc as powers of 2 in the computer industry goes back a long, long time and likely will not change. Language evolves on its own everywhere but France.

[mike_s]

That may be, but nobody will use it.

Some people use "ain't," too. It's even in most dictionaries. That doesn't mean it's proper English.

[cheer]

Some people use "ain't," too. It's even in most dictionaries. That doesn't mean it's proper English.
Mmmm. But in general conversation (which is what we're doing here), does anyone care? Honestly, a grammar nerd could go nuts around here...but I betcha every newbie constructs and/or buys a console cable before "gibabyte" starts getting used.

[ThurstonX]

Incidently 256 * 2^30 ~= 274 * 10^9, so you'll sometimes see this limit described as 256GB and sometimes as 274GB, depending on whether people are talking GB as powers of ten (10^9) or powers of two (2^30). The storage and telecom people tend to use the 10^9 definition for GB, while the rest of the computer industry uses 2^30. Gotta chime in in defense of my industry (were that were literally true!). Storage folk (not me) definitely use the 10^9 method, which is at the very least annoying (I suppose the fine print saves their collective butt from prosecution). The telecomm world uses 10^n, but to indicate bandwidth, as in Mega-bits-per-second (Mbps), which is distinctly dfferent from Mega-Bytes-per-second (MBps). Thus some math is needed to figure how much data (measured in, e.g., 2^10 or 2^20; will be nice when it can realistically be in the 2^30 range) can be transferred over, e.g., a 3 Mbps line.

Note the diff between MBps (standard computer world binary data storage use) and Mbps (telecomm bandwidth measurement). I've found that Google is great for doing the math. Plug this into a standard google.com search:

3 Mbps in MBps

The result is about where my DSL line maxes out when downloading from a good server on a slow day on the Net (so, within the US at around 4:33 AM ;-), as measured by Opera's transfer window calculation.

Jamie,
perhaps I've misunderstood how you think the telecomm world uses 10^9.

[cwerdna]

Since the OP is going over 274 gigs, assuming fsfix (mfsfix?) does run, his 127 meg swap file shouldn't be enough, so if he hits a GSOD, it'd be a continual GSOD loop.

How does one make a bigger valid swap file? Supposedly MFS Tools has a bug with making swap partitions and allocated space >127 megs.

I posted http://www.dealdatabase.com/forum/showthread.php?t=43628 and after 80 views, nobody has answered. :(

[Jamie]

Since the OP is going over 274 gigs, assuming fsfix (mfsfix?) does run, his 127 meg swap file shouldn't be enough, so if he hits a GSOD, it'd be a continual GSOD loop.

How does one make a bigger valid swap file? Supposedly MFS Tools has a bug with making swap partitions and allocated space >127 megs.

I posted http://www.dealdatabase.com/forum/showthread.php?t=43628 and after 80 views, nobody has answered. :(The mfstools beta (http://www.tivocommunity.com/tivo-vb/showthread.php?t=226416) is supposed to solve the swap >127MB problem.

You can always run mkswap yourself. Have you seen this (http://www.tivocommunity.com/tivo-vb/showthread.php?t=69952) thread?

[cwerdna]

You can always run mkswap yourself. Have you seen this (http://www.tivocommunity.com/tivo-vb/showthread.php?t=69952) thread?
I've seen the thread but it was started in 2002 WAY before this new kernel ever shipped on Tivos. So are you saying I should do an mfsrestore with -s 200 (for example) and then do a /sbin/mkswap -v0 /dev/hdc8 [changing hdc8 to whatever is appropriate]?

http://www.courtesan.com/tivo/bigdisk.html seems to say that I need to use a v1 swap and do this:
# mkswap -v1 /dev/hda
# swapon -a

I'd rather do something that's tried and true rather than guessing and facing problems down the road if I hit a GSOD or weird behavior. Restoring from a backup is no fun since I'll lose my recordings.

[Jamie]

I've seen the thread but it was started in 2002 WAY before this new kernel ever shipped on Tivos. So are you saying I should do an mfsrestore with -s 200 (for example) and then do a /sbin/mkswap -v0 /dev/hdc8 [changing hdc8 to whatever is appropriate]?

http://www.courtesan.com/tivo/bigdisk.html seems to say that I need to use a v1 swap and do this:
# mkswap -v1 /dev/hda
# swapon -a

I'd rather do something that's tried and true rather than guessing and facing problems down the road if I hit a GSOD or weird behavior. Restoring from a backup is no fun since I'll lose my recordings.It has to be a v1 swap. works for me. But you *don't* want to run mkswap on /dev/hda. That's definitely wrong.

You can also just wait for the GSOD, and deal with the problem then. Just turn the alternate root partition into a second swap partition to double your swap space when you need it for the GSOD.

[cwerdna]

It has to be a v1 swap. works for me. But you *don't* want to run mkswap on /dev/hda. That's definitely wrong.

You can also just wait for the GSOD, and deal with the problem then. Just turn the alternate root partition into a second swap partition to double your swap space when you need it for the GSOD.
So, in place of /dev/hda, I should be putting in /dev/hdX where X corresponds to what will become the Tivo A drive, correct?

I'd much rather not deal w/the latter since it's a PITA. Given the choices of auto self-recovery vs. me having to screw around with it, I always take the former.

It sounds like I can verify that Tivo's properly using the swap by viewing the /proc/meminfo file. Can I view this file while the drives are hooked to my PC? I guess the alternative would be to look at Tivo's kernel (or maybe tvlog) log files, right? How about mfsassert to force a GSOD and see if it "recovers"? Can I easily do that on my DVR80?

[Jamie]

So, in place of /dev/hda, I should be putting in /dev/hdX where X corresponds to what will become the Tivo A drive, correct?If you run mkswap on /dev/hdX you'll be turning your whole disk into one big swap area. You just want to do the swap partition, /dev/hdX8.
I'd much rather not deal w/the latter since it's a PITA. Given the choices of auto self-recovery vs. me having to screw around with it, I always take the former.understood.It sounds like I can verify that Tivo's properly using the swap by viewing the /proc/meminfo file. Can I view this file while the drives are hooked to my PC? I guess the alternative would be to look at Tivo's kernel (or maybe tvlog) log files, right? How about mfsassert to force a GSOD and see if it "recovers"? Can I easily do that on my DVR80?You'll have to check it once it's running on the tivo. TivoWebPlus displays it on the info package, for example. Or from a telnet or serial shell, run "swapon -s", examine /proc/swaps or /proc/meminfo. It should also be in the kernel log file. You should be able to pull the drive and mount the var partition to see the logs, if you don't want to hack the tivo to get shell access.

[cwerdna]

Ok, sorry to keep revisiting this. I was about to embark on the upgrade tonight when I realized I have another problem. I was going to let the full 80 gig to 300 gig complete drive copy go overnight while I was asleep. <sigh>

Where can I find a binary or better yet a bootable CD that has Todd Miller's updated mkswap for x86 that he references at http://www.courtesan.com/tivo/bigdisk.html? I have no means of easily recompiling mkswap.

The CD produced by burning ptvlba48-4.01.iso (which I think I got from http://www.ptvupgrade.com/products/software/lba48/lba_4.01_license.html) seems to have the wrong version of mkswap.

(can't delete my own post, otherwise I would)
Nevermind, it seems the ISO at http://www.dealdatabase.com/forum/showthread.php?t=30441&highlight=mkswap will do the job.

[Jamie]

Where can I find a binary or better yet a bootable CD that has Todd Miller's updated mkswap for x86 that he references at http://www.courtesan.com/tivo/bigdisk.html? I have no means of easily recompiling mkswap. That page is Series1 oriented. His mkswap patch just adds an option for byte swapping. You don't need that for a Series2. {Edit: read on: it looks like I was wrong about this...} The CD produced by burning ptvlba48-4.01.iso (which I think I got from http://www.ptvupgrade.com/products/software/lba48/lba_4.01_license.html) seems to have the wrong version of mkswap.Last time I checked, PTVupgrade was using a really old kernel (2.4.4) and probably a really old mkswap. It could be that their mkswap pre-dates the addition of version 1 swap.(can't delete my own post, otherwise I would)
Nevermind, it seems the ISO at http://www.dealdatabase.com/forum/showthread.php?t=30441&highlight=mkswap will do the job.That should work.

[cwerdna]

Damn, after making the 300 meg swap partition and doing mkswap -v1 /dev/hda8 (on the correct drive), it looks like the kernel doesn't work w/the swapfile. :( In my messages log, I see SwapTotal of 0kB where it used to be 64 megs.

Also in my kernel log, I can see it used to be able to add the 64 meg swap fine, I now see:
Activating swap partitions
Unable to handle swap header version 16777216
swapon: /dev/hda8/ Invalid argument

Oh well. It looks like I'm going to have to recopy my A drive over and just stick w/127 meg swap. :(

[Jamie]

Damn, after making the 300 meg swap partition and doing mkswap -v1 /dev/hda8 (on the correct drive), it looks like the kernel doesn't work w/the swapfile. :( In my messages log, I see SwapTotal of 0kB where it used to be 64 megs.

Also in my kernel log, I can see it used to be able to add the 64 meg swap fine, I now see:
Activating swap partitions
Unable to handle swap header version 16777216
swapon: /dev/hda8/ Invalid argument

Oh well. It looks like I'm going to have to recopy my A drive over and just stick w/127 meg swap. :(Odd. 2.4.20 kernels, such as the one in 7.1b, can definitely handle v1 swap. I run with a 256MB v1 swap. I created mine by running /bin/mkswap on the tivo itself.

Not sure what's going on here, but it seems like your swap area may not have been correctly initialized. Here's the code from the kernel that prints that message:
if (swap_header->info.version != 1) {
printk(KERN_WARNING
"Unable to handle swap header version %d\n",
swap_header->info.version);
error = -EINVAL;
goto bad_swap;
}
Note that your swap_header->info.version is 16777216 = 0x1000000.
Looks like a byte order problem to me.

[cwerdna]

Odd. 2.4.20 kernels, such as the one in 7.1b, can definitely handle v1 swap. Not sure what's going on here, but it seems like your swap area may not have been correctly initialized.
Yeah. Maybe I did need a patched mkswap and the one on the Knoppix Lite CD was no good? It did support the -v1 flag from the "help" that it had and didn't complain about -v1 either.

[Jamie]

Yeah. Maybe I did need a patched mkswap and the one on the Knoppix Lite CD was no good? It did support the -v1 flag from the "help" that it had and didn't complain about -v1 either.I did a mkswap on a tivo box and and one on a x86 box and dumped the result:
tivo:00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 00 00 00 01 00 00 ff ff 00 00 00 00 00 00 00 00 |................|
00000410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2|
00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|


x86:00000000 07 3b 07 ba 53 54 46 90 88 62 ed cb 7d 3b 49 45 |.;..STF..b..};IE|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 01 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 |................|
00000410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2|
00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Note the byte order of the integer start at offset 0x400.

The easy solution to this is to run mkswap on the tivo itself. Alternatively, get a mkswap that can do byte swaping of the integer fields. The patch at courtesan.com added a "-S" option to byte swap the integer fields. Perhaps the version on the knoppix cd has that option and you just need to use it?

[cwerdna]

IThe easy solution to this is to run mkswap on the tivo itself. Alternatively, get a mkswap that can do byte swaping of the integer fields. The patch at courtesan.com added a "-S" option to byte swap the integer fields. Perhaps the version on the knoppix cd has that option and you just need to use it?
Getting mkswap to run on the tivo itself might be tough for me. The knoppix CD's mkswap only supports -c -v0 -v1 -pPageSZ /dev/name [blocks]. :(

I think I'm going to just put my 80 gig A drive back in for the time being. I've got plenty of space for now since TV shows are in hiatus. Unless I find an easily solution, I might just go grab a 160 gig drive to add and save the 300 for my next PC. :/

[Jamie]

Getting mkswap to run on the tivo itself might be tough for me. The knoppix CD's mkswap only supports -c -v0 -v1 -pPageSZ /dev/name [blocks]. :(

I think I'm going to just put my 80 gig A drive back in for the time being. I've got plenty of space for now since TV shows are in hiatus. Unless I find an easily solution, I might just go grab a 160 gig drive to add and save the 300 for my next PC. :/Check your PM. I sent you a swap partition you can use.

[Jamie]

Here's a static linux x86 mkswap that includes the -S option to swap bytes in the integer header values.

[cwerdna]

Thanks for the help. I'll think about it when I have more time. Due to the errr... twists and turns this has taken, I'm a little concerned that there aren't that many people running w/>127 meg swap in conjunction w/really large drives on any Tivos. So it's unclear to me if some other unknown prob might come up and whether they can really recover properly from GSOD given this larger swap.

Divorcing my drives and losing my recordings cuz of some prob down the road is no fun.

Sorry to make this even more off topic. How much physical RAM does the RCA DVR80 have usable? I swear I saw a weird amount like ~43nnn KB in the kernel logs. I'd expected say 49152 or 40960K. I'm contemplating just adding the a 200 gig drive (they're cheap too) if the unit can recover from GSOD of ~280 gigs w/127 megs of swap.

[TiVo_jimbo]

Anyone who uses "giga-" (or "mega-," etc.) to refer to powers of 2 is, quite simply, incorrect. This despite that their use may be understood and commonly accepted within their area. These are internationally standardized SI prefixes, with specific, well defined meaning, and its powers of 10, NOT 2.

If you want to refer to powers of 2, the IEC has standardized appropriate prefixes, ex. "gibibyte." The US National Institute for Standards and Technology on prefixes. (http://physics.nist.gov/cuu/Units/binary.html)

Wrong. This is straight from your URL:

Faced with this reality, the IEEE Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body.

I'm so tired of this crap. Since most people are DUMB and don't want to learn something new, the smarter people must be wrong. WRONG! Computers don't talk in tens, they talk in twos. Period.

Before 48 bit addressing we had a 128 GB limit.
MFS Tools has a 256 GB problem.

And now, just for your amusement:

2^10 = 1,024 = 1 kilobyte = 1 KB
2^20 = 1,048,576 = 1 megabyte = 1 MB
2^30 = 1,073,741,824 = 1 gigabyte = 1 GB
2^40 = 1,099,511,627,776 = 1 terabyte = 1 TB

[joeblow17]

Yes, there is a known issue with mfstools creating a partiton larger than 256GB. My first suggestion is to try using "mfsadd -r 4 -x /dev/hdc". The details about why I think this might help are here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=2651665&&#post2651665).

If that doesn't work, I'm told that you can use BlessTivo. There are some details here (http://www.dealdatabase.com/forum/showthread.php?p=199259#post199259).

Please report back either way. I'm particularly interested in whether the first approach works.

Thank you so much for the info it worked flawlessly for me. I just wish it was easier to find. I spent all day banging my head and once I found this it worked like a charm. It says I have 285 hours on my 300gb drive. It seemed a little lower than expected but I am very happy I finally got it working!!

Thanks again you are a life saver!! :cool:

[fantmn]

I removed my original post information because I think I solved my output problem.

On my x86 system I was getting output that did not match Jamie's. I now used these commands and got these results.

firewall:/usr/local/sbin # ./mkswap -v1 -S /dev/hdc8
Setting up swapspace version 1, size = 524284K
firewall:/usr/local/sbin # hexdump -C /dev/hdc8
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 00 00 00 01 00 01 ff ff 00 00 00 00 00 00 00 00 |................|
00000410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2|
00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*


and now it matches. It also worked when I got home and tried it.

[ciper]

The makeswap on post 28 with byteswapping enabled is what I have been trying to find for a while!

To compliment it I will attach a makeswap for PPC tivos that can create version 1 swap (the original mkswap binary can only do version 0). Make sure you have a kernel that can support this since the stock kernel only supports the 127mb version 0 swaps.