UEFI, a Laptop, Debian and debconf
This would be a longish post about various bits and things which have on my mind for several days/weeks etc on variety of topics within the computing environment.
First things first, I am primarily a desktop user and have been for more than a decade or more in my involvement with computing. I love desktops than lappies for a variety of factors, it’s more accessible and open environment, parts are much more easily upgradable and cheaper and you do not have to be a ‘rocket scientist’ to fiddle around in the insides.Also I like assembling systems for the self rather than taking a branded system so I can pick and choose.
Now over period of time as I go to various places and sometimes do presentations or workshops there is a need to have my own laptop and I have been looking at the markets and have been sorely disappointed.
Now what I have been looking for are Intel Haswell I5 Core processors (say from Intel Core I5 – 4250U onwards with Intel HD 5000) with some combo of ATi Radeon Cards in at around 50-60k with NO OS bundled or maybe DR-DOS or something like that to just show that the lappy is functional as in the screen works, the k/b works like that and I have been unable to find such a system. Most of them come with MS-Windows 7 or 8 license (and that too the basic one) which is worthless to me.
In an ideal world I would get one with Debian stable installed but that would be an ideal world. The next best would be to have at the price-point I want with the features I want ^. This doesn’t seem to be happening and I have been looking at various vendors/brands and it’s the same story everywhere. It’s ugly that I have to use binary shims in some places (drivers) but to have a whole OS is now not possible for me. Also my time in Debian has made me much more of a control freak than previously. It takes me more than a month to set my system as I like which is both a good and a bad thing as well.
To top up the already sour-in-the-mouth situation we now have to deal with something called UEFI. To make it easy to understand, in the older generations of systems till about couple of years, we had something called a BIOS. It was a tool for the user to manipulate the hardware on a more simple, intimate manner than an OS. The BIOS required less than 1 MB of RAM and hence was faster than the OS in detecting pieces of hardware and was much more simplistic in looking.
Cut to 2013, and we have the Wintel (MS-Windows+Intel) coming up with UEFI. From the consumer point of view, the only good thing (pro) is that it’s better looking than BIOS. The bad/ugly things (cons) is it has all sorts of restrictions built into it. For e.g. it is supposed to have something called a ‘Trusted Mode’ which basically means the kernel is signed via Internet (if I remember rightly) at various times. It probably computes the SHA1sum of the various kernel bits and see if everything is right. I am not a MS-Windows user anymore so this is more of how I suppose it would work. Now in the MS-Windows world major changes in the kernel happen every 3 years or so (or used to happen) so signing once in a while is o.k. although boot-virus writers and hackers would find a way to attack it one way or the other if not already found making a mockery of the UEFI implementation as this is what it’s claimed to be protected from.
From a security viewpoint, the only secure system is a system which is never updated, never connected to the Internet but as this will not happen hence people will find loopholes and attack vectors in all and any implementation.
Now from the free software world and esp. GNU/Linux distributions and distributions like Debian, having trusted mode is not good for us. The churn of rate of development in GNU/Linux world make it next to impossible to have a kernel which will make everyone happy. We have a kernel release every 3 months, so roughly 3-4 kernel releases per year. While we do have long-term releases or long-term support releases it’s applicable mostly to Enterprise users. People like me who like to tinker with their boxes having third-party signing a kernel release would defeat the very purpose, not to mention the fact at some point it would become expensive to maintain in both the short-term and long-term. Just to accentuate this point, the 3.12 kernel just came out.
I am deliberately not going in the various ins and outs of UEFI because most of the people are only going to be a user using the GUI to access it, those who would be looking to develop on something similar would be better off using their resources for Coreboot for lack of a better alternative as of in this moment in time. Sadly, coreboot does not have any GUI of its own. I would not get into the reasons because there are and were variety of factors at play for that not to happen. If people are interested they can see the mailing list archives for the reasons thereof.
Now, the only salvage part from a purely free software user and supporter is as and when Syslinux 6.x series is in the next release. Just a few days back the 6.02 release was released upstream and has been packaged and merged by Daniel Baumann (A DM and contributor to one of Debian Blends as well, Debian Live.)
$ aptitude show syslinux=3:6.02+dfsg-1
Automatically installed: no
Maintainer: Daniel Baumann
Uncompressed Size: 641 k
Depends: libc6 (>= 2.2.5), mtools
Breaks: syslinux-common (< 3:6.02+dfsg-1)
Description: collection of bootloaders (DOS FAT and NTFS bootloader) syslinux is a suite of bootloaders, currently supporting DOS FAT and NTFS filesystems (SYSLINUX), Linux ext2/ext3/ext4, btrfs, and xfs filesystems (EXTLINUX), PXE network boots (PXELINUX), or ISO 9660 CD-ROMs (ISOLINUX).
This package contains the bootloader for DOS FAT and NTFS filesystems (SYSLINUX).
This is where the latest release is at :-
$ apt-show-versions -a syslinux
syslinux:amd64 3:6.02+dfsg-1 install ok installed
syslinux:amd64 3:4.05+dfsg-6+deb7u3 testing debian.ec.as6453.net
syslinux:amd64 3:4.05+dfsg-6+deb7u3 unstable debian.ec.as6453.net
syslinux:amd64 3:6.02+dfsg-1 experimental debian.ec.as6453.net
syslinux:amd64/experimental 3:6.02+dfsg-1 uptodate
Right now my system (the one on which I’m writing) is on the older BIOS and hence running in a sort of compatibility mode. For the newer UEFI the 6.0x whatever would be needed. We have a freeze time of November 2014 (for Debian Jessie) so in that time if we are able to have a version which can boot the lappies in the market it would be good enough. As far as it gives me a $UNIX shell I’m a happy customer, the rest can be taken care of.
Now coming to an important part for control freaks like me as well as sys-admins. Debian gives beautiful tools called dpkg-reconfigure, debconf and debian-configure. I would talk about the first two tools, dpkg-reconfigure and debconf as they are used if you want to configure some tool/utility.
The first thing I do is to configure debconf itself as IMO it’s the most important part when settling down a new system.
The first command I run is :-
$sudo dpkg-reconfigure debconf
I usually choose ‘Dialog’ as my front-end and ask it ignore questions with a priority less than ‘high’. You can even go more lower depending on your need, expertise and time. I use ‘Dialog’ as I want to have an interactive experience when I’m configuring a $PACKAGE, on servers people usually use ‘non-interactive’. They might do holds for some packages while others can upgrade without user-interaction. Lots of magic can be done with it. The utility is in perl and you will find some bits of it in /usr/share/debconf and find other bits from there.
Once the initial configuration option has been chosen you can easily configure any of the packages at any point in time.
For e.g. one of the important packages that usually is configured is for e.g. the locales package.
$sudo dpkg-reconfigure locales
Taking the choices here helps in generating as few or as many locales you want in both the packages and the overall-environment for the system.This is useful both for saving bandwidth and space in the system.
Just like the above there are other packages that can use debconf if the packager has used debconf for pre and post-configuration as well as user-configuration. See the tutorial at http://www.fifi.org/doc/debconf-doc/tutorial.html for an e.g. as to how to go about doing that.