Dan,
Your welcome and good luck.
Thank You,
Fernando Fuentes
DIGITALVOIPNET.COM
On Thu, Nov 29, 2012 at 12:58 PM, Dan Ryson <d...@ryson.org> wrote:
> Michael, Fernando, Lonnie, and Ron,
>
> To reduce clutter, I hope you'll accept a single, "thank you!" for taking
> time to help me find my way out of trouble. Lonnie, I particularly
> appreciate the detailed, step-by-step instructions.
>
> I guess this is what I get for making up my own restoration procedure
> instead of following the published installation instructions. If nothing
> else, perhaps this will help others avoid the same mistake.
>
> I'll report my findings as soon as we (hopefully) have a success story to
> tell!
>
> Take care,
>
> Dan
>
> -----Original Message-----
> From: Lonnie Abelbeck [mailto:li...@lonnie.abelbeck.com]
> Sent: Thursday, November 29, 2012 12:44 PM
> To: AstLinux Users Mailing List
> Subject: Re: [Astlinux-users] Backup => Restore to Different Platform?
>
> Dan,
>
> No need to try the serial console version, the core is exactly the same.
>
> I have never seen the issues you describe, but I have never performed the
> unionfs shortcut as you have done either.
>
> Personally I would rebuild a your SATA Flash module from scratch...
>
> 1.) Physdiskwrite.exe under Windows to write the SATA image
> 2.) Boot from SATA on NF99FL-525
> 3.) Use web interface to create a new /dev/sda2, install sounds, etc.
>
> Next I would go to the old net5501's web interface, System->
> Configuration/File Backup: [ All /mnt/kd/ files ], then click { Download
> Backup }
>
> On your new NF99FL-525 box increase the /tmp size limit, 100m allows 100MB,
> anything safely larger then your .tar.gz you downloaded.
>
> $ mount -o remount,size=100m /tmp
>
> Then, ftp the net5501's backup pbx-full-2012-11-29.tar.gz to the default
> /root directory on the NF99FL-525. Then stop Asterisk to be safe.
>
> $ service asterisk stop
>
> Finally, overwrite the current /mnt/kd with the tar backup.
>
> $ tar xzvf pbx-full-2012-11-29.tar.gz -C /mnt/kd
>
> Reboot, while fingers crossed. :-)
>
> The only thing still possibly missing is any changes to unionfs such as AGI
> scripts or such, but normally you should be good to go.
>
> Lonnie
>
>
> On Nov 29, 2012, at 10:53 AM, Dan Ryson wrote:
>
> > Hello!
> >
> > It seems my long run of good fortune has taken a turn for the worse.
> > After years of rock-solid AstLinux reliability, I've run into some
> > trouble. I'm hopeful that your expertise can help me get back to better
> times.
> >
> > Sorry... This is a bit of a ramble. But I'd like to provide a
> > detailed view of what we are seeing before soliciting your thoughts.
> >
> > Six hours after putting new hardware into service, I was INUNDATED
> > with file system related error messages in the log. I've pasted a
> > snippet below, which repeated continuously every few seconds for
> > several hours until I shut it down.
> >
> > This is the second time I've encountered this symptom in just a few days.
> > Both events were on virtually on the same hardware, a brand new
> NF99FL-525.
> > The first time this symptom appeared, I was temporarily using a USB
> > thumb drive in lieu of the recommended Emphase Industrial SATA module.
> > Because I suspected both the USB thumb drive and my twist on the
> > official installation procedure, I later installed the proper SATA
> > module and asked our group for advice regarding the general idea of
> > copying /oldroot/mnt/asturw from one platform to another. (Thanks
> > again for the ideas and comments.) Regardless, the symptom has repeated.
> >
> > Here is a more detailed version of the installation procedure that I
> used:
>
> >
> > 1.) Physdiskwrite.exe under Windows to write the SATA image
> > 2.) Boot from SATA on NF99FL-525
> > 3.) Use web interface to create a new /dev/sda2, install sounds, etc.
> > 3.) Use a Linux version of FileZilla to download /oldroot/mnt/asturw
> > from the old Soekris net5501
> > 4.) Use the same Filezilla to upload /oldroot/mnt/asturw to the new
> > NF99FL-525
> > 5.) Reboot
> > 6.) Test
> > 7.) Put in service
> >
> > The first time around (booting from USB last Friday), the unit worked
> > fine for ~36 hours and then starting throwing I/O errors. When I
> > realized this was happening, I remotely requested a reboot. The
> > machine shut down but didn't come back up until I arrived on-site and
> cycled the power.
> >
> > This time (booting from SATA flash yesterday evening), it ran only ~6
> > hours before errors appeared. Before rebooting, I downloaded the
> > messages file and noticed these symptoms: When I called into my voice
> > mail, app_voicemail generated this WARNING: "Unable to stream
> > password file". When dialing into our conference bridge, the dial
> > plan tried but failed to Playback sound file "conf-thereare".
> > App_playback WARNED, "ast_streamfile failed for conf-thereare."
> >
> > Upon a power cycle and reboot this morning, I noticed "fsck detected
> > errors on sta2" which it apparently corrected. (It went by in a
> > blur...) After taking the unit out of service, it's been running
> > without I/O errors for a couple of hours. However, it's really not
> > really doing anything either - except bitterly complaining about not
> > having a network route to phones or providers.
> >
> > Here's the log snippet. Imagine many MB of this, repeated over and
> > over again. Roughly 95 percent of the lines that specify a sector
> > number, such as "I/O error, dev sda, sector 524160" show either sector
> 524160 or 3145616.
> > Every now and again, a few other sector numbers also appear.
> >
> > Nov 29 06:31:13 sip user.info kernel: sd 1:0:0:0: [sda] Unhandled
> > error code Nov 29 06:31:13 sip user.info kernel: sd 1:0:0:0: [sda]
> Result:
> > hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Nov 29 06:31:13 sip
> > user.info kernel: sd 1:0:0:0: [sda] CDB: Read(10): 28 00
> > 00 2f ff 90 00 00 08 00
> > Nov 29 06:31:13 sip user.err kernel: end_request: I/O error, dev sda,
> > sector
> > 3145616
> > Nov 29 06:31:13 sip user.err kernel: EXT2-fs (sda2): previous I/O
> > error to superblock detected Nov 29 06:31:13 sip user.info kernel: sd
> > 1:0:0:0: [sda] Unhandled error code Nov 29 06:31:13 sip user.info
> > kernel: sd 1:0:0:0: [sda] Result:
> > hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Nov 29 06:31:13 sip
> > user.info kernel: sd 1:0:0:0: [sda] CDB: Write(10): 2a
> > 00 00 07 ff 80 00 00 08 00
> > Nov 29 06:31:13 sip user.err kernel: end_request: I/O error, dev sda,
> > sector
> > 524160
> > Nov 29 06:31:13 sip user.err kernel: Buffer I/O error on device sda2,
> > logical block 0 Nov 29 06:31:13 sip user.warn kernel: lost page write
> > due to I/O error on
> > sda2
> > Nov 29 06:31:13 sip user.crit kernel: EXT2-fs (sda2): error:
> ext2_get_inode:
> > unable to read inode block - inode=81936, block=327682 Nov 29 06:31:13
> > sip user.err kernel: EXT2-fs (sda2): previous I/O error to superblock
> > detected Nov 29 06:31:13 sip user.info kernel: sd 1:0:0:0: [sda]
> > Unhandled error code Nov 29 06:31:13 sip user.info kernel: sd 1:0:0:0:
> > [sda] Result:
> > hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Nov 29 06:31:13 sip
> > user.info kernel: sd 1:0:0:0: [sda] CDB: Write(10): 2a
> > 00 00 07 ff 80 00 00 08 00
> > Nov 29 06:31:13 sip user.err kernel: end_request: I/O error, dev sda,
> > sector
> > 524160
> > Nov 29 06:31:13 sip user.err kernel: Buffer I/O error on device sda2,
> > logical block 0 Nov 29 06:31:13 sip user.warn kernel: lost page write
> > due to I/O error on
> > sda2
> > Nov 29 06:31:13 sip user.crit kernel: EXT2-fs (sda2): error: ext2_fsync:
> > detected IO error when writing metadata buffers
> >
> > While this really smells like a hardware problem, it seems odd that I
> > could have both a bad USB and bad SATA flash module. Where might I be
> > going wrong? Other than trying the serial version (which I'll
> > probably do this afternoon), what might you do in a situation like this?
> >
> > Thanks for any insight,
> >
> > Dan
> >
> > -----Original Message-----
> > From: Lonnie Abelbeck [mailto:li...@lonnie.abelbeck.com]
> > Sent: Wednesday, November 28, 2012 3:31 PM
> > To: AstLinux Users Mailing List
> > Subject: Re: [Astlinux-users] Backup => Restore to Different Platform?
> >
> > Hi Dan,
> >
> > In addition to the "70-persistent-net.rules" file as Michael pointed
> > out, you may (or many not) have a "/etc/rc.modules" file, you will
> > need the "e1000e" line uncommented for your NF99FL-525.
> >
> > Personally I prefer the geni586-serial version, but the geni586 (VGA)
> > will work fine if you prefer a video console.
> >
> > Lonnie
> >
> >
> > On Nov 28, 2012, at 8:55 AM, Dan Ryson wrote:
> >
> >> All,
> >>
> >> Following David's excellent comment about backups by rsync (pasted
> >> below),
> > I've been keeping copies of /oldroot/mnt/asturw. It's a simple,
> > painless backup procedure.
> >>
> >> I'm now replacing a production Soekris net5501 with a shiny new
> >> Jetway
> > NF99FL-525. Presuming I start by installing the Generic i586 (VGA)
> > image on the Jetway, is it permissible to simply use ssh to copy the
> > Soekris' asturw file tree to the new machine? If so, this would be a
> > brain-dead simple way to migrate to the different hardware. Or are
> > there differences between the two asturws that will cause pain and agony?
> >>
> >> Thanks for any thoughts, recommendations, or advice.
> >>
> >> Dan
> >>
> >> From: David Kerr [mailto:da...@kerr.net]
> >> Sent: Tuesday, November 20, 2012 12:13 PM
> >> To: AstLinux Users Mailing List
> >> Subject: Re: [Astlinux-users] Mixmonitor storage options
> >>
> >> I actually do a pull from a server (actually a ReadyNAS box) for my
> > AstLinux backup... rsync over ssh with certificates so no
> userid/password.
> > The remote server has an hourly cron job that runs the rsync....
> >>
> >> #!/bin/bash
> >> rsync -avz -e "ssh -p<your-ssh-port>"
> > root@<your-pbx-url>:/oldroot/mnt/asturw /c/home/david/PBXbackup
> >>
> >> This way there is no dependency on anything running on the Astlinux box.
> > Something similar would work to pull off call recordings for safe
> storage.
> >>
> >> David
> >
> >
> > ----------------------------------------------------------------------
> > -------- Keep yourself connected to Go Parallel:
> > VERIFY Test and improve your parallel project with help from experts
> > and peers. http://goparallel.sourceforge.net
> > _______________________________________________
> > Astlinux-users mailing list
> > Astlinux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
> >
> >
>
>
>
> ----------------------------------------------------------------------------
> --
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts and
> peers. http://goparallel.sourceforge.net
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts
> and peers. http://goparallel.sourceforge.net
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
