3.1b and "updatesoftware=false" in rc.sysinit

[cdoggLBC]

Has anyone with rc.sysint upgradeoftware=false or with the entire updatesoftware section commented out gotten the 3.1b update.... I am just wondering what kind of alert status I should be on.

[ronnythunder]

i assume you're talking about series 1 dtivo? i have one with upgradesoftware=false in the bootparms that's got the update; it reboots at 2:00am after every successful call, but other than that, it's still sittin' happy with the old software. i'm waiting until all of my units get it so i can do the upgrades in a little production line.

ronny

[nsysblh]

Yes, that is all it takes to keep the update from going in. Then you can just change it back when you are ready to upgrade. If you do it right, you won't even have to remove the drives (you do have to mess with the upgrade script to pre hack the new rc.sysinit and kernel).

[swspjcd]

My dtivo downloaded the update last night but I also have "upgradesw=flase" in my rc.sysinit. I would like to get the upgrade but don't want to have to take the whole thing apart just to get telnet/ftp etc working again. What can I do to edit the new rc.sysinit so that it will also load the daemons after the upgrade is completed? Right now, I'm at "pending restart" and is I change the "upgradesw" parameter I'll get the upgrade after a reboot.
John

[cdoggLBC]

I'm also curious as to the exact steps anyone used to make the update smooth (ie no drive pull out). I have begun trying to figure it out my self, but.... I don't have access to a desktop PC right now, so I am hosed if I screw it up... I think I will postpone the update untill I get a new desktop or someone is sucessfully able to at least keep bash over serial through the upgrade. Or untill I become bored and go for the suicide mission.

I think the best fix will be if someone is able to package the update into an installer (like previous upodates), but I don't know if there is the demand.

[swspjcd]

Here is my current partition info:
bash-2.02# mount
/dev/hda4 on / type ext2 (ro)
/dev/hda9 on /var type ext2 (rw)
/proc on /proc type proc (rw)

What I can't figure out is which partition is my inactive one that contains the update that will be installed after a reboot and how do I mount it so that I can hack it so that rc.sysinit will still load bash,ftp and telnet? I assumed (incorrectly apparently) that hda7 was the inactive partition and tried doing a:

"mount /dev/hda7 /mnt/test" but I keep getting:

"You must specifiy a file type" and if I do a:

"mount /dev/hda7 /mnt/test -t ext2" I get:

mount: wrong fs type, bad option, bad superblock on /dev/hda7,
or too many mounted file systems

I'm sure it's something simple and maybe someone can help me here.

I have 2 120 gig drives in my Hughes GXCEBOT if that helps at all.

Thanks,
John

[cdoggLBC]

/dev/hda4 on / type ext2

This is your active partition.

mount /dev/hda7 /mnt/test -t ext2

This is in active. I don't think you need to specifiy the type.

mount /dev/hda7 /mnt/test

Should do the job. Just make sure you that /mnt/test exists. So you may need to do a

mkdir /mnt/test

first. Then you will have access to the inactive partition.

Here is where I am unclear. Just because the update will be installed on the inactive partion (After restart and the updatesoftware= is uncommented of course.),,, even if it is "pre hacked" won't any changes be over wiritten by the updater??

I have no idea how this updater works.. which is why I haven't allowed it yet. I would think though that even if you pre-hack the partition that the update will take place on (and then become active), when the updating takes place (during the restart) it would overwrite any changes....

Or is the above thinking wrong... and the inactive ext2 partition is updated right away and the whole "pending restart" part of the restart just for mfs?.... If this is the case, you should just be able to copy your hacks over, reboot and boom.

And one other question.... how do you know if the update is downloaded and "pending restart" I normally keep an exact dd copy of my active partition on the inactive one, so it would be easy enough to telll if dave has been moving files around on the inactive side, but I am wondering if there is a better way to tell.

[swspjcd]

I understand the logic but unfortunately doing a
"mount /dev/hda7 /mnt/test" tells me I need to specify a filesystem type. If I do specify a type, I get
"mount: wrong fs type, bad option, bad superblock on /dev/hda7,
or too many mounted file systems"

The /mnt/test directory does already exist.

Since I have 2 drives, isn't is possible that my inactive partition is on hdb? Even doing mount /dev/hdb7 /mnt/test gives me the same results. In fact, I've tried all combinations of /dev/hda* and /dev/hdb* and can't get any of them to work. Clearly I'm missing something but I don't know what it is!

I'm guessing, but I think the update wipes out everything on the inactive partition and then applies the update which is why I'm hoping to find the update and then alter it so it will load bash,telnet and ftp after a successful upgrade so I can avoid having to take my tivo apart yet again.
John

[cdoggLBC]

Well I just tried to mount my alt partition and it worked fine with the command I gave... so I think you may have some disk corruption.... And the 2nd drive is always just MFS so I don't think it is there.... Try it with the options again, maybe before the device. I know the man page says otherwise, but it is worth a try. Also throw in the -v verbose option. It may give you a little more specific description of what is going on.... ALSO I just thought of this. Make SURE your active partion (where you are creating the mount point) is mounted R/W. I bet that is it.

[swspjcd]

Ok. I'm completely baffled now. I did a "mount -o remount,rw /" and tried doing a "mount /dev/hda7 /mnt/test" and still get the same error. If i use verbose, it tells me
mount: you didn't specify a filesystem type for /dev/hda7
I will try all types mentioned in /proc/filesystems
mount: you must specify the filesystem type

Again, I tried this on all combinations of /dev/hda* and /dev/hdb* and get the same error.
Specifying a filesystem type just gets me the
mount: wrong fs type, bad option, bad superblock on /dev/hda7,
or too many mounted file systems
error. I guess there must be something corrupt but I have a ton of shows on my Tivo right now and have no desire to lose them all by starting all over. It's beginning to look like I have no way of upgrading to 3.1.0b without taking the whole box apart and who knows then if it would even work because of whatever may be corrupt. Wow this is frustrating!
John

[SR712]

Try booting from a 25xtreme boot CD if you have one around, and do the same commands.

[Tux Man]

Hmm, maybe there no filesystem on that partition :)

Tux