auto smbfs mount in /etc/fstab causes hald hang at boot

I can confirm this bug. My workaround was booting into rescue mode and running:
apt-get remove hal
That removed ubuntu-desktop gnome-volume-manager and a few other things, but at least my system boots now.

I've installed all the latest updates for Dapper Drake.

I tried the "apt-get remove hal" workaround described above on my Athlon64 computer. It worked and that computer now boots to GNOME.

I will try it on the AthlonXP system next.

I've found a better work around in this bug: https://launchpad.net/distros/ubuntu/+source/hal/+bug/37683

The working is to remove or comment out any smbfs mounts in /etc/fstab

I commented out the line in /etc/fstab that was mounting a share of a Windows PC and then re-installed ubuntu-desktop (which got me back hal and gnome-volume-manager).

When I rebooted everything worked normally and the freezing problem I was having accessing images on my USB camera was also fixed.

I can do without smbfs for now. Should this bug be filed against smbfs?

I have confirmed that this problem is triggered by an auto smbfs mount in /etc/fstab. You don't have to comment out the smbfs line in /etc/fstab; it is enough to change it from "auto" to "noauto". That way, once you have booted up, you can do "sudo mount /your/smbmount/path" and it will be able to get all the parameters from /etc/fstab for the mount.

The title of this bug should be changed to something like "auto smbfs mount in /etc/fstab causes hald hang". Or else, a new bug of that title should be opened and this bug should be closed with a reference to the new bug.

I'll upload a bootchart-picture over the problem.

Bootchart showing HAL hang.

Today's packages updates for Dapper included a new smbfs package. I updated all packages on my Athlon64 to the latest, and put back the auto smbfs mount.

When I booted, it did not hang in hald! However, the GNOME desktop took over 45 seconds (I timed it) to start. Once the desktop was up, I tried to look at the smbfs directory in Nautilus, which took a long time and then gave up.

When I changed the auto mount back to noauto and rebooted, the system came right up and the desktop came right up. When I then mounted the smbfs mount manually, there was no delay and Nautilus had no trouble with it.

So, the new smbfs fixes the hald hang but still doesn't quite do the right thing for an auto smbfs mount at boot time.

