Results 1 to 8 of 8

Thread: Close call: Upgrade forced attempt despite bootpage settings?

  1. #1
    Join Date
    Mar 2003
    Location
    Los Angeles County, CA
    Posts
    40

    Close call: Upgrade forced attempt despite bootpage settings?


    (NOTE: In reading my own post, I realize the tone may sound a bit like I'm throwing the gaunlet down, or challenging the statement of some well-respected folks. To be clear.... I know likely have an error here somewhere, either in my application or understanding....)



    Ok folks, funny how what I posted in a different thread seems to have bit me.

    Two days ago, I noticed I was now "pending restart" for 11.0h. Smiled to myself, figured it had been there a few days since I *knew* my bootpage settings were in place, as I was awaiting the latest tivoapp patches. I wanted to wait a few days for the tivoapp patches, and go over in place upgrade procedures.

    My wife awoke me this morning to tell me that the tivo was dead, except for a flashing green light. Oh crap....

    Fortunately for me, a hard restart of the and my box is again showing 10.g and is Pending Restart. I can telnet in, all is good...

    SO I start snooping around to try to figure out what happened:

    Code:
    macintel:~ david$ telnet 10.0.0.44
    Trying 10.0.0.44...
    Connected to tivo-guest.local.
    Escape character is '^]'.
    bash-2.02# bootpage -p /dev/hda
    root=/dev/hda4 dsscon=true console=1,115200 upgradesoftware=false

    Seems right....

    Check the enviroment.....

    Code:
    upgradesoftware=false
    PWD=/var/log
    TIVO_REMOTE=TIVO
    HOSTNAME=(none)
    TV_LOCALE=en_US
    LD_LIBRARY_PATH=/lib
    hpk_implementation=Gen06
    MODEM_TYPE=Si2434
    SwSystem=11.0g-01-2
    internal_drive=hda
    MFS_DEBUG=0x00008000
    varpartition=/dev/hda9
    MACHTYPE=i686-pc-linux-gnu
    DEBUG_INTERFACE_NAME=none
    HDA_ID=WD-WCAVY2378515
    DEBUG_BOARD=false
    primary_drive=hda
    PROMVERSION=
    
    TiVo/mips/Gen06/rel version v1.05-rel_C1
    IrdSerialNumber=5349*snip*
    SHLVL=3
    MODEM_REV=C
    HDB_ID=Unknown
    root=/dev/hda4
    TV_STD=NTSC
    dsscon=true
    EMERGENCY_REINSTALL=0
    MODEM_DEVICE=/dev/cua3
    SHELL=/bin/sh
    HOSTTYPE=i686
    OSTYPE=linux-gnu
    MFS_DEVICE=/dev/hda10
    HOME=/
    TERM=linux
    PATH=./:.:/bin:/sbin:/tvbin:/hack-bin
    SerialNumber=65200018(snip!)
    TIVO_ROOT=
    _=/hack-bin/env


    Is the green light blinking is not related to a reboot, just a coincidence?? Nope... it is clear there was an upgrade attempt


    (from 0tvlog):


    Code:
    Jul 31 09:00:15 (none) TvBusSession[350]: TVBCt 15/310: 242688 msg
    Jul 31 09:01:04 (none) TvVideoGuts[319]: OnOutputStateChange[0]: Recoding = NULL
    Jul 31 09:01:04 (none) TvVideoOutputListenerData[387]: Received TvVideoPlayerState event.
    Jul 31 09:01:04 (none) TvReplayControl[387]: Not viewing in-progress recording: cached=(nil) output=(nil)
    Jul 31 09:01:10 (none) DiskManager[3761]: Running task manager. nRequests=2
    Jul 31 09:01:10 (none) DiskManager[3761]: About to allocate for 1048576 Kb for recordingId 160139
    Jul 31 09:01:10 (none) DiskManager[3761]: Allocating clip. Size 1048576 KB
    Jul 31 09:01:10 (none) DiskManager[3761]: Partition 10, total 1941979520 free 1842637184
    Jul 31 09:01:10 (none) DiskManager[3761]: Dump: Id 160178 type 0 size 1048576 deadline 277 done:F running:F
    Jul 31 09:01:10 (none) DiskManager[3761]: Dump: Id 160139 type 0 size 1048576 deadline 2147483647 done:T running:F
    Jul 31 09:01:10 (none) Recorder[350]: Got disk manager result, 0x0
    Jul 31 09:01:10 (none) mediamgr[350]: AddLiveFile input#1
    Jul 31 09:01:10 (none) TmkClipFile.C[350]: flushed fsid 160266, up to 0 (8240) 
    Jul 31 09:01:10 (none) Recorder[350]: Add file 160266 to live cache 160139/-1
    Jul 31 09:01:10 (none) Recorder[350]: LiveCacheAction::OnDiskManagerResult
    Jul 31 09:01:10 (none) Recorder[350]: pAllocateNotificationInterfaceM is NULL
    Jul 31 09:01:16 (none) comm[3585]: RebootChore: rebooting (software install)...
    Jul 31 09:01:16 (none) TmkActivityStats[3648]: TvSwUpdateRebootServerActivity-->(Pri:0 Time Sample: 23 h 54 min)
    Jul 31 09:01:16 (none) TmkActivityStats[3648]: Fd    : Cur#:   0, Max#:   0, #Trig:       0, Time:    0 usec
    Jul 31 09:01:16 (none) TmkActivityStats[3648]: Timer : Cur#:   0, Max#:   0, #Trig:       0, Time:    0 usec
    Jul 31 09:01:16 (none) TmkActivityStats[3648]: Sema  : Cur#:   2, Max#:   2, #Trig:       1, Time:   77 usec
    Jul 31 09:01:16 (none) TmkActivityStats[3648]: Callme: Cur#:   0, Max#:   0, #Trig:       0, Time:    0 usec
    Jul 31 09:01:20 (none) Recorder[350]: Checking schedule
    Jul 31 09:01:43 (none) TvVideoGuts[319]: OnOutputStateChange[0]: Recoding = NULL
    Jul 31 09:01:43 (none) TvVideoOutputListenerData[387]: Received TvVideoPlayerState event.
    Jul 31 09:01:43 (none) TvReplayControl[387]: Not viewing in-progress recording: cached=(nil) output=(nil)
    Jul 31 09:02:09 (none) TvVideoGuts[319]: OnOutputStateChange[0]: Recoding = NULL
    Jul 31 09:02:09 (none) TvVideoOutputListenerData[387]: Received TvVideoPlayerState event.
    Jul 31 09:02:09 (none) TvReplayControl[387]: Not viewing in-progress recording: cached=(nil) output=(nil)
    Jul 31 09:02:12 (none) prioritizer[2954]: UpdateNightToken fNight=1
    Jan  2 00:00:47 (none) TmkInit[81]: Starting program HpkDisplay
    Jan  2 00:00:47 (none) TmkInit[81]:       0.000 seconds: TOTAL for HpkDisplay
    Jan  2 00:00:48 (none) TmkInit[85]: Starting program LoadHdcpKeySet
    Jan  2 00:00:48 (none) TmkInit[85]:       0.000 seconds: TOTAL for LoadHdcpKeySet
    Jan  2 00:00:49 (none) TmkInit[90]: Starting program osdwriter
    Jan  2 00:00:49 (none) TmkInit[90]:       0.000 seconds: TOTAL for osdwriter
    Jan  2 00:00:53 (none) hpk[90]: NIM[0]: analog tune to 0Hz (frequency masked), CABLE

    So, what happened? I'm fairly confident I've got the right casing and syntax on the bootpage, but I am taking this from other posts.



    I'm going to try to follow the in place upgrade, but I'm a bit freaked now, and feel I've got to rush it before it tries to reboot on me again tonight.


    BTW, this is the content of my rc.sysinit.author:

    Code:
    bash-2.02# cat rc.sysinit.author
    #!/bin/bash
    export PATH=./:.:/bin:/sbin:/tvbin:/hack-bin
    export TIVO_ROOT=
    export MFS_DEVICE=/dev/hda10
    #serial bash
    /bin/bash</dev/ttyDSS&>/dev/ttyDSS &
    #telnet
    /sbin/tnlited 23 /bin/bash -login &
    #ftp
    /hack-bin/tivoftpd &
    Last edited by dcbarry; 08-01-2010 at 01:24 AM.

  2. #2
    Join Date
    Aug 2004
    Posts
    4,075
    The bootpage "upgradesoftware=false" option doesn't prevent the nightly reboot, it just prevents the software install from happening after the reboot.
    You need the "no thanks!" patch if you want to avoid the nightly reboot. I'm not sure anyone has ported it to recent software versions.

    Perhaps you have one of the WD drives with the soft reboot problem, and hence the tivo isn't coming up cleanly after the nightly reboot? There's a fix for that.

    Further recent discussion here.

  3. #3
    Join Date
    Nov 2004
    Posts
    420
    Some more recent 11.0x ports added to the post here

  4. #4
    Join Date
    Mar 2003
    Location
    Los Angeles County, CA
    Posts
    40
    Thanks for the input Jaime.

    So I am 100% clear, when you say nightly reboot, you mean this occurs when the box is in "pending" status.. i.e., the box does not normally reboot nightly. In fact, other than a fault condition, or when an upgrade is pushed, there is no other time the box soft boots... right?


    When I got the drive, I was aware of the WD issue. I do have a 2TD WD EADS drive. However, I did several soft reboots of the box prior to this during the initial hack all without incident. My read of the WD failures was that it was a 100% issue.. i.e., all soft boots resulted in a lockup. So I was pretty sure it was a "good" WD drive. even now I can issue a reboot from telnet and come back up.







    Quote Originally Posted by Jamie View Post
    The bootpage "upgradesoftware=false" option doesn't prevent the nightly reboot, it just prevents the software install from happening after the reboot.
    You need the "no thanks!" patch if you want to avoid the nightly reboot. I'm not sure anyone has ported it to recent software versions.

    Perhaps you have one of the WD drives with the soft reboot problem, and hence the tivo isn't coming up cleanly after the nightly reboot? There's a fix for that.

    Further recent discussion here.

  5. #5
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by dcbarry View Post
    Thanks for the input Jaime.

    So I am 100% clear, when you say nightly reboot, you mean this occurs when the box is in "pending" status.. i.e., the box does not normally reboot nightly. In fact, other than a fault condition, or when an upgrade is pushed, there is no other time the box soft boots... right?
    Right.

    When I got the drive, I was aware of the WD issue. I do have a 2TD WD EADS drive. However, I did several soft reboots of the box prior to this during the initial hack all without incident. My read of the WD failures was that it was a 100% issue.. i.e., all soft boots resulted in a lockup. So I was pretty sure it was a "good" WD drive. even now I can issue a reboot from telnet and come back up.
    Shrug. It just sounded to me like the softboot issue: in other words, when the tivo reboots without a full power cycle, the drive isn't always ready when the tivo wants it to be. I thought this was a timing issue and might or might not happen depending on the timing during the boot.

  6. #6
    Join Date
    Jun 2003
    Posts
    611
    The tclient (or Otclient) log sheds more light on the update process and the role "upgradesoftware=false" plays. Once a new SW build is downloaded & loaded into MFS the box goes into a "Pending Restart" state. While in this state it will reboot around 2am in order to install the new software. When the box reboots, assuming you have "upgradesoftware=false" set, you'll see entries in tclient something along these lines:

    Code:
    NewSoftware: getting SwSystem name
    NewSoftware: SwSystem 11.0h-01-2-652 is present but not active
    NewSoftware: upgradesoftware=false set, not upgrading software
    This is from memory so the wording may not be exact. But you can see that the "Pending Restart" state and nightly reboots are independent of the upgradesoftware flag. You need the "No Thanks!" patch to prevent the "Pending Restart" state and the "upgradesoftware=false" flag to prevent accidental installation if the box is rebooted for any other reason.

    -psxboy
    TCD652160 TivoHD
    1TB
    11.0n.J1-01-2-652

  7. #7
    Join Date
    Mar 2003
    Location
    Los Angeles County, CA
    Posts
    40
    Jamie & psxboy:


    Thanks both for your posts.


    It certainly does _sound_ like a soft boot issue. I wish I could recreate it at least, but I can't. Tried a few more various soft boots, from the command line and from the tivo itself, and could not re-create the condition.

    I realized that I did forget to include in the message that this is a 2TB hybrid image. (THDXL on THD). Now, on that count, I did go through two incremental upgrades to 10g, also without the error, but who knows. I'll post in that owner's thread just to heads up.

    To wife-proof this, sounds like I should look at the no thanks! patch. The only reason I hesitate is that I don't see a lot of mention of it being in active use.

    I suppose/ wonder if the other way I could avoid the reboot is to force a manual extended recording in the wee hours. I imagine at some point the tivo would get more agressive and try a reboot during waking hours when there is no scheduled activity.... anyone know?

    Bottom line: the good news is that I am at 11.0h with my CCI fix in place. SO thanks again to you both (and to all the others whose good efforts make this possible.)

  8. #8
    Join Date
    Jul 2009
    Posts
    12
    Quote Originally Posted by psxboy View Post
    The tclient (or Otclient) log sheds more light on the update process and the role "upgradesoftware=false" plays. Once a new SW build is downloaded & loaded into MFS the box goes into a "Pending Restart" state. While in this state it will reboot around 2am in order to install the new software. When the box reboots, assuming you have "upgradesoftware=false" set, you'll see entries in tclient something along these lines:

    .....
    -psxboy
    My THD currently runs on 11.0g and has listed the 11.0h under /SwSystem for several days. I didn't apply the "no thanks" patch. But I don't think the box tries to reboot every night. The Last Status on the System Info page is "In Progress". What does it mean?
    Last edited by valley_nomad; 08-02-2010 at 09:21 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •