I just upgraded to the latest openafs (from 1.4.0 to 1.4.0-r1). Emerge went fine, during which I had openafs-client shutdown. I did a dispatch-conf to update to the new openafs config file. When I attempt to run it now, however I get: # /etc/init.d/openafs-client start * Starting OpenAFS client ... * Loading OpenAFS kernel module ... [ ok ] * Starting OpenAFS daemon ... [ !! ] Manually, I get /usr/sbin/afsd -verbose [...a bunch of messages saying it's creating cache files] All AFS daemons started. afsd: Forking trunc-cache daemon. SScall(137, 28, 3)=0 afsd: Mounting the AFS root on '/afs', flags: 0. afsd: Can't mount AFS on /afs(2) I fail to see what is wrong here. In the URL given above, I include pointers to suggestions/info I found from IBM and MIT, but they have not helped.
Created attachment 75589 [details] openafs emerge from /var/log/emerge.log
Created attachment 75590 [details] emerge --info
I considered the changes to the init script as only minor, so this kind of surprises me. Furthermore, the init script is the only thing that has changed from 1.4.0 to 1.4.0-r1 (the patch can be found in bug #116220). Does your /afs directory still exist? Did any messages appear in dmesg? What exactly did you try that didn't help? ...
(In reply to comment #3) > I considered the changes to the init script as only minor, so this kind of > surprises me. Furthermore, the init script is the only thing that has > changed from 1.4.0 to 1.4.0-r1 (the patch can be found in bug #116220). Yes, I'm surprised too. Since I really count on AFS being there (a work machine), and everything had worked so well with 1.4.0, I figured 1.4.0-r1 would be a piece of cake. > Does your /afs directory still exist? No: ls / shows no /afs No: # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/hdb3 / ext3 rw,noatime,data=ordered 0 0 proc /proc proc rw,nodiratime 0 0 sysfs /sys sysfs rw 0 0 udev /dev tmpfs rw,nosuid 0 0 devpts /dev/pts devpts rw 0 0 /dev/vg/usr /usr reiserfs rw,noatime 0 0 /dev/vg/home /home reiserfs rw,noatime 0 0 /dev/vg/opt /opt reiserfs rw,noatime 0 0 /dev/vg/var /var reiserfs rw,noatime 0 0 /dev/vg/tmp /tmp reiserfs rw,noatime 0 0 /dev/vg/afscache /var/cache/openafs ext2 rw,nogrpid 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0 usbfs /proc/bus/usb usbfs rw 0 0 but as you can see, /var/cache/openafs is still there. > Did any messages appear in dmesg? Yes, I see some problems there, but not sure how to address them. I will attach dmesg in a minute. > What exactly did you try that didn't help? ... (I mention this in the "URL", i.e., thread in the forum.) I tried deleting everything from /var/cache/openafs and then restarting. I verified values in ThisCell, TheseCells, and /etc/openafs/cacheinfo. There were no changes to the later three. Deleting cache made no difference. I played with rxdebug, as mentioned by MIT, but really don't know where to go with that.
Created attachment 75591 [details] dmesg
My guess is to fix this, you just need to "mkdir /afs" and restart openafs-client. As to how this occurred, did you have openafs-client running or not while you were upgrading? (Either should work, just trying to figure out how it went wrong)
Oops sorry, you already mentioned that in your first comment :) Working towards a fix...
(In reply to comment #6) > My guess is to fix this, you just need to "mkdir /afs" and restart > openafs-client. Your guess would be right! Thanks! gannet ~ # /usr/sbin/afsd -shutdown afsd: Shutting down all afs processes and afs state gannet ~ # modprobe -r openafs gannet ~ # mkdir /afs gannet ~ # /etc/init.d/openafs-client start * Starting OpenAFS client ... * Loading OpenAFS kernel module ... [ ok ] * Starting OpenAFS daemon ... [ ok > As to how this occurred, did you have openafs-client running > or not while you were upgrading? (Either should work, just trying to figure > out how it went wrong) No, I shut it down first, figuring it might cause problems. You know, I don't remember making /afs when I first installed openafs. I thought about doing that, but it seemed wrong to me. I thought the client should do all that. Sorry about that! I do backups (using rdiff-backup) through /afs so I pump quite a bit of data through it sometimes. I'll let you know if anything strange shows up. Any other questions? (In case so, I didn't close this bug, but you can as you see fit, of course.) I would like to thank you greatly for the magnificently FAST RESPONSE! Wow! I am not only deeply indebted, but happily impressed!!!! /iMike
> No, I shut it down first, figuring it might cause problems. > > You know, I don't remember making /afs when I first installed openafs. I > thought about doing that, but it seemed wrong to me. I thought the client > should do all that. Sorry about that! Ironically, this bug wouldn't have occurred if you hadn't shut down your client. And the openafs-ebuild makes the /afs-dir for you. Only problem is, it deletes it when it's uninstalled, regardless of whether you installed a newer version in the mean time or not. So this bug also only shows during an upgrade. FYI, the actual bug is in bug #9849, which is known, but the code designed to cirumvent it seems flawed as well. > I would like to thank you greatly for the magnificently FAST RESPONSE! Wow! I > am not only deeply indebted, but happily impressed!!!! You're very welcome. Our aim is to please and minimize downtime :-D
Thanks again, Stefaan! OpenAFS/Heimdal is working great now! (I'll try not to be so carefull about shutting it down before an upgrade again ;-)
Moved mountpoint creation/deletion from ebuild to init-script in openafs-1.4.0-r2. Thanks for reporting!
