Multisessional 2.12 CD save problem

[SAE140]

Using version 2.12 seamonkey, booting from a CD re-writer.

When attempting to save settings to the CD (multi-sessional) - I get a "premature EOF on stdin" message, followed by various 'aborting' messages. This occurs with both CDR/W and CD-R media.
If the *same* CD is then re-inserted, the running script continues where it left off and the settings are then saved ok. It's the same situation whether the re-writer has been left mounted or not.
Dunno whether this is my kit, or a software bug. If more info is required, I'll re-create the situation and take full notes.

Just want to say that this is only my second experience with a version of Linux which I can actually get to run (the other being the full Knoppix 5 live CD), and I'm mightily impressed !!

Puppy Linux is clearly the way ahead ...

Colin

[marksouth2000]

Some CD-RW drives need the drive to be opened and closed to reset it to be able to write once they have done a read.

Try this sequence:

Boot your Puppy CD.

When it's loaded to RAM, press the open button on the drive, leave the drawer open.

Do some stuff.

Just before selecting "shutdown" close the drive with the CD still in it.

If this works, it's a drive quirk.

IIRR someone once suggested that the multisession CD should open and close the drive before attempting to write the session back to the CD for just this reason. You could add this to the script yourself if necessary.

[raffy]

I guess it happens for the first save only. Please tell us if the next saves behave similarly.

[Gn2]

Puppy has another bad quirk Esp if a screen freeze was invoked,
necessitating a power re-boot -

The optical device may not be reset properly -
Check the BIOS if that happens - see if the drives are still detected.

Opening & closing Optical tray between boots accomplishes same thing - IF
Bios resets for found devices AND tray is MT -
Confirm by dmesg probe output

= Puppy has some bad scripting glitches not yet resolved.
This is NOT unique to Puppy - many other distributions have
perplexing automated bugs.

Developers are hampered in tracking down any - since they
do not have ready access to all hardware for testing -
Then reliance on users feedback is very important:
As is ACCURATE trouble shooting methods by all & interpreting of results - NOT guesses.

[Ted Dog]

Yeah I had like problems with 2.12, there is two sections of code in the init script dealing with multisession and it affects the memory allocated best I can tell it splits in half twice thereby allowing so little memory (usable grow space) for pup_rw that the machine will soon die of memory starvation (lack of X resources allocation ) it also affects the audio. (from a 256M ram machine, nvidia (kernel) X at 1200x1024x24) gives 114M of grow space to pup_rw )
changes to init script ( line 841 ) and
#total ram, less any shared video...
PCRAMSIZE=`free | head -n 2 | tail -n 1 | tr -s " " | cut -f 3 -d " "`
SIZEFILLK=`expr $PCRAMSIZE \/ 2` #half of ram.
#TEDDOG force more RAM USED
SIZEFILLK=`expr $PCRAMSIZE - 40000` #all but 40M
(line 1006)
ALMOSTFILLK=`expr $PHYSICALFILLK \/ 8`
#ALMOSTFILLK=`expr $PHYSICALFILLK - $ALMOSTFILLK`
(line 1012)
ALMOSTFILLK=`expr $ALMOSTFILLK - 10000`
SIZEFILLK=`expr $ALMOSTFILLK + $SWAPSIZE`

ideally the modification should be one tempfs with subfolders or saving the diskspace used by multisession, or reading multisessions twice to get the real size and creating the temp sized just for needed space, or use 1/2 memory to read MS, create used size in other half copy from first half mem-to-mem, release the first tempfs and recalc size before loading squashfiles

[SAE140]

I guess it happens for the first save only. Please tell us if the next saves behave similarly.

Spot on, Raffy. First save only, subsequent saves are no problem.

In fact, the first save would have 'worked ok' if I'd been more patient.
The script reports "dev/hdd is write-protected, mounting read-only", then some chat about DiskType followed by a cdrecord WARNING, then the "premature EOF" and "input buffer error, aborting" stuff.
Then - after a short delay, the disk ejects and automatically re-inserts with the script running to completion - writing to the CD ok in the process. Guess I was being a tad 'previous' and over-reacted mid-script to what appeared to be words of doom. Oh yea of little faith .....

Live and learn - told you I was new to this stuff !! (This was originally posted in the Beginners Section)

Thanks for your help guys - seems there never *was* a problem - just a lack of appreciation of what processes were taking place.

Might be worth adding a 'don't worry if ....' note to an FAQ ?

'best

Colin