Shallow Thoughts : tags : boot

Akkana's Musings on Open Source Computing, Science, and Nature.

Thu, 24 Nov 2011

Configuring extlinux's auto-update on Debian

A few days ago, I wrote about how to set up and configure extlinux (syslinux) as a bootloader. But on Debian or Ubuntu, if you make changes to files like /boot/extlinux/extlinux.conf directly, they'll be overwritten.

The configuration files are regenerated by a program called extlinux-update, which runs automatically every time you update your kernel. (Specifically, it runs from the postinst script of the linux-base package: you can see it in /var/lib/dpkg/info/linux-base.postinst.)

So what's a Debian user to do if she wants to customize the menus, add a splash image or boot other operating systems?

First, if you decide you really don't want Debian overwriting your configuration files, you can change disable updates by editing /etc/default/extlinux. Just be aware you won't get your boot menu updated when you install new kernels -- you'll have to remember to update them by hand.

It might be worth it: the automatic update is nearly as annoying as the grub2 updater: it creates two automatic entries for every kernel you have installed. So if you have several distros installed, each with a kernel or two in your shared /boot, you'll get an entry to boot Debian Squeeze with the Ubuntu Oneiric kernel, one for Squeeze with the Natty kernel, one for Squeeze with the Fedora 16 kernel ... as well as entries for every kernel you have that's actually owned by Debian. And then for each of these, you'll also get a second entry, to boot in recovery mode. If you have several distros installed, it makes for a very long and confusing boot menu!

It's a shame that the auto-updater doesn't restrict itself to kernels managed by the packaging system, which would be easy enough to do. (Wonder if they would accept a patch?) You might be able to fudge something that works right by setting up symlinks so that the only readable kernels actually live on the root partition, so Debian can't read the kernels from the other distros. Sounds a bit complicated and I haven't tried it. For now, I've turned off automatic updating on my system.

But if your setup is simpler -- perhaps just one Debian or one Ubuntu partition plus some non-Linux entries such as BSD or Windows -- here's how to set up Debian-style automatic updating and still keep all your non-Linux boot entries and your nice menu customizations.

Debian automatic updates and themes

First, take a quick look at /etc/default/extlinux and customize anything there you might need, like the names of the kernels, kernel boot parameters or timeout. See man extlinux-update for details.

For configuring menu colors, image backgrounds and such, you'll need to make a theme. You can see a sample theme by installing the package syslinux-themes-debian -- but watch out. If you haven't configured apt not to pull in suggested packages, that may bring back grub or grub-legacy, which you probably don't want.

You can make a theme without needing that package, though. Create a directory /usr/share/syslinux/themes/mythemename (the extlinux-update man page claims you can put a theme anywhere and specify it by its full path, but it lies). Create a directory called extlinux inside it, and make a file with everything you want from extlinux.conf. For example:

default 0
prompt 1
timeout 50

ui vesamenu.c32
menu title Welcome to my Linux machine!
menu background mysplash.png
menu color title 1;36 #ffff8888 #00000000 std
menu color unsel 0    #ffffffff #00000000 none
menu color sel   7    #ff000000 #ffffff00 none

include linux.cfg
menu separator
include themes/mythemename/other.cfg

Note that last line: you can include other files from your theme. For instance, you can create a file called other.cfg with entries for other partitions you want to boot:

label oneiric
menu label Ubuntu Oneiric Ocelot
kernel /vmlinuz-3.0.0-12-generic
append initrd=/initrd.img-3.0.0-12-generic root=UUID=c332b3e2-5c38-4c50-982a-680af82c00ab ro quiet

label fedora
menu label Fedora 16
kernel /vmlinuz-3.1.0-7.fc16.i686
append initrd=/initramfs-3.1.0-7.fc16.i686.img root=UUID=47f6b1fa-eb5d-4254-9fe0-79c8b106f0d9 ro quiet

menu separator

LABEL Windows
KERNEL chain.c32
APPEND hd0 1

Of course, you could have a debian.cfg, an ubuntu.cfg, a fedora.cfg etc. if you wanted to have multiple distros all keeping their kernels up-to-date. Or you can keep the whole thing in one file, theme.cfg. You can make a theme as complex or as simple as you like.

Tags: , , , , ,
[ 11:26 Nov 24, 2011    More linux/install | permalink to this entry | comments ]

Sun, 20 Nov 2011

How to install extlinux (syslinux) as a bootloader

When my new netbook arrived, I chose Debian Squeeze as the first Linux distro to install, because I was under the impression it still used grub1, and I wanted to avoid grub2. I was wrong -- Squeeze uses grub2. Uninstalling grub2, installing grub-legacy and running grub-install and update-grub didn't help; it turns out even in Debian's grub-legacy package, those programs come from grub2's grub-common package.

