2.14x filesystem-check problems (SOLVED)

Using applications, configuring, problems
Message
Author
Dewbie

2.14x filesystem-check problems (SOLVED)

#1 Post by Dewbie »

It's apparently there:
(line 141 of init)

Code: Select all

# a function to run e2fsck on the save partition (passed as a param)
run_fsck(){
 if [ "$FSCK" = "yes" ] ; then
  echo -n "Perfoming periodic filesystem check on /dev/$1..." >/dev/console
  e2fsck -yv /dev/$1
  check_status 0
 fi
}
However, when fsck boot option is chosen, it never displays on the monitor during boot.
(I'm assuming save partition above refers to a save file.)

It only filesystem checks partitions during shutdown.
There's another fsck script for this in rc.shutdown, activated by the fsck boot option:
(line 935 of rc.shutdown)

Code: Select all

# run periodic fsck on partitions
if grep -F -q 'fsck' /proc/cmdline ; then 
 echo -e "\n\\033[1;35mRunning filesystem check on available partitions:\\033[0;39m\n"
 for APART in `probepart | grep -E 'ext2|ext3|minix|reiserfs' | cut -d'|' -f1`
 do
   # make sure it's not still mounted
   busybox mount | grep -F -q "$APART" && continue
   fsck -y $APART
   echo
 done
So I requested some input...
npierce wrote:
I tested the function itself in an ash script and it worked OK for me. But I'm using Racy 5.2.2, which uses e2fsck 1.41.14 and the ash applet in BusyBox v1.19.3, so something could be different with Puppy 2.14x.

If the echoed message never appears on the console at all, then it is likely that the function never gets called at all, or $FSCK isn't being set.

I didn't see anything wrong with the code that looks for the boot option "pfix=fsck" and then sets FSCK="yes" (line 77).

So if the run_fsck() function is not being called, you will probably need to look closely at the code that is supposed to call it, which depends on the PUPMODE you are running (beginning at line 1439).

If run_fsck() is being called, you will need to look back in the code to see if the parameter being passed to run_fsck() ($PDEV1 or $SAVEPART, depending upon your PUPMODE) is being set correctly before the call.

Sorry that I couldn't be more helpful. I'm not the best person to ask about this, since I've never run a Puppy older than 4.3.1, and don't use save files.
I'm totally lost. Any suggestions?
Attachments
214x-init.tar.gz
init script from 2.14x
(20.52 KiB) Downloaded 249 times
214x-rc_shutdown.tar.gz
rc.shutdown script from 2.14x
(13.46 KiB) Downloaded 228 times
Last edited by Dewbie on Thu 21 Nov 2013, 07:59, edited 2 times in total.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#2 Post by mikeb »

no can't see it either.... looks like it will fsck ext2 or ext3 saves if pfix=fsck is set.
Are other pfix options working such as pfix=rdsh?

Only other suggestion is to debug each step with strategic echos to see what variables are set to and if functions actually get called.

I use a steamlined version of that init in all me pups so am a bit familiar.

It might be one of those right under your nose obvious things that get missed time...I love those :D

Mike

Dewbie

#3 Post by Dewbie »

mikeb wrote:
Are other pfix options working such as pfix=rdsh?

Didn't try that one, but pfix=ram works.
Only other suggestion is to debug each step with strategic echos to see what variables are set to and if functions actually get called.
How is this done?

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#4 Post by mikeb »

My usual strategy is to add things like
echo "you got here"
to see if a function is called and such as
echo $PDEV1
to check if a variable is being set correctly.

..so for example add echos to see if the fsck function is actually being called and what partition it is trying to check....
On that last subject its doing it on the partition NOT the save file itself.... just realised/remembered.... not sure if the later pups fsck the save file either....

As a side step ext3 is a better bet.

mike

Dewbie

#5 Post by Dewbie »

mikeb wrote:
..so for example add echos to see if the fsck function is actually being called and what partition it is trying to check..
Tried this, but no luck.
(I might have done something wrong...)
On that last subject its doing it on the partition NOT the save file itself.... just realised/remembered
I just heavily edited the first post to clarify this.
(attached rc.shutdown file, too...)
not sure if the later pups fsck the save file either
Indeed, they do...starting somewhere in the 4-series.

When I did this, it was an easy copy-and-paste, because the 3.01 and 4.12 init scripts were so similar. Everything worked right out of the box.

On the other hand, 2-series is radically different.
Thanks, Mike. :)

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#6 Post by mikeb »

