[mythtv-users] Various MythTV-related adventures

Roger Heflin rogerheflin at gmail.com
Mon Oct 13 00:06:44 UTC 2008


Yeechang Lee wrote:
> I've recently made some interesting and more or less MythTV-related
> discoveries.
> 
> The backend server mentioned in my signature runs Fedora Core 6 with
> the 2.6.20-1.2962 kernel. It is the master MythTV backend, mythconverg
> database host, software RAID 6 array that acts as one of my three
> recording drives, and a VMware Server virtual machine I use as my
> normal user environment.[1] I don't use 2.6.22 because for some reason
> I don't recall mdadm wasn't able to start its 16-drive array. The
> drives hang off a HighPoint RocketRAID 2240 acting purely as a SATA
> controller.[2]
> 
> I decided to try out HighPoint's proprietary hptmv6 driver in place of
> the Linux kernel's sata_mv driver. I expected that I would still be
> able to use software RAID. Since it is only available for the
> 2.6.18-1.2798 kernel (always a bane of binary-only drivers) for Fedora
> Core 6 I downgraded to it, then copied hptmv6.ko to the appropriate
> place in /lib/modules.
> 
> Rebooting brought issues. Both sata_mv and hptmv6 would load, causing
> the boot process to hang, even when booting into single-user
> mode. Using the magic SysRq to kill the boot process would get me to a
> root prompt but with a read-only filesystem and a mount that (thanks
> to the preexisting /etc/mtab) stubbornly refused all attempts to let
> me remount the root partition as read-write.
> 
> Since I couldn't find my Fedora Core 6 install DVD to use as a rescue
> disk I burned first the UltimateBootCD (which turned out to be more
> DOS/Windows-oriented), then SystemRescueCd. Although SystemRescueCd
> claimed JFS support, I was unable to mount the root partition. I
> finally realized that it simply needed fsck first.
> 
> The next few boot cycles were spent repeating the above steps. I'd try
> various ways of disabling sata_mv from loading, including 'alias
> sata_mv off', 'blacklist sata_mv', and even moving/renaming
> sata_mv.ko. No luck; it kept reappearing.
> 
> I finally played it smart by booting with just sata_mv, then shutting
> down mythbackend and autofs, then 'mdadm --stop /dev/md0', then 'rmmod
> sata_mv', then 'modprobe hptmv6'. It booted fine, and said though
> dmesg it'd found 16 devices, but /dev/sd[b-q] weren't
> there. Apparently, I'd have to go into the controller's BIOS setup and
> export each drive as a sigle JBOD array for it to appear. I'm not sure
> whether this would require erasing my software RAID array, which of
> course was not desired.
> 
> In any case, another issue cropped up that prevented further pursuit
> of the idea. I noticed that upcoming over-the-air recordings in
> mythfrontend were marked as unavailable. The server's mythbackend is the one
> set up to talk to my HDHomerun, and it was having trouble doing
> so. Sometimes 'ping hdhomerun' would work, and sometimes
> not. Sometimes 'hdhomerun_config discover' would work, and sometimes
> not. These were issues I'd never faced in a year and a half of using
> the HDHomeRun, which has always been a refreshingly install-and-forget
> device.
> 
> Given I was seeing some odd networking issues with the VMware VM
> (which bridges to the physical server's networking card), I figured it
> must be something to do with the 2.6.18 kernel. Since I was already
> again swapping kernels I figured I'd also try the 2.6.22.14-72 kernel,
> the most recent one before Fedora Core 6 hit end of life. No luck;
> only five or six of my 16 RAID drives appeared in /dev. So back to
> 2.6.20-1.2962 I went. Here I am, once again with a fully-functioning
> MythTV setup that's, well, exactly the same as it was this time
> yesterday.
> 
> Through all this my frontend/slave backend was plugging away. In fact,
> I rebooted the master backend server midway through a recording the
> slave backend was making to its own RAID array. I already knew slave
> backends continue recording if the master backend stops and they still
> have access to the recording drive being used
> (<URL:http://www.gossamer-threads.com/lists/mythtv/users/308094#308094>)
> --they just can't start new recorings--but I hadn't realized that they
> could do so even if the database itself is temporarily
> inaccessible.
> 
> Unanswered questions:
> 
> * Would exporting each drive as a separate JBOD drive via the
>   HighPoint RAID BIOS setup have erased the software RAID array?

Maybe.   At the very least the drive exported as a JBOD is going to be slightly 
smaller as Highpoint will put some stuff on the drive labeling/partitioning it 
for the raid controller, if this stuff was put in the partition table area it 
could erase the partition table, and appear to erase everything (if you could 
rebuild the partition table to be the same as before things may come back), or 
if their labeling is not on the partition table you would lose a few blocks 
somewhere which would also cause some issues.    The Highpoint raid for that 
card is software raid, and the highpoint driver's support (on their software 
raid devices) on most variants of Linux is somewhat badly supported on newer 
kernels (the driver is often unavailable or non-functional).    There software 
raid cards do make nice multi-port sata cards though.

> * Why couldn't I prevent sata_mv from loading no matter what I tried?

It was likely in the initrd so would load long before you had any chance to stop 
things.    And as you found out the sata_mv and highpoint driver don't play well 
together.

                                Roger




More information about the mythtv-users mailing list