empeg-preinit v6 has been released.

It provides support for /programs0 and /programs1 mounting at boot time. It will also check to see if /programs0/preinit.d exists, and, if so, will use it as the location to find startup scripts in favor of /etc/preinit.d. This will help in preserving said scripts upon empeg software upgrades.

There is also support for a `B' script which will block at the end of the preinit process, preventing the normal init from being run until it exits. This could be handy for starting the player app with nonstandard options.

It also includes the fixes posted by jaharkes (many thanks) for the crashes that many of you were seeing. (After looking at it, they were remarkably stupid errors.) I did not include the change to allow the execution of arbitary binaries. Your startup scripts must still be scripts. Should any of you like to change this, there are some vague instructions in the code, as well as jaharkes' patch still on the BBS.

This has not been extensively tested, especially the /programs1 and `B' scripts. Use at your own risk. Feedback and patches are appreciated, as ever.

Thanks Bitt,
This has fixed my memory errors, and i got to remove the reservecache setting from my config.ini

Now hopefully maybe i can play pacman with my player switching between aux in and the mp3 player, but only time will tell

Thanks again!

If anyone wants to help figure this one out....

It turns out that if I try to remount / read-write at preinit time, preinit goes into an endless loop of stack dumps that causes me to have to reinstall a stock kernel. I think that this is because it's just managed to remount it from the initrd root. I considered sleeping for a second or two, but I didn't want to delay startup, so I haven't even done it to check to see if that's the case yet.

But if anyone has any ideas, please let me know. The offending code is still in the source ifdef'd out.

I am getting weird results now, see the following exerpt:

Trying to unmount old root ... okay
Freeing unused kernel memory: 4k init
empeg-preinit starting...
Using /programs0/preinit.d as startup script directory
stat: No such file or directory
N10telnetd doesn't exist?
stat: No such file or directory
N20mount doesn't exist?
stat: No such file or directory
N5_vncscript doesn't exist?
empeg-preinit complete
empeg init 0.8
I see this is a developer image!
Mounting proc
Mounting first music partition
Tried to mount /dev/hda4 as reiserfs but got error 19
Mounting second music partition


Seems like it won't run "N..." scripts when they are in /programs0/preinit.d/ because that hasn't been mounted yet. "M..." scripts seem to not give an error but of course they just point to applications that are also in /programs0/ which never got mounted by N20mount. Just curious if this is even close to a correct explanation

Lynn

Nope. If it wasn't mounted, it wouldn't see that they exist to try to run them. Probably still a stupid bug on my part, though. I'll take a look.

Damn. Stupid buffer sizing mistake. A new version will be out in a few.

All right. v7's out. Same place.

Still doing the same thing.

Trying to unmount old root ... okay
Freeing unused kernel memory: 4k init
empeg-preinit starting...
Using /programs0/preinit.d as startup script directory
stat: No such file or directory
N10vncscript doesn't exist?
stat: No such file or directory
N15telnetd doesn't exist?
stat: No such file or directory
N20mount doesn't exist?
empeg-preinit complete
empeg init 0.8
I see this is a developer image!
Mounting proc
Mounting first music partition


It all works fine if I revert to the old /etc/preinit.d. Any idea what I am doing wring?

Lynn

It's not you. It's me, I'm sure. Lemme triple-check this stuff.

Actually, are you sure you installed v7? I didn't check it when I rebuilt it because it was such an obvious flaw that I assumed that I fixed it wrong. But it definitely works for me now.

You are right. Must have been klutzy work with the mouse/keyboard. Sorry for the false alarm. Back to the baseball game

Lynn

Okay, just installing preinint and messing with it now.

Readme file states...

"In order to use this feature, the /programs0 and /programs1 directories must already exist and those hard drive partitions must already contain a filesystem."

How's that done, again?

I have to say, installing preinit IS very painless. Including the FTP script certainly helped. The only thing is that I don't know how to create the /programs0 partition and make its filesystem so that I can install GPSapp.

Anyone?

