TiVo Community Forums Archives - Wrong hdX devices, unable to mount

TiVoCommunity.com
(c)opyright 1995-2005 All rights reserved
indexcheckTC
This area is a static history of posts in the TiVo Community Forum Archive.
This archive history was made for the simple indexing of search sites like Google.

Pages:1

Wrong hdX devices, unable to mount
(Click here to view the original thread with full colors/images)

Posted by: adamz

First of all, I want to thank Tiger, Hinsdale, and all the other experts who made my 125-hour TiVo possible - with or without the very odd results I'm about to describe below.

The Setup:
I started with an unmodified Phillips HDR31203, attempting to add an 80G Samsung as a B Drive. Since this was the simplest of all upgrade options, I figured I could use Kazymyr's Boot CD instead of MFST2, and thereby avoid the dreaded GSOD loop.

So, I attach the drives to my PC in the recommended order. Specifically:
- Primary master: the Maxtor (40G) that lives in my PC
- Primary slave: new Samsung (80G)
- Secondary master: original TiVo A drive - Quantum (30G)
- Secondary slave: CD-RW

The Problem:
I boot up with Kazymyr's CD, and find that my drives are numbered /dev/hd[e-h] instead of /dev/hd[a-d]. :confused: Here's an excerpt from dmesg (actually logged later using the MFST2 CD after a backup/restore cycle, but with the same results):

code:
hde: MAXTOR 6L040J2, ATA DISK drive
hdf: SAMSUNG SV8004H, ATA DISK drive
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
hdg: Unlocking QUANTUM FIREBALLlct15 30 
hdg: Challenge: 0xabcdef18 Response: 0xc49b864c
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
hdh: CW038D ATAPI CD-R/RW, ATAPI CD/DVD-ROM drive
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
ide3 at 0x170-0x177,0x376 on irq 15
hde: 78177792 sectors (40027 MB) w/1819KiB Cache, CHS=4866/255/63, UDMA(100)
hdf: 156368016 sectors (80060 MB) w/1945KiB Cache, CHS=9733/255/63, UDMA(100)
hdg: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(33)
hdh: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hde: hde1 hde2 < hde5 hde6 >
 hdf:Signature 1492, be16 Signature 9214
21:40: block 0 has signature 9214 rather than 1492
 unknown partition table
 hdg:Signature 1492, be16 Signature 9214
22:00: block 0 has signature 9214 rather than 1492
 unknown partition table

As you can see, the drive sizes are fine, but the device names are not. I later unlocked the Quantum with qunlock, so the boot CD didn't have to do it at boot time, but that didn't change anything else. Also notice that the partitions for hdg and hdf are not listed, and there appears to be a byte-swap (!) in the signatures.

This might have something to do with my motherboard. It's an Asus A7V266-E with an on-board Promise ATA/Raid controller that has its own cable connections. I don't normally use the Promise; instead I plug my IDE cables into the controller slots marked "Primary" and "Secondary". My normal Linux kernel (v2.2.18 patched from RH7) has no problem with this at all, and recognizes my drives as /dev/hd[a-d].

I did try hooking up the IDE cables to the Promise controller, but then my BIOS didn't recognize any of the drives, so I figured there was really no chance that would actually work.

So, I try the upgrade anyway. Using MFST1, I make a simple backup to my home drive and restored to the new 80G drive. I drop that into the TiVo by itself, and it works perfectlyas a 30G image as best I can determine.

Next, I put the 80G drive back into the PC and try to Bless it, but BlessTiVo doesn't recognize /dev/hdf. /dev/hdb (where the drive should have been) just doesn't seem to exist.

At the same time, I also wanted to enable bash by editing the rc.sysinit. But when I try to mount the appropriate partition:

code:
mount -r /dev/hdg4 /mnt/tivo

