Help! My Linux won't boot.
Lilo is not correctly set up. (For example, issues with old versions of lilo above block 1024 of the disk drive). See LiloErrorCodes.
If this is the case your CMOS battery might have gone flat. They generally last 3-5 years and you lose your hard disk setup often if the battery dies which then causes this problem.
...but if I type in configfile /grub/grub.conf the menu loads.
This may occur with a Mirrored SoftwareRaid setup. Reconfigure your grub.conf file and remove any reference to a root (*) device.
install --stage2=/boot/grub/stage2 (hd0,0)/grub/stage1 (hd0) (hd0,0)/grub/stage2 p /grub/grub.conf install --stage2=/boot/grub/stage2 (hd1,0)/grub/stage1 (hd1) (hd1,0)/grub/stage2 p /grub/grub.conf quit
NB: This assumes a seperate /boot partition
From all the research I've done, it seems like problems of this sort are always caused by grub.conf mistakes. Mine seemed to be OK though, but I was still seeing problems. I noticed that when I ran setup (hd0) at the GRUB prompt, it mentioned a file called menu.lst. I renamed grub.conf to menu.lst, and things are now working! (But you should make a SymLink from grub.conf to menu.lst instead of renaming.) Apparently there may be multiple default filename possibilities for the GRUB menu file.
Various VIA chipset AMD Athlon/Duron motherboards (eg KT400, KM266) running kernel 2.4 (e.g. kernel 2.4.21) hang after printing this message. For example, Athlon XP2000+ on an AD77 motherboard (KT400), Athlon XP1800+/XP2400+ on a PC Chips M825L (KM266)). It is caused by APIC support in the kernel (not to be confused with ACPI). Booting with the noapic kernel flag doesn't fix it (although it can make the machine go into an infinite loop printing an error about apic on cpu 0). However, booting with nolapic kernel flag does in many cases work. Recompiling the kernel without APIC support resolves this. Note that the same motherboards will need the nolapic kernel flag to boot Knoppix - otherwise the screen just turns black and the computer hangs.
My KT400-based motherboard (that used to give the previous error message under older kernels) hangs immediately after printing this message with Ubuntu 5.10's default kernel (2.6.12-6). The message just before it is ACPI: Looking for DSDT in initrd... not found! Again, adding nolapic and noapic to the kernel boot command fixes this. Note that if your distribution uses the quiet kernel boot flag to hide all those messages then you'll never know that it's the BIOS's buggy APIC support at fault. This motherboard is an AD77 flashed with the latest BIOS (2004/11/02) so you will only be able to boot a linux kernel that is compiled or booted without APIC support.
This is usually caused by a failure to find or mount /dev or a bad /dev being used. When remastering Knoppix this can be cause by failing to preserve the special nature of the device files under /dev while building remastering. See the dev option of mount(8).
Devices in Linux have major and minor numbers (unless you use the newer DevFs). Devices need to be implemented by the Kernel, either compiled in directly, or via a loadable Module. For example, serial ports are on char-major-4; eg ls -l /dev/ttyS0 shows major device number 4 and minor device number 64...
crw-rw---- 1 root dialout 4, 64 Feb 10 1998 /dev/ttyS0 major ^ ^^ minor
A common problem char-major-10 is misc devices such as psaux, watchdog, apm and nvram - cat /proc/misc should list the ones you're using. You will probably need to do some configuration in /etc/modules or /etc/modules.conf (see modules.conf(5)). Normally these messages don't cause problems later in life, but it's nice to have them cleaned up.
The allocation of each number to its respective device can be looked up in the file /usr/src/linux-$VERSION/Documentation/devices.txt, provided the Kernel sources have been installed. In this file you can find out what device and module are affected. It does not have to be an error, but perhaps only information about the module not having to be loaded any more because it is already loaded or is not required.
To see what module you're missing, use
grep char-major-10-135 /etc/modutils/arch/i386
See KernelErrorMessages for more information about missing modules.
Your problem is DNS, or the lack thereof. These services will all want to look up names in their configuration (normally your local machine name) and will be taking a month of sundays to time out as a result. Confirm this by typing host mydomain.tla at the root prompt.
127.0.0.1 localhost full.local.domain.name alias1 alias2
127.0.0.1 localhost firewall.wiki.invalid firewall