MEPIS Community Forum

I see this problem a very different way. Not being able to read the script exactly, I've structured it as a logical problem.
The corruption isn't random, it follows exactly the instructions on lines 81-89. See what it does if "goodentries" can't be found! They are not supposed to be used after install. And are normally not.
But as this corruption occurs there must be an exception. The exception must be if the information from udev differs from "goodentries", lines 81-89 are run again to fix this error.
(M8 had this: # Strip lines from previous errors
It shouldn't be there if buildstab in M8 wasn't trying to fix things when something differed from goodentries.)
The only well documented case (appealsman) has an udev mistake (sdc1).
It doesn't exclude a "Cleaning up temporary files" error. Two different errors could explain the difficulty of finding a solution.
Henry

I don't find that "# Strip lines from previous errors" comment line in the Mepis 8.0 buildfstab script, I do find it in the Mepis 7.0 version. I think your reading too much into it anyway. It's a just comment line at the start of the 'goodentries' function (lines 57-66).

The code for the 'goodentries' function hasn't changed between the M7 version and M11, just the comment line at the start of it. That comment line now reads "# Strip cd and fd static lines". The only thing the 'goodentries' function does is keep */cdrom* and */fd* from appearing in the static part of the fstab file. I think Warren changed the wording of the comment too more accurately describe what the 'goodentries' function does.

I still believe that the buildfstab hardly ever runs lines 81-89.

I can see the scenario of fstab corruption occuring while running buildfstab's lines 90 thru 93, for instance the "Cleaning up temporary files" event clearing "$TMP" right after line 92. That would leave the new fstab without it's static section and without a "# Dynamic entries below" line. The user wouldn't be able to login in that particular session. I can then see that user rebooting and trying again. Conditions are then setup so that lines 81-89 get run. The fstab created that time would still be missing the static section, but it would now have a "# Dynamic entries below" line (and all the partitions below it as dynamic entries).

Sorry about the M7, have been comparing to many and named them poorly.
One more argument: sdc1 instead of sdb1 is hardly a random write error. That mistake is done by an app that has access to the rules of correct numbering of hard drives and is the next one to use after sdb1. udev has that capacity.
Henry

Persistent device naming for block devices has been made possible by the introduction of udev and has advantages over the use of traditional bus-based names such as /dev/hda1 or /dev/sda2.
If you have more than one disk controller (IDE or especially SCSI/SATA), or even if you just have variable numbers of removable USB/firewire storage devices attached from day to day, the order in which they are detected may not be deterministic. The result is that device names like /dev/sda1 and /dev/sdb1 may switch around randomly on each boot. Persistent naming allows you not to worry about this at all.

Yes, it has been mentioned as the weak spot of Mepis. buildfstab must be working absolutely flawless.
Henry

The point is Henry install any current Debian system and it uses UUID, (Persistent naming), because it removes the problem of device's changing,
plus when you install Debian apps it expects the system to use UUID because that is now the Debian default.
A good example is VirtualBox, it is build for use on Debian, not Mepis, and that is why people get problems and will along with other applications continue to get problems.
the change in Debian was done for a good reason, and it works.

Good Morning Danum



Is this possible to do now in Mepis. It would seem a good thing to do if it is what newer Debian packages are expecting. If not now perhaps in the next release.

This question or thought is coming from a real Novice that has not used anything that is not already on the SimplyMepis CD / DVD and has not had any boot up problems.

http://www.arsgeek.com/2008/01/02/how-t ... d-distros/

You can use the results in your system. Check our wiki also.

With reference to the above link, plus experience gained, I changed to (tried to change to) persistent device naming. I wrote a new /etc/fstab and booted up. Calamity!

'Something' had rewritten the fstab and had just left the entries for the removable devices, just two lines alone in the fstab;

/dev/cdrom /media/cdrom udf,iso9660 noauto,users,exec,ro 0 0
/dev/sr0 /media/cdrom1 udf,iso9660 noauto,users,exec,ro 0 0

My carefully crafted file was done for obviously so I reverted to the "deprecated" naming form and all was fine on subsequent reboot/s.

With the second try all went well at first but then the system reported that it could not find my /dev/sda3 equivalent, named with a UUID. Checking fstab revealed that the UUID had altered from what I had actually put in the file, double-checked I might add before and after saving. The 'something' has struck again it seems and defeated my intention to get UUID naming so far. It may be that 'it' barfed at my file somewhere along and thus cleaned it up for me in the first attempt, but the second failure is just baffling!