This bug exist in most/all modern WOOF built PUPsNote: Although this has been observed in several PUPs, I am reporting it from a recent Carolina view.

Scenario
Here's a problem that Carolina is plagued by too. I have a "Compressed NTFS file system that I am testing Carolina from on a PC that is used to dual boot various OSes. This is rather a first for me, because I rarely use this method for running PUPs. But, I got started as a result of trying to help someone else in the forum.

The Boot manager is a Carolina installed GRUB4DOS to the MBR on the HDD. The menu.lst entry points to /LinuxBoots/Carolina (SDA5) folder where the contents of the Carolina ISO exist. On initial booting/pfix=ram all is well as its has always been. There is no GRUB4DOS error in getting the system booting and running properly accessing all HDD/USB partitions that exist. The funning system has NO ERRORs for anything it is doing. After desktop tailoring, I take the system thru Shutdown as I have done using Live media for years...ONLY THIS time, I select the option to store the save-session data to a file that is created in /LinuxBoots/Carolina folder.

So I now have a booting Carolina system with a Carolina file created of my session activities. This file is save by Carolina in the boot Carolina folder, as one would expect.

On reboot the system fails starting at the point when it attempts to reference the save file. It seems to find the file, but the file is not what the boot process wants to see.

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Question
Is there something wrong with Shutdown processing in Puppy Linux when it goes to create a save-session file from the running system to the Compressed NTFS?

Here to help_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPileLast edited by gcmartin on Tue 25 Dec 2012, 20:36; edited 1 time in total

This is because NTFS-3G, the Linux driver to work with NTFS partitions, will not be able to write files to NTFS with compression partitions. Therefore, what you can do will be limited to read only of NTFS compressed partitions. NTFS-3G works perfectly happily with the NTFS no compression system and you will be able to read from and write to such partitions.

This is because NTFS-3G, the Linux driver to work with NTFS partitions, will not be able to write files to NTFS with compression partitions. Therefore, what you can do will be limited to read only of NTFS compressed partitions. NTFS-3G works perfectly happily with the NTFS no compression system and you will be able to read from and write to such partitions.

Thanks James C. But the reality is that the system has absolutely no problems with any filesystem operations during normal system running.

None, yet the save-session is where the problem is introduced. Reading, writing, editing, creating, ... no problems in operations. This normal desktop accessing of compressed file systems has been working for quite some time. The reason I may have missed this in the past is that as everyone knows), I "almost never" install/write PUPs (frugal or main) on any HDD/USB. The problem is not normal system use. This occurs when the system is to create its save-session file. There are no known or reported other times of errors using the partition(s) on any PCs.

Thanks @Rcrsn51. The problem reported here was observed last week in recent BarryK's Precise. (Here hoping BarryK see this to move the resolution into his distros as well.)

Thanks though and Happy holidays._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPileLast edited by gcmartin on Tue 25 Dec 2012, 20:53; edited 1 time in total

Yeah. There is something that is happening in Shutdown's save-session processing that does NOT occur during normal system operations.

Since all other system operations work flawlessly, the problem "MAY" be in the tool used to either format the file for ext use or in something in how the system is mounting the file for copying the system changes.

I have a question which I hope someone entertains. Why is frugal save-session file different from what happens on Live media? I can create artificial reasons for the difference, personally, but, in practice seems that both should use the same technology; because, "the Live media reasoning is really a sound reasoning in how it is structured for recovery". This answer has nothing to do with whether its on Live media or frugally on USB/HDD. It only asks about the processing of save-sessions on reboots. This area may benefit from a minor change to reduce save-session processing to a single process no matter if its Live media or frugal. Hope the developer(s) see some benefit.

In any event, my question in the paragraph above has NOTHING to do with the current problem where PUPPY shutdown is have trouble creating-writing to its Shutdown file in the filesystem.

Hope this helpsLast edited by gcmartin on Tue 25 Dec 2012, 21:34; edited 4 times in total

I meant that there is no intention, claim or pretension to support MS compressed filesystems. It's not a bug because they tell you that compressed FS are not supported and should not be used by their NTFS/FAT drivers.

I meant that there is no intention, claim or pretension to support MS compressed filesystems. It's not a bug because they tell you that compressed FS are not supported and should not be used by their NTFS/FAT drivers.

Thanks @James C. I'm not sure that that is the issue here.

We have working filesystem operations. Its been working for years. We aren't making any grave departures here. We are reporting that in the normal workings of the system, we discovered a bug in PUPPY....NOT a bug in NTFS.

We are NOT trying to fix anything MS. This is a simple Puppy shutdown processing issue in its filesystem operations at shutdown time.

Thanks though for your comments._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

This issue was discussed at length during the Slacko 5.4 development cycle. Here is the gist of it.

1. Somewhere in the 5.3 cycle, some code was added to rc.shutdown to facilitate the unmounting of network shares. That code called the umount script.

2. However, the umount script had a bug that would cause it, under some conditions, to also unmount any mounted NTFS partitions.

3. So if you had selected an NTFS partition as the target for a save file, it would be accidentally unmounted before the internal filesystem could be written into the save file. If you have one of these non-working save files, you can verify this by click-mounting it and observing that it is empty.

4. The solution, which is now in woof, was to replace "umount" with "umount-FULL" in rc.shutdown.

The question of whether compressed NTFS save files work is a separate issue.

From an external view, it seems that during processing at shutdown the system is able to create the file to support the save-session.

Thus several things could be happening from; remounting the partition where the save-session is to be created; to the formatting of the file for Puppy use, to the logic being interfered because of a missing error message somewhere.

I do not have the skills to review the code for why this is showing up at shutdown, all the while, up until this point the system has behaved expectantly.

Wish I could contribute more or be more of a help._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

Here's more info from tests done with Carolina, for it seems to help hint at where to look for the save-session problems in Woof build PUPs.

Scenario
Boot Carolina with Live media. Tailored desk and requested reboot. The PupSave Wizard took me thru several screens in preparation for Shutdown.

This time, at the end, it prepared a folder to be used for Carolina and save-session.

Review of the Summary screen present (see below) and the folder contents (see below) Carolina seems poised to complete Shutdown.
But, even though the save-session file (pre-created by Carolina on the NTFS partition) is NOT a zero length, when the system attempts access to the "linasave" the save-session file in the Carolina folder, the boot fails with error messages reflecting attempt at access a "zero-length" file.

Hope this gives clear, repeatable evidence of where in Puppy shutdown processing this problem exisst so that it can be resolved for ALL Puppy distros which attempts save-session to NTFS..There appears to be something that Puppy is NOT honoring at this stage of shutdown processing that is normally respected when the system is running normally.

Here to help

Carolina save-session creation on NTFS.png

Description

Summary screen prior to shutdown. Following folder also created at this time.

Filesize

29.68 KB

Viewed

1083 Time(s)

Carolina Shutdown Folder.png

Description

Carolina creates this folder with its contents to support physical Shutdown

Filesize

54.5 KB

Viewed

1008 Time(s)

_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum