Pudd causes screeching from internal speaker during backup

Please post any bugs you have found
Post Reply
Message
Author
Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

Pudd causes screeching from internal speaker during backup

#1 Post by Sylvander »

1. I've used Pudd a few times to both backup a partitions' contents and restore them.
Both worked just fine.
But now things have changed.

2. Now when I complete the final step of specifying that zeros should be written to the "unused" space on the partition...
And the copying and compression of the partition contents begins...
The yellow window appears and my [Compaq Deskpro EN] PC's internal speaker begins to both beep extremely rapidly plus there's a raucus rasping like rough "pink noise".

POSSIBLE CAUSE?
3. Experimenting with the dd command?
I'm fairly experienced in Windows, but a beginner in Puppy/Linux/dd.
e.g.
(a) Backup your bootsector.
Seemed to succeed just fine.

(b) Testing sda was OK using a dd command.
Got it here at the forum.
Something like:
dd if=/dev/sda of=/dev/null

4. TESTS COMPLETED
Using the dd command.
e.g. From Learn the DD command.

(a) Backup C:=[sda1] to a file on USB FAT32 S: partition=[sdb5]:
dd if=/dev/sda1 of=/mnt/sdb5/deskpro/Pudd/Win2000Pro/090308.image bs=4096 conv=notrunc,noerror
Sort of succeeded!
Because the C: partition is about 6GB, the image file is about 4.3GB, which is too big for the FAT32 partition. It needs to be compressed to produce a file no greater than 4.0GB.
A 4.0 GB image file was produced and the dd command reported the problem.

(b) Tried running the following command in a terminal opened from within the destination folder.
dd if=/dev/sda1 ibs=4096 | gzip > 090308.image.gz conv=noerror
dd reported "gzip: conv=noerror: no such file or directory".[/url]

slippycurb
Posts: 5
Joined: Thu 12 Mar 2009, 14:36

How Strange!!!!!!!

#2 Post by slippycurb »

Wow thats sounds weird, perhaps youve stumbled onto something.....Richard d james(aka aphex twin) won a competition when he was twelve or so and managed to bleed frequencies from his spectrum 48k into the tv speaker, (which wasnt supposed to be possible)
sorry ive no explanation for your strange mishap!!

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#3 Post by Sylvander »

Managed to fix the Pudd problem. :D

See this thread->http://www.pcguide.com/vb/showthread.php?t=68775

I was correct in thinking it had something to do with messing up the Windows partition arrangements/parameters.
Not sure what it was.
Used "BootIT NG" [BiNG], played around in there, and something I did [or BiNG did] fixed the difficulty Pudd was having in attempting to copy the contents.

But it then caused other difficulties.
Couldn't use some of the arrangements set up to boot to OS's.
Used the older EBCD to restore a generic MBR.
That eliminated GRUB from the MBR, so couldn't use GRUB to boot to my 3 installed OS's [BoxPup, Windows, Ubuntu].
Used Puppy 4.1.2 [installed to a Flash Drive and loaded using WakePup2] to begin repairs.

Made a GRUB bootloader floppy.
Now able to use that to boot to all 3 OS's.
Might use either Ubuntu or BoxPup to install GRUB to the MBR.
Would like to have lots of different ways to get to the various installed OS's.

Exciting adventures in PuppyLand! :D

Learning lots.

Recommending Puppy and its various Puplets at my 1st home http://www.pcguide.com/vb/

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#4 Post by Sylvander »

1. The problem has magically disappeared [on ALL Puppies methinks] since I updated BoxPup 4.1.0 installed on an ext2 Linux partition on the internal HDD to the latest version 4.1.3

2. Is there any way to REPAIR a Puppy [installation or pup_save file?]

User avatar
sikpuppy
Posts: 415
Joined: Sun 29 Mar 2009, 05:54

#5 Post by sikpuppy »

If it's a savefile, you could try a repair using 'fsck'. If you press F2 when the boot reaches the part where is says "Press F2 for more options".

Then put in

Code: Select all

puppy pfix=fsck
the save file that is selected will be checked.

If it's a full install, then boot the Puppy disc "live" by using

Code: Select all

puppy pfix=ram
and then use the 'gparted' tool to check the partition.

