Re: [j-nsp] some bugs to avoid
Yes, but the system mountes them from root so if we have corrupted root, the system will not boot. On 18.05.2011 1:09, Stacy W. Smith wrote: That's probably not worth the hassle. The operating system is already mounted as a set of read-only memory-disk file systems from ISO images embedded within the install package. In addition, the verified-exec functionality will only allow Juniper-signed binaries to be executed. --Stacy lab@mxC-1> show system storage Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 885M 141M 673M 17% / devfs 1.0K 1.0K 0B 100% /dev /dev/md0 43M43M 0B 100% /packages/mnt/jbase /dev/md1231M 231M 0B 100% /packages/mnt/jkernel-ppc-10.3R1.9 /dev/md2 15M15M 0B 100% /packages/mnt/jpfe-MX80-10.3R1.9 /dev/md36.4M 6.4M 0B 100% /packages/mnt/jdocs-10.3R1.9 /dev/md4 72M72M 0B 100% /packages/mnt/jroute-ppc-10.3R1.9 /dev/md5 18M18M 0B 100% /packages/mnt/jcrypto-ppc-10.3R1.9 /dev/md62.8G 8.0K 2.6G0% /tmp /dev/md72.8G 4.3M 2.6G0% /mfs /dev/da0s1e 98M14K90M0% /config procfs 4.0K 4.0K 0B 100% /proc /dev/da1s1f 2.8G 279M 2.3G 11% /var lab@mxC-1> start shell % mount /dev/da0s1a on / (ufs, local, noatime) devfs on /dev (devfs, local) /dev/md0 on /packages/mnt/jbase (cd9660, local, noatime, read-only, verified) /dev/md1 on /packages/mnt/jkernel-ppc-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md2 on /packages/mnt/jpfe-MX80-10.3R1.9 (cd9660, local, noatime, read-only) /dev/md3 on /packages/mnt/jdocs-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md4 on /packages/mnt/jroute-ppc-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md5 on /packages/mnt/jcrypto-ppc-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md6 on /tmp (ufs, local, noatime, soft-updates) /dev/md7 on /mfs (ufs, local, noatime, soft-updates) /dev/da0s1e on /config (ufs, local, noatime) procfs on /proc (procfs, local, noatime) /dev/da1s1f on /var (ufs, local, noatime) On May 17, 2011, at 1:43 PM, Tima Maryin wrote: Did anyone try to hack /etc/fstab in order to mount / as read-only? Can it help ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] some bugs to avoid
Did anyone try to hack /etc/fstab in order to mount / as read-only? Can it help ? On 17.05.2011 3:14, Jeff Wheeler wrote: We have had our first instance of serious filesystem corruption on an EX4200 running 10.3R1.9. I am hopeful that the new-fangled stuff in 10.4 will stop these incidents from causing switches to reboot into an un-usable state requiring a reinstall from USB. :-/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] some bugs to avoid
Hi Jeff, Could you provide a little more information on your last fault with the MX80 as I am in the process on rolling out the code 10.4R4.5 to MX480's. If you have a case number off list that would be great as I will be asking the J-TAC about this as well. Thanks Patrick --- Patrick Tye Senior IP Engineer Primus Telecommunications Aust. Email: p...@primustel.com.au - - Original Message - From: "Jeff Wheeler" To: Sent: Tuesday, May 17, 2011 9:14 AM Subject: [j-nsp] some bugs to avoid We have had our first instance of serious filesystem corruption on an EX4200 running 10.3R1.9. I am hopeful that the new-fangled stuff in 10.4 will stop these incidents from causing switches to reboot into an un-usable state requiring a reinstall from USB. :-/ In other news, we also observed an M160 with two REs (one in the process of upgrading from JUNOS 6.2) exhibit an interesting new failure mode. The second RE incorrectly reported its CPU Temperature as about 800 million degrees, which caused the master RE's chassisd to spawn children emitting warnings about 3 times each minute. Unfortunately, chassisd was not wait(2)ing on these children after they exited. This produced additional console warnings about the maximum number of processes for uid 0. After about 15 minutes, there were enough children of chassisd that the kernel process table was full, resulting in a kernel panic and automatic reboot. We had to remove the second routing engine to prevent it from happening a second time. IRB on MX80 10.4R4.5 appears badly broken, too. Configuring a bridge-domain with one untagged/"access" interface and one dot1q-tagged sub-interface, plus an IRB interface for layer-3, is a pretty good way to waste a couple hours troubleshooting the router. It works fine most of the time, and all looks well in the PFE console; but a few times per hour the Bridge-Domain simply stops forwarding any traffic, while the IRB loses its ARP entries. This fault sometimes lasts long enough for BGP to drop. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] some bugs to avoid
We have had our first instance of serious filesystem corruption on an EX4200 running 10.3R1.9. I am hopeful that the new-fangled stuff in 10.4 will stop these incidents from causing switches to reboot into an un-usable state requiring a reinstall from USB. :-/ In other news, we also observed an M160 with two REs (one in the process of upgrading from JUNOS 6.2) exhibit an interesting new failure mode. The second RE incorrectly reported its CPU Temperature as about 800 million degrees, which caused the master RE's chassisd to spawn children emitting warnings about 3 times each minute. Unfortunately, chassisd was not wait(2)ing on these children after they exited. This produced additional console warnings about the maximum number of processes for uid 0. After about 15 minutes, there were enough children of chassisd that the kernel process table was full, resulting in a kernel panic and automatic reboot. We had to remove the second routing engine to prevent it from happening a second time. IRB on MX80 10.4R4.5 appears badly broken, too. Configuring a bridge-domain with one untagged/"access" interface and one dot1q-tagged sub-interface, plus an IRB interface for layer-3, is a pretty good way to waste a couple hours troubleshooting the router. It works fine most of the time, and all looks well in the PFE console; but a few times per hour the Bridge-Domain simply stops forwarding any traffic, while the IRB loses its ARP entries. This fault sometimes lasts long enough for BGP to drop. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
