When I installed my Mandrake 7.1 system, I partitioned it so that /dev/hdb4 would be mounted to /usr and /dev/hdb2/ on / and /dev/hda1 on /boot. My problem is when I restart or halt Linux at the stage when it unmounts the file systems, I get this error: /usr: device is busy. And then it freezes there. When I start the system again, it takes a long time to check it dev/hdb4. I would like to know how to fix this. —Charles Diaz-Alejandro, oguara@bellsouth.net
It sounds like there must be a process that is still running when the system drops runlevels. If that process has any files open or accesses to that partition, it is possible that mount will not be successful. What you might try booting into single-user mode and then looking at how many processes you have and which ones they are specifically. Runlevel 1 should have very few processes because they get killed when you switch runlevels—it is possible that one of the processes is not responding or cannot be terminated properly. What you could try doing while in single-user mode is to remount the /usr partition read-only with mount -o remount,ro /usr. If this fails due to “busy” errors, then try killing off some of the higher-numbered processes. You probably don't want to kill the very low-numbered ones, though. After each kill, try to remount the /usr read-only until it succeeds. Then you will know which process is causing the hangup. It may also be due to the amd process. I have seen amd and nfs cause mishaps like this. Once you know which process it is, you can disable the service or at least work towards getting it fixed properly. —Andy Bradford, andyb@calderasystems.com
The system prefers not to unmount a file system if a file within it is opened or if a process has its current working directory within the file system. Most distributions try to remount the file system read-only if umount fails, in order to avoid the file system check pass on next boot. Mounting read-only fails only if a file in the partition is opened for writing. If your mount command is not to ancient, change the umount to umount -r (manual says: “In case unmounting fails, try to remount read-only.”) I can't tell why your umount fails, but you can try to find the guilty process by calling “fuser” in the shutdown script before the umount command:
fuser -m /usr; ps afx; sleep 10
(The “ps” helps in understanding what the process IDs are). Refer to man fuser for any details. —Alessandro Rubini, rubini@linux.it
It's probably due to a minor bug in Mandrake. One way to find out is do add this just before the end of /etc/rc.d/init.d/halt:
(fuser -vm /usr; ps auxww )| more read a
(before the “# Now halt or reboot” section). This would usually require you to copy /usr/sbin/fuser to /sbin/fuser to that it's accessible, but since /usr is not being unmounted, it should still be accessible in /usr. Fuser should show you a list of processes that still use the /usr mountpoint and you can look up their number. Then, depending on the output, you can modify the halt script to kill those processes (although the halt script should already kill everything) or ask MandrakeSoft why those processes don't get killed and your partition doesn't get unmounted. —Marc Merlin, marc_bts@valinux.com
Does Linux have a “standby” mode similar to Windows 98? This would enable my computer to sort of power down and sleep when no activity is detected. —Ronnie Bell, ronbell@cais.com
If your kernel has APM compiled in (and I believe the default Red Hat 6.2 kernel does), you can use the standby button on your PC case if you have one and configure it to put the machine on standby if you do a short press. From the command line, you can also use apm -s or apm -S for suspend and standby. —Marc Merlin, marc_bts@valinux.com
The kernel automatically halts the CPU when there is no work to be done, enabling the CPU to enter a low-power mode (the CPU is reactivated when there's more work to do; this is all transparent to you). You can also configure APM (Advanced Power Management) support in your kernel, assuming you have a laptop with an APM-compatible BIOS. For even more power savings, you can tell the X server to use DPMS (the Display Power Management System) to turn off your monitor after a long enough period of keyboard/mouse inactivity. I do that with:
xset +dpms xset dpms 600 1800 3600
This puts the monitor in standby mode after 10 minutes (600 seconds), goes to suspend mode after 30 minutes (1,800 seconds) and turns it completely off after 60 minutes (3,600 seconds). Each of these levels increases the power savings. Adjust the numbers to suit your working style, but be aware that your video card and monitor must support DPMS in order for this to work—otherwise, nothing special will happen. As an alternative to the xset command, you can enable DPMS support in your XF86Config file; search for “power_saver” in the XF86Config man page for more information. Finally, you can use the hdparm command to spin down your hard disk. I don't personally recommend this, if only because spinning the drive down and back up reportedly causes as much wear and tear as six hours of use, but you can do it if you want to (read man hdparm for details). I'm willing to make some sacrifices for the good of the planet, but sacrificing my Linux disk is simply too much to ask. :-)—Scott Maxwell, maxwell@ScottMaxwell.orgi
You should use the apmd package, which is available from Red Hat's distribution. Of course, the “apmd” d<\#230>mon should be started at boot time (try “setup” or “linuxconf” to add it to the system services). —Pierre Ficheux, pficheux@com1.fr
I'm running Red Hat 6.1 on a Dell machine and I have DSL Internet access through Telocity. Until I got the Telocity service, my computer always thought of itself solely as “localhost.localdomain”. (For example, my bash prompt would read “[jenny@localhost tmp]$ ”). This seemed lame, but caused no problems. After Telocity came into my life, it mostly thought of itself as dsl-216-227-xxx-xxx.telocity.com. I'm not completely sure, but I think my prompt changed accordingly. After a recent reboot, though, we're back to “localhost.localdomain” and certain pieces of software with license managers that use the server's name are not working anymore. The licenses had been set up during the DSL phase. I've gotten them working again, but I'm afraid that one day my machine will go back to being dsl-blah-blah-blah and I'll have to fix it all again. Where does my computer's true identity reside? At what point in the boot process or on a running system does that get decided? How can I eradicate one of these identities entirely? What is the role of /etc/hosts? Could I have it both ways and have both entries in there? If so, would the IP address for dsl-blah-blah-blah need to be the loopback address 127.0.0.1, or my IP address from Telocity? For the record, the output from uname -n (today, at least) is localhost.localdomain. And here's my /etc/hosts file:
[root@localhost splus]# cat /etc/hosts 172.16.87.2 windoze.localdomain windoze 127.0.0.1 localhost.localdomain localhost
Thanks very much! —Jennifer Bryan, jennybryan@telocity.com
Red Hat keeps the machine name in three places: /etc/HOSTNAME (which is largely ignored; it's for compatibility with Slackware), /etc/sysconfig/network (HOSTNAME and DOMAINNAME) or /etc/hosts. You can change your machine's host name from the shell prompt with hostname:
moremagic:~# hostname foo moremagic:~# hostname foo moremagic:~# bash foo:~# exit exit moremagic:~# hostname moremagic.merlins.org moremagic:~# hostname moremagic.merlins.org
—Marc Merlin, marc_bts@valinux.com
Actually, your machine is “localhost.localdomain” when the Ethernet interface is down (ie the system is not connected to the network). Once the eth0 interface is up, the name of your system is “dsl-216-227-xxx-xxx.telocity.com”. According to the description of the problem, I think you don't use a fixed IP address, so your IP (and so your name) will change every time you reboot the system. If your license is configured for a static IP address, it would work only when your dynamic address matches the license address. I don't know a lot about your license manager, but maybe it's possible to use the Linux “dummy” net driver configured for the address defined in the license manager. Here is an example of dummy0 configuration on my system (assuming 192.168.3.3 is the static address used by license manager):
ifconfig dummy0 192.168.3.3 up route route add 192.168.3.3 dummy0
If connected to the Net, your system will reply both to the dynamic DSL IP address and the static dummy IP address. If not connected, the system will reply only to the dummy IP address used by the license manager. Another solution is to get a static DSL IP address from your ISP. It's more expensive, but will work every time. I don't think /etc/hosts could help you in case of dynamic IP. The file is useful for adding hosts name+address or name aliases you don't want to add to your DNS. —Pierre Ficheux, pficheux@com1.fr
Okay, this is silly I think, but I can't find ANY info on it. My floppy worked until today; now when I click on it or try to mount it or try to access a file on it, or format it or put a file on it, I get an error message saying “mount: can't mount, dev/fd0 has wrong major or minor number”. What is this about? How can I fix it? —Sean Lafreniere, sblafren@easystreet.com
Here are the correct permissions and major/minor numbers for /dev/fd0 on Red Hat:
brw------- 1 root floppy 2, 0 May 5 1998 /dev/fd0
If they don't match, you can recreate them with mknod /dev/fd0 b 2 0. —Marc Merlin, marc_bts@valinux.com
Is it possible for a mouse to cause a system lock? When I am in an X session and I use my mouse (I've tried the Microsoft Intellimouse, and the Logitech First Mouse), sometimes my system locks up and I can't exit the session even forcefully. The mice I've been trying function normally otherwise, and I've tried using them in both PS/2 and serial ports with both the generic and specific drivers. This lock happens only when I use the mouse, but it doesn't happen immediately—it can happen after five minutes of use or 45 minutes of use. There doesn't seem to be a pattern. The techs at Red Hat didn't have a clue, and I'm getting pretty desperate. Any help would be greatly appreciated. —Mike, shirleymg@netscape.net
Considering that a PS/2 mouse uses interrupt 12, which no self-respecting motherboard should assign to anything else, unless you have an ISA card that uses that interrupt, it's probably not a mouse conflict. It's not necessarily the mouse; it could simply be your X server or your graphics card. Try to see if upgrading X works, and if that still doesn't help, try swapping the graphics card with another type. —Marc Merlin, marc_bts@valinux.com
If this happens only with PS/2 mice, then it may be due to a problem in some versions of the kernel driver. A PS/2 mouse is managed by the keyboard controller, so if you lose one, you lose both. Try upgrading to the latest version of the kernel release you are using. Since you report the problem with any kind of mouse, I don't think it's related to mouse activity. Please try to resort to the “Magic SysRq” feature to print out some system information when the lock happens. Using the magic SysRq feature, you should also be able to kill X; if not, you should reproduce the problem in text mode. If no information can be extracted, then the system is locked hard, and it looks more like a hardware problem than a software one. Maybe the processor shuts down for overheating or something similar. —Alessandro Rubini, rubini@linux.it
How can I do an install with Corel 1.1 in text-based mode? Or, rephrasing the question: I'm trying to install Corel 1.1 on a laptop. Since Corel is GUI-based from the get-go, I get an unreadable screen during the install. I was able to do a Red Hat 6.2 install on the laptop, since I was able to put it into text mode during the install. Any words of wisdom on Linux laptop installs? —Ed, Ed.Werzyn@POBox.com
I think Corel requires a Vesa 2.0-compliant video card to install and doesn't offer a text mode install. If you really want to install Corel nonetheless, you can install it onto another machine, boot from an NFS+network+pcmcia boot floppy or CD (http://www.toms.net/rb/ for instance) and do an NFS copy of your installed distribution over to your laptop. —Marc Merlin, marc_bts@valinux.com
Hi, I seem to be having a slight problem. When I ctrl-alt F1-F6 from X or quit out of the wm, I am greeted with a blank console; everything I type on that console is blindly written. This happens anytime I go into X and back out to a console. I can issue a reset and I will get the console back, but soon as I go back to X and then back out, it's again blacked out (or no fonts/text showing). I have edited /etc/inittab for the alt + uparrow to issue a reset, but this is a workaround and very annoying. Does anyone know what is actually screwed up and how to fix? I recently compiled X 4.01 and it was fine up until the time I rebooted a day or so later for a kernel compile. I have seen this problem before, so it's not an X 4.01-specific problem. It's an “I screwed something up” problem, I am guessing. I am not running SVGAtextmode, nor are the fonts on console scrambled, they are just blacked out. —Steve Udell, hettar@home.com
If you aren't running your text mode in 80x25, try doing that. Some video drivers don't restore nondefault text modes very well, let alone deal with VesaFB (the graphical text console with a penguin boot logo). —Marc Merlin, marc_bts@valinux.com