Or use the command line to enter the 'fsck' command. Detailed manual is here http://www.ncsa.uiuc.edu/UserInfo/Resou ... 2/fsck.htm

This is only a basic file system check however, it is not a full blown file recovery tool which is something a little more involved.

*edit* You cannot repair a partition (or it is not advisable at any rate) that is mounted. This means either using another partition, another hard drive, a USB flash drive or a Puppy CD live to repair the disk from. You shouldn't be using the same partition that the puppy file you want to check resides on :P
ASUS A1000, 800Mhz PIII Coppermine!, 192Mb RAM, 10Gb IBM Travelstar HDD, Build date August 2001.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#6 Post by Sylvander »

I was thinking more along the lines of a "Repair Install" of the Puppy/puplet Operating System, rather like you can do with Windows.

Where all the OS files are checked for consistency, and the OS got back into good working order.

Obviously the BoxPup OS update has done this, but applying new versions of some files.
You cannot always rely on an update coming along just as a fix is needed.

User avatar
sikpuppy
Posts: 415
Joined: Sun 29 Mar 2009, 05:54

#7 Post by sikpuppy »

Probably an over temperature alarm because the backup is using 100% CPU and your PC is getting too hot? The rasping would just be your internal piezo speaker rattling,

As for checking files for consistency...someone would have to write a (bash?) script (at the very least) for that wouldn't they? Linux does have some rather powerful file comparison commands, so it's not beyond the bounds of reason or possibility.

Puppy has two modes for restoring files from the boot prompt. One is a clean, the other is a thorough clean, they are both supposed to be used for an upgrade, but that's your lot I am afraid.

They are simplistically what is involved in a Windows repair, so if you have a Puppy 4.20 Deep Thought system, mangle it, then try using the 2 cleaning methods, they might get your system back in business.
ASUS A1000, 800Mhz PIII Coppermine!, 192Mb RAM, 10Gb IBM Travelstar HDD, Build date August 2001.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#8 Post by Sylvander »

1. "Probably an over temperature alarm because the backup is using 100% CPU and your PC is getting too hot?"
NO, I'm certain that's not the case.
There has NEVER been any overheat on this PC.
Never get any alarm during long-term 100% CPU usage when scanning for viruses.

