Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 30 Oct 2014, 13:11
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
Pudd causes screeching from internal speaker during backup
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 1 of 1 Posts_count  
Author Message
Sylvander

Joined: 15 Dec 2008
Posts: 3472
Location: West Lothian, Scotland, UK

PostPosted: Sun 08 Mar 2009, 14:06    Post_subject:  Pudd causes screeching from internal speaker during backup  

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]
Back to top
View user's profile Send_private_message 
slippycurb

Joined: 12 Mar 2009
Posts: 5

PostPosted: Thu 12 Mar 2009, 14:54    Post_subject: How Strange!!!!!!!  

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!!
Back to top
View user's profile Send_private_message 
Sylvander

Joined: 15 Dec 2008
Posts: 3472
Location: West Lothian, Scotland, UK

PostPosted: Fri 13 Mar 2009, 04:34    Post_subject:  

Managed to fix the Pudd problem. Very Happy

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! Very Happy

Learning lots.

Recommending Puppy and its various Puplets at my 1st home http://www.pcguide.com/vb/
Back to top
View user's profile Send_private_message 
Sylvander

Joined: 15 Dec 2008
Posts: 3472
Location: West Lothian, Scotland, UK

PostPosted: Sun 26 Apr 2009, 03:34    Post_subject:  

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?]
Back to top
View user's profile Send_private_message 
sikpuppy


Joined: 29 Mar 2009
Posts: 433

PostPosted: Sun 26 Apr 2009, 03:52    Post_subject:  

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:
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:
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/Resources/Hardware/IBMp690/IBM/usr/share/man/info/en_US/a_doc_lib/cmds/aixcmds2/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 Razz

_________________
ASUS A1000, 800Mhz PIII Coppermine!, 192Mb RAM, 10Gb IBM Travelstar HDD, Build date August 2001.
Back to top
View user's profile Send_private_message MSNM 
Sylvander

Joined: 15 Dec 2008
Posts: 3472
Location: West Lothian, Scotland, UK

PostPosted: Sun 26 Apr 2009, 04:14    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
sikpuppy


Joined: 29 Mar 2009
Posts: 433

PostPosted: Sun 26 Apr 2009, 04:38    Post_subject:  

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.
Back to top
View user's profile Send_private_message MSNM 
Sylvander

Joined: 15 Dec 2008
Posts: 3472
Location: West Lothian, Scotland, UK

PostPosted: Sun 26 Apr 2009, 07:42    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sun 30 Dec 2012, 09:47    Post_subject: Explanation and suggested fix  

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:
mount -t ntfs /dev/sda1 /mnt/tmp

becomes three lines:
Code:
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:
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:
dd if=/dev/sda1 | gzip - > /root/myfile.img.gz

becomes two lines:
Code:
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:
In another forum, 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.
Pudd.diff.gz
Description  Suggested changes to Pudd
gz

 Download 
Filename  Pudd.diff.gz 
Filesize  667 Bytes 
Downloaded  344 Time(s) 
Back to top
View user's profile Send_private_message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7060
Location: Perth, Western Australia

PostPosted: Thu 07 Feb 2013, 08:49    Post_subject:  

Fixes applied, see here guys:

http://bkhome.org/blog2/?viewDetailed=00104

_________________
http://bkhome.org/news/
Back to top
View user's profile Send_private_message Visit_website 
Display_posts:   Sort by:   
Page 1 of 1 Posts_count  
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0972s ][ Queries: 13 (0.0048s) ][ GZIP on ]