(Sorry about the repeated messages. It turns out that if the browser refreshes the page after you post a bug on launchpad, that re-posts the bug. And if you reboot your computer and the browser comes back with Session Saver, that refreshes the page... From now on I'll close a bug window immediately after the bug is submitted, to prevent this.)

Today's package updates include updates to smbfs. I updated my Athlon64 to the latest, put back the auto smbfs mount, and rebooted. Same exact failure mode as reported above: desktop takes over 45 seconds to come up and the smbfs mounted volume just times out if you try to look at it.

Same here, though Nautilus still cannot browse the "Go -> Network -> Windows Network" area.

Another workaround is to change "smbfs" mounts in /etc/fstab to "cifs".

I am also experiencing this bug, using the k7 kernel on an nForce 4 mobo. Changing the mount option from smbfs to cifs works as a stopgap measure.

Is someone working on this?

Since it isn't assigned to anyone, I don't think so.

Changing to cifs is one idea, but it isn't always the best. Adding "noauto" to the end of the "options" part in smbfs also works as well... except you have to mount it manually on boot-up.

How do you assign it to someone then?
This is getting very annoying now to manually mount the shares.

I don't think you can. Hopefully SOMEONE notices...
:(

It's not a good solution, but it simplified things for me...

I've got my smbfs drives marked as noauto, so everything boots nicely,
but them I've just set a script to run at startup that mounts the
drives. It probably possible to make them user mountable, but I
wasn't in the mood to fiddle wth that so I'm using a script that runs
as root. It's nasty, but it works.

Hope it helps

On 5/25/06, javaJake <email address hidden> wrote:
> I don't think you can. Hopefully SOMEONE notices...
> :(
>
> --
> auto smbfs mount in /etc/fstab causes hald hang at boot
> https://launchpad.net/bugs/44874
>

--
O)-c

I have on that boots with the fstab just fine.. but with my laptop, I didn't want to do that. I 'had' a file that I made executable and clicked on with ease for more than a year.. until I upgraded to Dapper. Now the entire box freezes... hard.. I can type it in manually, but if I run it, it freezes. I have tested on another laptop, same thing.

My script was a simple
<sudo mount -t smbfs -o username=andrea,password=andrea?,dmask=777,fmask=777 //deb/andrea /home/bkastor/test-mount>

What do you have in your startup script? I am willing to try anything!
My bug was:https://launchpad.net/bugs/47685,but nobody has responded...

thanks...

Have you put noauto in your fstab?
If you can get it to boot with noauto, then a simple sudo mount
/your/share should do it (that's all that's in my startup script)

On 6/1/06, ipguru99 <email address hidden> wrote:
> I have on that boots with the fstab just fine.. but with my laptop, I
> didn't want to do that. I 'had' a file that I made executable and
> clicked on with ease for more than a year.. until I upgraded to Dapper.
> Now the entire box freezes... hard.. I can type it in manually, but if
> I run it, it freezes. I have tested on another laptop, same thing.
>
> My script was a simple
> <sudo mount -t smbfs -o username=andrea,password=andrea?,dmask=777,fmask=777 //deb/andrea /home/bkastor/test-mount>
>
> What do you have in your startup script? I am willing to try anything!
> My bug was:https://launchpad.net/bugs/47685,but nobody has responded...
>
> thanks...
>
> --
> auto smbfs mount in /etc/fstab causes hald hang at boot
> https://launchpad.net/bugs/44874
>

--
O)-c

I haven't tried noauto.. but the 'sudo mount.. ' in a script is what is causing my freeze ;-)

But I see what you mean.. put it in the /etc/fstab, but the noauto just means that I don't have to use the entire command in the script... ok, thanks, I will try. That might be the workaround I need...

ok, get this. I put this in my /etc/fstab:
//deb/andrea /home/bkastor/test-mount smbfs noauto,users,sync,username=andrea%password,dmask=777,fmask=777 0 0

(which I can type in .. using mount -t.. and it works)

After putting this in the fstab, I open a terminal and type in:
sudo mount //deb/andrea

It asks me for my password (sudo).. then HANGS... I have deleted this file and created a new one.. just to be sure. But I can run this script without the dmask and fmask options... Really weird? Nobody has contacted me about this being a bug though... mabye I am not telling my story well enough?
thanks...

whoops.. sorry, messed that up..

When I type it into the xterm, it works fine...

When I double click the executable file with
sudo mount //deb/andrea
it hangs...

sorry... little flustered. I can type this all just fine, and now my wife is learning what the hell was going on in the background!

Well, dapper is out including this bug. :/
I don't get it. Doesn't the developers automount their shares???

Did we put this in the wrong spot??? Maybe it belongs to smbfs....

hi i have the same problem

i´m useing kubuntu dapper since flight 6 and had no big problems during the boot up
but when i updated a big bunch of packages about May 10th the boot process hung at startup of the HALD , i´m still not very familliar with linux so i had no idea what the problem for this could be and i switched back to windows and dicided to wait for the final release and updated yesterday and still had the same problem ,so i started to google and found this bug thread ,

i also have a debian/samba share that is auto mounted with fstab , i read this thread and followed your workaround -booted the recovery mode added noauto to the smb share in the fstab and rebooted the PC. now its boot up fast without any problem after this i mounted the share manualy with a "sudo mount //IP/share/" and it also works fine
i hope that if there will be more people complaining about this anoying error anyone get attended to it :)

but anyway thanks for the workaround i was already starting to srew around the whole system without any clue what could be the error :)

i hope they will fix it soon

cya

and sry for my bad english

i agree with willie: this kind of bug should have been fixed before releasing something that you call "production ready". in a real environment i think there are many cases of file-serving through samba and not being able to automount the share is quite a severe bug in my opinion.

It seems to be a timing issue.

I put smbfs into /etc/modules to get the module loaded early in the boot process. This seems to help sometimes, but most of the time, it doesn't help either.

> I don't get it. Doesn't the developers automount their shares???

Perhaps they have faster machines where this problem doesn't show up.

