Klaus Knopper is the creator of Knoppix and co-founder of the LinuxTag expo. He currently works as a teacher, programmer, and consultant. If you have a configuration problem, or if you just want to learn more about how Linux works, send your questions to: email@example.com
About 24 months ago, I bought a plain, bottom-of-the-range PC with a built-in graphics card. Fedora 5 was out, but I installed Fedora 4 because I had it on hand, and I set up the system for a 19" LCD (1280x1024). Twelve months ago, I gave the 19" LCD to my mother when her 15" CRT died. Then I got a 22" LCD (1680x1050) and, under KDE's Control Center, I picked 1680x1050 in Peripheral | Display. The setting now states (1680x1200), although I am sure I picked 1680x1050.
I was actually quite happy with the situation. The LCD behaved as a viewport of a larger desktop. If I moved the mouse pointer to the bottom of the LCD, the desktop would scroll up to reveal the hidden 150 pixels.
My usual configuration is with the menu at the top (and most apps windows are the same). It is quite natural to work in the top 7/8 of the desktop. The bottom 150 pixels is a handy place to shove a window out of sight. The only problems occurs when a window initializes and its bottom is in the hidden area, or when the application's menu is at the bottom (for example, xpdf) and the mouse inadvertently touches the bottom of the LCD, causing the desktop to scroll up. Otherwise, this configuration is very convenient.
Is this novel configuration caused by a driver problem, or have I blundered onto a feature of X Window that is common knowledge but seldom used?
Recently, I tried Fedora 8. It just automatically recognizes the monitor size. At times I miss the hidden 150-pixel space at the bottom. Is there any way to get it back?
Also, I experience a logout problem with Fedora 8: I've found that, by right-clicking on the desktop background and logging out from that menu, the system doesn't freeze like it does when I am using the menu bar, but then, at shutdown, the system does briefly show a bland login window with a yellow flower in the bottom right hand corner.
The "hidden 150 pixels" is indeed caused by a feature of the X server. If the custom scree size is set to 1680x1200, but the "viewable" size is only 1680x1050, xorg will go into scrolling mode just like with the "lower resolution" modes that you can cycle into by hitting Control+Alt+NumericPlus.
Newer setups of xorg have replaced this feature by changing the desktop resolution instead, using the randr server extension. The advantage is that the desktop adjusts its size automatically when changing resolution.
Also, switching between different output devices is easier (e.g., connecting to a projector with a different resolution or scaling the internal display to the external resolution). Xorg will load the randr extension automatically, and then the Modes settings in /etc/X11/xorg.conf seem to get mostly ignored in favor of what the display specifies as its favorite resolution.
You can tell xorg to change its resolution settings on the fly using krandrtray (KDE) or xrandr (works with most desktops and session managers independently of the distribution).
# xrandr --output LVDS --auto
will try to auto-align the X server's resolution with the monitor or display, whereas:
# xrandr --output LVDS --mode 800x600
# xrandr --output LVDS -s 800x600
will set the mode or resolution to the specified 800x600 size, which will also make certain desktops "snap" into a new screen size.
# xrandr --output VGA --auto
should switch on the external VGA port of a notebook and also snap the desktop to the attached monitor's or projector's preferred resolution, in case the external port is not disabled by a hardware feature.
To switch back to the old behavior, (turning randr off in xorg), add the following section to your /etc/X11/xorg.conf file:
Section "ServerFlags" Option "RandR" "false" EndSection
You will have to restart the X server for the change to take effect. Also, check /etc/X11/xorg.conf for modes (fixed resolutions), and check /var/log/Xorg.0.log for anything with RandR or modes that are rejected.
Regarding your second question: It makes a difference whether the logout module of your desktop is called directly as a program, in which case there will be no "frozen" screen, or whether it is called by the session manager, which will attempt to block all interactive elements other than the logout window. This should explain the different is behavior.
The strange login graphics appearing when the system shuts down can either be leftover graphics in the shared memory of the graphics card, or the attempt by the display manager (kdm, gdm, or xdm) to launch a new login window before it realizes a shutdown is in progress.
I am fairly new to Linux, but now that I am getting familiar with it, I wish I would have switched years ago.
Your Knoppix project is the reason why I switched to Linux; it allowed me to fumble and mess-up as much as I wanted and did not effect my machine in the least bit – thank you! I'm glad I'm not alone in this migration, I read the Ask Klaus column in Linux Magazine, and I can see that other people are wearing the same boots.
Now that I do have a few months of experience under my belt, I attempted to test 128GB of RAM with the memtest utility in the boot menu, and it got stuck. I expected that result because I figure Chris Brady was not thinking of that much memory when he wrote the program. (By the way, I'm not complaining about memtest86 – I love it and use it all the time.)
After failing to run the memtest utility successfully, I attempted to boot Knoppix. The system would not boot either. So, my questions to you are: How can I test more than 64 gigs of memory in a single shot? How can I boot Knoppix on a machine running four Quad-Core AMD processors (that's 16 CPUs total) and more than 64GB of RAM? (I used 128GB.)
Typically, I test DDR2 and FBDIMM with various types of mother boards. For this test, I used a H8QME-2; the link is http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QME-2+.cfm.
If you need more information from me, please ask away; I appreciate your time and am a huge fan!
P.S. If you ever need help testing your software on large amounts of RAM and the newest motherboards, I just might be able to help.
I'm afraid I have to tell you that the Linux kernel on Knoppix does not support more than 4GB of RAM because it is compiled in compatibility mode, which allows it to work on every i*86-compatible CPU starting from the oldest i386 to the newest Intel or AMD chips.
To address more than 4GB of physical RAM, you must turn on a special CPU extension called "PAE" when configuring the kernel (see Figure 1). Unfortunately, this extension is incompatible with CPUs that don't support it; with PAE enabled on a non-PAE capable CPU, the system will freeze instantly. Therefore, most distributions choose to install a kernel without PAE by default, whereas you always have the option of installing a PAE-enabled kernel at a later time.
A kernel with PAE enabled – either on a Live or hard disk-based system – will support larger amounts of RAM, although installing a new kernel is somewhat difficult if you have not done it before. You'll need to worry about kernel configuration, installation, and probably also creating an initial ram disk.
Maybe you have to disable the "unsupported" RAM when booting a non-PAE-kernel with the boot option:
(watch out for the capital M) to free up the address space the CPU needs.
I still hope that kernel development will make it possible for future versions to check the PAE extension at boot time, and the kernel can just continue without it if it is not supported. But then, PAE probably changes a lot of machine instructions in the kernel code, and it's just not possible to have the same kernel run with and without PAE.
In the October 2008 issue of Linux Magazine, you discussed the script needed to put Knoppix 3.5.1 onto a USB stick.
I have a 4GB (3950MB or so) USB stick, and it is not big enough. It bombs out with an error stating not enough space. What size stick is needed to do this? I was under the impression that this type of thing could be done on a 1GB stick.
The CD version of Knoppix is about 700MB, whereas the DVD version is more than 4GB. You should well be able to put the CD version on a 1GB stick.
The DVD version requires a stick around 5GB, so the closest common size available is probably an 8GB stick for the DVD version (which I frequently use for testing USB boot compatibility).
Also, if you remaster the compressed files, please make sure the resulting size of a single file after compression does not exceed 4GB, because that is the maximum file size the FAT32 filesystem, (which is usually used for USB sticks) supports.
The same limit applies for a plain iso9660 CD/DVD filesystem; therefore, on the Knoppix DVD, the compressed files are split into two parts to stay below this limit, and they are merged with UnionFS/aufs during boot.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.