[Solved] Dirty Ext2 FS every time on FireBee...what's the issue??

[mikro]

Btw, a regression with very similar symptoms had been introduced in January 2017 in the FreeMiNT kernel, a fix is available: https://github.com/freemint/travis-pr/t ... int/42/new (before it gets accepted/merged), feel free to try it out if you suffer from the problem (but remember, it fixes an issue introduced fairly recently).

[Faucon2001]

Thanks Mikro, it works great on my CT60 Falcon : EasyAraMint is now fully functional on the CT60
I now have to dig my Firebee out of the boxes and test it.

[mikro]

Thanks for testing, Philippe! If you have a github account, feel free to mention your success here: https://github.com/freemint/freemint/pull/42 ;-)

[wongck]

Thanks. I will test it out.

-433 .... this not the old school distribution method.
Can you point me to the write-up on how to install this new dev distribution ?
IIRC, you did mention something in the mintlist but I have to dig through it.

[mikro]

-433 .... this not the old school distribution method.

Good old Mikro thinks about everybody: https://github.com/freemint/travis-pr/t ... int/42/old

Can you point me to the write-up on how to install this new dev distribution ? IIRC, you did mention something in the mintlist but I have to dig through it.

The point of the new method is to actually do as little as possible. So you take the archive, unpack it on C:, rename old auto\mint.prg to something else (please note how there's no name clash anymore), edit mint.cnf to setup your symlinks to u: (if needed), edit xaaes.cnf to point to your desktop and that's it. There are three archives: ST, FireBee and *all* the others. No need to mess with drivers or anything else.

[wongck]

The point of the new method is to actually do as little as possible. So you take the archive, unpack it on C:, rename old auto\mint.prg to something else (please note how there's no name clash anymore), edit mint.cnf to setup your symlinks to u: (if needed), edit xaaes.cnf to point to your desktop and that's it. There are three archives: ST, FireBee and *all* the others. No need to mess with drivers or anything else.

Thanks Mate ( as they say down under)
But I DO want to try the new method.

[wongck]

Btw, a regression with very similar symptoms had been introduced in January 2017 in the FreeMiNT kernel, a fix is available: https://github.com/freemint/travis-pr/t ... int/42/new (before it gets accepted/merged), feel free to try it out if you suffer from the problem (but remember, it fixes an issue introduced fairly recently).

So now I downloaded and tried this version, using the new distribution method.
I edited both MINT.CNF and Xaaes.CNF to add my environment, and I did not have any e2fsck in my MINT.CNF during this test.
My e2fsck is the one from Vincent.

I tested several cycle of
1) create a folder in my e2fs
2) copied some files into the folder
3) delete the files leaving the folder there or left the files & folder there
4) reboot
5) when desktop comes on, open a bash shell and ran e2fsck.

For each time, I had a "mounted sometime in the future. Fix ?" message even when my clock is synced to the NTP server.
Anyway, I press N to not do a fix, it will then go on to state that the fs is clean.
If I run e2fsck again, it will immediately state that the fs is clean.

Looks like you fixed it

[wongck]

My bad... the version is freemint-1-19-95d-col not the 433 build.

[wongck]

And also the new Toswin2.
The console window settings was not saved, I tried 2 times. My bash windows settings were saved.
I had to edit the CFG file to get the settings in for the console window.

[mikro]

You can try the official build now (https://freemint.github.io/#snapshots).

About the TosWin2 problem, that's rather strange, I fixed numerous bugs in it, many related to loading stored settings so I would definitely notice something odd.

Isn't possible your $HOME folder isn't mounted yet (or not set or disk is read-only) or something like that? Can you try booting bare distribution without any ext2 partitions, using just supplied mint.cnf (that's what I test) ?

[wongck]

Don't think it has anything to do with $HOME as it is set automatically, nor the read-only fs because it is about reading the config file.

So I delete the CFG file from the TOSWIN2 folder and the console default to white font on black background on start up after a reboot.
I changed the font, foreground and background colour, save the settings. I see the CFG being saved.
Reboot.... and when console comes up, it's font is white with black background.
I open the window config.... the font & colours that I chosen are shown!! So the settings are read but the settings are just not applied.

If I now open bash, makes some windows settings changes, and save it. On startup, the console will take on the settings as specified in the CFG file.
I tried to simulate the effect by deleting the bash config section in the CFG but the console settings are still being applied on start up after a reboot.

My guess is that it should not matter if the settings are not applied for a single console window as most ppl will have the command shell (bash/tcsh etc) window settings saved as well. So don't spend any effort in squishing this bug, there are more important bugs & enhancement to do.

[mikro]

Hmm, it's true I haven't tested changing colours that much. I'll try to remember to look at it, you can enter a bug here: https://github.com/freemint/freemint/issues

[wongck]

Hmm, it's true I haven't tested changing colours that much. I'll try to remember to look at it, you can enter a bug here: https://github.com/freemint/freemint/issues

Done,.