PDA

View Full Version : 11.0k upgrade fails while building basic filesystem skeleton



pscud
08-19-2011, 12:19 PM
I am having trouble upgrading a Series 3 HD to 11.0k. It is at 11.0j
and, for several reasons, I wasnít able to get around to processing
the upgrade until know. I have gone through the learning curve on this
site and done a couple of pulled drive upgrades and one in-place
upgrade. I generally follow the ManualInstall.tcl script methodology,
doing the steps manually rather than in one batch.

This is the first time Iíve seen this error. I havenít been able to
find something like this in other threads. It is an error from the
standard installSw.itcl, with only the ďrebootĒ to ďexit 0Ē
modification.

Below is the error capture. Actually, it is a log of my whole attempt at
just the beginning of the upgrade and patch process.

Any suggestions? Is there a way to maybe wipe hda4? It should just have
the image from before the 11.0j upgrade. I was thinking maybe as a last
reset I could change my bootpage to allow a software install. I could
then pull the drive and rework. However, if I canít run the script,
Iím afraid this would leave to a GSOD or reboot loop.

=-=-=-=-=
bash-2.02# pwd
/
bash-2.02# /tvbin/installSw.itcl 11.0k-01-2-652
08/19:02:22:48: /tvbin/installSw.itcl: *Installing "11.0k-01-2-652".
Installing module utils
08/19:02:22:48: /tvbin/installSw.itcl: *Executing updateroot /dev/hda
/install /
var/packages 11.0k-01-2-652
Path prefix is /var/utils/
Sha1hash passed for updatekernel
Sha1hash passed for checkkernel.tcl
Sha1hash passed for messagelib.tcl
Sha1hash passed for buildskeleton
Sha1hash passed for SwInstall.tcl
Sha1hash passed for builddev

Searching /etc/fstab for current root

Old root is on /dev/hda7, new one goes on /dev/hda4

Creating new filesystem on /dev/hda4

Mounting new root filesystem on /install

Installing module core
Installing module hpk-Gen06
Installing module locale-en_US
Installing module eiger
Installing module kernel-Gen06
Building basic filesystem skeleton on /install

