PIONEERS RasPi3: Incredible PBX for XiVO

dallas

Active Member
Joined
Oct 21, 2007
Messages
219
Reaction score
31
Location
Sydney, Australia
The reason I ask is that I have compiled a g729 codec on my Incredible PBX 4.11.3 for RasPBX. My question is can I just add the g729 modules I compiled on my Pi2 & Pi3 to the XiVO version on a Pi3 or are the asterisk modules compiled into the XiVO executable?
 

SMTC

Member
Joined
Jan 22, 2009
Messages
162
Reaction score
8
@SMTC: We have RasPi's with the same track record. The problem is that most folks DON'T buy a spare RasPi and most folks NEVER make a backup image. That's why we don't recommend them for production systems. If you do those 2 things and you've got physical access to the RasPi with a hot standby, it's a wonderful VoIP platform. We use them at our rental properties to provide free phone service and never have a problem. As you say, swapping out the SD cards once a year works wonders.

XiVO is a bit more disk intensive so I can't vouch for a full year of use with it yet.
After reverting back to Incredible PBX 13-12.5 I am now happy with the stability. I have taken a snapshot of the MicroSD card using the Win32DiskImager and then tried to do a restore to what I thought was the same Kingston 32GB Class 10 chip as is running in my active PBX.

Apparently not all Kingston 32GB Class 10 cards have the same geometry! There is just slightly not enough space to copy over the backup to the new chip.

So, the question is - how can I make a slightly smaller image file that can be periodically backed up and restored to similar SD cards?
 

jerrm

Guru
Joined
Sep 23, 2015
Messages
533
Reaction score
223
One reason I never expand the partition to use the entire card - I restrict it to 90%.

If the source partitioned space was using the full disk, the easiest option is probably to use something like gparted live cd/usb to resize the source partition(s) and re-image.

Tools like Win32DiskImager will still image the entire drive, but it will be safe to truncate the image file to a size that will restore to the target.

If the source partitioned space was already smaller than the full drive, it's safe to truncate the extra space off of the image.

You can do the math and come up with the exact size to truncate, but I just use safe round numbers. If I have 29gb partitioned, I truncate the image at something like 30gb.
 
  • Like
Reactions: wardmundy

SMTC

Member
Joined
Jan 22, 2009
Messages
162
Reaction score
8
Truncate? Sounds like a very manual and generically bad idea. And if you get a "slightly larger" 32 GB card and it becomes the working one then are you not then going to have to find yet again a slightly larger chip for the next iteration? If you take a 32GB image to a 64GB chip, will that always fit or the first time you Win32DiskImager Read it, will you get a 64GB IMG file?

Seems to me there has to be someone out there that has this licked? A way to format a microSD and restore backed up partitions (The small FAT and the larger EXT4)?

The initial objective was to have a full snapshot backup that can be restored to a standby Pi3 and microsSD.

Seems I have come across folks saying that even identical part number chips can have some marked bad bits and so won't be perfectly the same size. How can we succeed?
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,234
Reaction score
2,667
Not to beat a dead horse, but we've probably built a hundred or more RasPi images on 16GB and 32GB cards over the past 5 years. I've only seen this problem one time. You probably had a very good card that you originally imaged, and now you have another one with bad sectors. Like I said, try another card from another reputable manufacturer. You'll probably be just fine.
 

jerrm

Guru
Joined
Sep 23, 2015
Messages
533
Reaction score
223
Truncate? Sounds like a very manual and generically bad idea.
Manual yes, bad idea, no. Win32DiskImager is already a manual process.

Not using all of the possible space on the card is the only way to be 100% sure the image will safely fit on a target of the "same" size. I can't say how often it happens overall, but it was enough of a headache we got tired of fixing it after the fact and adopted the 90% rule for partitioned space long ago.

95% or even 99% is probably safe. The extra unused space will help with wear leveling and increase the life of the card in general, especially if approaching full usage of the partitioned space, so we stick with 90% max partitioned for SD and USB.

It's not necessary to physically truncate the image file. If sure the partitioned space will fit on the target (90% rule makes sure it will for "same" size cards), just use dd under Linux or Cygwin to write what it can of the image.

And if you get a "slightly larger" 32 GB card and it becomes the working one then are you not then going to have to find yet again a slightly larger chip for the next iteration?