What a hassle! But maybe it was a blessing in disguise -- I'd been looking for an excuse to explore extlinux as a bootloader as a way out of the grub mess.

Extlinux is one of the many spinoffs of syslinux -- the bootloader used for live CDs and many other applications. It's not as commonly used as a bootloader for desktops and laptops, but it's perfectly capable of that. It's simple, well tested and has been around for years. And it supports the few things I want out of a bootloader: it has a simple configuration file that lives on the /boot partition; it can chain-load Windows, on machines with a Windows partition; it even offers pretty graphical menus with image backgrounds.

Since there isn't much written about how to use extlinux, I wrote up my experiences along with some tips for configuring it. It came out too long for a blog article, so instead I've made it its own page: How to install extlinux (syslinux) as a bootloader.

Tags: , , ,
[ 15:19 Nov 20, 2011    More linux/install | permalink to this entry | comments ]

Sat, 30 Apr 2011

Ubuntu "Natty Narwhal" on the ExoPC

Intel hosted a MeeGo developer camp on Friday where they gave out ExoPC tablets for developers, and I was lucky enough to get one.

Intel is making a big MeeGo push -- they want lots of apps available for this platform, so they're trying to make it as easy as possible for develoeprs to make new apps for their AppUp store.

Meego looks fun -- it's a real Unix under the hood, with a more or less mainstream kernel and a shell. I'm looking forward to developing for it; in theory it can run Python programs (using Qt or possibly even gtk for the front end) as well as C++ Qt apps. Of course, I'll be writing about MeeGo developing once I know more about it; for now I'm still setting up my development environment.

But on a lazy Saturday, I thought it would be fun to see if the new Ubuntu 11.04, "Natty Narwhal", can run on the ExoPC. Natty's whizzy new "Unity" interface (actually not new, but much revamped since the previous Ubuntu release) is rumoured to be somewhat aimed at tablets with touchscreens. How would it work on the ExoPC?

Making a bootable Ubuntu USB stick

The first step was to create a bootable USB stick with Ubuntu on it. Sadly, this is not as easy as on Fedora or SuSE. Ubuntu is still very CD oriented, and to make a live USB stick you need to take an ISO intended for a CDROM then run a program that changes it to make it bootable from USB.

There are two programs for this: usb-creator and unetbootin. In the past, I've had zero luck getting these programs to work except when running under a Gnome desktop on the same version of Ubuntu I was trying to install. Maybe it would be better this time.

I tried usb-creator-gtk first, since that seems to be the one Ubuntu pushes most. It installed without too many extra dependencies -- it did pull in several PolicyKit libraries like libpolkit-backend-1-0 and libpolkit-gobject-1-0. When I ran it, it saw the USB stick right away, and I chose the ubuntu-11.04-desktop-i386.iso file I'd downloaded. But the Make Startup Disk button remained blank. I guess I needed to click the Erase Disk button first. So I did -- and was presented with an error dialog that said:

org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PolicyKit1 was not provided by any service files

