While this article is helpful in that it shows that the Cisco document had incorrect syntax (not to mention, typos) it still did not help my situation, other than prompting me to do a google search on "rootpatchpw", which led me to this other Cisco Community Article, which ultimately DID solve my problem (Prime Infrastructure 3.1 stuck in a boot loop due to file system corruption):
NCS boot loop at ADE OS (VMDK Recovery)
I added quite a long note of my experience, as the original article is over 6 years old at the time of my posting.
... View more
More than 6 years later, and this still saved my bacon. Was running PI 3.1 and for whatever reason ended up in a boot loop that was asking for a root password in order to run a File System Check:
We attempted to follow Cisco Document ID:200760, but the syntax was incorrect in multiple places. Still, even after finding a second article in the Cisco Community here stating that the syntax was incorrect in the first article, we still were at a loss, as the issue did not seem to be resolvable...by luck, a Google search returned the article on the page you are reading now. I used the Linux SystemRescueCd-6.0.2 Released on Feb 21, 2019, which you can download here: http://www.system-rescue-cd.org/Download/
When I booted, I was presented with this screen, and I chose the first option, which got me to a CLI:
At this point, I picked up with step 7:
7. Determine which designation has been given to the volumes we need to repair. In the output below, this
particular linux distro has given the volumes the 'sdb' designation. This can vary. There will be three of them (sdb1, sdb2, sdb3)
# fdisk -l
The only problem was that the output went completely off the screen. If you aren't familiar with Linux, this can be frustrating, however not to worry - just use the "less" command, which is just the command stated above with a pipe:
# fdisk -l | less
Doing this gave me the following output (you have to hit Q to exit back to the CLI):
From that screen above, this (below) is all we care about:
From here, we can continue on with steps 8 through to completion. Not all of the output will look like what is posted above, but that's ok. I've posted mine for examples, yours may look a little different. I didn't show all of my volume fscks, because only one needed fixing.
As you can see above, I re-ran the fsck on the /dev/smosvg/optvol, and the second time it ran completely clean.
So, I then cleanly shut down so that I could disconnect the ISO, and then the system booted properly.
#shutdown -h now
If you wait patiently, that command should shut down any linux OS properly, cleanly, and fully.
... View more
This apparently applies to later versions of Unity Connection and also to Office 365 when Outlook is NOT involved.
We are running 9.1(2) and Office 365 with forwarding enabled on a stand alone mailbox, and regular emails are forwarded as expected. Voicemails deposited via Unity Connection are not forwarded. The workaround is to use "Accept and Relay" or simply "relay" however the down side is that you lose synchronization.
According to this article: Inbox Rules Do Not Work on Unity Connections by Jeff Guillet (a VERY well known and respected Exchange MVP) it sounds like Cisco is not using a normal EWS/WebDav approach toplace the email in the Exchange/O365 mailbox. If Unity Connection were using a normal implementation of EWS/WebDAV, the forwarding should work.
... View more
I do have an update that you may find of interest.... I found another phone that is the same, and it is running an OLDER rev of code: App Load ID Jar41.2-9-0-117dev.sbn Boot Load ID 7961G_64-02070433Amd64megDEV.bin Version 7.0(0.151DEV) Any ideas where I can get this 7.0(0.151DEV) version? That might be the trick to getting it bootable again. Thanks! Jonathan
... View more
Thanks for taking the time to look at this. For those of you familiar with this process, I did this EXACT same procedure on a 7941G about 4 hours ago with success. From hard reset with blank screen, I was able to get it to load 7.0(2). From there, I upgraded to 8.5(2), followed by 8.5(2)SR1. From there, my call manager took over and upgraded the phone all the way to the latest rev that we had on the call manager....so this process should be the same, no? I have a 7961 that was not wanting to boot properly, and I couldn't get to the settings, so I don't know what firmware rev it was running before..... So I did the hard reset: 3491672850*# - got the blank screen on boot which was expected, followed by the line LEDs flashing green in sequence. It gets performs a TFTP request, and asks for term61.default.loads, gets an IP address, and that's it. The line lights continue to flash green in sequence until the phone appears to reboot with a quick flash of the microphone and speaker buttons, and then the headset button goes green and the line buttons continue flashing green in sequence.... If I hold down the # button while plgging it in, the speaker button will remain green for a bit, then the line buttons will flash in sequence amber, until I enter the reset string 123456789*0#, which makes the line buttons flash green in sequence, and the process continues from there as before. If I enter the hard reset string of 3491672850*#, the line buttons go from amber to red and flash in sequence for a bit, then the switch to green and sequence for a bit. I have tried every firmware version from 7.0(2) (the oldest I can find on Cisco.com for a 7961G) all the way up to 8.5(4) I watch the tftps client (tftpd64) and my ping stats - I see the tftp request as soon as I see ping responses, and that's it. It downloads the one term61.default.loads file, and then that's it. no other downloads. Then after just over a minute, the ping requests time out, and the cycle starts over. So, I unplug it and move on to the next version hoping that I would find one that works. Is my phone bricked, or is there something else I am missing? Is it possible that there is an older term61.default.loads that the phone is looking for that is no longer on Cisco.com? Thanks, Jonathan
... View more