jump to navigation

Ubuntu Intrepid Ibex Dissapoints 17 November, 2008

Posted by aronzak in Debian, Distro Wars, Grub, Linux, Ubuntu.
Tags: , , , , ,
add a comment

Ubuntu has a long and sad history of disregarding the needs and wants of power users in their drive for ease for users who are unfamiliar with, and have little inclination to become familiar with Linux. To me, it’s dissapointing. More hardline flamers have become angry at Ubuntu and Canonical. This is my experience.

I have a cheap computer. An old one died, so I simply bought a few cheap components to replace the dead box, reusing some drives. The machine has integrated grpahics, because I haven’t coughed up for a real card yet. Vesa drivers work fine, but both the 2d nv and proprietary nvidia divers don’t work. Probably because the mbo only cost me ~70AUD. I’ve known about this since I’ve had the machine. I can’t be bothered to fix it, because I can use 3d apps on another machine.

Ubuntu Intrepid Ibex uses a new version of xorg. Supposedly, it has a very little configuration needed and can dun with no /etc/X11/xorg.conf. This sounds like a good idea. But, for me it means that there are problems.

After finishing the Debian installer, Ubuntu boots. No grub menu is shown, another pet peeve I have. If you do hit escape, you are confrinted with an ugly, black screen. Then you get usplash. Great for some. Then again, if you turn it off you get ugly readouts from a kernel with useless timing enabled. Ok, this is a problem in Debian too, but I compiled my own kernel. Then you get the same ugly gdm theme Ubuntu has been using since forever.

The problem is, gdm didn’t come up. Rather than dropping to a shell to let me diagnose this, there is an ugly black screen with low resolution. I try as few options, none of which work. To finish applying settings, I’m informed that the xserver will restart in one minute. Pressing ok leaves the screen pitch black. The Ubuntu developers must be fond of black.

Dropping to a shell lets me find that there is indeed an xorg.conf. Wonderful. startx works, after killing xinit. And he voila, gnome appears. In SVGA (800×600) resolution. Xrandr will only let me change this down to 640×480. Brilliant. Copying over Debian’s configuration file is no good. Somehow, the new xorg does not accept screen resolutions in the configuration file. Anyway, after trying the other trick I’ve heard of, I remove the file. This works wonders, and now, somehow, my screen size becomes 1024×768 when using startx. No such luck when starting, the xserver still refuses to start. My next move is to uninstall the nv driver. Good thinking, I hear you say. Well, now gdm will start. But somehow, my former trick doesn’t work, and I am stuck with SVGA. So what am I supposed to do? Reinstall a broken driver?

Forget it. I’m sticking with Debian. Debian has failed in interesting ways, but I have always been able to fix it. I don’t like xorg.conf, or for that matter grub’s menu.lst, or fstab. But I’ve just learned to get used to them. Sooner or later I’m going to man up and just use vim. Don’t get me wrong, making the user do less work is great. I like apt, and rarely compile anything from source. I’m not a sadist. But, I think that these ‘miracle’ fixes, like having no configuration files, are a dumb idea. Why? Because there are situations that no developer can foresee, and they will end up just not working. And what do you do then? You edit the configs. I’ve done things the hard way, and my Debian install has more or less worked ever since.

Stay Away From Grub2 30 September, 2008

Posted by aronzak in Debian, Grub, Linux, Ubuntu.
Tags: , , , , , , ,
63 comments

I strongly recommend that you don’t try upgrading to grub2, and developers don’t implement it in new releases. I have a multiboot setup like most users, and bad things happened to me.

Having read about ‘new features’ in the next version of the GNU Grand Unified Bootloader, grub2, I decided to upgrade.

At first, the grub2 installer kept grub ‘legacy’, which could chainload into grub2, with the first entry in grub being:

title        Chainload into GRUB 2
root        (hd0,2)
kernel        /boot/grub/core.img

Unfortunately, I then removed grub legacy, replacing it entirely with grub2.  This left me booting into a screen with only Debian entries. This is no good; I have other distros on my laptop, like most users would have other OSes such as Windows.

So, next, I decide to edit the configuration file. I am used to editing menu.lst. Grub2 does not use menu.lst, it uses a file called grub.cfg (easy to confuse with grub.conf, which in my CentOS install menu.lst is a link to).

Let me digress and talk about the differences between grub.cfg and menu.lst.

Here’s menu.lst; with a familiar header:

# menu.lst - See: grub(8), info grub, update-grub(8)
#            grub-install(8), grub-floppy(8),
#            grub-md5-crypt, /usr/share/doc/grub
#            and /usr/share/doc/grub-doc/.

As well as being full of comments that help users to understand and edit the file, as well as ‘examples’ of Linux and Windows entries. Then there are the entries themselves, using a familiar, clean tabbed format that is default in Debian.

title        Debian GNU/Linux, kernel 2.6.26-1-686
root        (hd0,2)
kernel        /boot/vmlinuz-2.6.26-1-686 root=/dev/sda3 ro
initrd        /boot/initrd.img-2.6.26-1-686