I found Genixia's script for doing a whole bunch of stuff such as creating scripts for emptris and stuff, but I don't know how to extract just the part that builds /programs0.

Ok, I'm back from dinner

My script needs updating - the preinit.d scripts should really be installed per application. And they should now be installed into /programs0/preinit.d

But anyway, it's still going to be easiest to use the script to format the partitions, create the mountpoints etc. It's fairly intelligent - it will only do what it thinks needs to be done. Follow the destructions, and once done;

rw
rwp
cd /etc
mv preinit.d /programs0
cd /programs0/preinit.d
rm {any scripts that you don't want...ensure that N20mount is removed as preinit does this now}
rop

ftp empeg
site rw
cd /programs0/preinit.d
put M50gpsapp
site ro
bye.

Or give me a little while to fix up a new version...

I suck at linux, but it looks like it goes up until the line:

#Create a couple of useful 'binaries', /bin/rwp and /bin/rop. Guess what they do.

Everything before that appears to be the setup stuff. But from Genixia's comments if you already have the preinit.d directory created then it will skip building the scripts. I would just say try running the script since you already have preinit installed. I used the script before I installed preinit, and it worked great. But warning.. I am no linux freak.... I could be totally wrong... but thats my .02

New version coming soon....I had a reason to blast my player back to raw beta13, so I'm taking advantage of the opportunity to rehack the script to use /programs0/preinit.d instead of /etc/preinit.d

And no....you still want rop and rom as ro and rw don't manipulate the new partitions (although SITE ro and SITE rw in ftp do...that's a bug/feature of hijacks kftpd...whichever way you want to consider it!)

Gimme a few cycles for testing...