so you dropped in the initrd from 3 into 2.14x? or was it 4 to get an actual save file check? did I get that right.

Yes my init script is 22k and runs in 1.5 seconds on a pentium 3 including loading sfs to ram... thats the sort of radical I like :D.
The main change was the sub folder searches and options... for me it made adding or changing any features a nightmare and intorduced quirks like trashing full installs but thats another story .

Well at least you got sorted...... I question a system that needs a fsck every boot though...you might have an ext3 save option now. I added reiserfs to mine...was nice and solid though ext3 behaved well when I used to use save files.

mike

Dewbie

#7 Post by Dewbie »

mikeb wrote:
Well at least you got sorted.
With 2.14x, no. :?
With 3.01, yes.
I copied the filesystem check script from the 4.12 init to the 3.01 init.
And that one worked right out of the box.
so you dropped in the initrd from 3 into 2.14x?

Well, I tried, but it doesn't work.
It stalls after this part:

Code: Select all

Loading kernel drivers to access disk drives. 
I question a system that needs a fsck every boot though
It doesn't need it.
I just choose this option to recover some of the lost save-file space.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#8 Post by mikeb »

Ah ok

well it would stall then as it would have the wrong kernel drivers versions at a quick guess. (you used retro 4?)

So not really solved for 2.14x.

You can't quite drop in the init script as there would be some other changes needed too. (only minor ones though but that would be going from 3 -> 2.... 3 is not a cpio initrd, 4 is iirc.)
I did the opposite...the init I developed in puppy 2 is used in 4 and lucid :) ....

I just happened to be updating busybox and adding a couple of things to my initrds this week so its a bit of a topical subject for me.

Your original script hack looked like it would work actually...at least for the partition..the save would have only needed a bit extra.

So it recovers space.... forgot about that one.

you cannot escape from this thread....muh haw haw

mike

Dewbie

#9 Post by Dewbie »

mikeb wrote:
(you used retro 4?)

I tried the 3.01 hack that I linked to above.
So not really solved for 2.14x.
Nope.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#10 Post by mikeb »

Ok perhaps my question would be ... do you want to persue 2.14x.

I happen to be updating my initrds at the moment so a good time to test

mike

Dewbie

#11 Post by Dewbie »

If your init files need testing with 2.14x, I'd be glad to help. :)
But I'm set up to run only frugal with WakePup2 (no GRUB).

(If anyone else is interested, ttuuxxx's instructions here explain how to open initrd.gz in 2-series.)

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#12 Post by mikeb »

has ttuuxxx gone quiet? not seen anything from him for a while.

my init with 2.14x...well thats role reversal for you....also has companion rc.shutdown, and perhaps some changes in one or 2 other files eg rc.sysinit but they are more to do with the main system boot. What does 2.14x use for drive mounting...I made some icons like the 4+ series but not using the puppy frontend d and rox? He still uses the 2.6.18 kernel? I don't follow those long threads so have to pick your brains instead.

for the initrds I use a fiddled with xfilemount which gives a one click open and repack ability... nice and quick.

Well finished my updates... built a custom busybox to do as much as it can , made a custom mut for drive detection (and pci) and threw in fred ... a windows dos edit clone. So apart from some hid module handling needed in lucid 2.02, 2.12, 4.12 and lucid all run pretty much the same initrds....cheeky eh :D well they sort of did anyway....just found a lot of redundant functions in lucids.

Wakepup just does the grub boogie without grub for flash stick If i remember...so you on a flash stick...you probably mentioned this before but there are so many users on here all with unique setups :)

mike

Dewbie

#13 Post by Dewbie »

