Viewing Category: VMware  [clear category selection]

YAWDLCSB: Yet Another Way to Disable Linux Console Screen Blanking

I wrote about this topic several years ago, but I'll be darned if I can find it. I run several Linux virtual machines using VMware Fusion, and I'd rather the console text stay visible for the purpose of identification and to see any console messages. By default, they will go blank after a few minutes. If you do a Google search for how to disable console screen blanking, you'll see that the most common recommendation is to add /usr/bin/setterm -blank 0 to the end of /etc/rc.d/rc.local. For some reason, that feels icky to me. Another way is to append the control characters to the end of the /etc/issue file, with /usr/bin/setterm -term linux -blank 0 >> /etc/issue.

For background, the function of setterm is to issue specific control character sequences to the terminal to cause the terminal to change its behavior. There is a database of terminal capabilities (/etc/termcap) that correlates with the terminfo function that setterm uses. When Linux boots, it starts up terminals identified in /etc/inittab. My installation of CentOS 5.5, and I believe many others as well, starts six /sbin/mingetty virtual console listening to /dev/tty[1-6]. When mingetty starts up, it echos the content of /etc/issue, unless given the -noissue argument.

I should also mention that I made the modification to the /etc/issue file while connected to the (virtual) machine over an SSH terminal. Therefore, my TERM environment variable was not neccessarily the same as the terminal identifier that the virtual console at boot. In fact, it isn't (xterm vs. linux). For this reason, it's neccessary to include the -term linux argument to setterm command so it's query of the terminal escape codes is correct. You can verify that indeed there is a difference by running /usr/bin/setterm -blank 0 | /usr/bin/hexdump when connected to both terminals; there is no escape sequence meaningful to xterm about screenblanking. After making the modification to /etc/issue I see that the bytes are appended to the file: /usr/bin/hexdump /etc/issue. Obviously, this will only take effect when each /sbin/mingetty is restarted. The easiest thing to do is reboot.

CentOS 5.1 on VMware Server

I created a pretty awesome CentOS 5.1 virtual machine. It's quite lean, using only 256 Mb of RAM and a 2.0 Gb virtual disk. One issue that I encountered when doing the installation from a DVD (virtual CDROM using an ISO image), was that the installer boot kernel didn't have support for the virtual SCSI controller created by VMware Server 1.0.5. Apparently, my choice of OS (RHEL 4) when using the Create New Virtual Machine Wizard caused the VM to use a BusLogic controller. The fix was to edit the VMX file and add the following:

scsi0.virtualDev = "lsilogic"

For whatever reason, the scsi0.virtualDev was undefined, so I added the line, rather than editing an existing definition. The CentOS installation worked perfectly using the LSI Logic controller, and continues to function properly after the using the guest OS.

I see that there is an Open Source project to replace the proprietary VMwareTools package: Open Virtual Machine Tools. I would really like to use these, but I don't want to go through the effort of compiling them myself -- every time there is a kernel update. Hopefully they'll be added to a current repository soon. I installed the VMwareTools package, but since I'm not running X Windows on this VM and don't want shared folder support, I removed them.

While installing CentOS 5.1, I created a new kickstart script. It's a no-frills install: centos51.cfg. By the way, it will take more than 2.0 Gb of disk space for the installation using that kickstart script. On my first pass, the /var and /home logical volumes were so big that it didn't leave enough space on the root filesystem. When this happens, Anaconda presents an amusing error message:

Very funny, guys.

Offline Warning with JavaScript

The requirement is to check whether an HTML file has been loaded from a local source, say a CD-ROM, or from a website. It's possible to test the document.location.protocol value and act accordingly. This doesn't actually check to see if a valid network connection exists -- that would require a different test to attempt loading something from a remote site. The handleLinkClick function just evaluates the protocol to be used when a link from a local file is clicked.

<script> function handleLinkClick(link) { if (document.location.protocol == "file:" && link.protocol != "file:") { return confirm("This link requires Internet access.\nClick cancel if you're not online."); } return true; } </script>

In the body of the local document, the links would be updated with the onclick attribute. Technically, only the remote links need to be changed, but if a global search-and-replace didn't differentiate, that would be fine.

<a href="" onclick="return handleLinkClick(this);">Remote Site</a><br/> <a href="file.html" onclick="return handleLinkClick(this);">Local File</a>

Unfortunately, if the user doesn't follow the instructions, and clicks OK when they don't actually have Internet access, they'll get an error from their web browser about being unable to access the page. Can't help you there...