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

amn 01-21-2008 12:05 AM

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:


mkfs -V -t ext3 -v -j -L my-root /dev/sda10
and then immediately (it's all part of an automated script) do:


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


mount: special device /dev/disk/by-label/my-root does not exist
'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.....

BASHCuresCancer 01-21-2008 12:51 AM

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:


mkfs -V -t ext3 -v -j -L my-root /dev/sda10
mount -v /dev/sda10 /mnt/my-root

lambchops468 01-21-2008 07:36 AM

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

amn 01-21-2008 11:39 PM

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...

lambchops468 01-22-2008 06:15 PM

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

amn 01-23-2008 05:37 AM


Originally Posted by lambchops468 (Post 3031882)
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).

archtoad6 02-28-2008 12:39 PM

Did you find a solution?

What worked?

amn 02-29-2008 07:08 AM

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.

archtoad6 03-03-2008 10:02 AM

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.

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

amn 03-04-2008 08:29 AM

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.

archtoad6 03-04-2008 09:31 AM

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

archtoad6 03-20-2008 05:01 AM

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

amn 03-20-2008 11:16 PM

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 %)

mbr 05-07-2010 05:22 PM


Originally Posted by amn (Post 3029814)
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.

Try this:

sudo udevtrigger --verbose

archtoad6 05-10-2010 08:26 AM


~# aptitude search udevtrigger

Where do I find udevtrigger?

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

All times are GMT -5. The time now is 11:02 PM.