mikeb wrote:
has ttuuxxx gone quiet? not seen anything from him for a while.

He was working on the next 2.14x release here, but that was almost a year ago.
What does 2.14x use for drive mounting
HotPup and mut2.
(HotPup won't allow writing to NTFS partitions.)
He still uses the 2.6.18 kernel?
2.6.18.1.
Wakepup just does the grub boogie without grub for flash stick If i remember...so you on a flash stick.
I boot to IDE HD.
See the attached shell scripts?
You copy those from floppy to wherever you want to boot.
That's all.
(Frugal and FAT are required.)
Attachments
WakePup2-floppy.png
WakePup2 files
(21.63 KiB) Downloaded 156 times

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#14 Post by amigo »

has ttuuxxx gone quiet?
His stated goal seemed to be achieving the longest thread here. Once he reached that goal he slipped away.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#15 Post by mikeb »

Actually the only change in my rc.shutdown that would need adjusting would be related to multiuser support. This affects the startup and shutdown sequence but you get nice a nice login screen and a true /home working profile for a full su life :D ...optional of course.

Don't need testing as such as me wrappers have been used for 2-3 years ... just fancied playing with busybox and stuff out of general interest.. As to how 2.14x would benefit from them is another matter. The nearest I have is 2.12 though it uses aufs, has newer gtk2 and glibc and various fiddles like multiuser, NFS networking, ROX/xfce4 desktop and of course the alternative save options which were originally developed on there. But I did not go as far as ttuuxxx when it came to updates as. if you update to a newer version effectively why not use the newer version. I mentioned to him how fast 2.02 was but he went for 2.14 as a base as it was a better starting point for what he intended.

But enough history lesson :D

mike

Dewbie

#16 Post by Dewbie »

I wrote:
It only filesystem checks partitions during shutdown.
There's another fsck script for this in rc.shutdown, activated by the fsck boot option:
(line 935 of rc.shutdown)

Code: Select all

# run periodic fsck on partitions 
if grep -F -q 'fsck' /proc/cmdline ; then 
 echo -e "\n\\033[1;35mRunning filesystem check on available partitions:\\033[0;39m\n" 
 for APART in `probepart | grep -E 'ext2|ext3|minix|reiserfs' | cut -d'|' -f1` 
 do 
   # make sure it's not still mounted 
   busybox mount | grep -F -q "$APART" && continue 
   fsck -y $APART 
   echo 
 done
OK, since that fsck script works, I changed it to this:
(which is probably wrong...)

Code: Select all

# a function to run e2fsck on pup_save file (passed as a param)
if grep -F -q 'fsck' /proc/cmdline ; then 
 echo -e "\n\\033[1;35m'save file' filesystem check, please wait...\\033[0;39m\n" 
 e2fsck -y $SMNTPT$SAVEFILE
fi
The good news is, it still runs...or at least tries. :lol:
Now for the bad news:

Code: Select all

e2fsck 1.40.2 (12-Jul-2007)
e2fsck: No such file or directory while trying to open pup_save-test.2fs.

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>

And, of course, that doesn't work either. :?

I also tested line 920 of init, by resizing / rebooting:

Code: Select all

if [ -f $SMNTPT/pupsaveresize.txt ];then #created by /usr/sbin/resizepfile.sh
  # Dougal: run fsck before resizing!
  echo -n "Forcing filesystem check on $SAVEFILE before resizing..." >/dev/console
  /pup_ro2/sbin/e2fsck -vyf $SMNTPT$SAVEFILE
  check_status 0
The fsck here also works.
Any ideas?

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#17 Post by npierce »

Dewbie wrote:The good news is, it still runs...or at least tries.
OK, if I understand correctly, you modified the run_fsck() function, and when you booted you got the "No such file . . ." error message from e2fsck. Right?

If so, it does indicate that the function is at least being called, so that's good.

I suspect that the problem with the modified function is that $SMNTPT hasn't yet been defined when run_fsck() is called.

But rather than trying to fix that, I suggest you return to the original code for that function, and again try mikeb's suggestion of using echo. Specifically, I suggest that you try echoing directly to /tmp/bootinit.log by adding the following line as the first line of the function:

Code: Select all

 echo "run_fsck(): PUPMODE:$PUPMODE FSCK:$FSCK 1:$1" >> /tmp/bootinit.log
So the function will now look like this:

Code: Select all

run_fsck(){
 echo "run_fsck(): PUPMODE:$PUPMODE FSCK:$FSCK 1:$1" >> /tmp/bootinit.log  
 if [ "$FSCK" = "yes" ] ; then
  echo -n "Perfoming periodic filesystem check on /dev/$1..." >/dev/console
  e2fsck -yv /dev/$1
  check_status 0
 fi
}
The output should get logged even without the ">> /tmp/bootinit.log", but I've added that just to be sure that the output is sent to the right place, since you weren't having success with echo earlier.

Note that after booting, /tmp/bootinit.log becomes /initrd/tmp/bootinit.log, so look there for the line beginning with "run_fsck():", and let us know what you found.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#18 Post by mikeb »

Once a save file has been added to the unionfs it cannot be unmounted (in puppy at least) and you cannot e2fsck a mounted file or device...or it complains heavily so trying this at shutdown is a non starter.

Doing at the point that a resize is done is valid.

Why not use ext3.... its less error prone. If the pup you are testing has only ext2 then might be easier to add an ext3 option.

mike

edit...oh yes the gain space after corruption thing...not sure if ext3 helps with that.

Dewbie

#19 Post by Dewbie »

npierce wrote:
Note that after booting, /tmp/bootinit.log becomes /initrd/tmp/bootinit.log, so look there for the line beginning with "run_fsck():", and let us know what you found.
Apparently it's running...:)

Code: Select all

PUPSAVE is |vfat,hda5,/pup_save-214xRC5.2fs|
PUPSFS is |/pup_214X.sfs|
ZDRV is |vfat,hda5,/zdrv_214X.sfs|
PUPMODE is |12|
e2fsck 1.40.2 (12-Jul-2007)
/dev/loop1 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

/dev/loop1: ***** FILE SYSTEM WAS MODIFIED *****

    2438 inodes used (3.31%)
      37 non-contiguous inodes (1.5%)
         # of inodes with ind/dind/tind blocks: 334/49/0
  161953 blocks used (54.92%)
       0 bad blocks
       0 large files

    2031 regular files
     346 directories
       2 character device files
       0 block device files
       0 fifos
       0 links
      49 symbolic links (49 fast symbolic links)
       1 socket
--------
    2429 files
ls: *_214.sfs: No such file or directory
ls: PUPRO=pup_ro1: No such file or directory
Cleaning out /tmp...
Now have a look at this, from init.
Specifically the third line down (line 968):

Code: Select all

else
  losetup /dev/loop1 $SMNTPT$SAVEFILE
  /pup_ro2/sbin/e2fsck -yv /dev/loop1
  echo -n "Mounting ${SAVEFILE} on ${EFSMNT}..." >/dev/console
  FILEFS="ext3"
  case "$SAVEFILE" in *2fs*) FILEFS="ext2" ;; esac
  mount -t $FILEFS -o noatime,rw /dev/loop1 $EFSMNT;check_status $?
fi
It filesystem checks the save file by default at every boot, before mounting it.
But it's not displayed on-screen, like later Puppies.
Last edited by Dewbie on Thu 14 Nov 2013, 16:28, edited 1 time in total.

Dewbie

#20 Post by Dewbie »

mikeb wrote:
Once a save file has been added to the unionfs it cannot be unmounted (in puppy at least) and you cannot e2fsck a mounted file or device...or it complains heavily so trying this at shutdown is a non starter.

Indeed, I was aware that's a big no-no...:lol:

But the fsck script in rc.shutdown appears several lines after the "Unmounting stray filesystems" command, so I assumed that it was OK.
Why not use ext3.... its less error prone.
Because of what BarryK wrote over here.
(seventh post, comments section)

Plus, it uses less space.

Post Reply