MEPIS Community Forum

A Linux operating system based on Debian Stable
View unanswered posts | View unsolved topics | View active topics |



Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 8  Next
An opportunity to investigate the fstab thing? 
Author Message
Forum Guide
Forum Guide
User avatar

Joined: Sun Apr 29, 2007 11:53 am
Posts: 2772
Location: Stockholm, Sweden
Has thanked: 854 times
Have thanks: 666 times
Post # 288602
Post Re: An opportunity to investigate the fstab thing?
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


Wed Nov 16, 2011 1:08 am
Profile
Forum Veteran
Forum Veteran
User avatar

Joined: Wed Jul 12, 2006 2:26 pm
Posts: 6881
Has thanked: 374 times
Have thanks: 2201 times
Post # 288604
Post Re: An opportunity to investigate the fstab thing?
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).


Wed Nov 16, 2011 3:17 am
Profile
Forum Guide
Forum Guide
User avatar

Joined: Sun Apr 29, 2007 11:53 am
Posts: 2772
Location: Stockholm, Sweden
Has thanked: 854 times
Have thanks: 666 times
Post # 288605
Post Re: An opportunity to investigate the fstab thing?
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


Wed Nov 16, 2011 3:47 am
Profile
Forum Guide
Forum Guide
User avatar

Joined: Sun Mar 25, 2007 5:49 pm
Posts: 2656
Location: Doncaster UK
Has thanked: 110 times
Have thanks: 733 times
Post # 288616
Post Re: An opportunity to investigate the fstab thing?
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.
Quote:
That's why Debian encourages you to change your setup to persistent naming schemes.

_________________
*Never be afraid to try something new. Remember that a lone amateur built the Ark. A large group of professionals built the Titanic(Windoze)*

Kubuntu KDE 4.11.00 / KDE 4.11.60 / Debian Wheezy KDE 4.10.4 / Plasma Active 3 Tablet


Wed Nov 16, 2011 8:29 am
Profile
Forum Guide
Forum Guide
User avatar

Joined: Sun Apr 29, 2007 11:53 am
Posts: 2772
Location: Stockholm, Sweden
Has thanked: 854 times
Have thanks: 666 times
Post # 288620
Post Re: An opportunity to investigate the fstab thing?
Quote:
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


Wed Nov 16, 2011 8:49 am
Profile
Forum Guide
Forum Guide
User avatar

Joined: Sun Mar 25, 2007 5:49 pm
Posts: 2656
Location: Doncaster UK
Has thanked: 110 times
Have thanks: 733 times
Post # 288623
Post Re: An opportunity to investigate the fstab thing?
Utopia wrote:
Quote:
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.

_________________
*Never be afraid to try something new. Remember that a lone amateur built the Ark. A large group of professionals built the Titanic(Windoze)*

Kubuntu KDE 4.11.00 / KDE 4.11.60 / Debian Wheezy KDE 4.10.4 / Plasma Active 3 Tablet


Wed Nov 16, 2011 9:06 am
Profile
Forum Regular
Forum Regular
User avatar

Joined: Fri Sep 10, 2010 3:30 pm
Posts: 250
Location: PALM BAY, FLORIDA U.S.A.
Has thanked: 38 times
Have thanks: 32 times
Post # 288626
Post Re: An opportunity to investigate the fstab thing?
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


Wed Nov 16, 2011 9:38 am
Profile
Forum Veteran
Forum Veteran
User avatar

Joined: Wed Jul 12, 2006 5:54 am
Posts: 10799
Location: Tulsa, Oklahoma U.S.A.
Has thanked: 3592 times
Have thanks: 857 times
Post # 288853
Post Re: An opportunity to investigate the fstab thing?
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


Sun Nov 20, 2011 12:13 am
Profile
Forum Regular
Forum Regular
User avatar

Joined: Sat Dec 13, 2008 11:23 am
Posts: 549
Has thanked: 80 times
Have thanks: 43 times
Post # 288911
Post Re: An opportunity to investigate the fstab thing?
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!


Sun Nov 20, 2011 6:56 pm
Profile
Forum Regular
Forum Regular
User avatar

Joined: Sat Dec 13, 2008 11:23 am
Posts: 549
Has thanked: 80 times
Have thanks: 43 times
Post # 289322
Post Re: An opportunity to investigate the fstab thing?
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.


Sun Nov 27, 2011 12:08 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 8  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Protected by Anti-Spam ACP Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.