[j-nsp] Update failed on J-Series

Ben Dale bdale at comlinx.com.au
Tue Mar 10 20:59:26 EDT 2009 

My experience with upgrading on the J-Series is as follows:

In order to UPGRADE to 9.x you will need 512MB - that is you need  
enough space in flash to store AND expand the 9.x code during the  
upgrade and 256MB doesn't seem to cut it (even after "request system  
storage cleanup" etc).

If however you already have a box with 9.x on it, I have had success  
with running a "request system snapshot media removable-compact- 
flash"  to copy a working image back onto a 256MB flash, but clearly  
if you do this, you're going to have to go through the whole process  
again next upgrade (and you will have to physically visit each site to  
drop in flash cards etc).

Do yourself a favour and grab some 1GB compact flash cards (though not  
from Juniper) and make this issue go away for a few years - until  
JUNOS doubles in size again!


On 10/03/2009, at 12:15 AM, Patrik Olsson wrote:

I actually dont know why. I can just say I had the same experience as
you until I upgraded my flash to 1 1G flash (even though 512MB would
have been enough). With a larger flash the whole update worked fine.

Cheers
Patrik


Matthias Gelbhardt wrote:
> Hi!
>
> But why. I just saw in the Release notes, that the minimum flash
> required is 256, maximum ist 512.
>
> Regards,
>
> Matthias
>
> Am 08.03.2009 um 20:40 schrieb Patrik Olsson:
>
>> Then that is the problem.
>>
>> cheers
>> patrik
>>
>> Matthias Gelbhardt wrote:
>>> Hi!
>>>
>>> Perhaps the problem? The disk is 256 MB
>>>
>>> Regards,
>>>
>>> Matthias
>>>
>>> Am 08.03.2009 um 13:11 schrieb Patrik Olsson:
>>>
>>>> You need to make sure you have the new larger flash to go 9.X.  
>>>> Whats
>>>> your flashdisk size?
>>>>
>>>> Cheers
>>>> Patrik
>>>>
>>>> Matthias Gelbhardt wrote:
>>>>> Hi!
>>>>>
>>>>> Yesterday I tried to upgrade a J-Series from 8.5 to 9.3R2. Shortly
>>>>> after
>>>>> the reboot I got a segmentation fault, every time the forwarding
>>>>> daemon
>>>>> started. When I try to start the daemon manualy, the segmentation
>>>>> fault
>>>>> also occur. A rollback was successfully, to the system runs stable
>>>>> under
>>>>> 8.5 for now.
>>>>>
>>>>> The log:
>>>>>
>>>>> Mar  6 23:50:52  nordhorn2 /kernel: BAD_PAGE_FAULT: pid 4288
>>>>> (fwdd), uid
>>>>> 0: pc 0x80c0af3 got a write fault at 0x0, x86 fault flags = 0x6
>>>>> Mar  6 23:50:52  nordhorn2 /kernel: Trapframe Register Dump:
>>>>> Mar  6 23:50:52  nordhorn2 /kernel:     eax: 00000000    ecx:
>>>>> 00000000    edx: 00000000    ebx: 0000000c
>>>>> Mar  6 23:50:52  nordhorn2 /kernel:     esp: 4b4b0670    ebp:
>>>>> 4b4b0758    esi: 4c67198c    edi: 4c6bcfa8
>>>>> Mar  6 23:50:52  nordhorn2 /kernel:     eip: 080c0af3    eflags:
>>>>> 00013206
>>>>> Mar  6 23:50:52  nordhorn2 /kernel:     cs: 0033    ss: 003b     
>>>>> ds:
>>>>> 4b4b003b    es: b003b
>>>>> Mar  6 23:50:52  nordhorn2 /kernel:     fs: 4b4b003b    trapno:
>>>>> 0000000c    err: 00000006
>>>>> Mar  6 23:50:52  nordhorn2 /kernel: Page table info for PC address
>>>>> 0x80c0af3: PDE = 0x30440067, PTE = 38491625
>>>>> Mar  6 23:50:52  nordhorn2 /kernel: Dumping 16 bytes starting at  
>>>>> PC
>>>>> address 0x80c0af3:
>>>>> Mar  6 23:50:52  nordhorn2 /kernel:     89 04 8a ff 45 a8 8b 5d 98
>>>>> 81 c6
>>>>> b0 00 00 00 39
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]:
>>>>> --------------------------------------
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Segmentation Fault!
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Registers:
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: eip: 0x080c0af3 eflags:
>>>>> 0x00013206    trapno: 12
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: eax: 0x00000000    ebx:
>>>>> 0x0000000c    ecx: 0x00000000    edx: 0x00000000
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: esi: 0x4c67198c    edi:
>>>>> 0x4c6bcfa8    esp: 0x4b4b0670    ebp: 0x4b4b0758
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: cs: 0x0033 ds: 0x4b4b003b  
>>>>> es:
>>>>> 0xb003b fs: 0x4b4b003b gs: 0x001b ss: 0x003b
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Traceback:
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 0: sp = 0x4b4b0758,  
>>>>> pc =
>>>>> 0x828d08b
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 1: sp = 0x4b4b0838,  
>>>>> pc =
>>>>> 0x828b502
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 2: sp = 0x4b4b08a8,  
>>>>> pc =
>>>>> 0x82856ef
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 3: sp = 0x4b4b08e8,  
>>>>> pc =
>>>>> 0x8266a07
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 4: sp = 0x4b4b0948,  
>>>>> pc =
>>>>> 0x81e1532
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 5: sp = 0x4b4b0998,  
>>>>> pc =
>>>>> 0x81e1d08
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 6: sp = 0x4b4b0a38,  
>>>>> pc =
>>>>> 0x81df84a
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 7: sp = 0x4b4b0a78,  
>>>>> pc =
>>>>> 0x81c615b
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 8: sp = 0x4b4b0aa8,  
>>>>> pc =
>>>>> 0x81c62a9
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 9: sp = 0x4b4b0ac8,  
>>>>> pc =
>>>>> 0x81c313b
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 10: sp =  
>>>>> 0x4b4b0b08, pc =
>>>>> 0x81c3621
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 11: sp =  
>>>>> 0x4b4b0b38, pc =
>>>>> 0x81c5340
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 12: sp =  
>>>>> 0x4b4b0b68, pc =
>>>>> 0x804cb60
>>>>> Mar  6 23:50:52  nordhorn2 fwdd[4288]: Frame 13: sp =  
>>>>> 0x4b4b0b70, pc
>>>>> = 0x0
>>>>> Mar  6 23:50:53  nordhorn2 pfed: SNMP_NS_LOG_INFO: NET-SNMP  
>>>>> version
>>>>> 5.3.1 AgentX subagent connected
>>>>> Mar  6 23:50:59  nordhorn2 /kernel: pid 4288 (fwdd), uid 0:  
>>>>> exited on
>>>>> signal 11 (core dumped)
>>>>> Mar  6 23:50:59  nordhorn2 /kernel: peer_inputs: soreceive()  
>>>>> error 0
>>>>> Mar  6 23:50:59  nordhorn2 /kernel: pfe_listener_disconnect: conn
>>>>> dropped: listener idx=0, tnpaddr=0x1, reason: socket error
>>>>> Mar  6 23:50:59  nordhorn2 /kernel: pfe_peer_update_mgmt_state:
>>>>> type 10,
>>>>> index 0, old state Online new state Closed mastership 1
>>>>> Mar  6 23:50:59  nordhorn2 chassisd[4277]:
>>>>> CHASSISD_FRU_OFFLINE_NOTICE:
>>>>> Taking FPC 0 offline: Error
>>>>> Mar  6 23:50:59  nordhorn2 chassisd[4277]:  
>>>>> CHASSISD_IFDEV_DETACH_FPC:
>>>>> ifdev_detach(0)
>>>>>
>>>>> This error is reproducable under 9.3R2. Finally the chassid is  
>>>>> taking
>>>>> down the interfaces.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Matthias
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>>
>>>> -- 
>>>>
>>>> //Patrik
>>>>
>>>> Webkom
>>>> http://www.webkom.se
>>>>
>>>> +46 (0)709 35 22 99
>>>> +46 (0)8 559 26 488
>>>>
>>>>
>>
>>
>> -- 
>>
>> //Patrik
>>
>> Webkom
>> http://www.webkom.se
>>
>> +46 (0)709 35 22 99
>> +46 (0)8 559 26 488
>>
>>


-- 

//Patrik

Webkom
http://www.webkom.se

+46 (0)709 35 22 99
+46 (0)8 559 26 488


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

More information about the juniper-nsp mailing list