Question:
I have a laptop with a 3.06GHz Pentium processor, 512MB of memory, and a 40GB hard disk. The system came with Windows XP Pro. I resized the partition, created additional partitions, and installed Ubuntu 6.06 with separate /swap and /home partitions. The system operates as expected.
I find that some live CDs work and others don't. For instance, the system works with live CDs for SUSE 9.2, Ubuntu 6.10, and several of the distros on the April 2007 Linux Magazine Small Distros DVD.
The startup fails on live CDs such as Damn Small Linux 3.1 (startup hangs two lines after splash screen), DSL 3.2 DSL (there is nothing visible after booting from CD drive), Knoppix 3.6 (hangs after loading linux ...), and the SUSE 10.2 rescue disk.
Can you tell me what is going on and how to fix it?
Answer:
If the boot process hangs immediately after you hit return, it's almost certain that one of the following components won't work correctly with your board:
Some older boards will just hang when ACPI is on. Some newer boards will not work without ACPI, yet some don't support parts of ACPI, so there is no real "safe" default.
I have also seen some boards in which the built-in APIC controller freezes the system, and others in which accessing the PCI bus in direct mode fails to work. Again, no safe default exists. Many distributions just use default settings that "work on most boards."
To see what's wrong, try the following boot options after the name of the kernel:
debug vga=normal loglevel=6
This should give you a better hint as to where in the boot process the kernel stops dead. For fixing boot problems, I suggest trying one or many of the following options, separated by spaces. These options circumvent hardware problems in many common cases.
You'll find a description of these options, plus many other boot options, in the kernel documentation under /usr/src/linux/Documentation/kernel-parameters.txt, which is also available at www.kernel.org.
Question:
I have a problem that only occurs on Knoppix 4.0 and later and not on any other distros. On live disk boots, fstab comes out incorrectly. I have the following drives on a Win98/XP dual boot:
hda1=C: (win98) fat32 hda5=E: fat32 hda6=F: fat32 hda7=G: fat32 hdb1=D: WinXP, NTFS hdb5=H: fat32 hdb6=I: fat32 hdb7=J: fat32 hdb8=K: fat32 hdb9=L: fat16.
Knoppix v4.0 and after reports hda6 and hda7 as ext2 and ext3, respectively. I wonder what changed from v3.3 to v4 and later.
How do the later versions determine what to write when creating fstab?
I can always automatically just go in and edit fstab after booting, but it bugs me that I can't figure out what must have a very simple answer.
Answer:
It surely is a bug, but not an obvious bug, and I wonder if your hard disk partitions were once formatted with ext2 or ext3 before they were reformatted with fat32.
To get a quick overview of what the Knoppix filesystem detection finds, you can use the scanpartitions command as root. Knoppix tries to detect the filesystem type with the command:
file -Lkbs /dev/partitionname
and if that does not show any usable results, the fstype script checks for well-known filesystem labels in the first few blocks of the partition.
I did not find a faster method yet, but maybe parted would be more reliable. You can also type:
sudo file -Lkbs /dev/hda2
to see what the file utility thinks your second partition on the first drive contains. I'm very interested in the results, so could you please email me the output of the sudo file -Lkbs /dev/hda* commands, as well as sudo parted /dev/hda print?
Question:
I enjoy your articles in Linux Magazine. Here's a question:
Could you explain why Knoppix and Ubuntu have difficulties with hardware detection of Intel 845G series graphics chips and 17-inch 1280x1024 resolution? SimplyMEPIS, Mandriva, Puppy, ... boot right up.
Three of the five computers on our LAN have Intel Graphics: IBM ThinkCentre, IBM NetVista, and a SuperMicro board.
The ThinkCentre has a Sony 15-inch 1024x768 LCD, and Ubuntu crashes in normal boot.
I think Knoppix came up on that with only 800x600; however, it is someone else's computer, so I didn't experiment with it.
Yes, safe graphics mode works, slowly - especially the scroll wheel.
And yes, sudo dpkg-reconfigure xserver-xorg works, but ordinary desktop computer users do not want to enter that command on every CD live boot.
By the way, this is Puppy, which gives the option of storing changes and files on USB or hard disk; in this case, it's a file on the NTFS-formatted XP filesystem. Maybe by luck or design, XP doesn't seem to mind.
I built a USB live Knoppix as described in your March 2007 article (thanks!); however, these machines don't boot from USB. I have a setup with Puppy USB Live that uses a diskette to bootstrap in. Maybe I can look at that diskette or Lilo or something to bootstrap into Knoppix?
Answer:
The way Knoppix finds out which resolution to use is quite strange, but it attempts not to break anything. If graphics card and monitor both report that they can work with resolutions larger than 1024x768, the resolution that the monitor reports via DDC as the "preferred" mode will be taken. Some monitors report frequencies that are simply wrong and won't work in this mode. Then, the next lower mode is being used.
Some monitors (like most notebook displays) don't report any capabilities at all. For these, the default "safe" 1024x768/80Hz mode is used. Frequently, you see this with notebook displays, even though the graphics adapter claims it can do more than that.
If you like, you can just set a much higher resolution with the screen= parameter, and then the limiting factor is only the frequency, which can also be set by the hsync= and vsync= boot options.
My excuse for this crude way of video detection is just that I don't want to break old monitors or ruin any eyes with adventurous graphics modes. Many other distros are less conservative and probably have a better way of getting good resolution on newer hardware.
About your second question: A Knoppix 5.1 boot floppy is not easy to create because kernel 2.6 and initrd won't even fit on two floppies anymore. I'm still searching for a way to use a small kernel on a floppy for only CD-ROM detection, and then use kexec to start a new kernel from a mounted CD or USB stick.
Question:
When I run Knoppix 5.0.1 or 5.1.1 on my normal system, everything seems to work fine, but when I shut down, the unionfs seems to take two or three minutes before it finally shuts down.
This concerns me regarding potential issues with my hard drive. The partitions are ext3.
I've notice some other systems don't have this issue. I still use the Knoppix 3.6 version daily, and I have set up some very simple scripts to get MySQL and Apache to use directories on my hard drive after booting from CD-ROM.
This makes a great development environment for me. I was going to do that with 5.1, but it seems that there are only a few traces of MySQL, so I assume it was removed to make room for other things. Maybe it is on the DVD; I haven't checked because the DVD seems to boot much slower.
I played around with remastering 5.01, but every task that needs a root password, including changing the time, won't work with the old method of setting the root password in a terminal window first.
It seems that ksudo doesn't use the passwd file. Is there anything I should avoid in the remaster process that affects ksudo?
Answer:
You are right; kdesu is no longer asking for a root password in the live CD or DVD, and it uses the sudo command instead. You would have to edit /etc/sudoers to include the user who should run kdesu tasks without a password. You can revert to the old method by removing the user-specific kdesu config file:
rm -f /home/*/.kde/share/config/kdesurc
The reason why unionfs is sometimes taking awfully long to umount is yet unknown to me, but this problem is very annoying.
I'm also investigating this. In any case, I'm quite sure that your hard disk isn't broken because the problem also happens with USB sticks and various hard disks. To be sure that all data arrives on disk, you can enforce a filesystem sync by pressing the magic sysrq key combination, Alt+Print+S, before power-off or reset.
MySQL is still present on the DVD, which should not be much slower than the CD because the read data rate of a DVD is actually higher than that of a CD. Seek times can be slower, but this depends on your DVD drive type.
Question:
I read your article in Linux Magazine about ACPI and APM. I have not had luck with keeping the display enabled on a Dell 410 once the cover is closed and then reopened. Currently, I am running ACPI and using Mandriva 2007.0 with either the 2.6.17.14-mm-laptop-3mdv or 2.6.17-5mdv kernels. I can ssh into the laptop from another system.
Running init 3 then init 5 remotely on the laptop does not seem to turn the LCD display back on. The only option seems to be to reboot the laptop.
Running /etc/init.d/laptop_mode status returns the correct lid state and even returns the correct state of the lid if the LCD display has gone out due to closing the lid.
We tried a Knoppix 5.0 DVD on a Dell 410, let it boot up, and then closed the lid. We got the same result - the display on the LCD goes away, yet the system is still up and running.
Would you have any suggestions for how to fix this?
Answer:
It would be interesting to know if this problem happens in both Xorg and console mode. I think it is a hardware design error if a display turns off automatically, but not on again when the lid button is released. But in any case, you can probably fix the problem by installing an ACPI event handler that will switch on the display as soon as a "lid opened" event is detected.
For this, you first install a config file /etc/acpi/events/lid for acpid that will trigger an event handler. You also might want to check for any existing handlers:
event=button[ /]lid action=/etc/acpi/actions/lid.sh
Now, to create a /etc/acpi/actions/lid.sh that will do the right thing, you need to find a tool for switching on the light. My best guess for your notebook type is vbetool (http://freshmeat.net/projects/vbetool/), so if it is not already on your system, please install it.
You can check to see whether it's working by running vbetool dpms on in an open shell after closing and opening the lid. It works for me. In case of success, you could then create an ACPI action script similar to Listing 1.
Don't forget to make the script executable with:
chmod 755 /etc/acpi/actions/lid.sh
and restart acpid with /etc/init.d/acpid restart. Now the script should start automatically every time the lid button is pressed or released, and if it is released, the script will start vbetool to put the light back on.
| Listing 1: /etc/acpi/actions/lid.sh |
01 #!/bin/bash 02 03 if grep -q open /proc/acpi/button/lid/*/state 2>/dev/null 04 then 05 /usr/sbin/vbetool dpms on 06 fi |