Mounting partition(s) by label - Reboot required??
 

Hi all,

After googling around I start to come to the fact that there are areas Linux requires reboot, just as Windows regrettably does.

Which it should not have to IMO. Anyways, here are details...

I labeled a newly created ext3 partition like this:

and then immediately (it's all part of an automated script) do:

Note that /mnt/my-root has been installed earlier, so no problem there. The problem is it says in response to mount request:

'blkid /dev/sda10' shows that it indeed has the 'my-root' label assigned to it, but 'ls /dev/disk/by-label/*' does not show any file named 'my-root'. Googling revealed that a reboot is required before the label(s) just created are truly available to the system.

Is there any command that can do the same thing reboot would do, effectively bringing the label(s) to immediate availability? I am sure upon rebooting, there is some logic that re-reads labels or something.

Its all a script, this thing of mine, and I don't want to do any logic that will continue from reboot or anything. This smells Windows.....

While not exactly sure, I would guess that a reboot or at least a mounting of the device would be required before the /dev file system would be updated. This is a relatively new "feature" that actually I did not even know about until I read this post.

None the less, there is another solution. You can mount the file system with the device name, which it appears you have since you are creating the file systems. Like so:

I'm just guessing blindly...but since udev controls the device nodes in /dev, maybe you should try and restart udev?

Find out how to restart udev in your distro. There's probably some script in /etc/init.d

Mounting by device name is exactly what I am trying to avoid.

Restarting udev might be a very good idea...

I have another solution though, i did not test it yet, but i observed the following: the files in /dev/disk/by-label are symlinks to device name files (as in /dev/hda1 etc) so i just create symlinks and later when i don't need them i remove them, since /dev is not on disk. I am not sure whether it will work though...

well...when you reboot (if you ever do), i think those symlinks will be gone.

Well, if I reboot after doing creating partitions with labels assigned, symlinks may be gone but will reappear because udev will put them there after enumerating labelled partitions. Thats the point, because after doing "mkfs -t ext3 -L some_label" symlinks ARE supposed to be there, but are not, because a reboot is required (arguably restarting udev may do the trick, which i havent tried yet).

Did you find a solution?

What worked?

Create symlinks yourself
 

Yes, I did. It is not the most elegant one, but it's quite ok i guess.

What I did was to inspect how the mount by label really works. It turned out it looks for symlinks in /dev/disk/by-label that point to real device nodes in /dev/. So all I had to do after creating partition labels and before reboot, was to create these symlinks, as apparently, they would not appear until next boot. For instance i had a partition labelled "temp". I did ln -s /dev/sda8 /dev/disk/by-label/temp (dont remember exact switches now).

It all worked after these commands.


The only possible problem i see is whether these links I manually created are going to remain there and pollute the /dev filesystem. In case of dev residing in memory, i guess it's not a big deal, but with old fashioned MAKEDEV /dev systems, its on disk, hence my symlinks will stay until removed again. So i do remove them when i no longer need them, since it was a script that needed them, when the script cleans up after itself, it removes these links. Apparently the links that are created by system itself for labelled partitions are of the same sort as those i created manually.

Recap
The key thing you had to do was label the partitions. Then the necessary symlinks would be (re-)created at the next (& all subsequent) reboot(s).

However, you needed the symlinks before rebooting, so you created them "manually"; actually, w/ a script.

Because you were not certain that these symlinks would not cause problems after reboot, you "manually" removed them, again w/ a script.


Unresolved
Was the removal of those symlinks necessary? --
Would they, in fact, have caused problems, or would the system have taken them in stride?

Too early to say now. Have to do more testing to find out. So far no side effects, as long as you remove the manually created links yourself as soon as you no longer require them.

What I'm curious about is: What happens if you DON'T remove them?

Did you ever do any further testing? -- I'm still very curious about what happens if you DON'T remove them.

Sorry, did not do that yet. I am stuck with a stupid Windows box. Hope i will finally switch over to Linux permanently. Windows is as addictive as crack, and just as lethal %)

Try this:

Where do I find udevtrigger?

I'm running MEPIS 8.0.15, KDE 3.5.10, kernel 2.6.27-1-mepis-smp.

It is a part of the "udev" package, which should be installed by default.

Type this to check it up:
If you get this:

udev: /sbin/udevtrigger
udev: /usr/share/man/man8/udevtrigger.8.gz

you are all set.

Or if you don't use dpkg

just do a "whereis udevtrigger"

I should have been more clear ...
I meant the extra blank line to show that it's not in any package available from my current repositories, let alone installed on my system.


I meant where, as "in what repository", not how, like locate, find, whereis, dpkg -S, udev<TAB>, etc.


I normally don't bother w/ so much system info., but I was hoping for an answer specific to mine. See below:

So it's not in any installed package, but udev is installed:
These are the commands that start w/ "udev", udevtrigger is not among them: Finally, here is the version of udev that is installed: I suspect that the version which MEPIS 8.0.15 uses is older & that is why it doesn't contain udevtrigger.