it tells me I have to specify the filesystem type. When I add '-t ext2', it gives an error. (I forget the exact text; it looks like the standard error you get when mount just doesn't recognize the partition.) And yes, I know -r is read-only, but I wanted to test the mount before doing anything that might destroy my A drive.

I also tried using the 'swap' and 'nodma' options at boot. 'nodma' made no difference in mounting (speed notwithstanding) and 'swap' caused a kernel panic on boot...

Eventually, I just crossed my fingers and used MFST2 to bless the new drive with 'mfsadd -x'. I put both drives into the TiVo, powered up, and lo and behold it all seems to work, including the reported storage space. I enabled backdoors to check the kernel log, and the swap seems ok too.

So, has anybody had a similar experience?
Does anyone with more linux kernel mojo than myself (lots of room there!) have an explanation for this?
Do I have any reason to question the quality of my backup? It did restore at least once...

I can provide more info if anyone asks, but I figure this post is long enough for now.

Posted by: Robert S

As you seem to be guessing, it's a byteswapping issue. For obscure technical reasons, pairs of bytes are written in reversed order by the TiVo's PowerPC CPU. The TiVo boot disks configure Linux to byteswap hdb, c and d so you can read TiVo drives attached to them. MFS Tools 2 has internal support for byteswapping, so that's not affected.

How many IDE connectors does your mainboard have? Some have four, a normal pair and a UDMA-66 pair. Perhaps the normal pair have been deleted from your model?

It should be possible to pass the byteswapping boot options to Linux at boot time to get it byteswap hdf.

You will not be able to mount partitions from a Series 1 TiVo without byteswapping.

Oh, and congratulations on a model tech-support request, never be afraid to pile on the detail, something most people here don't seem to understand.

Posted by: adamz

My board has 4 connectors total, allowing 8 IDE devices. The two that I use are labelled "Primary IDE" and "Secondary IDE" (Simple enough, right?). The other two are "Promise IDE 1" and "Promise IDE 2".

Apart from the attempt I described earlier, I've never used the Promise ones. And I've never before had a problem with the (supposedly) normal connectors. Also, I think UDMA is supposed to work on all of the connecters, if I remember my mainboard manual correctly, but I don't think I've got UDMA working either with my PC drive. It hasn't really been an issue up until now. I do have the manual, it's just not in front of me right now.

As far as some controllers being deleted or disabled, my BIOS only shows slots for 4 IDE devices instead of 8. Maybe a BIOS upgrade will change this, but it seems like a bit of a long shot, and a risky one at that.

If you're suggesting that I use the 'swap' option at boot, I would if the CD could actually boot that way without a panic (see earlier post). The last time I tried it, I didn't think to copy down the panic message or any part of the boot log. I'll try again and post the results. Is there another way to get hdg or hdf to swap?

If it helps, I can also provide the rest of the dmesg that I posted earlier, maybe via PM.

As for my bug-reporting skills, attribute that to 5 years writing SW at a large company. I know how tough it is trying to debug without enough (or any!) details. :D

And thanks for the help, Robert!

Posted by: Robert S

Actually, reviewing your post I'm not sure I was any help at all :)

A few things spring to mind. Have you tried giving Redhat the swap command at boot, that might give BlessTiVo the access it needs.

It's probably that the kernel on Dylan's Boot disk is too old to be aware of these newer IDE arrangements. Also, does Dylan create all the device nodes? Usually there are millions of them, but sometimes boot disks just create a few in their RAM drive. Is there a /dev/hdg node for BlessTiVo to connect to?

Is BlessTiVo a script (I know TiVoMad is)?, if it is you might be able to tweak it.

Posted by: adamz

Well, you've at least convinced me that my backup is ok, since MFSTools was able to deal with the byteswapping even when the boot disk couldn't. :)

Does BlessTiVo not require an MFS-aware kernel? (I know - RTFHackFAQ) I wouldn't mind doing that if I thought it was safe. But then again, I've already done msfadd and powered up the TiVo with both drives at once, so a do-over would require me to restore from backup, right? Apart from the GSOD risk, I'm not sure that it's worth it just to re-bless a working drive.

Come to think of it, my RH kernel would probably detect the drive as hdb anyway, since it doesn't seem to have this device problem...

The RAM disk from the CD contains all of the /dev nodes you would expect to see, including every combination of /dev/hd[a-h][1-12], at a glance. That's how I was able to use MFSTools at all. I didn't try to verify that all of them were actual working nodes, though.

I just tried to open BlessTiVo in an editor. Definitely not a script, although the error messages are visible as text. I don't suppose the author (or whoever holds the source now) would consider patching an updated version?

Posted by: Robert S

There's such a thing as an MFS-aware kernel? I rather assumed that the only thing BlessTiVo required was byteswapping. Surely the worst it could do is give an error message.

To get a 'safe' TiVo you would need to restore your backup back to the A drive with MFS Tools 1.x and then bless the B drive. Presumably RedHat booted with a suitable swap command would allow this, but you might have to take a new backup of the A drive first (not sure if MFST1 can deal with byte-swapped backups made by MFST2).

It depends how worried you are about a green screen. I upgraded my TiVo with MFST2 about a month ago and it's still fine. Hopefully a non-destructive fix for the mfsfix problem will be released before my TiVo green screens!

Posted by: adamz

Oh, I thought the boot CDs had some kind of special MFS-related kernel mods, and that's why we need them. I guess byte-swapping is the only real key here. Would a more-or-less normal kernel have such a swap option at boot? (My current kernel isn't exactly the RH release, although I do still have the original kernel and could boot it.) Do you know of any documentation that describes this? The kernel HOWTO doesn't, and I've never explored the deeper kernel docs. Maybe now's the time.