I can confirm the hald <--> smbfs problem on an AMD64-machine in Dapper Drake. I'm currently using cifs as workaround, but there seems to be antother problem: cifs-mounts auto-mounted via fstab don't show up in mtab, but work otherwise as supposed to. This can lead to a bit of a fuzz aka double-mounts when using tools like smb4k or kdf. Btw, smb4k doesn't find any shares in it's AMD64-incarnation in Dapper, while it's counterpart in Breezy works fine.

Sadly, even with the six week delay, Dapper feels quite rushed IMHO.

One time Gaim wouldn't start, Firefox couldn't find anything, then after
a few minutes everything was fine. It must be that!

I am also having the same problem.

After the long hald timeout (which doesn't happen every time), I seem to also get a long wait before the desktop initializes the menu and the icons (i get the desktop background with empty bars for the menus) (this may not be related).
After waiting for a long time, the desktop comes through. However, mounting samba shares when referring to hostnames still doesn't work (haven't tried ip)

regards

fraco, that is completely related.

Except for one thing: I no longer have this issue. I didn't touch configurations or anything.

You know what, though, is I always leave my computer sitting at the login screen for about two minutes. Try setting the mount back to auto, wait for two minutes at the login, and see what happens.

I also have this problem. Adding noauto to the end has solved it, but it is rather annoying to mount my shares by hand...

Same problem here.

same problem here, too.
even cifs "workaround" doesn't do it.
i would rate this a major problem!

This is a big bug for SMB users!

My last post is about the change of importance from Medium to High... sorry about that.

Yey. Atleast the status is High now.

A workaround could be to configure /etc/fstab with "noauto" and put in /etc/rc.local "mount /mnt/sambadirectory".

I've tried it and it works.

Please don't play with the importance settings, this is for developers to prioritize the work

Well, if the work gets done, then I'll accept this. I haven't heard a
thing from any developers about any fix that might happen. Can you
update us on this?

Martin Bergner wrote:
> Please don't play with the importance settings, this is for developers
> to prioritize the work

mambo your work around works for my situation. thanks, John

well, it seems quite a big bug to me as well. Isn't it enough to have shipped Dapper with issues like this untouched?
it seems to affect a lot of people.

I can confirm this bug. It's really-really annoying and should be fixed soon.

I've found a solution... Please let me know if it's working for you.

/etc/network/interfaces:

add this line right after your active interface setup:

pre-up sleep 5

i.e:
auto eth0
iface eth0 inet dhcp
pre-up sleep 5

I don't know why the devs not working on it... :-(
It's sooo sad.

If worked here - at least for now (I restarted the system a few times without problems).

In my opinion, this work-around also points to a timing issue between starting the ethernet network, starting the samba system and mouting the network shares.

Most of most of the above mentioned suggestions influence the point in time when a specific service is started:

putting smbfs in /etc/modules: early in the boot process

mounting shares in /etc/rc.local: late in the boot process

pre-up sleep 5 in /etc/network/interfaces: give something else more time to finish

This would also be consistent with my observation that the /etc/modules variant sometimes work and sometimes it doesn't.

My guess: This problem is a hick-up in the multi-threaed booting process introduced sometime during the latest Dapper pre-releases.

some more info:
After hanging on hald, and hanging on entering the desktop, the mount doesn't work.

every time i do
ifdown eth0; ifup eth0
or mount /mymount

I find following message in my dmesg
Jun 13 21:44:17 localhost kernel: [4296366.388000] smb_lookup: find //DISK 1 failed, error=-5

and the mount still doesn't work

strangely, //DISK 1 is the name of the share, but I would expect the servername too, complete path would have been //server/DISK 1

regards

Tim

anybody tried using the _netdev option in fstab.... that may work ;)

hello,

i encountered this experience with placing auto mountable smbfs in /etc/fstab

if this is the case try the solution:

1) place a noauto option in your /etc/fstab smbfs entry

2) mount network shares using /etc/rc.local
if your network share is to be mounted to /mnt/shared then within /etc/rc.local
place

mount /mnt/shared

the mount command will further check fstab for correct mount options

Placing it in /etc/rc.local ensures that all modules are loaded before mounting the network share.

Hope this helps....

