save.dat not writable [Solved]

[Ed_P]

Booting indicates that the changes file is now not writable!!
Booting to Always Fresh mode I ran the fsck command and got this:

Code: Select all

guest@porteus:~$ fsck /mnt/sda5/porteus/changes/porteussave.dat
bash: fsck: command not found
guest@porteus:~$ su
Password: 
root@porteus:/home/guest# fsck /mnt/sda5/porteus/changes/porteussave.dat
fsck from util-linux 2.21.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see .xfs_check(8) and xfs_repair(8)
root@porteus:/home/guest# fsck --help
fsck from util-linux 2.21.2
root@porteus:/home/guest# 

What the heck are xfs_check(8) and xfs_repair(8) and where do I find them?? fsck --help was of no help.

Code: Select all

root@porteus:/home/guest# fsck --help
fsck from util-linux 2.21.2

[freestyler]

no idea what it is but it works from terminal

Code: Select all

root@porteus:~# xfs_check
xfs_check is deprecated and scheduled for removal in June 2014.
Please use xfs_repair -n <dev> instead.
Usage: xfs_check [-fsvV] [-l logdev] [-i ino]... [-b bno]... special

[freestyler]

I imagine it would work like:

Code: Select all

xfs_repair -n save.dat

I haven't got the balls to try

[brokenman]

Check the Porteus Settings Centre. Click on the floppy disk icon, then on Porteus save changes (blue module icon). It will attempt to repair your changes file. Freestyler's line of code is correct.

Welcome to the downside of NOT using a native linux file system for linux.

Before running any program against your change file have you tried mounting it and looking inside?

Code: Select all

mloop mysavefile.dat
ls -l /mnt/loop

[Ed_P]

no idea what it is but it works from terminal

Code: Select all

root@porteus:~# xfs_check
xfs_check is deprecated and scheduled for removal in June 2014.
Please use xfs_repair -n <dev> instead.
Usage: xfs_check [-fsvV] [-l logdev] [-i ino]... [-b bno]... special

They're commands!!! I certainly didn't connect ".xfs_check(8)" as being a command reference. I thought it was referring to a file in a folder or a section of a manual.

I imagine it would work like:

Code: Select all

xfs_repair -n save.dat

I haven't got the balls to try

I understand. I will make a backup before I do anything.

Thank you freestyler.

Before running any program against your change file have you tried mounting it and looking inside?

Code: Select all

mloop mysavefile.dat
ls -l /mnt/loop

An excellent idea.

Thank you brokenman.

I'll let you guys know what I find.

[Ed_P]

Welcome to the downside of NOT using a native linux file system for linux.

Or not using a Windows file system for the save.dat file.

So I mounted the save.dat file, and looked at it with spaceFM and even edited my file ok. So not understanding Porteus's boot indicating it's not writable.

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# mloop  /mnt/sda5/porteus/changes/porteussave.dat
using /dev/loop16

Please wait while i gather some info ....



 #################################
 Your data file has been mounted at: 
/mnt/loop

You can unmount it by typing uloop

Here is a list of the files:
etc  home  opt	root  usr  var

root@porteus:/home/guest# ls -l /mnt/loop
total 4
drwxr-xr-x  7 root root 4096 May  5 00:51 etc/
drwxr-xr-x  3 root root   18 May  4 10:34 home/
drwxr-xr-x  3 root root   28 Apr 15 20:43 opt/
drwx------  7 root root   98 May  4 11:19 root/
drwxr-xr-x  5 root root   40 May  4 10:34 usr/
drwxr-xr-x 10 root root   90 May  5 00:51 var/
root@porteus:/home/guest# cat /mnt/loop/home/guest/mychanges.sh
#!/bin/sh

# chmod +x mychanges.sh

ls -R /mnt/live/memory/changes/homeroot@porteus:/home/guest# 

The xfs_change command was informative.

Code: Select all

root@porteus:/home/guest# xfs_check /mnt/sda5/porteus/changes/porteussave.dat
xfs_check is deprecated and scheduled for removal in June 2014.
Please use xfs_repair -n <dev> instead.
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
root@porteus:/home/guest# 

How do I "replay the log"?? Or should I just use Porteus Settings Centre?