My A drive backup was made using MFST1, so I should be able to restore it with MFST1, no problem. Is there any other reason I would need to make a newer backup?

As far as green screen paranoia goes, it looks like many of us are in that boat. If I'm going to do a destructive restore (lose my recordings), I guess I'd rather do it now while 1) my big storage is still relatively empty and 2) my TiVo is still half-disassembled, with the B drive not yet tied down.

Do you think that the next TiVo SW upgrade will trigger fsfix, and lead to a rash of GSOD in the underground? (Wait, that didn't sound right...)

BTW, as far as the boot CDs panicking on the swap option, it turns out the CD is fine, I'm just too dumb (or too dependent on well-formatted LILO configurations!) to know how to enter boot params. When I got it right, the MFST2 CD booted just fine, but it still only swapped hd[b-d] so it didn't make any difference to me.

Posted by: Robert S

As you can probably guess I'm reaching well beyond my knowledge of what's really going on, but it won't do any harm to experiment a bit.

I don't think the Linux kernel on the boot disks is heavily modified. I think the byteswap option is a standard part of the IDE driver. On some boot disks (floppies) you can see the boot parameters being passed to the kernel and there are three that same something like hdb=swap (it wasn't exactly that, it was 2 months ago and I wasn't really paying attention). So I think that if you pass the same parameters to RH it should swap hdb. I don't think it could do any real harm to try.

Posted by: adamz

I found a way around the device problem with the boot CDs. For anyone who's interested, the details are here.

The short solution is: Dylan's Boot Disk doesn't have the device name problem! Whatever is tripping up the CD's device recognition doesn't affect DBD.

Chalk that up as a difference between the boot floppies and the boot CDs.

Posted by: Robert S

Perhaps it's something to do with the way your M/B boots off a CD? Anyway, we sure learned a lot about how those TiVo boot disks work!

Posted by: adamz

Maybe, although my RH install CD didn't seem to have this sort of problem, as far as I can recall... I don't think I've tried any other Linux boot CD's since then, apart from the TiVo-related ones.

And I always welcome a chance to learn about this sort of thing, even if I was tearing my hair out for a while!

Posted by: rsnodgrass

I had exactly the same byteswapping problems after restoring my MFST1 backup images using MFST2 and trying to mount /dev/hdb9 to look at the logs after a boot on my TiVo. Thanks for the 'dmesg' tip to dump messages, for some reason /var/log/messages didn't contain everything.

Based on your DBD tip I booted with DTiVoMad Boot Cd (nuboot6.iso) and was able to mount without any problems.

Does anyone know why there are byteswapping differences for the MFST2 boot image? The nuboot6.iso even has bootup options to enable/disable the bswap mode.

Ryan

Posted by: Robert S

Byteswapping is broken on the MFS Tools 2.0 CD, it boots a DMA-enabled kernel and although everything boots correctly, DMA actually disables the byteswapping patch so you can't read a byteswapped TiVo disk.

Posted by: adamz

rsnodgrass- Well, I'm glad someone else has benefitted from my experience. Although, my problem was really a combination of factors:
1) my RAID controller was confusing the boot CD's device recognition, and
2) the MFST1 boot CD's built-in byteswapping parameters weren't prepared for the resulting HD device IDs.

Live and learn. But make back-ups first. :)

Posted by: Yike

quote:
Originally posted by Robert S
Byteswapping is broken on the MFS Tools 2.0 CD, it boots a DMA-enabled kernel and although everything boots correctly, DMA actually disables the byteswapping patch so you can't read a byteswapped TiVo disk.

DOH! God help us n00bs who are using instuctions out there without this knowledge! =)

I think I remember you mentioning the correct boot parameter to pass for this, will have to look back through your recent posts Robert.

Posted by: Robert S

It's in the Fixes thread. It's something like vmlnodma hdc=bswap - obviously you adjust the device node or even add more hdX=bswap entries (separated by comma's) as appropriate for your setup.

You might argue that you'd be following Steve's instructions more precisely if you didn't use MFS Tools 2.0, which in some senses isn't a TiVo boot disk (unless you use the magic incantation correctly).

If you get it right, you should see the TiVo partition table displayed at boot - invalid partition table means you messed up!

Posted by: Yike

http://www.tivocommunity.com/tivo-v...hlight=vmlnodma

You beat me to it Robert, you mentioned the fix above a while back that I remember reading, I just substituted the correct drive designation. Looks like that lets me move forward ... cheers!