Unmount at shutdown too soon, causing flash memory filesystem corruption?

[racepres]

Hello all... haven't been on a Puppy forum since the old ??? Murga maybe??
I started at I believe version 2 or late 1 maybe
In the beginning, being naive, up to version 3, I was partitioning, and full loading complete with Grub.. since then, been booting from CD with a Save File, just recently booting from USB... Yea... I'm slow!
Currently running Fossa64 on my main Laptop...happens to be an old Dell. From the beginning, the usb boot has given zero problems... but, I mostly boot from CD with a Save file... I must have done something wrong tho. When I shut down, it is very Fast... so fast, that when I boot back, I always get the Script that (loop4 maybe) was not cleanly unmounted... so fsck is Forced... Did Not seem to be causing problems... but, began paying attention to the Contiguous part!!
It is escalating now... it is up to 32 percent, non contiguous, and no doubt will continue this trend..
Operating in pupmode 12, and initrd/init, seems to shows pmedia=cd... good or Not...I thought pmedia should be atahd??
Possibly, I screwed sonething up when I was trying to get Wireless printing going, which will wait for now!!
Bottom line, is it Probable that the unclean, unmounting, indeed causing loss of contiguous-ness??
Can someone provide some simple steps to Cleanly unmount at shutdown??
Is there a Way to "clean up", or make the current save file contiguous??

Not stopping me at all from using the thing, but it is a wonderment to me... Hopefully the answer is "don't sweat it" !!!
Thanks for looking

[rockedge]

Great you're back!

I'll have to look at this a bit to figure out what's happening. Sounds like something that can be resolved though. I am posting to attract some attention and get some ideas from the community.

[Trapster]

Hello all... haven't been on a Puppy forum since the old ??? Murga maybe??
I started at I believe version 2 or late 1 maybe
In the beginning, being naive, up to version 3, I was partitioning, and full loading complete with Grub.. since then, been booting from CD with a Save File, just recently booting from USB... Yea... I'm slow!
Currently running Fossa64 on my main Laptop...happens to be an old Dell. From the beginning, the usb boot has given zero problems... but, I mostly boot from CD with a Save file... I must have done something wrong tho. When I shut down, it is very Fast... so fast, that when I boot back, I always get the Script that (loop4 maybe) was not cleanly unmounted... so fsck is Forced... Did Not seem to be causing problems... but, began paying attention to the Contiguous part!!
It is escalating now... it is up to 32 percent, non contiguous, and no doubt will continue this trend..
Operating in pupmode 12, and initrd/init, seems to shows pmedia=cd... good or Not...I thought pmedia should be atahd??
Possibly, I screwed sonething up when I was trying to get Wireless printing going, which will wait for now!!
Bottom line, is it Probable that the unclean, unmounting, indeed causing loss of contiguous-ness??
Can someone provide some simple steps to Cleanly unmount at shutdown??
Is there a Way to "clean up", or make the current save file contiguous??

Not stopping me at all from using the thing, but it is a wonderment to me... Hopefully the answer is "don't sweat it" !!!
Thanks for looking

How are you shutting down?

[bigpup]

If booting from a CD install and putting the save on the internal drive.

pmedia=cd is correct for pmedia=

Running in pupmode12 is correct and the save will be written to, at the exact time, something needs to be in it.
So shutdown is not going to need to stop, to update the save, during shutdown.
Shutdown will be fast.

I assume the computer can boot using Windows OS.
Check the partition the save is on, using Windows OS defrag program.
See if it shows fragmentation and how much.

One problem with putting the save on a fragmented drive partition.
If you do not defrag the partition first, before putting the save on it.
The save will be made as a fragmented file.

That may be requiring the needed file system check of the save.

[racepres]

I am using the menu/exit/shutdown... Never thought about using windows defrag...try it soon...

BTW I did Not originally post anything about Flash Memory corruption... my Usb (flash) is doing everything properly.
I am In Fact booting from CD using a save file on the HDD..
Thinking a bit here... maybe if I drop out to command line, I can manually unmount the save file????
cure one Problem perhaps...If, Big Word, If I knew how!!!
Windows cannot defrag an .sfs file...and I certainly do Not know how to do it with Linux!!!