title           Ubuntu /dev/sda1
root            (hd0,0)
kernel          /vmlinuz root=/dev/sda1
initrd          /initrd.img
savedefault
boot

As well, I have a list of kernels that Ubuntu populated using update-grub, and that can be loaded using ‘configfile’

title        >Ubuntu List
root        (hd0,0)
configfile    /boot/grub/menu.lst

But to edit grub.cfg, first we get this friendly welcome:

# DO NOT EDIT THIS FILE

Then we get these nice, easy, simpler list entries:

menuentry "Debian GNU/Linux, linux 2.6.26-1-686" {
linux    /boot/vmlinuz-2.6.26-1-686 root=UUID=124b49d6-a3eb-4eae-9e5d-e0000b5efda3 ro
initrd    /boot/initrd.img-2.6.26-1-686
}

The problem is, they aren’t. After users have struggled for a long time to edit menu.lst in order to make their computers boot properly, they will now need to learn a complicated, obscure format. It seems difficult if not impossible to convert boot entries in menu.lst files to grub.cfg files, with time being wasted adding unnecessary brackets and quotes, whereas they were not needed before.

Back to what happened. So, wanting to add in an Ubuntu entry I take menu.lst, and use find and replace to change ‘title’ to ‘menuentry’, ‘root’ to ‘set root=’ and ‘kernel’ to ‘linux’. Makes perfect sense. So I enter the following entry based on menu.lst

menuentry    "Ubuntu /dev/sda1" {
root=(hd0,0)
linux              /vmlinuz root=/dev/sda1
initrd          /initrd.img
}

The problem is, after ignoring  the ominous “DO NOT EDIT THIS FILE”, grub2 then refused to boot anything, throwing up an error that I need to boot the kernel first. Before what?  Luckily, I had a version of grub legacy on my usb stick, and only wasted about 10 minutes installing grub back onto the hard disk. Now my laptop works fine, and is able to boot into Ubuntu, Debian and CentOS.

I have a feeling that this problem arises with the difference in partitions, since grub2 seems to use variables that remain set for a section, rather than having a ‘root’ line in each entry. This probably makes sense in some applications. It sounds like a good idea for USB sticks, where the stick will change position in relation to other disks on different computers (but the UUID won’t change). If you want to edit your grub.cfg, probably edit the ‘custom’ section, rather than adding an entry in the ‘linux’ section

So, for me grub2 could only boot up Debian or nothing at all. There is very little documentation on how to edit the confusing grub.cfg, compared to menu.lst, where there is much community support. Whatever the benefits of grub2 are, I don’t think that they are worth the damage it could cause. Developers should steer clear of using the code, as it will only mean grief for the end user.

Howto: Syslinux and Grub on one USB drive 16 September, 2008

Posted by aronzak in Grub, Linux, Live Usb.
Tags: , , , , ,
13 comments

Intro: This is probably the coolest thing that I have done with USB bootloaders up until this point.Syslinux is an extremely useful tool that can easily and safely be installed to a usb flash drive. It can then be used to boot any version of linux, or even floppy disk images on the drive. But is is limited in that it cannot boot up operating systems on another drive. It can chainload to a working bootloader, but what if it is broken and needs to be fixed. Of course, you can start up a Linux distribution on the usb stick to fix it.

Grub is an extremely versatile tool that is used to boot up almost any operating system other than Windows. It can also be used to modify some files, or install another version of itseld to another hard disk. This is extremely useful if you have a broken grub installation.

Well, you can run boot grub from syslinux. And it’s really easy.

Step one: Stick syslinux on a drive. See this guide for easy installation of Puppy Linux.

Step two: Download a file called grub.exe. It can be found here.

Step three: This is a windows executable file (.exe) that can be run from dos. But the most impressive thing: It’s actually a linux kernel. Plonk it on the root of the drive.

Step four: Start up the usb stick and type “grub.exe’. Then, you’ve got grub. That’s it.

The rest is optional.

– Stick grub.exe in boot/grub and create a syslinux.cfg entry called grub looking like this:

LABEL grub
KERNEL /boot/grub/grub.exe

– Create your own menu.lst.

– Use a hex editor (eg. “khexedit”) and search for “timeout” or “default”. You’ll find the section that is the pretend ‘menu.lst’. You can edit as such.

– Download a useful grub tool chest called SuperGrub Disk (SGD) from here. Extract the .tar.gz onto your usb stick (should be in a folder called boot). NB. This does not work out of the box. SGD uses a customised version of grub that has a command setgrubdevice to set a variable called $grub_device. This is then used in ($grub_device). If you use Grub.exe, it does not understand this, but does not need it, as it already sets root to the correct device. You can use kate (KDE Advanced Text Editor) to remove all references of ($grub_device) (Use find and replace to replace it with nothing). Better is probably the following solution.

Edit: By accident I installed grub onto the device. Interestingly, syslinux still works fine. Syslinux has its main part in the partition of a drive, not the whole drive. Thus, grub can chain to syslinux using “root (hd(x),0) rather than “root (hd(x)”. Syslinux can also chain back to grub itself, (using chain.c32) or start grub.ex.