If you take a 32GB image to a 64GB chip, will that always fit or the first time you Win32DiskImager Read it, will you get a 64GB IMG file?
That is exactly what it means. Win32DiskImager is a dumb tool and knows nothing of partition tables. It is a byte for byte copy of the entire device. If you have a 2GB of partitioned space on a 128GB card, you will get a 128GB image, 126GB of which is garbage. The only way for Win32DiskImager to restore that image to less than a 128GB target is to truncate the file.

Unfortunately Win32DiskImager doesn't have an option (to my knowledge) to write what it can and stop. Even if it did, you have to ensure the partitioned space safely fits on the target (90% rule again).

dd is a better utlility to use for both read and write in my opinion. It's dumb too, but at least can be told how much to read or write.

Seems to me there has to be someone out there that has this licked? A way to format a microSD and restore backed up partitions (The small FAT and the larger EXT4)?.
We do - using these simple techniques.

For the PBX's and some other Pi uses, we also keep local nightly backups to an SD card in a USB reader - ready to swap and boot, and to an image file mounted remotely using a backup script based on the RasPBX image backup script - ready to burn and boot.

Seems I have come across folks saying that even identical part number chips can have some marked bad bits and so won't be perfectly the same size. How can we succeed?
"Same Part Number" doesn't mean anything, regardless of bad bits. Underlying chips can change with each production run.
 
  • Like
Reactions: ostridge

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,234
Reaction score
2,667
@jerrm: If you wouldn't mind, please document the steps to do the 90% drill when you have the time. Thanks.
 
  • Like
Reactions: ostridge

SMTC

Member
Joined
Jan 22, 2009
Messages
162
Reaction score
8
Not to beat a dead horse, but we've probably built a hundred or more RasPi images on 16GB and 32GB cards over the past 5 years. I've only seen this problem one time. You probably had a very good card that you originally imaged, and now you have another one with bad sectors. Like I said, try another card from another reputable manufacturer. You'll probably be just fine.
Hi Ward, Just received yet another new microSD 32GB Kingston card. This one is the exact part# (SDC10G2/32GBCR) match to my current running one. I get the very same error in that I am about 7000 512byte sectors short of what is needed. (3,500K)

Going to need some help with a script to write out a back up chip using other tools....
 

SMTC

Member
Joined
Jan 22, 2009
Messages
162
Reaction score
8
Manual yes, bad idea, no. Win32DiskImager is already a manual process.

Not using all of the possible space on the card is the only way to be 100% sure the image will safely fit on a target of the "same" size. I can't say how often it happens overall, but it was enough of a headache we got tired of fixing it after the fact and adopted the 90% rule for partitioned space long ago.

95% or even 99% is probably safe. The extra unused space will help with wear leveling and increase the life of the card in general, especially if approaching full usage of the partitioned space, so we stick with 90% max partitioned for SD and USB.

It's not necessary to physically truncate the image file. If sure the partitioned space will fit on the target (90% rule makes sure it will for "same" size cards), just use dd under Linux or Cygwin to write what it can of the image.


That is exactly what it means. Win32DiskImager is a dumb tool and knows nothing of partition tables. It is a byte for byte copy of the entire device. If you have a 2GB of partitioned space on a 128GB card, you will get a 128GB image, 126GB of which is garbage. The only way for Win32DiskImager to restore that image to less than a 128GB target is to truncate the file.

Unfortunately Win32DiskImager doesn't have an option (to my knowledge) to write what it can and stop. Even if it did, you have to ensure the partitioned space safely fits on the target (90% rule again).

dd is a better utlility to use for both read and write in my opinion. It's dumb too, but at least can be told how much to read or write.


We do - using these simple techniques.

For the PBX's and some other Pi uses, we also keep local nightly backups to an SD card in a USB reader - ready to swap and boot, and to an image file mounted remotely using a backup script based on the RasPBX image backup script - ready to burn and boot.


"Same Part Number" doesn't mean anything, regardless of bad bits. Underlying chips can change with each production run.
I would be very grateful for some step by step instructions on how to get a partition backup onto my backup chip. Don't know exactly how you are doing it but the Rasp Pi3 came with a USB 3.0 microSD chip reader. Can this be plugged into my running PBX and then using DD to copy the running and active over to the backup - including whatever it takes to make it transparently bootable? Do we need to stop the PBX, reduce run levels etc in order to close any open file locks?
 

Members online

No members online now.

PIAF 5 - Powered by 3CX

Forum statistics

Threads
22,449
Messages
138,027
Members
14,613
Latest member
roshan2019