[j-nsp] Update failed on J-Series
alain.briant at bt.com
alain.briant at bt.com
Wed Mar 11 05:17:17 EDT 2009
Hi all
On my side I have a some Jseries running 9.3 (R1 not R2) with only 256Mb of Flash without problem
As I can remember, the upgrade has done using the command:
"request system storage cleanup"
And
"request system software add no-copy unlink ----- reboot"
--- JUNOS 9.3R1.7 built 2008-11-12 23:38:19 UTC
Alain at J6350> show chassis hardware detail
Hardware inventory:
Item Version Part number Serial number Description
Chassis xxxxxxxxxxxx J6350
Midplane REV 03 710-014593 xxxxxx
System IO REV 01 710-016210 xxxxxx JX350 System IO
Crypto Module Crypto Acceleration
Routing Engine REV 10 710-015273 xxxxxx RE-J6350-3400
ad0 244 MB 256MB CHH 5073G0C31A3267000F Compact Flash
FPC 0 FPC
-----Message d'origine-----
De : juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] De la part de Ben Dale
Envoyé : mercredi 11 mars 2009 01:59
À : juniper-nsp
Objet : Re: [j-nsp] Update failed on J-Series
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
_______________________________________________
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