The noauto/mount in rc.local does work, and that is how I am currently working around the issue.

However, this is a workaround and NOT a solution. There is no reason mounting network shares in fstab should not work, and it worked fine in Breezy. Upgrading from Breezy gives the impression that Dapper is "broken". To a novice user, there is nothing in the symptoms of this bug (long load time with no taskbar/nautilus) that points to a network share as the problem.

This bug is a regression from Breezy, and I am very surprised that it has not received developer attention after nearly 2 months.

Please solve this bug.

To me this solution partially helped:

sudo apt-get remove --purge hal dbus

I really don't need neither hal, nor dbus. But I need the samba shares to be automatically mounted at boot time.

It *partially* works means that sometimes it mounts all samba shares, sometimes it skips some mounts. So it's like a lottery or roulette: every morning at work I don't know if it will mount all my shares.

Now I've tried to add

pre-up sleep 5

in

/etc/network/interfaces:

as Andras told in his comment ( https://launchpad.net/distros/ubuntu/+source/hal/+bug/44874/comments/44 )

I rebooted and all my shares are mounted. I hope it will work also during the next days ;-)

One month later and still no solution, or at least, not a permanent one. I have this same annoying bug ("Failed to initialize HAL" after adding smbfs share to /etc/fstab), however only when I boot with kernel 2.6.15-26-386. Booting with a previous version of the kernel, 2.6.15-23-386, everything is working fine. I would say: "Devs hop to it!".

I just (mid August '06) auto-upgraded to Dapper from Breezy.

I encountered the same problem on reboot.

The workaround provided by Nathaniel B. Jayme above worked for me.

This is a serious problem for anyone upgrading from Breezy to Dapper with smbfs mounts in their fstab. Please fix!

Successful workaround comment:
https://launchpad.net/distros/ubuntu/+source/hal/+bug/44874/comments/48

I want to clarify and give credit where it is due; the full workaround using rc.local was proposed by mambro and then further detailed for us less skilled users by Mr. Jayme.

I don't think this is a bug in smbfs. Since I upgraded to Dapper, my cifs (i.e. not smbfs) mount in /etc/fstab hasn't been working on boot. There weren't any obvious problems, no errors from the kernel, and no hangups*, so I was a bit puzzled but didn't get around to investigating it. The share doesn't get used very often and a simple 'sudo mount /mnt/share' mounted it when I needed it.

Today I found this report and tried the workaround suggested, by adding noauto to the fstab entry and putting 'mount /mnt/share' in /etc/rc.local. This fixed the problem. It seems to me there is a general problem with mounting network shares, not just smbfs. I've not tried nfs.

* unlike the experiences described here with smbfs - although I'm using Kubuntu and don't have Gnome installed, which may have affected things since some people mentioned problems with Nautilus.

I'm also experiencing this issue. Changing the mounts to cifs has alleviated the symptom of a hanging hald on startup.

Same here. When the samba share is auto mounted in /etc/fstab, HAL fails to initialise, the desktop is stalled for a couple of minutes. Then the desktop appears, and the samba share gets mounted. When doing lshal immediately in a terminal I got a message saying that HAL could not be connected to, either it was not running or not ready. After a couple of minutes trying lshal again shows me 94 entries from the global list. In other words, HAL seems stalled itself, waiting (too) long for samba to finish (even though it has nothing to do with samba I feel but it is in fstab the share is mounted so...).
The work around, putting noauto in the fstab and after the desktop appears, mounting the share by hand seems to do it... for now.
Let someone please take a look at this...

System specs:
AMD Athlon 64 3500+
ASUS A8V-X
2x 256MB PC3200 DDR400
Ubuntu Dapper Drake (up-to-date)
Radeon 9550 AGP8x

I'm experiencing a problem maybe related to this, but with nfs-shares (running up-to-date dapper):

/etc/fstab-entry:
     zweistein:/home /home nfs auto,nolock,tcp 0 0

This share get's mounted successfully at boot, but it doesn't show up neither in /etc/mtab nor running 'mount -l'.

Trying to run 'sudo mount -a' gives me an error:
     mount: zweistein:/home already mounted or /home busy

'sudo mount -o remount /home' doesn't change anything.
I have to run 'sudo umount /home; sudo mount /home' to get things right.

One point I found:
There isn't any link pointing to /etc/init.d/mountnfs.sh in any of /etc/rc?.d/

Markus

This sucks. Why does nobody take care of it? It just can't be that an operating system aiming at taking market share away from Microsoft (Bug #1) COMPLETELY STALLS if a network share is unavailable.

I think it's largely ignored because as people have suggested, if you
use cifs instead of smbfs it works, without stalling.

From what I know cifs is the replacement for smbfs. (from man
mount.cifs: The CIFS protocol is the successor to the SMB protocol)
It's installed when you install smbfs.

I had to start using it trying to get Ubuntu to connect to a 2003AD
server, and I noticed how much better it seems to work. No more hang
on boot, no more hanging if the share goes offline (it seamlessly
drops and picks up the remote share as it goes up and down)

my fstab:
//192.168.1.1/share /media/data cifs
file_mode=0777,dir_mode=0777,uid=0,gid=0,auto,rw,nouser,credentials=/etc/fstab_smb_credentials
0 0

fstab_smb_credentials:
username=user%
password=password

I've had absolutely no problems since I started using it (and I auto
mount shares with it on at least half a dozen systems)

