I've been installing the new Mandriva 2010.0 RC2 distribution on various of my notebooks, netbooks and nettop this morning. Well, trying to, anyway. It has turned out to be a bit more difficult than I had expected. I can only speak about the Mandriva One KDE LiveCD, as that is the only one I have tried, but I would assume that this is true at least for all of the One LiveCD versions.
The first problem is that the LiveCD failed to boot on my Fujitsu Lifebook S6510, which is really a pretty standard Intel Core2 Duo system with an Intel 965 graphic controller, and on my HP Pavillion dv2-1010ez, which is a not-so-standard AMD Athlon Neo CPU and ATI Mobility Radeon 3410 graphic controller. What I finally found was that Mandriva is still trying to auto-generate their own xorg.conf file, on those two systems they got it sufficiently wrong that the X display server couldn't even start. However, they are using the latest X.org server (1.6.4), which is plenty smart enough to figure out everything it needs to know on its own, so it doesn't need an xorg.conf file. So the solution was to just login as root on the text console, delete the file /etc/X11/xorg.conf, and then run startx to get the X display server going so that you can then use the LiveCD graphic installer as usual.
The second problem is that after installation, at least on the S6510 (Intel 965 graphics), the screen resolution was incorrect (1024x768 rather than 1280x800). Once again, the problem is that they tried to auto-generate an xorg.conf file, and got it wrong, and once again the solution is to just delete (or rename, if you are very conservative) the xorg.conf file. Then reboot, or otherwise restart the X server, and all should be well with the world.
In fact what I have done is delete the xorg.conf file after the installation completes, even on those where they "got it right", because it's not necessary and I don't see any benefit to having it any more. I have checked screen resolution, keyboard maps and such, and it all seems to work just fine. If anyone should try this and find a system which does not work properly, I would be very interested in hearing about it.
I have just installed Ubuntu 9.04 from a cd that came with the Linux format magazine. Wow!
It has so many applications. I'll enjoy learning them. I hope there is one for a webcam driver.
I no longer have any other OS's , only this. I'm new to this, so it'll take time.
After the release of ojuba Linux 2 (code named
alqahira which means victorious) we are pleased to announce our third
release of ojuba Linux code named "arrebat” (which means standing firm
ojuba Linux is an Arabic/Islamic focused Linux distribution based on Fedora (and rpmfusion). Ojuba which contains many patches (for example Arabic shaping in wine)
ojuba is gnome centric our LiveDVD/USB is a gnome desktop
we also provide an installation media which contains kde and other desktops
this release contains kde 4.3.1 and it supports off-line installation of packages
note: ojuba means wonderful or incredible.
Two of my favorite things converged over the weekend - Linux Mint, which I think is an excellent distribution for average users, and the Xfce desktop, which I find myself using and liking more than either Gnome or KDE, especially on netbooks. So the Linux Mint 7 'Gloria' Xfce Community Edition was a welcome addition for me. The following are a few notes that I have made about installing and configuring it on various of my notebook and netbook computers.
- The Mint Xfce Community Edition is built from the Xubuntu distribution, in much the same way that the standard Linux Mint distribution is built from the standard Ubuntu distribution. It looks like it includes all the 'mint' utilities, such as install/update/backup/disk/nanny, and the same artwork and themes as the standard Linux Mint distribution.
- Installation is essentially identical to installing the stand Mint or Ubuntu distributions. When the installation is complete it boots to a gdm session manager, and on login you get a pretty standard Xfce desktop (very similar to Xubuntu).
- When the installation is complete, the first thing to do is let mintUpdate install all updates.
- mintUpdate does not pick up all of the updates that have been made by Ubuntu for the base distribution. At the present time, for example, Linux Mint still runs on the 2.6.28-11 Linux kernel, while Ubuntu is running 2.6.28-15. If you want or need to have all of the latest updates, you have to run the Synaptic Package Manager, select "Status" from the display options at the bottom left, then "Installed (upgradeable)" from the status list. That will show you what upgrades are available, then you can select the ones you want, or simply click "Mark All Upgrades" and "Apply".
- Even after updating with Synaptic, you're still not quite home free. Mint Xfce uses Wicd for network management, and like Xubuntu it is using version 1.5.9. The latest version, though, is 1.6.2 - and I have found that on my HP 2133 Mini-Note with a Broadcom wireless adapter, the older version of Wicd causes the system to hang during boot very frequently if the wireless adapter is enabled, but the newest version of Wicd does not. So, I update to the latest Wicd by adding their Repo to Synaptic. Of course, you could do this before doing the full update with Synaptic, and it would then be updated along with everything else. The Sourceforge pages for Wicd contain instructions for doing this. (Hint: the -O- in the wget command is an upper case letter O, not a numeric 0, it is used to direct the output of the command to stdout; if the entire command works, you should get a response of "OK") After adding the key and repo, all you need to do is click "Reload", then "Mark All Upgrades", then "Apply".
- The sound on all three of the notebook/netbook systems I have installed on was working immediately after installation, but after installing all updates there was no sound. I had to click the mixer icon in the panel, select controls and add "Master", then un-mute and set the volume level.
- The mintDisk program will automatically mount any FAT or NTFS partitions it finds on boot. If you don't want/need those to be mounted you can control that through Applications/System/mintDisk
- The visible desktop icons are selected in "Desktop Settings...". Because screen space is at a premium on netbooks, I remove the Trash, Home and Filesystem icons; on ordinary notebooks with larger screens, I leave them on.
- On my netbooks, I set up two panels on the Xfce desktop. In addition to the standard one at the bottom of the screen, I create a new one on the right side of the screen. I move all of the simple "icon only" objects there, such as the mixer, clock (which I change to analog), workspace switcher, notifier and show desktop, and I add a Logout button. That leaves only the text items on the bottom panel - the menus and task list. I then set both panels to "Fixed position" and "Normal Width", and the bottom panel to Autohide. The idea behind all of this is that netbook screens are small, so I need to save space, but there are certain icons I like to be able to see and access at all times. For those, the netbook screen generally has more room to spare horizontally than vertically so I shift them to the right side and don't hide them, and then hide what is left on the bottom panel. I like the result, but it is really a matter of taste.
- I was very pleased to see that Linux Mint includes Opera in its Software Manger package list (aka mintInstall) - and it is even at the latest version (10.00) already! Firefox is of course included in the basic installation, but I prefer Opera in most situations. It's nice to have it included in the package manager, so it will get updated automatically and thus save me from having to keep an eye on Opera updates.
- In fact, it is interesting and probably worthwhile to start mintInstall (Applications/Software Manager), and just click the "Featured Applications" to see what is there. Lots of good stuff. I generally also install Picasa and the VLC media player, for example.
That is essentially what it took to get the Linux Mint Xfce distribution installed and configured on my systems. I strongly recommend it to casual users, and I honestly think that even experienced users are likely to be pleased and impressed with it. I certainly am.
I have mentioned this topic in passing before, when talking about Ubuntu Karmic GRUB, but I have since discovered that that issue is serious enough, or at least the consequences can be serious enough, that I think it deserves a separate and more detailed explanation.
During the installation of Ubuntu 9.10 Alpha 5, there are no questions about installing GRUB. It does not ask if you want to install GRUB or not, or even where you want to install it, it quietly installs GRUB 2, and it installs it to the MBR (Master Boot Record) of your primary disk. There are at least two specific things you need to be careful about related to this:
- First, and most important, if you intend to preserve your existing bootloader, meaning that you want to keep your MBR intact as it is, you are going to be surprised and disappointed. Even if you install to a second disk, an external disk, or whatever, it will overwrite the MBR on your primary disk. To be honest, I would love to be wrong about this because I think it is at the very least a bad idea, if not outright dangerous. Certainly in the case of installation to a second disk, I would think that the very most it should do is install GRUB to the MBR of that drive, and not just silently modify your primary drive. But I have tried the installation more than once, in several different systems and configurations, and this is what it has done every time. Please, if I am wrong about this, someone tell me about it.
- Second, if you have a multiboot installation, and you are using Legacy GRUB for other Linux partitions, you are going to have to learn to deal with mixing the two versions of GRUB. My blong entry, mentioned above, gives some more information about how to do this.
P.S. According to the Release Announcement, "GRUB 2 is the default boot loader for new installations". This implies that if you upgrade an existing installation, it will not install GRUB 2, but since I never install an Alpha release as an upgrade (and it probably wouldn't be a good idea to do so in any case), I can't vouch for what it does in such a case.
Have you ever been interested in PXE or netbooting but was afraid to ask? You're probably not the only one. Luckily, help is on the way. netboot.me makes the network booting process quite a bit less daunting, hopefully making you more confident and familiar with the process along the way. What is netboot.me? I'm glad you asked.
When I read the release announcement and release notes for Slackware Linux 13.0, I thought it might be interesting to try to add it to MMS, my Dual Atom Multi-Boot Mini-Server. I knew that it wouldn't be trivial, for two main reasons:
- I multi-boot openSolaris and several Linux distributions, and that only works using the GRUB from openSolaris, so I have to be careful not to replace that when I make a new installation.
- The last time I looked at Slackware Linux, they still used the LILO bootloader. So not only did I have to be careful not to overwrite the openSolaris GRUB, I would have to figure out how to boot Slackware from GRUB on my own.
The installation turned out to be easier than I expected in some ways, but more difficult in others.
First, be aware that Slackware is not a distribution for Linux beginners, and probably not even for casual users. It expects that you know quite a bit about Linux administration, and it doesn't spend a lot of time or effort on hand-holding or "doing things for you". The first good example of this comes up right away - there is no LiveCD, as most popular Linux distributions have these days, there is only an installation DVD. Along the same lines, there is no fancy-looking graphical installation process, like Ubiquity or Anaconda, there is just a rather old-fashioned looking ASCII/text installation process. That installation process is quite straightforward, though, and it gives you plenty of control over what will and will not be installed.
Near the end of the installation process you get into the section pertaining to LILO. First, it asks if you would like to create a USB stick to boot LILO. This is an excellent idea - it gives you the chance to dual-boot Windows and Linux without having to overwrite the Windows bootloader. There is a problem with that, however - not all computers are able to boot from USB sticks, and even those which can do not always automatically give the USB stick priority over the hard disk in the boot sequence. That can lead to considerable confusion, when installation finishes, the computer simply reboots to Windows, and the entire Linux installation seems to have "disappeared". If this has happened to you, go into your computer BIOS setup and check to see if USB devices are bootable and are listed in the boot sequence ahead of the disk drive.
Once the USB boot stick is created (or not), the next question is about installing LILO. As I have to keep the openSolaris GRUB as my bootloader, I simply told it not to install LILO. Whew, that was a relief, I was afraid it might install LILO without asking, and then I would have had to go back and repair or reinstall the openSolaris GRUB.
After the installation completed, I rebooted with the USB stick plugged in, and it Slackware came right up. Hooray! Remove the USB stick and reboot, and the openSolaris GRUB comes up. Good stuff. This isn't the way I want it for the long term, though - I want everything to be listed and bootable from GRUB. To do that, I had to learn about Slackware kernels and initrd.
In a nutshell, the problem is this. Slackware installs with two kernels - one called "huge", which contains pretty much every device driver and module known to man, and one called "generic", which contains only the absolute minimum and uses loadable modules for everything else that it needs. It boots by default from the huge kernel. If you want to use the generic kernel, you have to create an initrd.gz file which contains at least the modules required to ready your hard drive and complete the boot. I decided to take the obvious (easy) path of booting the huge kernel first, and once that was working figuring out how to boot the generic kernel.
There are two kernels of each type in Slackware, one for single-processor systems and one with multi-processor/mult-core/hyperthreading support (which has 'smp' in its name), and one with only single-processor support. The choice was easy on my Dual Atom system, but in fact they recommend running the SMP kernel even on single processor systems whenever possible. I have set up more than enough dual-boot systems to know the kernel boot syntax for GRUB, so I added the following to the openSolaris GRUB menu.lst file:
title Slackware Linux 13.0
kernel /boot/vmlinuz-huge-smp-22.214.171.124-smp root=/dev/sda9 vga=794 ro
For the first trivial boot, that was all it required! Reboot the system, choose that line from the GRUB boot menu, and Slackware Linux came right up. I would prefer to specify the root partition by UUID, because my systems tend to be a bit variable in terms of partition names, but I found out the hard way that the Slackware Linux kernel doesn't understand that. Ah well.
The next step was to figure out how to boot the generic kernel, which requires figuring out how to create the appropriate initrd.gz filesystem. The note in /boot/README.initrd is very good, and combined with reading the mkinitrd man page, I had a pretty good idea what I needed to do. Because I am using an ext3 partition for Slackware, I needed to create an initrd image with the modules to support that included. The README file is a bit misleading on this; you don't have to list the dependent modules in the mkinitrd command, it will find and load those modules on its own. On the other hand, I don't think the README puts nearly enough emphasis on the fact that you have to give the mkinitrd command the exact name of the kernel you are going to be booting, so that it can find the right modules - and if you are going to use the SMP kernel, you have to specify that in the name as well. So the command that I ended up using, after some experimentation, was this:
mkinitrd -c -k 126.96.36.199-smp -m ext3
Note that you do not have to specify the root filesystem type and location (-f and -r options) to the mkinitrd command . This produces a file called initrd.gz; for convenience and consistency, I renamed that to initrd-188.8.131.52-smp.gz and changed the GRUB boot specification to this:
title Slackware Linux 13.0
kernel /boot/vmlinuz-generic-smp-184.108.40.206-smp root=/dev/sda9 vga=794 ro
I shutdown and rebooted one more time, and it came up running the generic kernel and everything works just fine.
Once I got the boot configuration working the way I wanted, I was still confronted with a significant problem - Slackware came up with a plain old text "login: " prompt on the console. That gave me warm fuzzy feelings of nostalgia inside, because of all the years I have spent working on VT100 (or even LA-36) consoles, but it isn't what I wanted my fancy Mini-Server to look like. Come to think of it, the installation process hadn't even created a "normal user" login, there was only a "root" login. So the first thing I had to to was use "adduser" to create my own login name, then I logged in and confirmed that "startx" got me an Xfce desktop (I had selected Xfce during the installation process). After a bit more investigation I learned that the Slackware default runlevel is 3, which is multiuser with a text console; changing that to 4 starts an X11 seesion manager on the console. It surprised me by starting KDE, when I had already seen Xfce come up with "startx", but when I looked at the rc.4 script, it looks like it only knows about Gnome (GDM), KDE (KDM) and plain old XDM, so I'm going to have to work on that a bit more.
So, there is plenty more to do, but at least I now have Slackware Linux loaded and working on MMS, along with openSolaris, CentOS, Debian, openSuSE, and Fedora 11 & 12. What fun!
I got ambitious this morning, and wanted to add the new Fedora 12 Alpha distribution to the Dual Atom Multi-Boot Mini-Server. Why go looking for trouble? Take a look at the Release Notes, there is a LOT of really interesting, exciting stuff in there!
I expected it to be tricky, for two reasons:
- As mentioned in a previous blog entry, when multi-booting openSolaris and Linux distributions, the openSolaris GRUB has to be used. Once you get that set up and working, as I have, you then have to be careful when installing additions Linux distributions that you you don't let them overwrite the openSolaris GRUB.
- Fedora 11 (Leonidas), which was only recently released, had some problems with Anaconda, their installation program, installing from a LiveCD, with ext3/ext4 file systems. I assume that they have fixed most of this, but I was still going to have to be careful about it.
So, I downloaded the LiveCD image, burned it to a CD-R, and booted it up on MMS (the MiniMultiServer). It came up, looked good, and seemed to run just fine. I then started the installation to hard disk, and that went smoothly until I got to the point where I suspected I might run into trouble, and I did. The LiveCD will not allow installation to an ext3 filesystem, and I already know from experience that openSolaris and its version of GRUB don't support ext4 filesystems. Ok, time to try to get creative.
I went ahead and installed to an ext4 filesystem, which worked just fine. That's an improvement over the Leonidas release, because their GRUB previously didn't support booting from ext4. Then, when it asked about installing GRUB, I told it to put it into the boot partition, rather than the MBR, so it wouldn't overwrite the openSolaris GRUB. This paid off in another way later.
Once the installation was complete, I rebooted and as expected the openSolaris GRUB was still in control. I brought up openSolaris, and added Fedora 12 to the GRUB menu.lst file in the usual way, with a configfile directive. I didn't expect this to work... and it didn't. When I rebooted, and selected Fedora 12, the openSolaris GRUB told me it couldn't find the file, obviously because it couldn't read the ext4 filesystem.
Now comes the creative bit. In the process of getting Ubuntu 9.10 Alpha, with its GRUB 2, to multi-boot with various other Linux distributions that still use Legacy GRUB, I learned that GRUB 2 can be chainloaded from Legacy GRUB. It seemed like a reasonable guess that Legacy GRUB itself could be chainloaded too, and the openSolaris GRUB still understands all of the standard GRUB syntax, so why not try that? If it works, it will bring up the Fedora 12 GRUB, which obviously supports ext4 filesystems, and the world will once again be a wonderful place. So, I changed the configfile directive to chainloader +1 and rebooted... and it worked!
So, I now have Fedora 12 (Constantine) running on the MMS, and I can tell you that it is well worth the effort. As expected, there are lots and lots of interesting things in there. I'm looking forward to working with it, learning about it and all the new stuff. The way it looks right now, when the final release of Fedora 12 eventually comes out, it is going to be an even bigger step forward than Fedora 11 was!
I have recently been setting up a "mini-server", using a Dual-Atom CPU system, and wanted to have openSolaris on it along with various Linux server distributions. Here are a few tips based on what I have found so far:
- openSolaris uses a significantly modified GRUB bootloader. After numerous attempts and failures, and one success, it appears to me that the general rule is that you can boot Linux from the openSolaris GRUB, but you can't boot openSolaris from a Linux GRUB.
- openSolaris does not support the ext4 filesystem yet, so at least the boot partitions of the Linux installations have to be ext3 (or something else supported by openSolaris, I didn't look any further than ext3).
- openSolaris uses the ZFS filesystem, which is not supported by any of the major Linux distributions that I have tried. This is one of the reasons you can't boot openSolaris from Linux, but it also means that you can't mount an openSolaris partition under Linux.
- Since you need to end up with the openSolaris GRUB as the installed bootloader, the simplest way to proceed is to install whatever Linux distributions you want first, and then openSolaris last. There are other ways to do this, of course, but they involve special manipulation when installing (or not installing) the Linux GRUB.
- openSolaris does not understand Extended Partitions on the disk, but the openSolaris GRUB does understand them. This means that you can multi-boot from Logical Partitions within an Extended Partition, but when running openSolaris you will not be able to mount them.
- In addition to not handling Extended/Logical Partitions, openSolaris is not particularly good at finding and identifying other Linux installations when setting up its GRUB configuration. So be prepared to add the Linux installations to the openSolaris GRUB configuration manually. This is made somewhat less painful by the fact that the openSolaris GRUB does understand the configfile directive, and it generally understands ordinary Linux GRUB menu.lst files, so you can add them using only the title, root, and configfile directives. Of course, if you want to you can put in the complete kernel and initrd commands.
Using these general guidelines, I have succeeded in setting up the mini-server as follows:
Primary Partition0: openSolaris 2009.06
Primary Partition 1: CentOS 5.3
Primary Partition 2: Linux Swap
Extended Partition 3:
Logical Partition 4: Debian 5.0.2
Logical Partition 5: openSuSE 11.2 Milestone 6
Logical Partition 6: Fedora 11 Leonidas
So far, so good!
I recently obtained an IBM Thinkpad X41 Tablet from ebay. It came with no OS, which was exactly how I wanted it, since I planned to install Linux on it. This post will describe my attempts to install Ubuntu 9.04 on the aforementioned tablet PC.