As for limiting which preinit scripts get created, you can either cut out individual scripts (remove every line from it's comment header to the next scripts comment header, or comment them out with '#'.

But it's probably as easy to let them get created and remove unwanted stuff afterwards...

mkprgpt - v2.

Darn, that URL didn't work for me.

Hmmm. Odd. Aahh...

Try this one.
It probably helps if I give you an externally resolvable DNS hostname. I really should start using dyndns.

Okay, got the file. Where do I put it and how do I run it?

Note: Already installed preinit v7.

ftp empeg
site rw
cd / (Probably redundant)
put mkprgpt
bye

serial:
cd /
./mkprgpt

Once completed to your satisfaction, you can remove the script if desired.

Thanks, running now. I'll try to remember to strip the Windows CR/LF problem before putting it on the player....

And I am remembering to put it back in RO mode and to chmod 755 the script...

Do any of the error messages here indicate a problem, or are they normal?


empeg:/# rw
empeg:/# chmod 755 mkprgpt
empeg:/# ro
empeg:/# ./mkprgpt
VFS: Can't find an ext2 filesystem on dev ide0(3,2).
mount: wrong fs type, bad option, bad superblock on /dev/hda2,
or too many mounted file systems
VFS: Can't find an ext2 filesystem on dev ide0(3,66).
mount: wrong fs type, bad option, bad superblock on /dev/hdc2,
or too many mounted file systems
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda2 is mounted.
warning: 495 blocks unused.

Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
32768 inodes, 32769 blocks
1663 blocks (5.07%) reserved for the super user
First data block=1
4 block groups
8192 blocks per group, 8192 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
8193, 24577

Writing inode tables: done
Writing superblocks and filesystem accounting information: done
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hdc2 is mounted.
warning: 306 blocks unused.

Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
32768 inodes, 32769 blocks
1653 blocks (5.04%) reserved for the super user
First data block=1
4 block groups
8192 blocks per group, 8192 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
8193, 24577

Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Entry for /dev/hda2 appended to /etc/fstab
Entry for /dev/hdc2 appended to /etc/fstab
mount: /programs0 not mounted already, or bad option
mount: /programs1 not mounted already, or bad option
Old /etc/preinit.d entries found! Moving to /programs0/preinit.d
empeg:/# ro
empeg:/# rom
empeg:/# rop
mount: /programs0 not mounted already, or bad option
mount: /programs1 not mounted already, or bad option
empeg:/# cd /programs0
empeg:/programs0# ls
preinit.d
empeg:/programs0#

Also, despite my verification (see end of previous post) that programs0 existed and contained preinit.d, I get the following error on boot of the player:


Trying to unmount old root ... okay
Trying to unmount old root ... okay
empeg-preinit starting...
/programs0/preinit.d doesn't exist
You might want to consider placing your startup scripts there
Using /etc/preinit.d as startup script directory
no /etc/preinit.d
empeg-preinit complete
empeg init 0.8
I see this is a developer image!

These problems, by the way, are the whole reason I've been asking for a simple FTP-and-add-to-config method for putting user programs on the player. The average joe is not going to be able to do all of the above. If I can't even do it without hand-holding from Genixia and Bitt, how is anyone else going to be able to do it?

When I FTP to the player, I cannot see a preinit.d in the location where I saw it before.

Why did it dissapear, and where can I get this file again?

Okay, now my player is completely fux0red.

I was going to try to start FTP'ing the GPSapp files to the player, and I opened up IE and hit my "Set RW" link. I noticed the player was in standby so I tried to wake it from the front panel. That didn't work and I realized it was because the serial shell was still open and I was exited to the bash prompt.

So I tried to set the player back to RO from the web browser and then go to the shell to exit back to the player software, and the shell screen goes nuts with segfaults:



c0871f80: c00c1708 c0012b08 20000013 c02e6610 00000013 00000000 c02e6000 000000
06
c0871fa0: 00000001 c02e6000 c011dc24 c00c2bf0 c01e70c4 c0871fe4 c0871fc4 c02e60
00
c0871fc0: 00000001 c01e70c0 00000001 c011dc24 c00c2bf0 c01e70c4 c0871ffc c0871f
e8
c0871fe0: c00c2c54 c00c2408 00000001 c00c2bf0 c01e70bc c0872000 c000b650 c00c2b
fc
Backtrace: frame pointer underflow
Function entered at [<c001024c>] from [<c00117a4>]
r10 = 00000002 r8 = C087064C r7 = 00000002 r6 = C00F46E8
r5 = C0870000 r4 = BFFFFDA4
Function entered at [<c0011738>] from [<c0011a5c>]
r8 = BFFFFDA4 r7 = C087064C r6 = C0870000 r5 = 00000005
r4 = C087064C

(etc.)


My only recourse was to cycle the power. The player booted and began to play a song, but then locked up completely with garbage on the serial port. Still locked up.

[censored] what do I do?

(Second reboot player seems to work, but now is there something wrong?)

Heh, I get:

empeg:/empeg/bin# rw
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

Guess I should go FAQ myself now.

empeg:/# rw
empeg:/# chmod 755 mkprgpt
empeg:/# ro
empeg:/# ./mkprgpt
VFS: Can't find an ext2 filesystem on dev ide0(3,2).
mount: wrong fs type, bad option, bad superblock on /dev/hda2,
or too many mounted file systems
VFS: Can't find an ext2 filesystem on dev ide0(3,66).
mount: wrong fs type, bad option, bad superblock on /dev/hdc2,
or too many mounted file systems


This is the script attempting to mount the partitions before we do anything to them. This is neccessary to check that they weren't already formatted. As they weren't mount spews this error. ie...it's all good.


mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda2 is mounted.
warning: 495 blocks unused.

Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
32768 inodes, 32769 blocks
1663 blocks (5.07%) reserved for the super user
First data block=1
4 block groups
8192 blocks per group, 8192 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
8193, 24577

Writing inode tables: done
Writing superblocks and filesystem accounting information: done
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hdc2 is mounted.
warning: 306 blocks unused.

Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
32768 inodes, 32769 blocks
1653 blocks (5.04%) reserved for the super user
First data block=1
4 block groups
8192 blocks per group, 8192 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
8193, 24577

Writing inode tables: done
Writing superblocks and filesystem accounting information: done


Now we have formatted both paritions. Good.

Entry for /dev/hda2 appended to /etc/fstab
Entry for /dev/hdc2 appended to /etc/fstab

...modified /etc/fstab.

mount: /programs0 not mounted already, or bad option
mount: /programs1 not mounted already, or bad option
Old /etc/preinit.d entries found! Moving to /programs0/preinit.d

Now why do we see the mount errors here? mkprgpt has figured out that old /etc/preinit.d scripts were present, and therefore calls rwp before moving them, and this is the call that appears to fail. But later on, we see that /programs0 definately has preinit.d in it - suggesting that it didn't fail. Multiple rwp's should be fine.
But both rop and rom are re-mount scripts - they assume that the paritions were mounted somehow first. Ahhhhhh....they weren't mounted first - the first mount commands failed didn't they. (This is one of those hard to test without destroying you /dev/hda2 parition bugs).
Ironically, what has happened is near exactly what you were asking for. Everything has been done except for the creation/moving of preinit scripts. The /programs0/preinit.d entry that you see is actually on the root drive under /programs0, not on /dev/hda2. Remember that mountpoints in unix are just directories? Well if you create a directory in an unmounted mountpoint like we just did.

empeg:/# ro
empeg:/# rom
empeg:/# rop
mount: /programs0 not mounted already, or bad option
mount: /programs1 not mounted already, or bad option


Same deal as before rop is trying to remount unmounted directories.

Ok. So at this point:
paritions are formatted.
fstab is correct.
rwp and rop are there.
You have /programs0/preinit.d scripts living in the root partition, not /dev/hda2

Ok......this will work.
rw
cd /programs0
mv preinit.d /etc/
ro
./mkprgpt

I've just updated the script so that other people wont see this... (you don't need to upgrade in this situation though)