InitializeProgramOrDie (tivosh) failed: 0x11002
***while executing
"exec tivosh /var/utils//buildskeleton /install"
***("eval" body line 1)
***invoked from within
"eval exec tivosh $prefix/buildskeleton $installdir"
***(file "/var/utils/updateroot" line 147)
child process exited abnormally
***while executing
"exec /var/utils/updateroot /dev/hda /install /var/packages $name >&@
stdout"
***invoked from within
"if [catch { set fIsActive [CheckActive $db $name] } res] {
*******putlog "No software found in db for \"$name\", $res"
***} else {
*******if { $eme..."
***(procedure "InstallSoftware" line 7)
***invoked from within
"InstallSoftware $db $name"
***(file "/tvbin/installSw.itcl" line 119)
=-=-=-=-=

lrhorer
08-19-2011, 09:24 PM
Any suggestions?
One way or another, it should be recoverable. You do have copies of your original kernel and tivoapp, right. 'Wost case, you can restore those, allow the upgrade, and then hack again. I suspect that won't be necessary.


Is there a way to maybe wipe hda4? It should just have
the image from before the 11.0j upgrade.
Yeah, sure, but why?


InitializeProgramOrDie (tivosh) failed: 0x11002
***while executing
"exec tivosh /var/utils//buildskeleton /install"
***("eval" body line 1)
That looks like a mal-formed path, to me. "//" would be a null directory, although bash should not croak on it, but a space after "buildskeleton" doesn't sound likely, to me. Linux would allow it, but I am skeptical it's the right directory.

Edit: Hmm, maybe not. If the parameters are not quoted, then perhaps /install is a directory name passed as a parameter.


***invoked from within
"eval exec tivosh $prefix/buildskeleton $installdir"
That's where the space gets put into the expression. I think it should probably be


exec tivosh $prefix/buildskeleton$installdir

I also think $prefix is no doubt "/var/utils/" when it should be "/var/utils"


child process exited abnormally
***while executing
"exec /var/utils/updateroot /dev/hda /install /var/packages $name >&@
stdout"
***invoked from within
"if [catch { set fIsActive [CheckActive $db $name] } res] {
*******putlog "No software found in db for \"$name\", $res"
***} else {
*******if { $eme..."
***(procedure "InstallSoftware" line 7)
***invoked from within
"InstallSoftware $db $name"
I could be wrong, but it also looks to me like $name may be set to "$name". I believe bash should be expanding the variables (in this case $name) before sending them to exec, in which case the exec line above should not have a variable name in it.

pscud
08-19-2011, 10:16 PM
Thanks for the quick reply, lrhorer. My TiVo is working fine but at sw revision 11.0j-01-2. I just can't move forward to 11.0k.

I am running the standard installSw.itcl script. I edited only the reboot line to exit 0 to intercept and allow me to finish changing. I didn't edit any of the paths or other variables. I thought some looked strange but I'm not a Linux expert and, like I said, it's the factory script and I've only done minimal changes. Are there things I might have borked that would screw up the standard script? Fear of a reboot loop is why I don't want to just put "reboot" back in and see what happens.

AFAIK, the buildskeleton and updateroot program in /var/utils are generating the strange syntax. I think the extra "\" are being used as delimiters but I can't tell if it's from shell execution or how the error is being reported.

I'll keep poking and see if I can find any more information.

lrhorer
08-19-2011, 11:44 PM
I am running the standard installSw.itcl script. I edited only the reboot line to exit 0 to intercept and allow me to finish changing. I didn't edit any of the paths or other variables. I thought some looked strange but I'm not a Linux expert and, like I said, it's the factory script and I've only done minimal changes. Are there things I might have borked that would screw up the standard script?
It doesn't appear the installSW.itcl script is what is causing the issue.

On line 54, the installSW.itcl script defines a procedure named "Install Software". This subroutine is called with two variables, which are named internally within the script as "db" and "name". Line 119 within the script calls the "Install Software" routine with the two variables $db and $name. These two variables are set in the lines just preceding the call to "Install Software". I suspect the database entries may be what are screwing up the call. My next guess would be missing files.

Report the following:

1. The output of the swversion command

2. The contents of the /var/utils directory

3. The contents of the /var/packages directory

4. The contents of the buildskeleton and updateroot scripts.

pscud
08-20-2011, 12:51 PM
Attached are the output of the swversion command, the contents of /var/utils and /var/packages directories, and zipped buildskeleton and updateroot scripts. You mentioned missing files and /var/packages is empty.

I am looking at buildskeleton and updateroot scripts. They didn't have extensions and I forgot in Linux even text files can be executables so I started looking.

The failure is from buildskeleton, line 146


puts "Building basic filesystem skeleton on $installdir\n"
eval exec tivosh $prefix/buildskeleton $installdir

$prefix = /var/utils

I'm going to pull that line and try to run it manually to see if I can build the skeleton.

pscud
08-21-2011, 10:02 PM
I tried to manually run the buildskeleton script but I am not able to get it to run successfully. I've tried a few times and the best was this:



bash-2.02# exec tivosh /var/utils/buildskeleton /install
create: /install/var
create: /install/proc
create: /install/install
<snip: lots of creates>
link: /install/tmp to /install/var/tmp
<snip: lots more creates and a few links>

Connection to host lost.

Press any key to continue...

I have tried this a few times and sometimes I get errors, other times I get partial success. Mostly I lose connection to the host or get a message that it cannot create a link to /install/tmp to /install/var/tmp.

I also cannot edit buildskeleton as it appears to be signed and any edits I make are purged. I tried to hard code

eval exec tivosh /var/utils/buildskeleton /install
but the edit won't take and when the installSw.itcl script runs it expands the variables as

eval exec tivosh /var/utils//buildskeleton /install

Thoughts, anyone?

lrhorer
08-23-2011, 07:10 PM
I tried to manually run the buildskeleton script but I am not able to get it to run successfully. I've tried a few times and the best was this:



bash-2.02# exec tivosh /var/utils/buildskeleton /install
create: /install/var
create: /install/proc
create: /install/install
<snip: lots of creates>
link: /install/tmp to /install/var/tmp
<snip: lots more creates and a few links>

Connection to host lost.

Press any key to continue...
That's weird. I can't think what would cause networking to be lost. Is the TiVo's IP static? If not, try setting it to a static IP.


I also cannot edit buildskeleton as it appears to be signed and any edits I make are purged. I tried to hard code

eval exec tivosh /var/utils/buildskeleton /install
but the edit won't take and when the installSw.itcl script runs it expands the variables as

eval exec tivosh /var/utils//buildskeleton /install

Thoughts, anyone?
There's no signining involved. It sounds like you forgot to set the / mount point to read-write. By default it is read-only.

I haven't had a chance to look at your output. I'll try to take a look tonight.

pscud
08-25-2011, 09:52 PM
I was referring to buildskeleton having a signature as any changes I make are discarded and the file date resets.

I don't think it is a mount point ro vs. rw issue. I have all drives mount rw.

/dev/hda7 on / type ext2 (rw)
/dev/hda9 on /var type ext2 (rw)
/proc on /proc type proc (rw)
/dev/hda4 on /install type ext2 (rw)

I tried to execute ManualInstall.tcl and it returns the exact same error. It also conveniently remounts hda7 as ro.

I'll keep looking at things.

Jamie
08-26-2011, 06:40 AM
IIRC, installSw.itcl unpacks the util slice each time it is run, and buildskeleton (and everything else in /var/util) comes from the util slice. You can see from the original output that there is an Sha1hash check on the files in the util slice:
Sha1hash passed for updatekernel
Sha1hash passed for checkkernel.tcl
Sha1hash passed for messagelib.tcl
Sha1hash passed for buildskeleton
Sha1hash passed for SwInstall.tcl
Sha1hash passed for builddevIf you try to update buildskeleton in the slice, you'll likely need to update the sha1hash too (see variable sha1hashes in updateroot.

When I've had problems in the past with installSw.itcl, it's usually been an environment or PATH problem. I don't know if that is the case here, but it is the first place I'd look.

pscud
08-28-2011, 01:13 PM
It was MFS_DEVICE=dev/hda10 that was the problem. It should be MFS_DEVICE=/dev/hda10. I must have missed that in the last upgrade. It caused no problems until I tried to move to 11.0k.

I was able to successful upgrade and patch 11.0k.

Thank you, lrhorer and Jamie, for your suggestions.

Jamie
08-28-2011, 04:45 PM
Glad you figured it out.