[OscarTalks]

Hello and welcome back to Puppy Forum Land
There is a known issue involving "not cleanly unmounted" messages after shutdown, but I am not sure if that is what you are experiencing here. It happens only in ext2 partitions (and maybe ext2 save-files) so I would ask if the partition in which the save-file is stored or if the save-file itself is formatted ext2 ?

I have seen it on one of my machines which I have had for some years which has an ext2 partition. The non-contiguous percentage always remains quite low every time though, never more than about 5% so that makes me wonder if this is different. I have seen explanations posted about this (bug) in the past and I seem to recall that it is considered harmless (if a little irritating). These days I would always use ext3 or ext4 on HDD

[williwaw]

From the beginning, the usb boot has given zero problems.

burn a new cd?
find an different cd drive to try? maybe the old dell's drive may be reaching the end of it's service life if you have used it a lot. Try an external USB cd drive before tearing into the laptop?
maybe make a back-up of your savefile before it gets worse?

Should you start having the problem with a USB, you could also try to narrow it down by...

1. eliminate the possibility of something corrupted in the fossapup sfs's by downloading a fresh fossapup, checking the hash, and creating a fossapup #2 in a subdirectory. Point it to the same savefile and see if there is any difference in the shutdown behavior when you alternate booting into the two different frugals.
if they both seem to work equally well (or unwell) after a number of sessions.

2. boot the fossapup#2 frugal into ram and create a new savefile to use for a number of sessions while observing the shutdown

3. I know nothing about the implications of defragging a disk with your existing savefile, but if push comes to shove, you could try creating a new save after defragging and see if it acts different.

[bigpup]

I am In Fact booting from CD using a save file on the HDD..
Windows cannot defrag an .sfs file...and I certainly do Not know how to do it with Linux!!!

That is why I am telling you to first defrag the HDD partition using Widows defrag program.
Then make a save file and place it on the partition.
Then the save file will not be fragmented.

Just to add about choosing ext2 for the save file type.
That makes the save file have an ext2 file system in it.
To make sure it is not corrupted or has errors.
The boot process is set to do a file system check if it sees the save is a .2fs save file. (example: pupsave.2fs)
But it usually does not need to check it every time you boot.
About every 3 or 5 times you boot.

[racepres]

More stuff to check...thanks.. And yes, I understand putting save on a "defragged" media.
So... Now... I have Never experienced this before, and I really do use my Puppy Boxes for everyday tasks... all of em!!!
So who has experience recreating/copying a Save file?? Sure be a Shame to start from scratch... I do have the Back-up .GZ on a USB here.. have in fact unzipped it and replaced the one on the Hdd with it...same % of Fragmentation every time... Once this file is fragmented...Ya must just be screwed...
I do Not do anything on my Laptop(s) but real work... Not Program/OS, development..
After starting with Puppy 2.?? I was starting to feel like I was back on my Mac!!! Left behind... Now I am really Loving Fossa... so gonna spend a Minute on this one.. Thank you all for suggestions.. Off searching for a Defrag method!!! Im pushing 33% this AM

Just got to thinking about the old Dell hardware getting tired... excellent idea to investigate.. thought about the CD, definite maybe also... as I put the ISO right onto the USB stick...and again, that works perfectly.. I simply do not prefer to have the thing hangin outa my laptop all the time... I like portable.. I carry the USB with me to have most of my Crap with me elsewhere..

[bigpup]

If the drive partition is A windows ntfs or fat32 format.

Run Windows defrag program and defrag the partition.

The Puppy save file is still just a file to Windows.
So maybe in defraging the partition it will handle it the same as the other files.

Anyway, when partition is defragged.

Now try placing the backup save file on it.

See how it shuts down using it.

[racepres]

Darn good idea BigPup... Will try that as well!!

[rockedge]

I agree that @bigpup 's suggested method might be the fix

[racepres]

Interesting.. I put my pupsave file onto a blank usb drive, after Defragging/optimizing, with windoze
Then defrag/optimized again. Yes had to have 2 boxes running... but not at all a problem.
Plugged usb drive directly into the Puppy Box, and FSCK -f
32% unoptimized...
I'm just Not gonna sweat this another second... Have a clean (I hope) save file on usb and just gonna run this box til it does something foul!!
Tried a different ISO... No change.. Remember the original ISO works perfect on a USB.
next maybe if I feel like it, a different optical Drive