Dave (who's wrestled with this problem more than I have) suggested maybe it wanted a vfat partition on the USB stick. So I quit usb-creator-gtk, used gparted to make the stick into a single vfat partition, and restarted usb-creator-gtk. Now everything was un-greyed -- so I clicked Make Startup Disk and was immediately presented with another dialog:

Installation failed

No clue about what went wrong or why. Okay, on to unetbootin.

When I ran unetbootin, it gave me a helpful dialog that "unetbootin must be run as root." Then it proceeded to show its window anyway. I can read, so I quit and ran it again as root. I chose the iso file, clicked OK -- and it worked! In a minute or two I had a bootable Ubuntu USB stick.

(Update: unetbootin is better than usb-creator for another reason: you can use it to burn CDs other than the default live desktop CD -- like if you want to burn the "alternate installer" ISO so you can install server systems, use RAID partitions, etc.)

Booting on the ExoPC

[Ubuntu Natty running on ExoPC] Natty booted up just fine! I inserted the USB stick, powered on, leapt for the XXX button that shows the boot menu and told it to boot from the stick. Natty booted quite fast, and before long I was in the Unity desktop, and, oddly, it started off in a banshee screen telling me I didn't have any albums installed. I dismissed banshee ...

... at which point I found I couldn't actually do much without a keyboard. I couldn't sign on to our wi-fi since I couldn't type the password, and I didn't have any local files installed. But wait! I had an SD card with some photos on it, and Ubuntu recognized it just fine and popped up a file browser.

But I wanted to try net access. I borrowed Dave's Mac USB keyboard to type in the WPA password. It worked fine, and soon I was signed on to wi-fi and happily browsing the web.

"onboard" keyboard

What about an onscreen keyboard, though? I found one, called "onboard". It's installed by default. Unfortunately, I couldn't find a way to run it without a keyboard. Unity has a "+" button that took me to a window with a text field labeled Search Applications, but you have to type something there before it will show you any applications. I couldn't find any way to get a list of applications without a keyboard.

With a keyboard, I was able to find a terminal app, from which I was able to run onboard. It's tiny! Far too small for me to type on a capacitive display, even with my tiny fingers. It has no man page, but it does have a --help argument, by which I was able to discover the -s argument: onboard -s 900x300 did nicely. It's ugly, but I can live with that. Now if I can figure out how to make a custom Unity launcher for that, I'll be all set.

Unity on tablets -- not quite there yet

With onboard running, I gave Dave back his keyboard, and discovered a few other problems. I couldn't scroll in the file browser window: the scrollbar thumb is only a few pixels wide, too narrow to hit with a finger on a touchscreen, and the onboard keyboard has no up/down arrows or Page Up/Down. I tried dragging with two fingers, but no dice.

Also, when I went back to that Unity Search Applications screen, I discovered it takes up the whole screen, covering the onscreen keyboard, and there's no way to move it so I can type.

Update: forgot to mention that Unity, for all its huge Playskool buttons, has a lot of very small targets that are hard to hit with a finger. It took me two or three tries to choose the wi-fi icon on the top bar rather than the icon to the left or right of it, and shutdown is similarly tricky.

So Natty's usability on tablets isn't quite there. Still, I'm impressed at how easy it was to get this far. I didn't expect it to boot, run and be so usable without any extra work on my part. Very cool!

And no, I won't be installing Natty permanently on the ExoPC. I got this tablet for MeeGo development and I'm not welching on that deal. But it's fun to know that it's so easy to boot Ubuntu when I want to.

Tags: , , , ,
[ 12:46 Apr 30, 2011    More linux/install | permalink to this entry | comments ]

Thu, 08 Apr 2010

Article: Linux Boot Camp, part 2: Upstart

On Linux Planet, an article about how Upstart manages the Linux boot process, how it's used in various distros, and how to explore and control it:

The Upstart Startup Manager (Linux Boot Camp part 2)

Tags: , ,
[ 09:49 Apr 08, 2010    More writing | permalink to this entry | comments ]

Thu, 25 Mar 2010

Article: Linux Boot Camp (part 1: SysV Init)

My latest article is up on Linux Planet: How Linux Boots: Linux Boot Camp (Part I: SysV Init)

It describes the boot sequence, from grub to kernel loading to init scripts to starting X. Part I covers the classic "SysV Init" model still used to some extent by every distro; part II will cover Upstart, the version that's gradually working its way into some of the newer Linux releases.

Tags: , ,
[ 14:25 Mar 25, 2010    More writing | permalink to this entry | comments ]

Mon, 02 Nov 2009

Autologin changes again for Ubuntu Karmic

The syntax to log in automatically (without gdm or kdm) has changed yet again in Ubuntu Karmic Koala. It's similar to the Hardy autologin, but the file has moved: under Karmic, /etc/event.d is no longer used, as documented in the releasenotes (though, confusingly, it isn't removed when you upgrade, so it may still be there taking up space and looking like it's useful for something). The new location is /etc/init/tty1.conf. So here are the updated instructions:

Create /usr/bin/loginscript if you haven't already, containing something like this:

#! /bin/sh
/bin/login -f yourusername

Then edit /etc/init/tty1.conf and look for the respawn line, and replace the line after it, exec /sbin/getty -8 38400 tty1, with this:

exec /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

As far as I know, it's safe to delete /etc/event.d since it's now unused. I haven't verified that yet. Better rename it first, and see if anything breaks.

Tags: , ,
[ 19:46 Nov 02, 2009    More linux/install | permalink to this entry | comments ]

Tue, 29 Apr 2008

How often does updatedb really need to run?

Since updating to Hardy, I've been getting mail from Anacron:
/etc/cron.weekly/slocate:
slocate: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory

That's the script that updates the database for locate, Linux's fast find system. I figured I must have screwed something up when I moved that slocate cron script from cron.daily to cron.weekly (because I hate having my machine slow to a crawl as soon as I boot it in the morning, and it doesn't bother me if the database doesn't necessarily have files added in the last day or two).

But after talking to some other folks and googling for Ubuntu bugs, I discovered I wasn't the only one getting that mail, and there was already a bug covering it. Comparing my setup with another Hardy user's, I found that the file slocate was failing to find, /etc/updatedb.conf, belongs to a different package, mlocate. If mlocate is installed, then slocate's cron script works; otherwise, it doesn't. Sounds like slocate should have a dependency that pulls in mlocate, no?

But wait, what do these two packages do? Let's try a little aptitude search locate:

p   dlocate                         - fast alternative to dpkg -L and dpkg -S   
p   kio-locate                      - kio-slave for the locate command          
i   locate                          - maintain and query an index of a directory
p   mlocate                         - quickly find files on the filesystem based
i   slocate                         - Secure replacement of findutil's locate   
Okay, forget the first two, but we have locate, mlocate, and slocate. How do they relate?

Worse, if I install mlocate (so slocate will work) and then look in my cron directories, it turns out I now have, count 'em, five different cron scripts that run updatedb. They are:

In cron.daily:

locate: 72 lines! but a lot of that is comments and pruning, and a lot of fiddling to figure out what version of the kernel is running to see whether it can pass any advanced flags when it tries to renice the process. In the end it calls updatedb.findutils (note no full path, though it uses a full path when it checks for it earlier in the script).

slocate: A much simpler but unfortunately buggy 20 lines. It checks for /etc/updatedb.conf, runs it if it exists, fiddles with ionice, checks again for /etc/updatedb.conf, and based on whether it finds it, runs either /usr/bin/slocate -u or /usr/bin/slocate -u -f proc. The latter path is what was failing and sending root mail every time the script was run.

mlocate: an even slimmer 12 line script, which checks for /usr/bin/updatedb.mlocate and, if it exists, fiddles ionice then runs /usr/bin/updatedb.mlocate.

In cron.weekly:

Two virtually identical scripts called find.notslocate and find.notslocate.dpkg-new, which differ only in dpkg-new having more elaborate ionice options. They both run updatedb. And which updatedb would that be? Probably /usr/bin/updatedb, which links to /etc/alternatives/updatedb, which probably links to either updatedb.mlocate or updatedb.slocate, whichever you've installed most recently. But in either case, it's hard to see why you'd need this script running weekly if you're already running both flavors of updatedb from other scripts cron.daily. And having two copies of the script is just plain wrong (and there was already a bug filed on it). (As long as you're poking around in cron.daily and cron.weekly, check and see if you have any more of these extra dpkg-new or dpkg-old scripts -- they might be slowing down your machine for no reason.)

Further research reveals that mlocate is a new(ish) package intended to replace slocate. (There was a long discussion of that on ubuntu-devel, leading to the replacement of slocate with mlocate very late in the Hardy development cycle. There was also lots of discussion of "tracker", apparently a GUI fast find tool that can only search in the user's home directory.)

What is this mlocate? The m stands for "merge": the advantage of mlocate is that it can merge new results into its existing database instead of replacing the whole thing every time. Sounds good, right? However, the down side is that mlocate apparently can't to purge its database of old files that no longer exist, and these files will clutter up your locate results. Running locate -e will keep them from being printed -- but there seems to be no way to set this permanently, via an environment variable or .locaterc file, nor to tell updatedb.mlocate to clean up its database. So you'll need to alias locate to locate -e if you want sensible behavior. Or go back to slocate. Sigh.

Cleaning up

The important thing is to get rid of most of those spurious updatedb cron scripts. You might choose to run updatedb daily, weekly, or only when you choose to run it; but you probably don't want five different scripts running two different versions of updatedb at different times. The packages obviously aren't cleaning up after themselves, so let's do a little manual cleanup.

That find.slocate script looks suspicious. In fact, if you run dpkg -S find.notslocate, you find out that it doesn't belong to any package -- not only should the .dpkg-old version not be there, neither should the other one! So out they go.

As for slocate and mlocate, it's important to know that the two packages can coexist: installing mlocate doesn't remove slocate or vice versa. A clean Hardy install should have only mlocate; upgrades from Gutsy are more likely to have a broken slocate.

Having both packages probably isn't what you want. So pick one, and remove or disable the other. If mlocate is what you want, apt-get purge slocate and just make sure that /etc/cron.*/slocate disappears. If you decide you want slocate, it's a little trickier since the slocate package is broken; but you can fix it by creating an empty /etc/updatedb.conf so updatedb.slocate won't fail.

Tags: , , ,
[ 20:48 Apr 29, 2008    More linux/install | permalink to this entry | comments ]

Tue, 22 Apr 2008

Autologin changes again for Hardy's upstart

Seems like each new Ubuntu release makes a few gratuitous changes to the syntax of system files. Today's change involves autologin, controlled by the "upstart" system (here's what I wrote about the previous syntax for autologin under upstart).

The /usr/bin/loginscript still hasn't changed, and this still works:

#! /bin/sh
/bin/login -f yourusername

But the syntax has changed a little for the getty line in /etc/event.d/tty1: respawn is now on its own line (I don't know if that matters -- I still can't find any documentation on this file's syntax, though I found a new upstart page that links to some blog entries illustrating how upstart can be used to start system daemons like dbus). And the getty now needs an exec before it. Like this:

respawn
exec /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

Update: this changed again in Karmic Koala: the file has moved from /etc/event.d/tty1 to /etc/init/tty1.conf.

Tags: , ,
[ 14:27 Apr 22, 2008    More linux | permalink to this entry | comments ]

Sat, 17 Feb 2007

Autologin under Upstart

The simple auto-login without gdm which I described a year ago stopped working when I upgradeded to "Edgy Eft". As part of Ubuntu's new "Upstart" boot system, they've replaced /etc/inittab with a new system that uses the directory /etc/event.d.

There's a little bit of documentation available, but in the end it just came down to fiddling. Here's how it works:

First, use the same /usr/bin/loginscript you used for the old setup, which contains something like this:

#! /bin/sh
/bin/login -f yourusername

Then edit /etc/event.d/tty1 and find the getty line: probably the last line of the file, looking like

respawn /sbin/getty 38400 tty1
Change that to:
respawn /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

That's it! If you want to run X (or anything else) automatically, that works the same way as always.

Update: This changed again in Hardy. Here are the details. And then changed again in Karmic Koala: the file has moved from /etc/event.d/tty1 to /etc/init/tty1.conf.

Tags: , ,
[ 12:37 Feb 17, 2007    More linux | permalink to this entry | comments ]

Sun, 05 Feb 2006

Auto-Login, and X Without gdm

I've been unable to persuade Ubuntu's "Dapper Drake" to log me in automatically via gdm. My desktop background flashes briefly during the login process, then vanishes; it appears that it actually is logging me in briefly, then immediately logging me out and presenting me with the normal gdm login screen.

I never liked gdm much anyway. It's heavyweight and it interferes with seeing shutdown messages. The only reason I was using it on Hoary was for autologin, and with that reason gone, I uninstalled it.

But that presented an interesting problem: it turns out that Dapper doesn't actually allow users to run X. The error message is:

Unable to open wrapper config file /etc/X11/Xwrapper.config
X: user not authorized to run the X server, aborting.
The fix turned out to be trivial: make the X server setuid and setgid (chmod 6755 /usr/bin/X). Mode 4755 (setuid only, no setgid) also works, but other Debian systems seem to set both bits.

The next question was how to implement auto-login without gdm or kdm. I had already found a useful Linux Gazette article on the subject. The gist is that you compile a short C program that calls login with your username, then you call getty with your new program as the "alternate login program". Now, I have nothing against C, but wouldn't a script be easier?

It turns out a script works too. Replace the tty1 line in /etc/inittab with a line like:

1:2345:respawn:/sbin/getty -n -l /usr/bin/myloginscript 38400 tty1
where the script in question looks like:
#! /bin/sh
/bin/login -f username

At first, I tried an even simpler approach:

1:2345:respawn:/bin/login -f username

That logged me in, but I ended up on /dev/console instead of /dev/tty1, with a message that I had no access to the tty and therefore wouldn't be able to use job control. X didn't work either. The getty is needed in order to switch control from /dev/console to a real virtual terminal like /dev/tty1.

Of course, running X automatically once you're logged in is trivial, just a line or three added to .login or .profile (see the Linux Gazette article referenced above for an example).

It works great, it's very fast, plus I can watch shutdown messages again. Nice!

Update 9/9/2006: the Linux Gazette article isn't accessible any more (apparently Linux Journal bought them and made the old articles inaccessible). But here's an example of what I do in my .login on Dapper -- this is for tcsh, so bash users subtitute "fi" for "endif":

    if ($tty == tty1) then
        startx
    endif

Tags: , ,
[ 10:53 Feb 05, 2006    More linux | permalink to this entry | comments ]

Syndicated on:
LinuxChix Live
Ubuntu Women
Women in Free Software
Graphics Planet
DevChix
Ubuntu California
Planet Openbox
Devchix
Planet LCA2009

Friends' Blogs:
Ups & Downs
DailyBBG
Long Live the Village Green
Dan Heller
Morris "Mojo" Jones
Jane Houston Jones

Other Blogs:
DevChix
Scott Adams
Dave Barry
BoingBoing (Cory Doctorow)
Young Female Scientist

Powered by PyBlosxom.