Re: Strange umount problem in latest 2.4.0 kernels
On Fri, 12 Jan 2001, [EMAIL PROTECTED] wrote: > Same cam be applied to shm ? Thus kernel Documentation/Changes > should be changed: [...] > > none/dev/shmshm defaults0 0 > > to > > shm/dev/shmshm defaults0 0 > Yes, I thought that I changed that :-( I always have the type as device in my fstab. Linus, it is not really crucial, but still could be applied without breaking anything for sure ;-) Greetings Christoph --- 2.4.0/Documentation/Changes Mon Jan 1 19:00:04 2001 +++ linux/Documentation/Changes Fri Jan 12 09:03:35 2001 @@ -121,7 +121,7 @@ memory. Adding the following line to /etc/fstab should take care of things: -none /dev/shmshm defaults0 0 +shm/dev/shmshm defaults0 0 Remember to create the directory that you intend to mount shm on if necessary (The entry is automagically created if you use devfs). You - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
On 2001.01.11 [EMAIL PROTECTED] wrote:
> > The "none" bit puzzles me the most.
>
> It is a common misconfiguration. Given a line
>
> device dir type options garbage
>
> in /etc/fstab, some umount versions will complain "device busy"
> when the umount fails. Thus, it is better to use
>
> proc/proc proc
> devpts /dev/pts devpts
>
> instead of
>
> none/proc proc
> none/dev/pts devpts
>
> so as to avoid this silly "none busy".
> But many distributions come misconfigured like this.
>
Same cam be applied to shm ? Thus kernel Documentation/Changes should be
changed:
System V shared memory is now implemented via a virtual filesystem.
You do not have to mount it to use it. SYSV shared memory limits are
set via /proc/sys/kernel/shm{max,all,mni}. You should mount the
filesystem under /dev/shm to be able to use POSIX shared
memory. Adding the following line to /etc/fstab should take care of
things:
none/dev/shmshm defaults0 0
to
shm/dev/shmshm defaults0 0
--
J.A. Magallon $> cd pub
mailto:[EMAIL PROTECTED] $> more beer
Linux werewolf 2.4.0-ac5 #1 SMP Wed Jan 10 23:36:11 CET 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
"Udo A. Steinberg" wrote: > "Udo A. Steinberg" wrote: > > > > The very strange stuff is umount at reboot: > > > > umount: none busy - remounted read-only > > umount: /: device is busy > > Remounting root-filesystem read-only > > mount: / is busy > > Rebooting. Are you using devfs and do kernel threads have /dev/initctl open? # lsof /dev COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root 10u FIFO0,5 574 /dev/initctl keventd 2 root 10u FIFO0,5 574 /dev/initctl kapm-idle 3 root 10u FIFO0,5 574 /dev/initctl kswapd4 root 10u FIFO0,5 574 /dev/initctl kreclaimd 5 root 10u FIFO0,5 574 /dev/initctl bdflush 6 root 10u FIFO0,5 574 /dev/initctl kupdate 7 root 10u FIFO0,5 574 /dev/initctl i2oevtd 8 root 10u FIFO0,5 574 /dev/initctl i2oblock 9 root 10u FIFO0,5 574 /dev/initctl khubd12 root 10u FIFO0,5 574 /dev/initctl khttpd 16 root 10u FIFO0,5 574 /dev/initctl -d begin:vcard n:Ford;David x-mozilla-html:TRUE url:www.blue-labs.org adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A x-mozilla-cpt:;9952 fn:David Ford end:vcard
Re: Strange umount problem in latest 2.4.0 kernels
[EMAIL PROTECTED] wrote: > > These days umount is done by directory, not by device, > since a device may be mounted multiple times, so > I expect the silly message is gone. > (Is your umount recent?) > > [But this is only about the "none". I don't know what is > wrong in your situation.] My umount is 2.10r. Alan says he knows what is wrong, so we're all curiously expecting -ac7 ;) -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
> The "none" bit puzzles me the most. It is a common misconfiguration. Given a line device dir type options garbage in /etc/fstab, some umount versions will complain "device busy" when the umount fails. Thus, it is better to use proc/proc proc devpts /dev/pts devpts instead of none/proc proc none/dev/pts devpts so as to avoid this silly "none busy". But many distributions come misconfigured like this. These days umount is done by directory, not by device, since a device may be mounted multiple times, so I expect the silly message is gone. (Is your umount recent?) [But this is only about the "none". I don't know what is wrong in your situation.] Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
Udo, you write: > Anyway, disabled both lpd and httpd from the startup scripts > and now the bug is triggered *every* time. I cannot reboot > a single time without partitions being busy. When neither > lpd nor httpd run, fsck finds nothing wrong. > > The very strange stuff is umount at reboot: > > umount: none busy - remounted read-only Check the output of "mount" and/or your /etc/fstab for a device called "none". On my system, there is devpts which has device "none", so it is possible this is busy, and can't be unmounted, and hence root is also busy and can't be ro remounted. Maybe also check /proc/mounts for "none". > umount: /: device is busy > Remounting root-filesystem read-only > mount: / is busy > Rebooting. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
> I've checked a couple of other machines, different setups etc. > all with -ac6 and all show this behavior - also the umount stuff. Wait for -ac7 and see if that fixes it. I think I know whats up there - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
"Udo A. Steinberg" wrote: > > The very strange stuff is umount at reboot: > > umount: none busy - remounted read-only > umount: /: device is busy > Remounting root-filesystem read-only > mount: / is busy > Rebooting. I just noticed another strange effect: ps uxa misses a couple dozen processes. Effectively I'm seeing only the kernel processes, all gettys, rpc.portmap, bash and ps. All other processes, all daemons etc. are invisible. If I kill portmap another process becomes visible. I've checked a couple of other machines, different setups etc. all with -ac6 and all show this behavior - also the umount stuff. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
Alexander Viro wrote: > > umount: none busy - remounted read-only > > > The "none" bit puzzles me the most. /etc/fstab and /etc/mtab > > look perfectly ok. > > > > Has anyone got an idea? Everything worked well with 2.4.0 and > > Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes > > up now. > > Try to revert to -ac4 fs/super.c and see if it helps That makes no difference. Still acting weird. Must be something else. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
On Thu, 11 Jan 2001, Udo A. Steinberg wrote: > > /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED > umount: none busy - remounted read-only > The "none" bit puzzles me the most. /etc/fstab and /etc/mtab > look perfectly ok. > > Has anyone got an idea? Everything worked well with 2.4.0 and > Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes > up now. Try to revert to -ac4 fs/super.c and see if it helps - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
> /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED Ok, culprit identified: /var/spool/lpd/lpd.lock On another partition I had the same problem with httpd's error_log. Since both of those seem to be log- and lock-files, maybe there's something wrong with file locking? Anyway, disabled both lpd and httpd from the startup scripts and now the bug is triggered *every* time. I cannot reboot a single time without partitions being busy. When neither lpd nor httpd run, fsck finds nothing wrong. The very strange stuff is umount at reboot: umount: none busy - remounted read-only umount: /: device is busy Remounting root-filesystem read-only mount: / is busy Rebooting. *fsck* The "none" bit puzzles me the most. /etc/fstab and /etc/mtab look perfectly ok. Has anyone got an idea? Everything worked well with 2.4.0 and Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes up now. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
On Thu, 11 Jan 2001, Daniel Phillips wrote: > "Udo A. Steinberg" wrote: > > Upon fscking after reboot, I always have errors on a > > single inode and it's always the same one: > > > > /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED > > > > Can someone tell me an easy and reliable way of figuring > > out which file (program) uses said inode? I think that's > > probably the key to figuring out why the partition is > > busy on umount. > > ls -iR | grep 12345 find `mount | grep hdb1 | cut -f3 -d' '` -inum 522901 -xdev - no need to walk through all filesystems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Strange umount problem in latest 2.4.0 kernels
As previously reported by someone, there are occasional problems when shutting down with unmounting partitions, that are reported as busy for strange reasons. Keith Owens said it was supposedly a Redhat shutdown script issue and I since I'm not using Redhat, it's most likely not that. Upon fscking after reboot, I always have errors on a single inode and it's always the same one: /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED Can someone tell me an easy and reliable way of figuring out which file (program) uses said inode? I think that's probably the key to figuring out why the partition is busy on umount. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Strange umount problem in latest 2.4.0 kernels
As previously reported by someone, there are occasional problems when shutting down with unmounting partitions, that are reported as busy for strange reasons. Keith Owens said it was supposedly a Redhat shutdown script issue and I since I'm not using Redhat, it's most likely not that. Upon fscking after reboot, I always have errors on a single inode and it's always the same one: /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED Can someone tell me an easy and reliable way of figuring out which file (program) uses said inode? I think that's probably the key to figuring out why the partition is busy on umount. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
On Thu, 11 Jan 2001, Daniel Phillips wrote: "Udo A. Steinberg" wrote: Upon fscking after reboot, I always have errors on a single inode and it's always the same one: /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED Can someone tell me an easy and reliable way of figuring out which file (program) uses said inode? I think that's probably the key to figuring out why the partition is busy on umount. ls -iR | grep 12345 find `mount | grep hdb1 | cut -f3 -d' '` -inum 522901 -xdev - no need to walk through all filesystems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
/dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED Ok, culprit identified: /var/spool/lpd/lpd.lock On another partition I had the same problem with httpd's error_log. Since both of those seem to be log- and lock-files, maybe there's something wrong with file locking? Anyway, disabled both lpd and httpd from the startup scripts and now the bug is triggered *every* time. I cannot reboot a single time without partitions being busy. When neither lpd nor httpd run, fsck finds nothing wrong. The very strange stuff is umount at reboot: umount: none busy - remounted read-only umount: /: device is busy Remounting root-filesystem read-only mount: / is busy Rebooting. *fsck* The "none" bit puzzles me the most. /etc/fstab and /etc/mtab look perfectly ok. Has anyone got an idea? Everything worked well with 2.4.0 and Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes up now. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
On Thu, 11 Jan 2001, Udo A. Steinberg wrote: /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED umount: none busy - remounted read-only The "none" bit puzzles me the most. /etc/fstab and /etc/mtab look perfectly ok. Has anyone got an idea? Everything worked well with 2.4.0 and Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes up now. Try to revert to -ac4 fs/super.c and see if it helps - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
Alexander Viro wrote: umount: none busy - remounted read-only The "none" bit puzzles me the most. /etc/fstab and /etc/mtab look perfectly ok. Has anyone got an idea? Everything worked well with 2.4.0 and Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes up now. Try to revert to -ac4 fs/super.c and see if it helps That makes no difference. Still acting weird. Must be something else. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
"Udo A. Steinberg" wrote: The very strange stuff is umount at reboot: umount: none busy - remounted read-only umount: /: device is busy Remounting root-filesystem read-only mount: / is busy Rebooting. I just noticed another strange effect: ps uxa misses a couple dozen processes. Effectively I'm seeing only the kernel processes, all gettys, rpc.portmap, bash and ps. All other processes, all daemons etc. are invisible. If I kill portmap another process becomes visible. I've checked a couple of other machines, different setups etc. all with -ac6 and all show this behavior - also the umount stuff. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
I've checked a couple of other machines, different setups etc. all with -ac6 and all show this behavior - also the umount stuff. Wait for -ac7 and see if that fixes it. I think I know whats up there - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
Udo, you write: Anyway, disabled both lpd and httpd from the startup scripts and now the bug is triggered *every* time. I cannot reboot a single time without partitions being busy. When neither lpd nor httpd run, fsck finds nothing wrong. The very strange stuff is umount at reboot: umount: none busy - remounted read-only Check the output of "mount" and/or your /etc/fstab for a device called "none". On my system, there is devpts which has device "none", so it is possible this is busy, and can't be unmounted, and hence root is also busy and can't be ro remounted. Maybe also check /proc/mounts for "none". umount: /: device is busy Remounting root-filesystem read-only mount: / is busy Rebooting. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
The "none" bit puzzles me the most. It is a common misconfiguration. Given a line device dir type options garbage in /etc/fstab, some umount versions will complain "device busy" when the umount fails. Thus, it is better to use proc/proc proc devpts /dev/pts devpts instead of none/proc proc none/dev/pts devpts so as to avoid this silly "none busy". But many distributions come misconfigured like this. These days umount is done by directory, not by device, since a device may be mounted multiple times, so I expect the silly message is gone. (Is your umount recent?) [But this is only about the "none". I don't know what is wrong in your situation.] Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
[EMAIL PROTECTED] wrote: These days umount is done by directory, not by device, since a device may be mounted multiple times, so I expect the silly message is gone. (Is your umount recent?) [But this is only about the "none". I don't know what is wrong in your situation.] My umount is 2.10r. Alan says he knows what is wrong, so we're all curiously expecting -ac7 ;) -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
"Udo A. Steinberg" wrote: "Udo A. Steinberg" wrote: The very strange stuff is umount at reboot: umount: none busy - remounted read-only umount: /: device is busy Remounting root-filesystem read-only mount: / is busy Rebooting. Are you using devfs and do kernel threads have /dev/initctl open? # lsof /dev COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root 10u FIFO0,5 574 /dev/initctl keventd 2 root 10u FIFO0,5 574 /dev/initctl kapm-idle 3 root 10u FIFO0,5 574 /dev/initctl kswapd4 root 10u FIFO0,5 574 /dev/initctl kreclaimd 5 root 10u FIFO0,5 574 /dev/initctl bdflush 6 root 10u FIFO0,5 574 /dev/initctl kupdate 7 root 10u FIFO0,5 574 /dev/initctl i2oevtd 8 root 10u FIFO0,5 574 /dev/initctl i2oblock 9 root 10u FIFO0,5 574 /dev/initctl khubd12 root 10u FIFO0,5 574 /dev/initctl khttpd 16 root 10u FIFO0,5 574 /dev/initctl -d begin:vcard n:Ford;David x-mozilla-html:TRUE url:www.blue-labs.org adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A x-mozilla-cpt:;9952 fn:David Ford end:vcard
Re: Strange umount problem in latest 2.4.0 kernels
On 2001.01.11 [EMAIL PROTECTED] wrote:
The "none" bit puzzles me the most.
It is a common misconfiguration. Given a line
device dir type options garbage
in /etc/fstab, some umount versions will complain "device busy"
when the umount fails. Thus, it is better to use
proc/proc proc
devpts /dev/pts devpts
instead of
none/proc proc
none/dev/pts devpts
so as to avoid this silly "none busy".
But many distributions come misconfigured like this.
Same cam be applied to shm ? Thus kernel Documentation/Changes should be
changed:
System V shared memory is now implemented via a virtual filesystem.
You do not have to mount it to use it. SYSV shared memory limits are
set via /proc/sys/kernel/shm{max,all,mni}. You should mount the
filesystem under /dev/shm to be able to use POSIX shared
memory. Adding the following line to /etc/fstab should take care of
things:
none/dev/shmshm defaults0 0
to
shm/dev/shmshm defaults0 0
--
J.A. Magallon $ cd pub
mailto:[EMAIL PROTECTED] $ more beer
Linux werewolf 2.4.0-ac5 #1 SMP Wed Jan 10 23:36:11 CET 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Strange umount problem in latest 2.4.0 kernels
On Fri, 12 Jan 2001, [EMAIL PROTECTED] wrote: Same cam be applied to shm ? Thus kernel Documentation/Changes should be changed: [...] none/dev/shmshm defaults0 0 to shm/dev/shmshm defaults0 0 Yes, I thought that I changed that :-( I always have the type as device in my fstab. Linus, it is not really crucial, but still could be applied without breaking anything for sure ;-) Greetings Christoph --- 2.4.0/Documentation/Changes Mon Jan 1 19:00:04 2001 +++ linux/Documentation/Changes Fri Jan 12 09:03:35 2001 @@ -121,7 +121,7 @@ memory. Adding the following line to /etc/fstab should take care of things: -none /dev/shmshm defaults0 0 +shm/dev/shmshm defaults0 0 Remember to create the directory that you intend to mount shm on if necessary (The entry is automagically created if you use devfs). You - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