changes from using smbfs were:
changing smbsf to cifs (obviously)
replacing dmask=777,fmask=777 with file_mode=0777,dir_mode=0777
and stripping the whitespace from the credentials file (cifs would choke on it)

I'd seen it mentioned here, but never knew anything about it until I
had to research 2003AD stuff. I'd been using smbfs because (like so
many people) I'd started my Linux learning at ubuntuguide.org who
still say to use smbfs

While I agree smbfs requires fixing, at least from the perspective of
compatibility - I think it's a documentation problem, users need to
know to use cifs instead of smbfs

On 10/22/06, Dennis Heinson <email address hidden> wrote:
> This sucks. Why does nobody take care of it? It just can't be that an
> operating system aiming at taking market share away from Microsoft (Bug
> #1) COMPLETELY STALLS if a network share is unavailable.
>
> --
> auto smbfs mount in /etc/fstab causes hald hang at boot
> https://launchpad.net/bugs/44874
>

--
O)-c

[edit]

forgot to mention in reference to my fstab and permissions my shares
are all passwordless and I want anonymous r/w - hence why everythings
777.
--
O)-c

May I link to my bug report Bug#62607, which addresses some issues I have with cifs. Perhaps some other cifs users can confirm it.

according to this thread: http://www.ubuntuforums.org/showthread.php?p=1660934#post1660934

the hal error happens when mounting by ip address. if you enable wins support and mount with netbios name '//netbiosname/share', the hal error goes away.

Hi,
Thanks for all the advise, this HAL problem happened on my old pc ages ago and being lazy and busy i've used the wireless laptop for a while.. until now.. anyway. Got the shares working thru cifs but had a few issues so i thought why didn't this error happen on the laptop ? hmmm, so i put the original shares back in fstab and ONLY added the "pre_up sleep 5" line to eth0 in the interfaces file (thanks Andras Nemeseri) and all the shares are working fine.
thanks.

I think it might be worth adding something I have noticed: the bug is more of a problem for shares where there are a large number of files/directories present.

I am generally able to boot successfully if I only attach to "small" shares (those with few files/folders in the root) but experience the hanging issue when the shares are "large", with a large number of files/folders in the root of the share.

Hope this helps any developer with the time to look at this; it's probably a fairly minor timing issue.

...and I have also noticed that it affects both cifs and smbfs.

replacing "smbfs" with "cifs" in fstab seemed to help for me. Long waits at boot time went away and the filesystem seems available. Manually mounting the filesystem every boot wasn't an option, because servers are supposed to be available automagically. (Dapper under VMWare)

From GNOME upstream:

"It seems from the Ubuntu report that this is a HAL bug and not a Nautilus one,
so closing NOTGNOME. Thanks for the report, please feel free to report any
other bugs you find.
"

Thank you for reporting this bug.

Does this occur in Lucid?

http://www.freedesktop.org/wiki/Software/hal/