Klaus Knopper answers your Linux questions
Curiosity Kills Klaus
Hello, Klaus. I'm 12, and I've got quite a few computers – about nine in total – and about four are functioning. On one of them, I've decided to install Knoppix because it's easy, has a lot of good programs, and you just insert the CD, plus it's free. But I've had a few problems installing on the disk. I've tried other distros, swapped hard disks, put more RAM in, and even tried to change things with GParted and Disk Utility, but when I try to install it, it just says error partitioning disk. Now, I'm just wondering if you could help me. Thank you.
<2 hours later …>
I did something and it worked! So, I'm sorry if you started to reply. Thank you. Gabriel
My curiosity about what was wrong and what you did to fix it is killing me. :-) Seriously, if you could send me an email and tell me your solution, I would be happy to review the hard disk installation scripts for adding a possible fix.
For a Knoppix hard disk installation, you can either repartition the computer's hard disk so that there is at least 15GB of free unpartitioned space and let the installer do the creation of the needed two partitions, or you can choose
use entire disk (which means that all existing partitions will be deleted and two new ones will be created), or you can call the partitioning program on your own and create two partitions, which are:
- One partition with the ReiserFS Linux filesystem (partition type 83) – at least 14GB for DVD-sized Knoppix, or 3GB for CD-sized Knoppix,
- One partition for swap space (partition type 82) – at least 1GB.
The Knoppix installer will check to see whether empty, formatted partitions match this criteria on startup, then it will display the Linux filesystem partition as a possible destination for an installation in the first selection menu shown.
For manual creation, the partitions must be formatted by the partitioning program (like GParted), so the installer can detect whether they are really empty. You should check the outputs by running
sudo fdisk -l.
A reason why a partitioning program could fail to repartition your disks can be that a filesystem or swap partition from the disk is already in use. You can check this from the command line by running:
cat /proc/mounts cat /proc/swaps
In some rare cases, usually very old computers, the hard disk controller needs to be reset to report the new partitions correctly to the operating system, although fdisk attempts to read them directly from the disks.
Sometimes, it helps to call
sfdisk with the "reread partition table" option as root for the second hard disk in this example:
sudo sfdisk -R /dev/sdb
If GParted fails, you can usually get an explanation in the Details drop-down box.
Another possibility that comes to mind is that perhaps the disk in question was previously partitioned with a GPT/GUID partition scheme, which is used for large (>=2TB) disks, if sector size stays at the usual 512 bytes. In this case, the
fdisk commands would issue a warning and refuse to overwrite the GPT record. You will have to erase the previous partitioning by zeroing the first 8MB of the disk before you can create a traditional MBR.
If the Knoppix hard disk installation tool reported an error during the automatic partition, this may just mean that there wasn't enough unpartitioned space left on the target hard disk or that the disk was in use and the kernel was not able to reread the partition table. I must admit that the error messages in the simple Knoppix installation script (
0wn) are not very intuitive sometimes. ;-)
Hi Klaus, I enjoyed your explanation about MBR and VBR. I'm stuck with a few difficulties that I'm at a loss to explain.
My desktop has three hard drives and my boot order is USB, DVD, and HD. The HD order is SATA, IDE master, IDE slave. On the 500GB SATA, I had Mint 15, and this was installed to the whole disk. The IDE master I reformatted to use for backup storage; it was the original disk with Hardy Heron vintage stuff. I seem to remember just right-clicking the disk properties and formatting.
On the IDE slave, I installed 64-bit Knoppix 7.0.5 on the whole disk, and this was after the Mint 15 install. With Knoppix 7.0.5, I gave it a free hand with everything except changing the MBR. When I rebooted, it was not there, but I fixed that from the Mint side with
update-grub and got Debian Wheezy, which boots into Knoppix. The whole operation was much simpler than any Ubuntu/Mint Live boot, as I did not need the
nomodeset kernel attribute to make my NVidia 8500GT work. The only missing item in Knoppix 7.0.5 was not having a simple means of getting the driver to use the 1600:900 monitor resolution.
First strange item: Booting into Mint 15, I saw the Debian logo. Other than that, it was sort of okay, or as well as can be expected.
Second strange thing: Usually
sudo fdisk -l shows the SATA as
/dev/sda, but occasionally it's
/dev/sdc, and the other two drives move up one notch. The
info grub section 3.3 mentions this, but I thought it would be corrected by the time Linux was running.
I eventually gave up on NVidia 8500GT and got a Radeon HD6450 video card, and it would not boot any distro (Knoppix; Mint 9, 11, 13, 15; Debian; openSUSE 12.3; Fedora 16). I eventually found the kernel argument
vga=771, and at least Knoppix and Mint Debian boot, and Debian came up in 1600:900 without a screenful of garbage. Funny, there were no problems on my laptop with a Radeon HD 6310.
With all my video hacking, Mint 15 on the HD was dead, so I replaced it with Mint Debian, and I hope it's as stable as they claim. For Knoppix, I have to add the
vga-771 each load because the
/etc/default/grub is not on the Knoppix filesystem, only on the Debian side. I've added the results from
fdisk and noticed the drive with Knoppix has only two partitions. I guess that's from declining the MBR during install? I'm sure a reinstall will fix that.
I guess my main question is: With multiple distributions on multiple disks with the corresponding multiple filesystems and multiple
/etc/default/grub files, which
/etc/default/grub configures, what – and how – does it all synchronize to the GRUB startup menu? I seem to remember from GRUB1 getting very confused with that.
Another minor item for me, but serious to anyone new to Linux, is the kernel attribute
vga=771. I suspect that is only used in the early boot stage, and I suspect that it's a fluke that somehow a good video driver kicks in.
With GRUB2, all the GRUB-specific configuration options in
/etc/default/grub or /etc/grub.d/* are not evaluated by GRUB during the boot process, they are just human-readable configuration files that are merged into a single configuration for GRUB, which is created as
/boot/grub/grub.cfg when running
update-grub. With version 1 of GRUB (now called "GRUB legacy"), the file
/boot/grub/menu.lst contained the (simpler) boot menu structure and options and was edited directly.
So, the answer depends from which partition GRUB is starting, and in which sequence it scans the
boot/grub/grub.cfg files. To get an idea of which of the multiple grub.cfg files was detected, you could add a message or special menu entry to the GRUB menu changing the templates in
/etc/grub.d/ and then running
My personal guess is that GRUB2 searches your hard disk partitions in the BIOS sequence.
Once the Linux kernel loads, hard disks
/dev/sdz are detected in the order of drivers being loaded by the initial ramdisk and, later, udev's automatic loading of modules, which explains why you get different results for each of the Linux versions you installed.
Now about the
vga= boot option: Indeed, it is used at a very early stage of the kernel boot process, and it sets your graphics card in a specific VESA mode.
Table 1 is extracted from the Linux kernel's documentation in
Documentation/fb/vesafb.txt, with the
vga= numbers converted to decimal values.
Decimal Values of vga= Numbers
From Table 1, you can see that you are actually using a resolution of 800x600 pixels with a maximum of 256 different colors when you type vga=771. I often use vga=791, which is 1024x768 in 64k colors, and it happens to work on many notebooks.
Besides the framebuffer color and resolution, you get penguin graphics displayed at the top of your screen, one for each CPU present in your computer.
A few problems exist with VESA modes:
- The VESA framebuffer can only be activated during the early kernel initialization.
- Once set, size and resolution of the framebuffer console cannot be changed.
- Some of the accelerated graphics drivers, like Radeon and Nouveau, get confused by an already set graphics mode, with unpredictable results once the Xorg server switches to the graphical interface. Some drivers can even freeze the screen until a complete reset of the graphics hardware occurs (meaning, you have to pull the power plug, because most computer boards are still powered, even when the computer has been shut down by software).
Because of this, I don't use VESA framebuffer in Knoppix anymore unless I have to (i.e., for graphics cards that don't work with the accelerated free drivers) and stay in text mode. The kernel module for a graphics card is then able to switch to a full-screen accelerated framebuffer mode, which can even change resolution by the
fbset program, and Xorg has no problems starting up.
If you have experienced problems with newer free accelerated Xorg drivers, try to disable the splash screen (which most likely uses the VESA graphics mode that will later crash the X server) and use
vga=normal to force text mode. If Xorg still doesn't start up properly, your workaround with
vga=… may work because it forces the graphics card into an initial state that the fbdev Xorg driver can handle in case the accelerated driver fails.
Good day, Klaus: I am trying to convert from Windows to Linux. I am trying different distros to see which one I like best. I prefer to fully install rather than try Live CDs only, so I have a plan to install many distros on one USB external hard disk. I installed Linux Mint by itself on one disk. I improvised and installed Ubuntu 13.04 and Zorin 7 together sharing the
/home folder on another. Can you give me a guide on the best way to install multiple distros on one external disk? For example, what space to allocate; is it better to share the
/home folder or not; and so on. I was successful but not sure I did the optimal thing.
Another issue is, can I install Red Hat-based and Debian-based distros together? Can they share the
I am interested in trying: Ubuntu, Zorin, Linux Mint, Knoppix, PCLinuxOS, Fedora, Mageia, and Elementary. The list might get even longer – who knows!
Thank you, Mohammad
Many Linux distributions can be installed in parallel and still share one or a few partitions for common data, such as the users' home directories in
/home/<username>. For your specific setup, it is not the kind of distribution that could cause problems; however, you want to use an external hard disk and also the user ID of the "standard user," so this is where we have to look a little deeper.
External USB disk: For starting from this (assuming your BIOS can boot from USB disks, which seems to be the case), the kernel needs to get the drivers for the USB controller and USB storage device. For Knoppix, this is part of the static kernel; other distros include these drivers in the initial ramdisk, which is set up during installation.
USB hard disks are not present immediately after loading the drivers; sometimes they need up to 10 seconds to appear. The kernel, the initial ramdisk, or both need to wait for the USB drivers to settle down before accessing the disk. For a purely static kernel setup, this can be reached by the boot option
waitroot, which will just delay the boot process until the hard disk partition defined with kernel parameter
When loading USB drivers from the initial ramdisk instead, the ramdisk's boot script itself has to delay the boot process until all necessary disks are detected. From there, booting from USB is pretty much the same as booting from an internal hard disk. If the boot delay does not work, or if disks are numbered in the wrong sequence, you will get a kernel panic saying, cannot mount root device. This is an indication that either the root partition wasn't defined in the bootloader or that the kernel tried to mount it before it was there.
The second potential problem involves the username and the numerical ID each of your distros chooses for the unprivileged user. For Knoppix, the login name will always be knoppix and has user and group ID 1000. For most other distros, the login name can be freely chosen. If you always want the same data and home directory, you would define a partition for
/home (where the user's home directory will be created) and use it in every installation for personal user data.
During account creation, watch out for the numerical user and group IDs. If they differ, files will not be writable by the other user anymore, even if you have chosen the same login name under various distros.
If you have to choose different login names, you can create a symlink on the mounted
/home partition for allowing access to the common user data under a different name. If you have already installed Knoppix and copied the user's home directory
/home/knoppix to the common partition with
sudo cp -a /home/knoppix /media/<common-home-partition>/
you can add a symlink allowing a new username with the same numerical user ID to access Knoppix files:
cd /media/<common-home-partition> ln -s knoppix user
where "user" is the desired name for the default user for a different distro, which now points to the Knoppix user's data.
To add the common home partition to a newly installed Linux distro, you can either use the installation GUI (if it has the possibility to include other partitions as
/home without overwriting the old content) or add an entry to
/etc/fstab that says
/dev/<partitionname> /home auto defaults 0 0
/dev/<partitionname> is the block device containing the home directories that were installed earlier.
If you have created a common home partition and user home directory in this way, and the user IDs on all systems match, then the user can use the same data and personal settings on all installed distros.
Another partition that can be shared is the swap partition, especially if you plan to use the suspend-to-disk feature, which writes a snapshot of the currently running system and RAM to the swap partition for later restart.
Debian vs. Red Hat or
rpm should not matter concerning the shared home directories, because the package management lives inside the
/var filesystem, which should not be shared between distros. However, if you have installed the same program in different versions on one or the other distro, the program could try to migrate user settings to a newer or older version. This can be especially harmful when using KDE or Gnome, which changed their configuration schemes recently and thus may get confused if they find a newer or older version of their configuration files from an earlier session in a common home directory.
However, if you are up for testing, the possible problems with automatic configuration file migration should not be too dramatic (in the sense of a no longer booting system); rather, your desktop background or some program settings will be changed when switching between different distros frequently.
Buy this article as PDF
Mozilla’s product think tank sinks silently into history.
TODO group will focus on open source tools in large-scale environments.
New tool will look like GParted but support a wider range of storage technologies.
New public key pinning feature will help prevent man-in-the-middle attacks.
Carnegie Mellon researchers say 3 million pages could fall down the phishing hole in the next year.
The US government rolls new best-practice rules for protecting SSH.
Klaus Knopper announces the latest version of his iconic Live Linux system.
All websites that use these popular CMS tools could be vulnerable to denial of service attacks if users don't install the updates.
According to a report, many potential victims of the Heartbleed attack have patched their systems, but few have cleaned up the crime scene to protect themselves from the effects of a previous intrusion.
DARPA and NICTA release the code for the ultra-secure microkernel system used in aerial drones.