(I've not been a fan of all these stupid logs and becoming even less so.)

PS

Code: Select all

root@porteus:/home/guest# ls /var/log/
ConsoleKit/  debug    messages          removed_packages/  slim.log
Xorg.0.log   dmesg    nfsd/             removed_scripts/   spooler
btmp         faillog  packages/         scripts/           syslog
cron         lastlog  pm-powersave.log  secure             wpa_supplicant.log
cups/        maillog  porteus-livedbg   setup/             wtmp
root@porteus:/home/guest# 

[freestyler]

I would make a copy of the save.dat then try

Code: Select all

xfs_repair -L copied-save.dat

[tome]

not enough space or you have destroyed your save.dat file by using if for changes and probably mounting(changing) it at the same time at /mnt/loop - if yes don't do it next time - go to mnt/live/memory/changes.

[Ed_P]

I would make a copy of the save.dat then try

Code: Select all

xfs_repair -L copied-save.dat

An interesting idea.

Code: Select all

root@porteus:/home/guest# cp /mnt/sda5/porteus/changes/porteussave.dat /mnt/sda5/porteus/changes/testsave.dat
root@porteus:/home/guest# xfs_repair -L /mnt/sda5/porteus/changes/testsave.dat
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
        - scan filesystem freespace and inode maps...
sb_fdblocks 3301, counted 1528
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
root@porteus:/home/guest# 

[Ed_P]

I've rebooted with the testsave.dat file and Porteus indicated it still can't write to it.

Code: Select all

guest@porteus:~$ sh /mnt/sda5/porteus/Guest/modules.sh
cat /proc/cmdline
quiet from=/ISOs/Porteus-RazorQT-v3.0-x86_64.iso changes=EXIT:/porteus/changes/testsave.dat extramod=/mnt/sda5/porteus/modules

(Nice to see that the sh command works for scripts stored on Windows file systems also. )

Retried the xfs_check command.

Code: Select all

guest@porteus:~$ xfs_check /mnt/sda5/porteus/changes/testsave.dat
bash: xfs_check: command not found
guest@porteus:~$ su
Password: 
root@porteus:/home/guest# xfs_check /mnt/sda5/porteus/changes/testsave.dat
xfs_check is deprecated and scheduled for removal in June 2014.
Please use xfs_repair -n <dev> instead.
root@porteus:/home/guest# xfs_repair -n /mnt/sda5/porteus/changes/testsave.dat
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
root@porteus:/home/guest# 

And the results of using Porteus Settings Centre:

Code: Select all

Phase 1 - find and verify superblock...
Cannot get host filesystem geometry.
Repair may fail if there is a sector size mismatch between
the image and the host filesystem.
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

[Ed_P]

Rebooted, Linux still can't write to the save.dat file. Nice. Seeing Linux in a whole new light.

[fanthom]

maybe it's issue with filesystem on which save.dat is placed? can you write on that partition some other files?
please do two things:
a) use 'save .dat manager' to resize the container. content of the old one will be copied to the new one. boot with this new save.dat.
b) if you still get the same error then reformat your stick (hd partition?)

also - would be nice if you could boot with 'debug' cheat and take a photo of the error.
thanks

[Ed_P]

maybe it's issue with filesystem on which save.dat is placed? can you write on that partition some other files?

Unlikely and yes I can write other files to the filesystem.

also - would be nice if you could boot with 'debug' cheat and take a photo of the error.
thanks

LOL I tried that and even running under a VM I would need a movie camera to record the screens. The lines really FLASH by. Too bad there is no pause/read capability in debug mode. Or a log to record the screens.

please do two things:
a) use 'save .dat manager' to resize the container. content of the old one will be copied to the new one. boot with this new save.dat.

Ok. I'll try later.

b) if you still get the same error then reformat your stick (hd partition?)

Not gonna happen. Too much other stuff on that partition.

also - would be nice if you could boot with 'debug' cheat and take a photo of the error.
thanks

[brokenman]

The repair function isn't working. I second the idea that the save.dat is full. Resizing it through the Porteus Settings Centre will just move your data to a bigger home. Make sure you work on a copy of the save.dat. Hang in there ... I've learned the most when breaking things.

[Ed_P]

also - would be nice if you could boot with 'debug' cheat and take a photo of the error.
thanks

Now this is interesting. Booting under QEMU the msgs fly by. I expected the same situation booting live but that is not what happened. The process stops every few lines. So as you requested sir: http://imageshack.com/a/img838/804/rkos.jpg

The repair function isn't working. I second the idea that the save.dat is full.

full!!!

To that thought:

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# mloop  /mnt/sda5/porteus/changes/testsave.dat
using /dev/loop16

Please wait while i gather some info ....



 #################################
 Your data file has been mounted at: 
/mnt/loop

You can unmount it by typing uloop

Here is a list of the files:
etc  home  opt	root  usr  var

root@porteus:/home/guest# df -h /mnt/loop
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop16     252M  252M     0 100% /mnt/loop
root@porteus:/home/guest# du -sh /mnt/loop
245M	/mnt/loop
root@porteus:/home/guest# 

Now the thing with that is, up up until a few months ago I was using 2.1 Razor with a 128 MB save.dat that stayed at about 80% full. When I upgraded to 3.0 Razor I made the save.dat 256 MB and now it's FULL!!! With what, /var/log files and deleted file ghosts??? I haven't created that many new scripts and any modules I've added are stored outside the save.dat file so it ain't me. Something is wrong with this release.

Resizing it through the Porteus Settings Centre will just move your data to a bigger home. Make sure you work on a copy of the save.dat. Hang in there ... I've learned the most when breaking things.

Thank you brokenman.