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
Installing Eee PC from External Drive
I bought an Eee PC 1000H netbook a few weeks ago and would like to have SUSE 11 installed, preferably in dual-boot mode with the existing Windows XP. The 160GB disk has a second partition, formatted to NTFS and with a size of ~60GB. I have tried to install SUSE 11.1 from a USB stick after setting the BIOS accordingly. There is an ISO image on the stick, and the stick shows in BIOS, but the computer still boots up with Windows.
I've also tried it with an external DVD drive, again setting the BIOS to boot from it with the SUSE 11.0 DVD. But, although the BIOS seems to detect the drive, the machine still boots XP. I also copied the ISO image into the vacant partition, but of course that doesn't make it boot either.
I've got to admit that the information that I have found in various web blogs is mostly beyond my understanding. Maybe you can help? Thanks a bunch! Florian Huber
Luckily, I have an Eee PC (older model than yours), too, and can answer this. Although it should be possible to set boot priorities in the BIOS (which did not work in your case), the easiest way to make the Eee PC boot from different media is by pressing the Esc key during BIOS initialization (i.e., as soon as the Eee PC logo shows up). For other notebooks, it is usually F8 or F12, which displays the boot selection menu, so Esc might sound a little odd. Anyway, if the device is shown in the boot selection menu, you should be able to select it for boot.
The Eee PC boots fine from DVD as well as from a USB flash drive, provided the boot media really are bootable (i.e., have valid boot signatures) and do not throw your computer back into its internal boot sequence. Some older USB flash drives (pre-2009) just won't boot on the Eee PC, I noticed, but I have successfully tested many different USB DVD drives, as well as recent 4GB and 8GB flash memory sticks. You mentioned that you have an ISO image on the USB stick as a file, or maybe even as a partition-wise copy of the DVD drive. Unfortunately, this is not going to work because your computer's BIOS has no idea what to do with an ISO file or ISO filesystem on a flash disk, especially because no operating system is running at that time.
To create a bootable flash memory stick from a bootable DVD, you will have to take the following steps. (In these examples, the DVD is mounted at /media/dvd, and the flash memory stick is mounted at /media/sdc1. When the DVD uses Isolinux as the bootloader, it is easily replaced by Syslinux because both have the same syntax.)
Copy the contents of the DVD over to /media/sdc1, where the USB flash is mounted. If you have an ISO file and no real DVD drive, you can mount this like a DVD drive with:
sudo mount -o loop,ro dvd-image.iso /media/dvd
Now the actual file/directory-wise copy can be done with:
cp -r /media/dvd/* /media/sdc1/
Hint: How files are named on the FAT-formatted flash media will depend on your system's setup. Some systems use lowercase only, so you should check to see whether ls -l /media/dvd actually looks the same as the copy with the use of ls -l /media/sdc1. If file names look different on source and copy, you will have to unmount the flash disk and mount it again with the mount option shortname= winnt
mount -t vfat -o shortname=winnt /dev/sdc1 /media/sdc1
and try again.
- Check for boot/isolinux in the copy and rename boot/isolinux to boot/syslinux.
- Rename boot/syslinux/isolinux.cfg to boot/syslinux/syslinux.cfg. (If *linux.cfg is directly in the root directory of the disk, just rename it there and don't bother about directory names.)
- umount /media/sdc1
Next, you need to make the USB flash disk bootable. Remember that the entire flash disk is /dev/sdc, and /dev/sdc1 is the name of the first (usually FAT16- or FAT32-formatted) partition found on it:
sfdisk -A1 /dev/sdc syslinux /dev/sdc1 ms-sys -s /dev/sdc
These commands create a master boot record and a Syslinux partition boot record, and they mark the first partition as bootable. After this, you should be able to boot from the USB flash disk as if it were a bootable CD-ROM.
If you don't find any of the files I mentioned on the mounted DVD, then it's probably using GRUB instead of Isolinux, which is a different boot method. In this case, use
grub-install -root-directory=/media/scd1 /dev/sdc
to install the GRUB bootloader while keeping the menu files as they are.
Repairing the User Profile
Recently, a friend of mine ran a standard update of Xubuntu 9.04 that required a restart. When the computer was restarted, the panels had completely disappeared. The panel options within the menus are not working, and neither my friend nor myself have any experience beyond basic use.
His PC is an IBM ThinkPad T30, with an Intel Mobile Pentium 4, 1.80GHz, 1GB of RAM, and 60GB of hard drive space. Is it a hardware issue, or is there a way to fix this that is relatively easy to do for us non-technical Linux users? Chris Saldana
It seems that the personal desktop configuration files are broken. Now, as much as it would be interesting to know how this happened in order to keep it from happening again, I'll just try to help you get it fixed.
I'll start with some background. Most programs in Unix/Linux have a system-wide configuration that is stored somewhere in the /etc/ directory and works for ALL users, as well as a second, personal configuration in the user's home directory. The system-wide configuration cannot be changed by an unprivileged user, so this is the "safe fallback" in case the user accidentally deletes his or her own configurations.
The personal configurations are traditionally kept in files or directories inside the user's $HOME (/home/login_name) and start with a dot, so they don't appear in directory listings with ls -l or in the file browser unless the latter is set to display "hidden files." You can see them by entering
from the shell while you are in your home directory.
Everything personal that you might have set, such as stored access passwords for websites or just your desktop's wallpaper, is located somewhere in these files and directories starting with a "." in their name.
A quick and very dirty approach would be to try to delete everything starting with a dot, but if you do this, you could accidentally delete everything in your home directory, not just the configuration, because the "parent directory" (one above your home) is also called ".." and would match a deletion on ".*" – so please don't do this. ;-)
Instead, try to find the file that is responsible for whatever does not work and move it away with the mv command, like this:
mv .config/xfce4 config_xfce4.old
Now you have a visible backup of the configuration directory of your Xfce desktop in your home directory, and it has disappeared from its old place. You should probably only issue this command when NOT logged in to the Xfce desktop, because during logout, the old (incorrect) config files could be recreated. So, it's better to move the old configs in a non-graphical session from the text console (use Ctrl+Alt+F1, login, and Ctrl+F7 to go back to the graphical login screen).
When the personal configuration for Xfce is gone, Xfce will use the system-wide default again, and your problem should be solved. If you miss anything from your old configuration, try moving files back to the old location from the directory you just renamed.
If you feel adventurous, you can try loading individual config files into your favorite editor and see what you can change manually. However, be aware that the configuration file syntax has no common standard, so every program has its own idea of what a configuration file looks like.
Most desktop-related application files store their configurations in .config; KDE uses .kde(4) instead, and Gnome uses .gconf. When using Gnome, you might want to try gconf-editor, which is a graphical tool for changing the configuration of various Gnome-related programs (Figure 1).
If configuration and other files are frequently destroyed or if your machine freezes or loses data on a regular basis, it could well be a RAM or hard disk defect that is causing the problem, in which case no software will help. If the command dmesg shows multiple segfaults in arbitrary programs or hard disk read/write errors, then your computer hardware might be broken.
Installing nVidia Drivers after Kernel Update
I have been a Fedora distro user since I picked up the magazine in Australia that had Fedora Core 6 on the DVD. I converted when I returned to the UK and have been using Fedora and Linux ever since. Windows is long gone. I do have issues, however (see Listing 1).
Output from uname -a
01 Linux Fedora10 22.214.171.124-170.2.72.fc10.i686 #1 SMP Sun Jun 21 19:03:24 02 EDT 2009 i686 athlon i386 GNU/Linux 03 04 [xxx@Fedora10 ~]$ yum list | grep nvidia 05 kmod-nvidia.i686 180.51-1.fc10.8 rpmfusion-nonfree-updates 06 kmod-nvidia-126.96.36.199-170.2.56.fc10.i686.i686 07 kmod-nvidia-188.8.131.52-170.2.72.fc10.i686.i686 08 xorg-x11-drv-nvidia.i386 180.51-1.fc10 09 installed 10 xorg-x11-drv-nvidia-libs.i386 180.51-1.fc10 installed
When Fedora sets a kernel update, I often lose the screen driver for my nVidia card. This means I have set my GRUB configuration to show previous kernels so that I can boot the kernel and get the nVidia driver to load and wait till the appropriate nvidia.so file is released. This is painful, and I'd like to know how I can match a new kernel to the right nVidia driver. Is there an easy way? As you can see, a kmod is awaiting an install on rpmfusion. How can I be sure it will match the kernel I have? Nik Youell
Proprietary drivers like those used for nVidia cards can be painful for updates because they usually lag behind the most recent kernel release.
I can give you some suggestions to address this, but the best solution would still be for nVidia to release an open source driver that can easily be integrated into the mainstream kernel and Xorg packages.
Solution 1: Only update when both the kernel and matching nVidia module+driver are released. Because of security issues, kernel updates have become rather infrequent these days, and as long as your computer system works fine, there is no reason to update the kernel very often.
Kernel module RPM packages have dependencies on the kernel for which they were built, so it should not be possible to install a wrong version (just an older version for a kernel package that has not been removed after update). However, if you have been waiting for a new kernel feature, such as drivers for a new WiFi card, you might not be content with this solution.
Solution 2: Just grab the kernel headers package that matches your new kernel package and install the nVidia driver, downloaded from the official nVidia website , on your own. nVidia's installation/compilation script is quite straightforward, does not require any developer skills, and usually works well when all dependencies (e.g., kernel source headers, C compiler) are present. This is the perfect option for the impatient user. ;-)
Solution 3: Instead of using nVidia's accelerated drivers, use the free "nv" driver from Xorg. It is not fast, but it works sufficiently fast for normal desktop use. Of course, gaming is no fun with this option, and 3D desktops like Compiz Fusion won't work either. But at least, it will save you some gray hair by avoiding trouble with the proprietary driver updates.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
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.