Thanks, will do that (although I could swear that there is no preinit.d in /programs0, I'll find out when I get there) as soon as this disk check is finished.

Boy, fsck -fay /dev/hda4 sure is taking a long time.

I am admittedly behind on these efforts to create a standard partition layout and painless 3rd-party app installs, but I don't understand this /programs0 stuff. Why don't we use /usr/local as the standard mount point like the rest of the UNIX-using world? I think this /programs0 /programs1 stuff is really confusing. Especially for those of us who *don't* want 3rd-party apps on our music partitions.

Yeah, like I said. There is no preinit.d in either /programs0 or in /etc.

empeg:/empeg/bin# cd /programs0
empeg:/programs0# ls
lost+found
empeg:/programs0# mv preinit.d /etc/
mv: preinit.d: No such file or directory
empeg:/programs0# ro
empeg:/programs0#

Since you've rebooted, /dev/hda2 has been mounted on /programs0, and the contents of /dev/hda2 have thus obscured the contents of /programs0/ (the directory on the root parrition).

Try:
umount /programs0
ls /programs0

and you will probably see preinit.d
So, after having done this,

rw
cd /programs0
mv preinit.d /etc/
cd /
./mkprgpt


Yeah, you're right...even with the script, it still takes a willingness to learn and understand a smattering or more of linux principles and commands. I want to get this down to point and click.

How to deal with 2 drives?

/usr/local0
/usr/local1
??

/usr/local/drive0
/usr/local/drive1

??

Maybe /opt0 and /opt1 ?

My main reasons for using /programs0 and /programs1 were;
Make them easily available from the / partition.
Make it obvious which patition is on which drive.
Make it obvious what the partitions are for non- linux/unix users, who make up the majority of mortals here.
The empeg is hardly a typcial unix/linux system - so standards weren't a major concern.


That being said - when we get to point and click installation via JEmplode or any other package, those points become moot. But we needed a start point to get more people using 3rd party apps to start driving this stuff, and my script provided that.

Now is the time to be having this debate though. We need to standardise stuff like this before point and click for the masses is implemented. We also need to ensure that migration is painless. (not too tricky)

Sorry. I went to bed early and have been working on a real bugbear of a problem at work, thus my silentness during all of this.

In general, the correct procedure for doing this is simply:

mkdir /programs0

mkdir /programs1

mke2fs /dev/hda2

mke2fs /dev/hdc2

mount /dev/hda2 /programs0

mount /dev/hdc2 /programs1

You can leave off the /programs1 and /dev/hdc2 stuff if you have only one drive.

The reason I didn't include those instructions is because I assumed that genixia's script already did it and I didn't want everything to change all of a sudden for people not using it. (Maybe that's not a good reason.)

