I selected a directory that I wanted to archive, which showed "Minimum disk size: 1294Mb". I clicked "Burn" button then chose DVD, on-the-fly, close session (note, starting Pburn afterward, it does remember those settings, but not the "DVD" selection -- goes back to "CD" -- with gtkdialog3 you have to reorder the list with the default one at the top).
However, it was unable to burn to my DVD-R, came up with a window:
"Unknown error -- see log for further information"
What log? There is nothing anywhere for opening any log file.
However, I had run pburn from a terminal, so I was able to see error messages, and there were heaps of them, mostly looking like this:
/usr/local/pburn/func_build_command: line 3: /root/.pburn/tmp/pburn-exec: No space left on device
...which makes no sense at all, as there is plenty of space. Believe me, in all respects, RAM, partititons, tmpfs's, there is plenty of space.
I looked in /root/.pburn, 'du' shows it has 64MB of stuff in there ...yikes! I am doing on-the-fly burning, so it's all heaps and heaps of symlinks. Anyway, the filesystem that /root is in is far from full -- it's the pup_save file and has 240MB free.
Note, if I chose a smaller directory, it does work. The directory that I wanted to burn, 'du' shows it to occupy 1566MB, which Pburn estimates needs media space on the DVD of 1294MB. Whatever, there should not be any problem with burning that on-the-fly.
Changing the subject, but only slightly, earlier I was using Pfind and Pfilesearch hung on me. I was running that from a terminal and did CTRL-C to kill it, but that left a couple of processes running, and had to use 'kill' on those. I rebooted after that, so that problem has no relationship with the Pburn problem.
Changing back to DVD-burning, I have a regular need to burn directores to DVD, and it is so darn simple to do, basically just one line. For my own use anyway, I am going to be forced to write a little GUI for doing that one job, just so that I have confidence that it is going to work right.
I am sorry to be so harsh, but this as been an ongoing thing, and I have been expecting Pburn to have reached the stage of extreme reliability. I don't care about the bells and whistles that keep getting added, I just want it to work.
Comments:Posted on 32 Jul 2008, 4:26 by Martin
Puppy really is ahead of its time..see Posted date.
Posted on 32 Jul 2008, 8:43 by dogone
Purn problem confirmed
I was able to reproduce exactly as you describe. Tasked with burning my "other" Linux system to DVD (3+ GB), Pburn tried and failed - log file not located. What I did "locate" was a tree of symlinks under /root/.pburn/tmp/pburm/ with thousands of entries.
Tempting fate, I rebooted, permitting all to be saved to pup_save (as the unwary user would certainly do). The save failed, leaving Puppy hanging. Hard reset required. I rebooted 405 w/pfix=ram and checked the state of my pup_save file. Fsck found several thousand "unused nodes" and other problems. The damage was serious and required several careful fsck runs.
Sorry, but Pburn must be considered "dangerous" in this particular failure mode. I suggest it be repaired and carefully tested (with tough tasks) before 4.1 final.
These things happen.
Posted on 1 Aug 2008, 13:43 by ANOSage
Since you, yourself, digress onto CTRL-C issues, I reckon I might get away with a couple of reminders here that:
1) CTRL-ALT-BKSPCE needs urgent attention for use on boards with SiS chipsets. With Puppy, it causes immediate hard power shutdown.
2) Speaking of which, The 'power off' hangs at the final hurdle on SiS chipsets and many laptops. This continues to attract much comment on the Forum. Only seen this 'feature' on one other distro - the others all get it right acpi=force shouldn't be necessary.
Posted on 1 Aug 2008, 20:17 by kirk
no space left
The "No space left on device" problem with Pburn sure sounds like the problem me and MU was having with Unionfs. But now we're using AUFS. I wonder if the 64MB of symlinks eats up all of AUFS inodes?
Posted on 2 Aug 2008, 19:42 by BarryK
RE: Pburn doesn't work
Some people, including zigbert, feel offended by this blog post.
I had intended it to be a strong message, as the problem is quite fundamental and should have been tested for, and fixed, long ago.
As it turns out, the message was too strong, and may have had the reverse effect, instead of a mild "kick in the pants" to the developers to get the fundamentals in order, they might not be so happy to comply.
Ah well, nobody is an employee here, so I can't get heavy-handed. So, I apologise to any who have been offended.
Posted on 3 Aug 2008, 6:21 by MU
Important really would be to know, if you ran unionfs or aufs.
unionfs was extremely, very extremely buggy in Puppy 3.
So the statement "this was always a problem with Pburn", is not valid.
It was a problem with unionfs.
I don't know, how far this changes in Puppy 4, but I already have read at least 2 messages, that reminded me.
Aufs runs rock-stable in Muppy, I just2 times had filesystem errors, that resembled unionfs.
But that also could have been something else.
I would suggest, to start a testscript.
It culd create 100.000 symlinks.
Then look, what happens.
If you can reproduce irregularities here also with aufs, this would indicate, that the way Pburn organizes files, is not suitable in layered filesystems.