Plus I can see during the early steps in the Pudd backup that I'm about to experience problems.
This because Pudd tells that more than the chosen partition is about to be backed up. [Uh-oh, shouldn't be so]
It appends some other partition file system to the one specified.
e.g. The optical disk when working in BoxPup on the HDD...
But some other when working in Muppy loaded from a DVD...
And yet another when working in Puppy loaded from a USB Flash Drive.
Whilst working in BoxPup, I can forestall the appending of the optical disk, by placing a disk in the drive so that the disk file system is mounted, and it cannot then be chosen, and is not appended.
And there is then no screeching, and no rapid flashing of text down the Pudd window.
And the backup then completes just fine.

2. "The rasping would just be your internal piezo speaker rattling"
I think you're right there.
The speaker is attempting to screech so rapidly that it comes out like white/pink noise.

3. No big deal if there's no way to complete a total repair of a Puppy, just hoped there would be.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

Explanation and suggested fix

#9 Post by npierce »

Thanks, Sylvander, for your excellent documentation of the symptoms of this bug.

The root of this problem with Pudd is that, under certain conditions, when the user selects a partition or drive from a menu, Pudd gathers information about that partition and one or more others that were not selected. It places that information (the device name and the filesystem type) into internal variables that were meant to hold information on only the one selected partition or drive.

Those variables (SOURCEPART, SOURCEFS, FDISKPART, DESTPART, and DESTFS) then contain the device name or filesystem type of the selected partition or drive, followed by the device name or filesystem type of one or more other partitions or drives. Within the variable, the items are separated by newline characters, since they were obtained from separate lines in Pudd's internal lists of available partitions or drives.

Needless to say, when other variables are set, based on the corrupt values in these variables, they are set incorrectly, or not set at all due to syntax errors.


Pudd builds a script, backuppartition.sh, based on user input. After building the script, Pudd runs it to do the actual backup or restore work. When investigating this problem, I temporarily modified a copy of Pudd to skip running that script. That way it would build the script so that it could be examined without any risk to my drives.

Below are some of the problems in the script when the value of SOURCEPART and SOURCEFS have, respectively, the device name and filesystem type for two partitions:

Normally, to enhance compression of the backup file, the script temporarily mounts the source partition and fills unused space with zeros. But when the values of SOURCEPART and SOURCEFS are bad, what should be one line:

Code: Select all

mount -t ntfs /dev/sda1 /mnt/tmp
becomes three lines:

Code: Select all

mount -t ntfs
ext3 /dev/sda1
/dev/sda11 /mnt/tmp
None of those lines is valid, so the partition doesn't get mounted.

Then when it executes these two commands:

Code: Select all

cd /mnt/tmp
dd if=/dev/zero of=empty.tmp bs=1024 count=$PARTFREE
It is writing to the the tmp/ subdirectory of /mnt/, not the desired source partition.

Depending upon the size of the filesystem where the /mnt/ directory lives (this would usually be the unionfs or aufs for frugal installations) and the value of PARTFREE, this could quickly result in "no space on device" errors. (I have not been brave enough to actually run backuppartition.sh to see what happens, but it is not likely to be pretty.)

Later, when it is time to make the image file, what should be one line:

Code: Select all

dd if=/dev/sda1 | gzip - > /root/myfile.img.gz
becomes two lines:

Code: Select all

dd if=/dev/sda1
/dev/sda11 | gzip - > /root/myfile.img.gz
The first line is perfectly legal. So dd starts copying the partition to stdout (which is the default for output when no of= is given). And a jumble of strange text will probably scroll through the window. (Again, I've not been brave enough to try it.)

The above could explain the symptoms described above by Sylvander:
Sylvander wrote:Now when I complete the final step of specifying that zeros should be written to the "unused" space on the partition...
And the copying and compression of the partition contents begins...
The yellow window appears and my [Compaq Deskpro EN] PC's internal speaker begins to both beep extremely rapidly plus there's a raucus rasping like rough "pink noise".
And it could also explain the "rapid flashing of text down the Pudd window" that no longer appeared after he found a work-around for this problem.

A similar description is found elsewhere:
[url=http://www.pcguide.com/vb/showpost.php?p=422910&postcount=1]In another forum[/url], Sylvander wrote:After the final choices have been correctly made as per usual...
And Pudd opens its yellow window and begins making the image...
The PC's internal speaker begins bleeping/screeching/pinknoise, and all kinds of characters flash up the screen at great rate.
(Another bug thread with with reports from other folks who have run into this problem in 2011 and 2012 is here: Pudd adds partition for backup on its own)


This problem only occurs when there are at least eleven partitons or drives in a menu, and the user selects a partition or drive early in the list. For instance, if the user selects the first item in the menu, the device name for both that item and the eleventh item will be placed into the SOURCEPART, DESTPART, or FDISKPART variable. (If there were twenty-one or more items in the menu, the device name for the twenty-fist item would also be added to the variable.) Or, if the user selects the second item in the menu, the device name for both that item and the twelfth item will be placed into the SOURCEPART, DESTPART, or FDISKPART variable. If there are nineteen or more items in the menu, this pattern could continue on up through the ninth item.

Internally, Pudd identifies the menu items with names like "1PART", "2PART", etc. This problem happens because when Pudd searches its partition list for the strings "1PART", "2PART", etc., it also finds "11PART", "12PART", etc. ("11PART", "12PART", etc.).

Since those names are at the beginning of each line in the partition list, the solution is a simple one: just search for those strings at the very beginning of each line, not anywhere in the line as is currently the case. Only seven lines of code need to be changed.

I am attaching a .diff file with the suggested changes. It is based upon the Pudd currently in Woof (dated "2012-03-31 09:07:26").

A utility with the power to overwrite partitions and drives yet is sometimes confused about which partition or drive to overwrite is kind of a scary thing. While I would like to think that my suggested changes will totally fix this problem, I would not recommend that anyone use this on any PC that has any important data on its drives until someone with eleven or more partitions (containing nothing irreplaceable) gives this some thorough testing.
Attachments
Pudd.diff.gz
Suggested changes to Pudd
(667 Bytes) Downloaded 572 times

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#10 Post by BarryK »

Fixes applied, see here guys:

http://bkhome.org/blog2/?viewDetailed=00104
[url]https://bkhome.org/news/[/url]

Post Reply