Wandering Thoughts archives

A thought on the advance of X auto-configuration

That X needs a configuration file less and less makes it more and more important to have your monitor(s) powered on when you're powering on or rebooting a machine, because otherwise X won't be able to get the DDC information it needs to do most of that nice automatic configuration. A side effect of this is killing off BNC monitor connectors, because you can't do DDC over BNC.

(Yes, I still have a CRT monitor at home, and until recently I was using a BNC connector for peculiar reasons. I think someone told me a long time ago that BNC had better signal quality than D-SUB, although I don't know if that's true.)

This effect actually isn't entirely restricted to X, since the BIOSes of modern video cards do funky monitor auto-detection to decide which out of a whole bunch of possible connectors to light up as the text console. I think my theoretically dual-DVI video card in the office workstation has four possible outputs (through two DVI-I connectors, so not all can be used at once), and I know that the BIOS doesn't light all of them. (I call the card theoretically dual-DVI because I have yet to get X to drive both digital outs.)

As a semi-old fogy, I have to say that the advances in automatic X configuration are amazing. For someone who once had to manually stuff modelines into my X86Conf file in order to get 1280x1024 to come out just right, being able to start the X server with no configuration file at all and have it not just come up, but come up right as I want it is a definite marvel and a nice sign of just how far we've come.