Thanks for all the Help etc.... but... I don't really feel like worrying/wondering... This old box smokes stupid Slow, windoze..

[williams2]

Hopefully the answer is "don't sweat it" !!!

Yes, the correct answer is don't sweat it

Can someone provide some simple steps to Cleanly unmount at shutdown??

No. You can't unmount the file system because it is being used by the Puppy operating system.
Like this:

Code: Select all

# mount-FULL -o loop bionicpup64save.3fs /mnt/tmp/
# cd /mnt/tmp/
# pwd
/mnt/tmp
# umount-FULL /mnt/tmp/
umount-FULL: /mnt/tmp/: target is busy.
# cd /tmp/
# umount-FULL /mnt/tmp/
#

which mounts a file system on dir /mnt/tmp/
the cd (change directory) to that mounted file system /mnt/tmp/
which prevents it from being unmounted because it is in use, by you.
If you cd to /tmp/, then /mnt/tmp/ is no longer being used by you,
and can be unmounted.

When Puppy's file system is mounted, it is mounted on the dir /
Puppy is in / and is constantly using the file system in /
which is why Puppy can not unmount /
/ is being used, by the Puppy operating system.

Is there a Way to "clean up", or make the current save file contiguous??

An ext4 file system can be defragged ( e4defrag )
Probably not really necessary.

An ext3 file system does not have a defrag tool,
but ext2 and ext3 and ext4 don't really need defragging anyway.

The noncontiguous number shown by fsck refers to the ext file system in a savefile.
It does not refer to the file that contains the ext file system.
For example:

Code: Select all

# filefrag *fs | grep -v '1 extent'
adrv_bionicpup64_8.0.sfs: 33 extents found

This is my BionicPup64 adrv file, the equivalent of a savefile.
I'm using it right now, after it was copied to ram.

AFAIK, I have never had a problem with any save file or sfs file or swap file because of fragmentation.

Windows cannot defrag an .sfs file...and I certainly do Not know how to do it with Linux!!!

Windows cannot defrag the squashed file system jnside an .sfs file
but it certainly can defrag any normal file on any of it's file systems.
All of my Puppy sfs files (and 3fs files) are on the main Windows ntfs partition,
and can be defragged by Windows.

