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.
