An opportunity to investigate the fstab thing?

Feel free to talk about anything and everything in this board. Just don't post offensive topics that are meant to cause trouble with other members or are derogatory towards people of different genders, race, color, minors (this includes nudity and sex), politics or religion. Let's try to keep peace among the community and for visitors.

No spam on this or any other forums please! If you post advertisements on these forums, your account may be deleted.

Do not copy and paste entire or even up to half of someone else's words or articles into posts. Post only a few sentences or a paragraph and make sure to include a link back to original words or article. Otherwise it's copyright infringement.

You can talk about other distros here, but no MEPIS bashing. You can email the developer of MEPIS if you just want to say you dislike or hate MEPIS.
Message
Author
User avatar
Utopia
Forum Veteran
Forum Veteran
Posts: 3602
Joined: Sun Apr 29, 2007 11:53 am

Re: An opportunity to investigate the fstab thing?

#21 Postby Utopia » Wed Nov 16, 2011 1:08 am

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

User avatar
kmathern
Forum Veteran
Forum Veteran
Posts: 9012
Age: 58
Joined: Wed Jul 12, 2006 2:26 pm

Re: An opportunity to investigate the fstab thing?

#22 Postby kmathern » Wed Nov 16, 2011 3:17 am

Utopia wrote: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).

User avatar
Utopia
Forum Veteran
Forum Veteran
Posts: 3602
Joined: Sun Apr 29, 2007 11:53 am

Re: An opportunity to investigate the fstab thing?

#23 Postby Utopia » Wed Nov 16, 2011 3:47 am

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

User avatar
Danum
Forum Guide
Forum Guide
Posts: 2688
Joined: Sun Mar 25, 2007 5:49 pm

Re: An opportunity to investigate the fstab thing?

#24 Postby Danum » Wed Nov 16, 2011 8:29 am

Utopia wrote: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.
That's why Debian encourages you to change your setup to persistent naming schemes.
Desktop.
Zalman Z11 Plus ATX PC Tower, AMD FX 8350 Black Edition Vishera, 8 Core 4.4 GHz, Kingston HyperX FURY Red 16GB, Nvidia GT740 Graphics, Pioneer BDR-209EBK Writer, 2 x Seagate 1TB SSHD SATA Hybrid Hard Drives. ASUS VS278Q 27 inch HD Monitor

User avatar
Utopia
Forum Veteran
Forum Veteran
Posts: 3602
Joined: Sun Apr 29, 2007 11:53 am

Re: An opportunity to investigate the fstab thing?

#25 Postby Utopia » Wed Nov 16, 2011 8:49 am

Quote:
That's why Debian encourages you to change your setup to persistent naming schemes.

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

User avatar
Danum
Forum Guide
Forum Guide
Posts: 2688
Joined: Sun Mar 25, 2007 5:49 pm

Re: An opportunity to investigate the fstab thing?

#26 Postby Danum » Wed Nov 16, 2011 9:06 am

Utopia wrote:
Quote:
That's why Debian encourages you to change your setup to persistent naming schemes.

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.
Desktop.
Zalman Z11 Plus ATX PC Tower, AMD FX 8350 Black Edition Vishera, 8 Core 4.4 GHz, Kingston HyperX FURY Red 16GB, Nvidia GT740 Graphics, Pioneer BDR-209EBK Writer, 2 x Seagate 1TB SSHD SATA Hybrid Hard Drives. ASUS VS278Q 27 inch HD Monitor

User avatar
Frank D. Hubeny
Forum Regular
Forum Regular
Posts: 250
Age: 64
Joined: Fri Sep 10, 2010 3:30 pm

Re: An opportunity to investigate the fstab thing?

#27 Postby Frank D. Hubeny » Wed Nov 16, 2011 9:38 am

Good Morning Danum

Danum wrote:Utopia wrote:
Quote:
That's why Debian encourages you to change your setup to persistent naming schemes.


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.
Until the next time we meet thank you for taking the time out of your day to visit
with me. I enjoyed spending time with you.

Frank D. Hubeny

User avatar
lucky9
Forum Veteran
Forum Veteran
Posts: 12359
Joined: Wed Jul 12, 2006 5:54 am

Re: An opportunity to investigate the fstab thing?

#28 Postby lucky9 » Sun Nov 20, 2011 12:13 am

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

You can use the results in your system. Check our wiki also.
Yes, even I am dishonest. Not in many ways, but in some. Forty-one, I think it is.
--Mark Twain

User avatar
Zevon
Forum Regular
Forum Regular
Posts: 549
Joined: Sat Dec 13, 2008 11:23 am

Re: An opportunity to investigate the fstab thing?

#29 Postby Zevon » Sun Nov 20, 2011 6:56 pm

lucky9 wrote:http://www.arsgeek.com/2008/01/02/how-to-find-your-uuids-for-devices-in-ubuntu-and-other-debian-based-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!

User avatar
Zevon
Forum Regular
Forum Regular
Posts: 549
Joined: Sat Dec 13, 2008 11:23 am

Re: An opportunity to investigate the fstab thing?

#30 Postby Zevon » Sun Nov 27, 2011 12:08 am

EDIT;
I'd prefer the persistent naming scheme for all the reasons that Danum lists, so a gentle inquiry....
Is there any further action taking place on this MEPIS 11 fstab re-writing problem?
Thank you.


Return to “General”

Who is online

Users browsing this forum: Baidu [Spider] and 3 guests