|
Description
Each time I change my partitions, I have to do 'it' again. Yes, you know what I mean. Change /etc/fstab to point to the new partitions. Or suppose I insert a USB harddisk with more than one partition. I either have to mount those partitions myself, or edit, yes again, /etc/fstab. But then I reboot without the external drive attached.... "Kernel panic, filesystem not found". That happens automatically when you have a ext2/ext3 filesystem in /etc/fstab that doesn't exist.
Now, you might say "You don't often change your partitions, do you?" Yes, that's true. But think of a newbie. Installs Ubuntu, likes Ubuntu, says "Hey this Linux thing is wicked, lets try uhm... say Mandriva". Good, he installs Mandriva, but what happens? The partitions are messed up, Ubuntu won't boot anymore. In a very bad case, the previous Ubuntu /-partition had the same name as the /-partiton of the other Linux install, resulting in something very messy.
Now, this all can be avoided very easy. Like any problem, solving this problem requires eleminating the root of the problem. Yes. /etc/fstab. But how do we have to eleminate it? Simply removing it isn't an option, since that would result in a kernel panic. So, you say, "Well it's simply impossible to eleminate /etc/fstab". Think again. Mac OS X is a good example of a Unix system that doesn't require /etc/fstab. Even better: /etc/fstab contains a single line: "# This file is present for backwards compatibility. It may be removed all together from future versions." This can become reality for Ubuntu too. How, do you say? Very simple actually. Somewhere in the early boot process, mount -a gets called. As we all know, this will mount everything in /etc/fstab. So remove that. Next we need something to replace it. A daemon that cooperates with hal, udev, ... to check for new devices. Or even merge hal and udev with this daemon. The daemon -- lets call it "mountd" -- will check for any new filesystems. It checks if it can mount it, if it can, it will do so, at a predefined location, such as /media/devname where devname is something like hda1, sdb3, ... This directory will be created if it doesn't exist. It also has to check if a filesystem hasn't been just unmounted by the user, so it won't remount it again. This can be done by patching umount to log the devices it has unmounted.
But how about special mount-points? How about homedirectories? Well, that's solvable, too. In the root of each partition which has to get mounted on a special location, a text file called ".mountpoint" will be created which contains the path where to mount that partition, e.g. /home. Mountd will check for such a file once a partition is mounted, next it will unmount that partition, and remount it on the proper location.
Of course, the root partition. How will mountd know that? Well, that's a little bit more complicated, until you know more about boot parameters. The Linux kernel creates an enviromental variable for each name=value parameter that's passed to it and it doesn't recognise. So passing a parameter ROOTDEV=/dev/blablablah, and mountd mounting $ROOTDEV on /, well... I think the problem is solved. Actually, this still requires manual editing of /boot/grub/menu.lst, but wait until I post my Autogrub (something similar to Supergrub, but then meant for installation and compatible with mountd) idea....
Attachments
No attachments.
Duplicates
Comments
|
rgiskard wrote on the 29 Feb 08 at 12:20
| |
Hay veces que añadimos un segundo disco a nuestros equipos. En ese momento hay que estar montando las particiones siempre de forma manual. En caso contrario debemos editar fstab. ¿No sería interesante contar con una opción que lo haga sin que el usuario entienda de puntos de montaje? ¿Que todo fuese de forma gráfica y guiada?
|
|
pierrebrody wrote on the 29 Feb 08 at 12:58
|
I have a second disk with Windows and EVERY time I restart my computer, I must "mount the disk" , and give my password, to access it.
it should be automounted on boot.
I think that this may be fixable in fstab, but my experiments there were not successfull and nearly made the machine unusable.
|
|
SeySayux wrote on the 29 Feb 08 at 13:52
|
@rgiskard: No habla española (or something like that)
@pierrebrody: that's exactly what i meant it for.
|
|
SeySayux wrote on the 29 Feb 08 at 15:50
| |
@rgiskard:Esto es un texto traducido computadora, tan allí puede ser errores en él. Como dije antes, no hablo español sino que todavía deseo intentar contestar en su comentario. ¿Si usted no puede patear en su sistema más, una herramienta gráfica no está de mucho uso, es?
|
|
combatwombat_nz wrote on the 3 Mar 08 at 01:50
| |
I was thinking along the same lines, as I have to change harddisks in my machine often, in order to remove windows virii, data backups, etc. This throws /etc/fstab for a spin.
|
|
XerxesXS wrote on the 18 Mar 08 at 19:58
| |
Would something like this be applicable to automatically unmounting mounted CD/DVDs when the buttons on the front of the drives are pressed?
|
|
atos38 wrote on the 13 Apr 08 at 15:06
| |
Yes, please.
|
|
natureflow wrote on the 15 Apr 08 at 19:38
| |
Automatic mountig is great! But when I want to mount something in /usr or /home I need fstab. In any other case, this informatiob would be stored anywhere else. So please not delete fstab, but provide automatic mounting to any directory in /home, if this is really wanted, or to /media or /mount by default.
|
|
nedu wrote on the 16 Apr 08 at 01:11
|
When I have multiple distros on one disk, then I typically don't want all my partitions mounted. And, even when I want the same partition mounted under two distros, often I want different default mount options.
You have to store the fstab information _somewhere_. And your ".mountpoint" proposal removes the capability for having a partition use different mountpoints in different circumstances.
(A side note: As far as your "Kernel panic, filesystem not found" problem goes--I hope you're familiar with the "noauto" keyword.)
|
|
SeySayux wrote on the 11 May 08 at 13:26
|
@nedu: there could be a simple solution for that one. The first thing that needs to be done, is adding a new function to the installer that generates an Unique Distro Key, a predefined amount (32 will be enough?) of random numbers and letters, which will be stored in e.g. /etc/udkey. The algorithm for the key should be based on a random number generator and should take a few parameters, such as the distro name and version to make sure it's unique when multiple distro's are installed.
Below is an example situation. The user has Ubuntu 7.10, Ubuntu 8.04 and openSUSE 10.3. They have the keys 'A', 'B' and 'C' resp. An example .mountpoint would look like this:
A=/home
B=/media/sda5
C=/ubuntu-home
You get the idea, I suppose?
|
|
dima.shmidt wrote on the 20 May 08 at 13:38
| |
I think this automount feature should be available as a checkmark in drive properties.
|
|
pturing wrote on the 24 Jun 08 at 20:26
|
I must respectfully disagree. Here are some of my reasons:
First, I think that spreading this information out onto the partitions themselves will only add complexity, and thus frustration
Also, all existing knowledge, howtos, etc. that reference fstab would now be invalid and useless
But more significantly, this solution could only work in the simplest cases, such as when you only have local, unencrypted filesystems on a single-boot machine.
There are all manner of volumes that can be defined in fstab that aren't even enumerable. For example, if your home directories are on NFS (as is the case for most networks I deal with) then your machine has to be configured to know exactly where to look. Maybe they are on the local network, but maybe they are on another subnet. Maybe you are mounting a CIFS volume from a windows server across town.
And it's not just network filesystems that can't be simply walked through and inspected at boot.. there's loopback filesytems (such as .iso files) and SANs, and encrypted filesystems where the system can't even tell what it is until you give it the password, to name a few.
I would suggest that any features you want (such as remembering where you want a particular device mounted) be added to a seperate mounter (such as gnome-mount, which is called for example when you click on a usb drive in nautilus)
Btw, if you want to define in fstab where and how something should be mounted, but you don't want the system to try mounting it itself on boot, you can add noauto to the options column, like so:
/dev/my_device /mount/point ext3 user,noauto 0 0
|
|
SeySayux wrote on the 24 Jul 08 at 13:53
|
@pturing: So why did you actually install Linux in first place? All your existing knowledge, howtos, etc. that are for Windows became useless the moment you installed Linux.
Next, NFS, SMB, AFS, and I-dont-know-what-other-kind-of-networking-FS should be configured to use Zeroconf or Apple Bonjour. Yes, the latter one *is* open source, to be specefic, Apache Public License.
Encrypted filesystems have an identifier in the MBR telling what they are.
The root device actually *is* detectable, as Darwin (a free Unix implementation, derivation of FreeBSD) can do this. Darwin doesn't require fstab. /etc/fstab contains the following on Darwin:
IGNORE THIS FILE.
This file does nothing, contains no useful data, and might go away in
future releases. Do not depend on this file or its contents.
And how do you think they manage to do that? Exactly, by implementing what I posted above.
Darwin works a little bit different, for example it doesn't store things on the disk, and I didn't figure out yet how you can do stuff like home directories -- I think it's impossible in Darwin.
However, I'm not an expert on Darwin, but since it's open source, you (or anybody else that wants to know and understands enough C/C++) can download the source codes and read them.
|
Post your comment
|