(My preferred solution to the 'monitor must be on' DDC issue for X would be to introduce some sort of default value settings. Right now, I believe that xorg.conf values override what DDC et al discover; default values would be fallbacks instead, so you could say 'if you don't get better information, assume that you have a monitor with these garden-variety capabilities'. For bonus points, you could make X record the last DDC values it saw and use them as the defaults if nothing else is set.)

Fedora Core's memory problem

; chkconfig --list autofs
service autofs supports chkconfig, but is not referenced in any runlevel (run 'chkconfig --add autofs')
; rpm -U autofs*.rpm
[...]
; chkconfig --list autofs
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off

Is it too much to ask that Fedora Core remember what services I want and don't want running over package upgrades? Apparently it is, because this happens EVERY DAMN TIME. I am perpetually running around doing 'chkconfig --list | fgrep :on | sort' and disinfecting the latest infestation of stray daemons.

(I find autofs one of the more annoying daemons to pop up, because it claims some random directories and, worse yet, will remove them (assuming they're empty) when you shut it down. If you were using one of those directories as a regular mountpoint, interesting things (or at least annoying ones) can start happening. And it's not like the names it uses are obscure or uncommon, since it wants at least /net and /misc.)

This is an RPM packaging flaw; autofs's postinstall script does an unconditional 'chkconfig --add autofs'. The xinetd postinstall script illustrates the correct way to do this:

if [ $1 = 1 ]; then
    /sbin/chkconfig --add xinetd 
fi

This only runs the chkconfig when xinetd is installed, not when it is upgraded; if I turn it off, it stays off.

(For bonus irony, many RPMs that get this wrong manage to correctly not restart themselves during an upgrade when they weren't running in the first place, using 'condrestart' instead of 'restart'.)

What I want out of a Linux partitioning program

Programs like fdisk, sfdisk, and even parted are really irritating to deal with most of the time because they ask you too many nitpicking questions. What I want is a partitioning program with a command oriented 'shell' interface, with the core command being:

make N SIZE [TYPE]

This makes partition N be SIZE big (with the default units being megabytes), optionally making its type be TYPE (which can be in hex or in English). If N is 1 to 4, it is a primary partition; otherwise it is a logical partition and the program automatically creates an extended partition as necessary. Partitions are allocated in order, from the start of the disk on up. You can use 'sdaN' and the like as a synonym for 'N'; if you do so, by default it is an error if you are not operating on /dev/sda or the like.

The next most important command is:

grow N TO [MAX]

This allows partition N to grow to be TO big (up to MAX size). 'TO' can be 'rest', for the rest of the disk, a percentage of the total disk size, or a size (in which case MAX is redundant). Growth requests are satisfied in order.

Then our default partitioning scheme could be expressed simply and directly:

make 1 512M      # /boot
make 2 2G swap   # swap
make 5 5G raid   # /
make 6 20G raid  # /usr
make 7 5G raid   # /var
make 8 2G raid   # /tmp
make 9 1M raid   # rest

grow 8 10% 4G
grow 9 rest

An if command that let me conditionalize things on at least the total disk size would also be handy (and avoid the temptation to have make and grow grow too many options).

This omits a great many advanced features that are part of fdisk et al that we never use in practice, in favour of doing the right thing by default. (If I need the advanced features, I can always drag out fdisk (or ideally cfdisk, which I like much better; unfortunately, Fedora Core has not packaged it for some time).)

Some existing programs come close:

• GNU parted has the command shell approach, but makes me specify the starting point of partitions. I don't want to have to do that, because the answer is always 'after the previous one'.
• sfdisk can do this, but has an interface in the finest Unix traditions of, say, ed. (I really like sfdisk for what it does well, but manual partitioning is not really one of those things.)
• fdisk has no command line mode. While I can feed it standard input, I'd have to tediously navigate through text menus.

(The 'grow the last partition to the rest of the disk' is the piece of grow that I really care about; other things are gravy.)

(These are all the Linux partition editors that I know of, apart from qtparted and gparted, which are parted frontends, and cfdisk, which is entirely curses-based. If there's others, let me know.)

Since I've now discovered that sfdisk comes closest to what I want, and I can actually write a command file for it, I expect that it's what I'll use in the future for this kind of thing. It may be arcane, but it's less tedious than fdisk.

Another obnoxious discovery about Ubuntu's /var/run stuff

Today, I had the distinct pleasure of discovering that /var/run must exist on the root filesystem, even if you have a separate /var filesystem. If your root filesystem does not have such a hidden /var/run, you experience mysterious failures of various boot stuff, including an inability to bring up the network; for bonus points, nothing gives you any meaningful error messages.

(For bonus points, the default Ubuntu server startup sequence wipes out the console scroll buffer, so you can't scroll back to see many boot time messages anyways. And nothing captures them elsewhere.)

I find this incredibly obnoxious, because it means that if you move your root filesystem around, you must move it with something that peeks under mount points (effectively only dump or an equivalent will do) and you must not, on any account, move it to a place with a replacement /var already mounted in place. (Guess what we did, not knowing any better.)

If you started out without a separate /var filesystem and now want to move to one, apparently your life just sucks.

There are some comments in /etc/init.d/mountvirtfs that suggest that it should be recreating the root filesystem's /var/run if it doesn't exist. However, there are two problems:

• there is no actual code in mountvirtfs to do this, just comments saying that it should be done.
• trying to do it wouldn't help anyways, because the root filesystem is mounted read-only at this point.

(While /var/lock also exists on the root filesystem and is necessary, don't worry about it; LVM will helpfully create it for you in early startup as a side effect of making its /var/lock/lvm directory. So you only have to reboot twice to have everything working right with that.)

Ubuntu's attention to detail in init.d scripts

# /etc/init.d/exim4 stop
Stopping MTA: exim4.
# pidof exim4
3559
# grep PIDFILE /etc/init.d/exim4 | sed 1q
PIDFILE="/var/run/exim4/exim.pid"
# ls -ld /var/run/exim4
ls: /var/run/exim4: No such file or directory
# mount | fgrep /var/run
varrun on /var/run type tmpfs (rw)

Well, that would explain it.

It turns out that the official Ubuntu exim4 package (which is in their core repository, not one of the less supported expanded ones) creates /var/run/exim4 in its post-install script. This probably works well on Debian, where I suspect that /var/run is part of a persistent filesystem, but works rather less well on Ubuntu (and fails mysteriously; 'exim4 stop' and 'exim4 restart' work fine after you install exim4 up until you reboot the machine). And Ubuntu clearly didn't make a systematic sweep through all packages looking for things that needed /var/run subdirectories when they decided to make /var/run a volatile filesystem.

(They weren't completely ignorant of the whole issue, since /etc/init.d/klogd carefully creates its /var/run directory every time.)

In general, I have not been pleased with Ubuntu's entire /etc/init.d setup. Coming from a Red Hat/Fedora Core environment, I keep finding things missing, like syslogging of the results or a consistent format for startup scripts and information about them. (Ubuntu has the start of this in some init scripts, with the 'BEGIN INIT INFO' section, but only about half of the init scripts on my test machine seem to use it.)

(I suspect that this anarchism and lack of features is a sign of Ubuntu's status as a relatively thin veneer over Debian. The Debian policy guide section on init.d scripts is pretty basic, which is a recipe for widely divergent init scripts.)