On Thu, 05 Oct 2000, you opined:
>On Wed, Oct 04, 2000 at 09:49:06PM -0500, Uncle Meat wrote:
>> > Turning off quotas [ok]
>> > Unmounting file systems umount2: Device or resource busy
>> > umount: /usr/hda1: device is busy
>> > umount2: Device or resource busy
>> > umount: /usr: device is busy
>> >
>> > No process references; use -v for the complete list
>> > No automatic removal. Please use umount /usr/hda1
>> > INIT: no more processes left in this runlevel
>>
>> I have no idea what this umount2 command is or what's generating it. But,
>> that is likely what is causing it. Any idea where it came from? If you have
>> a pure rpm system:
>>
>> locate umount2
>>
>> will get a path, and:
>>
>> rpm -qf /<path>/umount2
>>
>> will get the name of the rpm that owns it.
>I did 'locate umount2' and it didn't find anything. I also used find
>from the root like this 'find -iname "umount2"' and it found nothing.
>Then I ran grep on all the files in rc[0-6].d and init.d looking for
>umount2. Still no references to umount2. I can't figure out where
>it's coming from.
Curiouser and curiouser. I can't fathom this happening without something
calling a file or function named 'umount2' (since that's what the log claims
is happening).
>> The only other reason that I can think of for this happening is if
/usr/lib >> or /usr/hda1/lib was in active use when the shutdown tried to
umount it >> (like sitting in /mnt/cdrom then issuing the command 'umount
/mnt/cdrom' - >> will give a device busy error). Since /usr/lib is used by
many things, this >> could be the case.
>
>>From reading the umount man page, I figured that umount was opening
>libraries in /usr/lib and causing the error itself. The manpage says
>this is possible. What I don't understand is why that wasn't a
>problem before--seems like that would be a problem regardless of
>where the /usr/lib directory is mounted. I.e., it has to be
>unmounted regardless of where it is.
Possibly because of the order in which the umounts take place. Obviously,
some have to remain (/) to execute commands until the last one is down. For
some commands, /usr/lib may be essential and /usr/hda1 may be trying to
shut it down too early.
Just a guess. I haven't delved into it that much.
>> You might try (besides locating the umount2 command and shutting it off
if >> possible) logging in as single user, move the lib directory back
where it >> was and move something else with a symlink, like /usr/share.
That one >> shouldn't give you such a problem (unless umount2 is the
problem) and it's >> generally huge, which would free up a lot of space.
>
>I was afraid this is what I'd have to do. It just seems like there'd
>have to be some way around it--I mean, on a large system do you
>always have to have /usr/lib on the same disk and in the same
>partition as / or /usr?
Never tried mounting /usr/lib anyplace else so I can't answer that. But,
it's entirely possible that the system functions may well _assume_ mounting
/usr will also get /usr/lib, /usr/bin, /usr/sbin, etc. In that case, moving
it and symlinking wouldn't work too well.
Personally, I don't think I'd ever try doing it to any of those named
above, plus a few others I can bring to mind (/boot, /lib, /sbin, /etc)
because those (the latter ones) guarantee failure.
--
Excuse my english. I went to US public school.
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