The squashed file system in each sfs can not be defragged by Puppy or any Linux.
The data in ISO file systems and in tar and zip archives and in sfs files
are all contiguous (or were contiguous before being compressed.
(which is the main reason they are read only.)

fsck should run every time a file system is mounted that was previously not unmounted cleanly.
Which for Puppy is just about every time.
Which typically takes about 1/10 of a second.

[racepres]

Thanks for that^^
I have ignored it... hasn't changed much.. Matters not a Whit, what "burn", which "download", what cd ROM...
Still tells me save file was Not cleanly unmounted...every startup... but, runs great...
I guess now it is simply a Wonderment..
BTW I have had opportunity to boot a couple other Boxes with my USB Puppy... Works just like I suspected it would... Perfectly..
Big reason I have a Pup on USB..

[Marv]

Some time ago, with several pups including fossapup64, I noticed that I was always getting a forced fsck of the savefile on reboot. I ask for that in the Grub4Dos menu items. I chased my tail quite a bit over it and looked at snapmergepuppy etc. but really couldn't pin it down. I both boot from and have the savefiles on a fat32 partition on a pretty quick SSD so that seemed unlikely as a cause. Seemed kernel dependent but it was a slippery little bug. While I was working on it I modified the end of /etc/rc.d/rc.shutdown with the following to more easily see when it was happening and perhaps forestall it:

Code: Select all

sync
umount.crypto_LUKS all
sync
sleep 0.1  #Marvmod
umount-FULL -in -a -r -d >/dev/null 2>&1
sync
sleep 0.1  #Marvmod
echo Final double check of savefile integrity > /dev/console         #Marvmod
e2fsck -y "/initrd/mnt/dev_save""$SAVEPAR""$SAVEFILE"  >dev/console  #Marvmod
sleep 3

### END ###

I still see it but less often now and have indeed kind of 'stopped sweating it'. I think it has to do with timing/sync/kernel but that's just my WAG.

[Phoenix]

The script does not background the syncs, so it should block on sync disk wait, if there is anything left to be written. The sleeps feel like a dirty patch.
As of note depending on how you decided to boot up puppy, it may cause the parent partition to always have a dirty flag bit set since its not possible to cleanly unmount... for example `nocopy` means that the SFSs are not copied to memory.
SFSs are not defragmentable, these are compressed, packed files that is a read only 'partition' in a file.

[racepres]

^^^ A Revelation... for me anyway...
The Not Cleanly, Un-mounted ...probably has Zero to do with the 30% non-contiguous!!!!
It seems to be all about the pup mode running in...that unmounts in an unclean manner....
as...Again, the USB Puppy, behaves as I would Expect... giving zero Problems...whilst the "Frugal" install, (boot from CD, using a Save File on the ntfs disk of the Parent box) is Unlike previous Versions... Probably all a result of running much Older Equipment... which I thought Puppy was about.
I now have more equipment that Will Not run 64bit, than Will!!!! Now if there was an up to date Browser for 214R...I would be back where I want to be!!!!!
Dream on... it is the outdated browser that keeps me Updating!!!!

[bigpup]

The problem with the latest browsers and trying to run them in very old versions of Puppy Linux.

The very old versions of Puppy, have dependency software needed to run the browser, that is way to old.
The browsers are coded to run, using much newer dependency software.

I now have more equipment that Will Not run 64bit, than Will!!!!

Give us the specs of these computers?
CPU
RAM
Graphics hardware

There are plenty of 32bit newer versions of Puppy, but hardware specs are needed to suggest one to try.

[wiak]

I now have more equipment that Will Not run 64bit, than Will!!!! Now if there was an up to date Browser for 214R...I would be back where I want to be!!!!!

One of the many great things about distros that use upstream Void Linux repos is that Void continues to support 32bits. It can provide 32bit versions of both firefox and chromium. I no longer have any usable 32bit only computers personally, but I believe peebee produces a 32bit version of Void Pup. KLV-Airedale is a 64bit distro, however, had there been sufficient need and demand I am quite sure it would have been easy to make a 32bit build of the same (or better maybe for low-powered computers KLV-Boxer since that uses JWM/Rox viewtopic.php?p=45826#p45826). These are current up-to-date distros and hence include latest apps and security fixes. Demand is key (though maybe second place to what the developers themselves need to be honest...) to what gets produced, but 32bit is clearly not yet dead (though probably going to be sooner or later I'd imagine).

Of course 32bits isn't the only problem. Modern browsers 'sometimes' need CPU support such as SSE2 I believe, though I know nothing about that.

[racepres]

Give us the specs of these computers?
CPU
RAM
Graphics hardware

There are plenty of 32bit newer versions of Puppy, but hardware specs are needed to suggest one to try.

Oh... I believe I have maxed out at Xenial with the (Very) old Laptops.. one HP, and a nearly identical Compaq
the desktop antique however can sort of do FossaPup... but is better with Bionic pup
BTW the biggest problem I had when Puppy got more mature.... My Wireless cards were not Functional...so the Browser was Moot..

One of the many great things about distros that use upstream Void Linux repos is that Void continues to support 32bits. It can provide 32bit versions of both firefox and chromium. I no longer have any usable 32bit only computers personally, but I believe peebee produces a 32bit version of Void Pup. KLV-Airedale is a 64bit distro, however, had there been sufficient need and demand I am quite sure it would have been easy to make a 32bit build of the same. These are current up-to-date distros and hence include latest apps and security fixes. Demand is key (though maybe second place to what the developers themselves need to be honest...) to what gets produced, but 32bit is clearly not yet dead (though probably going to be sooner or later I'd imagine).

If I really needed to "keep up" I would be on that... But...I may be a "gear head" but not a very good "computer head"

[racepres]

Update...
The Puppy on the USB is still rock solid...
the Save file on the HDD of the laptop (booting from CD) is trouble free...And... The contiguous number is somehow Shrinking... down to 27% now again... been up to 35%...
Not something I am gonna even wonder about anymore...Just an Observation.