LiveUSB/LiveHDD Shutdown Error

[Was_Just19]

I only took notice of this recently, so have no idea how long it is present, but when shutting down a LiveUSB install of PCLOS - LXDE in this case - the partition is not cleanly unmounted.

So this raises my question:   is there a boot code which might affect this, or is it down to the system Halt and cannot be changed by a boot code?

My live partition is labelled LivePCLinuxOS and the following is the output from a file system check immediately after booting the flash stick (in non persistent mode), withdrawing it after power off, and booting again into my installed OS (KDE) to do the check.

# fsck -n /dev/sdh1
fsck from util-linux-ng 2.16.2
e2fsck 1.41.12 (17-May-2010)
LivePCLinuxOS was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
LivePCLinuxOS: 86/251472 files (7.0% non-contiguous), 185132/1004054 blocks

I am somewhat concerned that when using persistence with this error there could be some corruption or other negative results.

Obviously in non-presistent mode there is not so much to be concerned about as this output shows

Code: [Select]

# fsck -y -v /dev/sdh1                                                            
fsck from util-linux-ng 2.16.2                                                                    
e2fsck 1.41.12 (17-May-2010)
LivePCLinuxOS was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

      86 inodes used (0.03%)
       6 non-contiguous files (7.0%)
       0 non-contiguous directories (0.0%)
         # of inodes with ind/dind/tind blocks: 10/2/0
  185132 blocks used (18.44%)
       0 bad blocks
       1 large file

      72 regular files
       5 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
       0 symbolic links (0 fast symbolic links)
       0 sockets
--------
      77 files

EDIT:

Default menu.lst stanza

Code: [Select]

title   KDE
kernel (hd0,0)/KDE.0/vmlinuz livecd=KDE.0 fromusb root=UUID=956e91c9-2559-46f2-a0aa-64d320eef851 acpi=on vga=791 splash=silent
initrd (hd0,0)/KDE.0/initrd.gz

Ideas welcome.

Thanks for reading.

regards.

[DeBaas]

The bootcode is     fromusb    and mostly your shutdownproblems are gone.

[Was_Just19]

The bootcode is     fromusb    and mostly your shutdownproblems are gone.

Already in use ......

[DeBaas]

Sorry overlooked

[Was_Just19]

Sorry overlooked

Nope .......  I edited to add the boot stanza.   

[Was_Just19]

This is bugging me now that I have noticed it ......  and am noticing it even more as I test out the new ISOs on USB sticks.

There must be something that can be done ......

[Was_Just19]

Now that the copy2ram situation has been resolved I want to come back to this 'problem'.

Is anyone familiar with the shut-down procedure and what may be causing the filesystem to be marked as unclean after shutting down or rebooting the PC?

The only situation I am familiar with that causes 'unclean shutdown' of the filesystem is that if the power is shut off before the filesystem is unmounted.

Is that what is happening here?

If so there should be a means of preventing it .....

Is there anyone who would like to investigate this and help get the LiveUSB situation operating and shutting down correctly?

I hope so ......

[Was_Just19]

Maybe someone who knows something about this process could enlighten me and help me understand what is happening.

I have taken a brief look at the  /etc/rc.d/init.d/halt  file, of which I have a minimal understanding.

There are a few entries in that file referring to

update_boot_stage

which I guess must be defined somewhere.
I do not immediately see the definition of this in the file itself and so wonder where it is defined.

I do not mean to imply that this is related to the 'unclean' problem (but I guess it may be), but I would like to know what it is and how the file can use it if it is apparently not defined within the file.

The entries I see are these

Code: [Select]

update_boot_stage kill
update_boot_stage clock
update_boot_stage exit
update_boot_stage umount
update_boot_stage lvm
update_boot_stage umount_force
update_boot_stage remount_ro
update_boot_stage halt

As it is my understanding that halt.local is used when running live, the following lines might be pertinent ....

Code: [Select]

if [ -x /sbin/halt.local ]; then
   clear
   update_boot_stage exit
else
   update_boot_stage umount
fi
Hopefully someone can post some explanation that will be easy to understand (for me) 

[Was_Just19]

I have been doing some tests on using LiveUSB and here are the results.

I installed the latest KDE ISO (Nov) using PCLinuxOS-liveusb creator Ver. 0.8. on a 4GB USB flash drive.

I set up four different boot options as follows

1.  Standard Boot ....  the default booting the ISO from the device.
2.  Copy2RAM .......     the default ISO copied to RAM
3.  With Persistence ... no changes made to the OS
4.  With Persistence & Copy2ram ...  where any changes are copied and written back to the device