However, I'll go back and include those instructions on my web page ASAP.

I think /programs{0,1} is fine. As you imply, all ``standards'' are down the toilet now anyway, since we're avoiding /etc for configuration scripts. It's not like knowledge of that sort of preexisting knowledge is really going to help anyone anyway, and for the rest, hopefully, they'll never see it.

Try:
umount /programs0
ls /programs0

and you will probably see preinit.d
So, after having done this,

rw
cd /programs0
mv preinit.d /etc/
cd /
./mkprgpt

This worked. Thanks.

However, now every time I use the Hijack/CharcoalGray XML web interface to set RW and RO, the player segfaults like crazy in an infintite loop (as described earlier in this thread).

Hmm..I hate to use these 2 words together, but.... bug.....hijack.

Let me look at this a bit, see if I can work out what's going on.

Might have something to do with the ``mount'' command with no options no longer reporting correctly. Can we talk to him and see if he can use /proc/mounts instead? (I don't use the web interface.)

FYI, the Hijack I'm running is jaharkes modified version that has the fix which will make it work better with the GPSapp. Dunno if that has any bearing.

How to deal with 2 drives?
/usr/local0
/usr/local1
??
/usr/local/drive0
/usr/local/drive1

How to deal with 2 drives?

/usr/local0
/usr/local1
??
/usr/local/drive0
/usr/local/drive1


Nope...

The ideal situation as I see it is /usr/local containing symlinks to /drive0/emptriv, /drive1/gpsapp, or whatever. So the install program would install them to a user-chosen path, then create a link in /usr/local.

That way, those who choose to install on the music partitions and those (like me) who install to the spare 32mb partition can both have our programs available under /usr/local. The physical location is abstracted.

It shouldn't. Beyond having hijack exec /sbin/hijack instead of /sbin/init, it's all pretty basic userland stuff. But if you want to be sure, you could try just installing a normal Hijack kernel temporarily.

I'd argue that /opt makes more sense here than /usr/local, but a good idea nonetheless.

My main reasoning for this is that if the empeg guys ever decided that we needed a separate /usr filesystem (unlikely but possible), then preinit would have to mount /usr in addition, which could be a bad thing. Having an immediate subdirectory of / obviates that possibility.

By the way. I now get "EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended" twice when I do RWP.

What commands do I execute to fix this for the new programs partitions? It's not in the FAQ.

I think I figured it out. Do what's in the FAQ, except replace "4" with "2".

Yeah, that seemed to work.

Hey - you're learning

Okay, I think I got preinit and GPSapp installed. Finally. Thanks, everyone, for all your help. Now to interface my Rand Mcnally unit to the player (I'll take those questions to another thread).

Jaharkes, your installation instructions in the readme need clarification. For example, you don't say that you need "incar" uploaded to /programs0, though I gleaned that this would be necessary so I did that and it seems to work. You also did not say that you need to chmod 755 all the files, which I also gleaned would be necessary. And to run the hack_init, you did not say it has to be ./hack_init in order to work. And I don't know if hack_init sets the drives back to read only, but its onscreen prompt says to reboot. If I had rebooted when it said to, and hadn't done an RO, I'll bet I would have been in trouble, huh?

Also, my player is in home mode but I still see GPS in the Hijack menu. Does that mean the "incar" test in the M50gpsapp script didn't work?

Also, my player is in home mode but I still see GPS in the Hijack menu. Does that mean the "incar" test in the M50gpsapp script didn't work?

More info. Serial port when booting says:

player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
: command not foundd/M50gpsapp:
: command not foundd/M50gpsapp:
: command not foundd/M50gpsapp: exit
: command not foundd/M50gpsapp:
GPS app started

Yeah, I'm down with /opt/ too. The empeg installer could drop a symlink from /opt/appname to wherever it puts the actual subdirectory. Then the preinit scripts don't need to be custom, they can all go after /opt/appname/name_of_binary. IWBNI the installer provided good "default" places to put the apps in a dropdown box. I suggest the following:

/drive0/appname (default, since a lot of people seem to want to use the music partitions)
/drive1/appname (for those who ran out of space on /drive0)
/usr/local/appname (my preference, since I have a separate /usr partition)

For those with a non-standard location where they want to physically put the directory, they could just type that in or put it in the installer's INI file or something.

Tony, is that you I see volunteering to write a GPS FAQ after you're done with all this stuff?

Tony, is the next Empeg meet going to have a prize for "most followups to oneself on the BBS", or something? I think you'd be the front runner?

No offence meant - do keep following-up yourself with new information, etc. It's just that I noticed you replying to yourself in three different branches of this thread at the same time. Hmm, I think I've discovered your secret - all the sub-Tony instances that you use to keep people pointed at the FAQ have lost their synchronisation and are replying to each other. Even more strangely, @O#o$@#e@P#@,.$%%xaUu--\

+++
NO CARRIER

Looks like a buffer overrun in notify.c

If my analysis is correct, this should only happen when you have used ftp or web inteface to both remount drives rw and then ro. If you use serial/telnet to run rw, rwm, rwp, then an ftp/web ro command will be fine. And if you use ftp/web to set rw, then a serial/telnet ro will also work. And all paritions need to be rw for the site ro to fail, ie if you ftp/web site rw, then serial/telnet rom, then ftp/web site ro will be okay.

The reason for all of this is because hijack's ftp/web remount commands use some performance-enhancing flags, whereas the binary utilities don't. These flags increase the amount of data read into the buffer, as does the fact that we've added 2 partitions, and once that data hits >256 byte we're in trouble. This theory is supported by the charactor count of /proc/mounts after an ftp site rw, which returns 268 bytes.

So I'm currently building a modified HJ299 with a larger buffer to see if that fixes it.

If my analysis is correct, this should only happen when you have used ftp or web inteface to both remount drives rw and then ro.

Correct. Nice catch.

So I'm currently building a modified HJ299 with a larger buffer to see if that fixes it.

You rock. I also need Jaharke's fixes for the GPSapp in it, too, though.

If the fixes for GPSapp amount to just making the player start without grabbing the serial port (and I don't know that that's true), you might be able to get it to work by using a blocking script in preinit that calls the player with -s-.

No the hijack kernel patch actually involves resetting the knob-press timer to 0 when we enter a userland application. It avoids switching between mp3/aux/tuner about 1-2 secs. after the moment application is selected.

Then nevermind.

BTW, if someone would like to ``donate'' a GPS receiver, I might keep more up to date with such things.

I'm considering what to do with my Trimble SV6 at the moment. It's missing an antenna. (I stuck it on my Oncore)

I think bgmicro still have some...did the other day.

Yep, that appears to be the problem.

Try hijack299-jh1-mount fix

I'll ask Mark to include that mount fix in the next HJ.

Try hijack299-jh1-mount fix

Does this have Jaharke's changes too?

Take a guess: hijack299-jh1-mountfix

You don't really think I'd tag one of my changes with jh1 do you????? the -mountfix is mine.

Thanks. You guys are great.

Any chance of talking Mark into including both in the standard release?

I already sent my change to mlord

Now that the problem in the kernel is fixed, I've already managed to crash the player a few times because of the bug, and on one of my FSCK repairs I got the following error text indicated. Do you think this indicates a serious problem or not?


Pass 1: Checking inodes, blocks, and sizes
Deleted inode 2078 has zero dtime. Fix? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -9733 -9734 -9735 -9736 -9737 -9738 -9739 -9740 -9741
-9742 -9743 -9744 -9745 -9746 -9747 -9748 -9749 -9750 -9751 -9752 -9753 -9754 -
9755 -9756 -9757 -9758 -9759 -9760 -9761 -9762 -9763 -9764 -9765 -9766 -9767 -97
68 -9769 -9770 -9771 -9772 -9773 -9774 -9775 -9776 -9777 -9778 -9779 -9780 -9781
-9782 -9783 -9784 -9785 -9786 -9787 -9788 -9789 -9790 -9791 -9792 -9793 -9794 -
9795 -9796 -9797 -9798 -9799 -9800 -9801 -9802 -9803 -9804 -9805 -9806 -9807 -98
08 -9809 -9810 -9811 -9812 -9813 -9814 -9815 -9816 -9817 -9818 -9819 -9820 -9821
-9822 -9823 -9824 -9825 -9826 -9827 -9828 -9829 -9830 -9831 -9832 -9833 -9834 -
9835 -9836 -9837 -9838 -9839 -9840 -9841 -9842 -9843 -9844 -9845 -9846 -9847 -98
48 -9849 -9850 -9851 -9852 -9853 -9854 -9855 -9856 -9857 -9858 -9859 -9860 -9861
-9862 -9863 -9864 -9865 -9866 -9867 -9868 -9869 -9870 -9871 -9872 -9873 -9874 -
9875 -9876 -9877 -9878 -9879 -9880 -9881 -9882 -9883 -9884 -9885 -9886 -9887 -98
88 -9889 -9890 -9891 -9892 -9893 -9894 -9895 -9896 -9897 -9898 -9899 -9900 -9901
-9902 -9903 -9904 -9905 -9906 -9907 -9908 -9909 -9910 -9911 -9912 -9913 -9914 -
9915 -9916 -9917 -9918 -9919 -9920 -9921 -9922 -9923 -9924 -9925 -9926 -9927 -99
28 -9929 -9930 -9931 -9932 -9933 -9934 -9935 -9936 -9937 -9938 -9939 -9940 -9941
-9942 -9943 -9944 -9945 -9946 -9947 -9948 -9949 -9950 -9951 -9952 -9953 -9954 -
9955 -9956 -9957 -9958 -9959 -9960
Fix? yes
Free blocks count wrong for group #1 (2096, counted=2324).
Fix? yes
Free blocks count wrong (6117, counted=6345).
Fix? yes
Inode bitmap differences: -2078
Fix? yes
Free inodes count wrong for group #1 (1302, counted=1303).
Fix? yes
Free inodes count wrong (2572, counted=2573).
Fix? yes
/dev/hda5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda5: 1523/4096 files (0.5% non-contiguous), 10039/16384 blocks

No that shouldn't be serious. Some large file was removed, but was still in use when the drive was remounted readonly. So it was only 'marked' for deletion (deleted inode has 0 dtime), but never really reclaimed. When that is 'fixed' the blocks that were part of this file are no longer referenced, but the allocation bitmap still shows them as used. those are the block bitmap differences. Finally the free blocks counts are corrected, as long as the number of free blocks increases it should be safe.

It actually looks like 2 files were deleted, as the inode count was off by 2. Both of them were about 228 blocks, so about 228KB or 872KB depending on the filesystem blocksize.

Some large file was removed, but was still in use when the drive was remounted readonly.

Cool, I think I know what file it was. All is well.

I'm trying to download preinit but it looks like the site is down Sat 12.7.02 @ 3:00pm PST.

http://www.beaglebros.com/empeg/empeg-preinit/

Would someone be kind enough to either attach it to this thread or post it somewhere else?

TIA.

-lothar

Hi.

http://www.beaglebros.com/empeg/empeg-preinit/
You are probably able to get it from the quoted URL again, but I attach it to this post anyway.

cu,
sven

Sorry. My computer was down for nearly four days due to a large ice storm combined with CP&L's general incompetence. Off to research hydrogen fuel cells.