In all boots I accepted the the default location/keyboard and auto logged into the Guest account. After it finished loading I immediately selected to shutdowm the PC. I made no change whatsoever to the OS as booted.
Then I withdrew the flash device and check the filesystem, without mounting the partition, on another PC, using the fsck command.

Here are the results .....  from a number of boots in the four categories ....

1. Standard Boot ........  when shut down always left the filesystem in an unclean state ....  implying incorrect shutdown or no unmount.

2. Copy2RAM .....  the OS is copied to the memory and when shutdown, it is the filesystem in memory that is closed so the device partitions remains Clean

3. With Persistence ....... this resulted in an unclean unmount plus errors in the filesystem -- the numbers of Free Blocks and Free Inodes count are wrong and had to be corrected.

4. Persistence & Copy2RAM .......  I saw no mention of an unclean unmount but the filesystem had errors as with 3. above.

The above results have led me to the belief that we have two separate problems here.
The first being an unclean shutdown - it is also apparent if reboot is used.
The second being with Persistence.

Until now I was concentrating on the unclean shutdown.
After these tests I am inclined to the opinion that Persistence is a potentially bigger problem.

I suppose a quick and dirty solution would be to introduce a filesystem check just after the partition is unmounted and before the shutdown sequence completes.
That should ensure that the partition's filesystem is good after a boot, regardless of which option is chosen.

Personally I think there must be a better way to cure these problems.
For instance it may simply be that the partition is not unmounted before the shutdown procedure completes, thus leaving the filesystem 'unclean'.
If that is the case then it should be easily correctable.

The errors resulting from the use of persistence is a different matter.
I have no idea at this time what may be causing these errors.
It requires some investigation I think.

So I guess the best thing for me to do now, would be to concentrate on trying to find a solution to the incorrect shutdown.

Maybe someone will post a suggestion about the Persistence errors and what may be causing them.

That's it for now ......  some more tests to do to see if I can manage to get rid of the shutdown error.

regards.

[Was_Just19]

It really is time this thread was resurrected ......

The solution is even more importatnt where partitions, that are already in use for others files (OS or Data), are used to hold the LiveOS files and persistence files.

This has become more apparent as work proceeds on a script for liveHDD (poorman's) installs.

Who wants their partition corrupted by running a liveHDD or liveUSB install?


comments/suggestions/whatever  most welcome ......

regards

[AS]

Hi, Just19,

just read this thread, wasn't following this forum at the time..

I suppose a quick and dirty solution would be to introduce a filesystem check just after the partition is unmounted and before the shutdown sequence completes.
That should ensure that the partition's filesystem is good after a boot, regardless of which option is chosen.

The first guess is that the partition is not unmounted at all at time of shutdown, a properly unmounted partition can't result in a dirty filesystem ...
... and one for all, a partition can't be unmounted while in use. Going to investigate the issue ... 

AS

[Was_Just19]

Hi, Just19,

just read this thread, wasn't following this forum at the time..

I suppose a quick and dirty solution would be to introduce a filesystem check just after the partition is unmounted and before the shutdown sequence completes.
That should ensure that the partition's filesystem is good after a boot, regardless of which option is chosen.

The first guess is that the partition is not unmounted at all at time of shutdown, a properly unmounted partition can't result in a dirty filesystem ...
... and one for all, a partition can't be unmounted while in use. Going to investigate the issue ...  

AS

Thank you  AS .......  I look forward to your posts  

/usr/share/mylivecd/halt.local

[smcs_steve]

deleted by _steve

[Was_Just19]

Just19,
I don't think I have the same issue with unmounting here as I run my PCLOS liveUSB stick as an isohybrid partition with a separate partition for the changes stuff.   
I do however have some limitations with data file size due to RAM limits (large torrents and copying large video files etc)
>Steve

You won't, as I won't when 'burning' an image to a drive or partition or CD or DVD .....  they are not RW media in that form.
The changes partition though should be worth looking at ........  as that might exhibit some incorrect shutdowns .....  but I do not know this as I have not used an ISO built for persistence and hybrid, since I tested the idea some time back.

It would be interesting to see the results of a fsck on the changes partition after some changes are made, the OS shut down, the device unplugged and then tested from another OS.

Have you been checking that partition?

That might give some indication.

regards.

[AS]

Hi _steve,

where did you found info about this flags ?

root=/dev/rd/3

THX,

AS