Hi, I'm Colin Watson, this is a recruitment drive.

I'm glad to see quite so many people here, that's very useful.

[video team]: (inaudible)

[Colin]: There's a little bit of feedback?

Okay, is that any better?

[video team]: (inaudible)

[Colin]: Alright.

Somehow over the years I've found myself

as the de facto GRUB maintainer in debian

and I'm also a GRUB developer over the years

and I'm here to persuade you all that this is a fun thing to do

and that can you help, because I need more people

So yay

grub has moved on a long way from it's beginnings

It's called the GRAND UNIFIED BOOT LOADER

which is a bit of an aspirational name

and certainly was an aspirational name

back in 1995 and back then most us of just

used it over LILO which is the really traditional

x86 loader, because you didn't have to remember to reinstall

your bootloader when you installed a new kernel which was really

annoying, but even so quite a few debian developers have

hacked on grub over the years and nowadays it's a very powerful

bootloader, it's been ported to many architectures

it's actually quite rewarding to hack on

so I'll be giving you a tour of its history

and of its design and suggesting a some particular areas

where we could really do with help

Now the grub project; this is grub 1

it was originally just called grub and now

we call it grub legacy, but it was started in 1995 by Erich Boleyn,

he was initally trying to build something to boot GNU/Hurd

and among the loaders of the day it was quite unusual in that

you know, you could edit its menus on the fly and

that sort of thing. It had an emacs or bash style interface to that.

Other loaders usually just let you append kernel line options and that was

about all you got

and grub even then had a reasonably capable file system

interface as well

so it was by and large good enough, so many people adopted it as it was.

and of course it was originally designed for the Hurd

to start with so it started out with a focus on a new boot method

they designed which is called multiboot and the history file says

they were determined not to add to the large number of mutually

incompatible PC boot methods

[laughter]

Yes, well.

grub did soon become a little bit more generic

it supported the methods for booting linux and such

and I am being a bit unfair

multiboot has been genuinely useful to people doing academic experiments

with kernels written from scratch and custom payloads

because they don't have to do all of that work from scratch

anyway I won't cover multiboot further.

This is a rough layout of grub legacy back in the day

You had stage 1, this was a tiny thing that fitted

in the 512 byte master boot record.

It just knew how to read the first sector of the next

stage along, stage 1.5, from a fixed location, and jump to it.

That was all it could do, it was really stupid.

There was a seperate stage 1.5 for each separate file

system type that grub understood.

And that had enough file system code to

read stage 2 from an ordinary file system.

So it's the usual kind of bootstrap your way gradually up the stack.

The real meat of the loader lived in stage 2 and that included

all the command line commands, configuration file parsing

and the code to actually boot a payload,

like a Linux kernel image,

which is probably what you wanted to do with it.

So far, so good.

But there were quite a few problems with the design

as it was initially put together.

The file system abstraction was pretty ad-hoc.

It was achieved by building a seperate stage 1.5 blob

for each file system that grub knew about

and shipping that in the package.

The terminal abstraction was pretty reasonable aswell,

but other than that there wasn't much in the way of

internal expressive par(sing??) going on.

So it was very difficult to extend it safely.

It's hard to work out how grub legacy could ever

have been taught to handle LVM, for instance,

because you would then have to have a stage 1.5 that knew

about each of the file systems on LVM and so on.

You end up with a combinatorial explosion.

So it wasn't very elegant, from that point of view.

There were lots of PC BIOS assumptions aswell.

It may have been grand and unified,

but it wasn't particularly portable at that point.

Fedora did manage to get it to work with UEFI.

Actually, probably Red Hat then managed to get it

to work with UEFI, but it wasn't at all

a straight-forward exercise and it was very hacky.

So as time went on, upstream maintenance kind of

fell by the way side, it was such a pain to work

on and even though there wasn't really anything newer

that was usable, nobody wasn really interested in the

upstream so the distributions did what they had to do.

This meant we have ended up with grub legacy packages

in Debian and Ubuntu and Fedora and SUSE and all the rest,

that are actually completely different products.

I don't just mean have a different patch set,

in the usual way that you get,

they have completely different installation

and configuration tools that don't exist in

other multiple branches.

So today it's impossible if someone comes to us upstream,

to support grub 0.97, because it just isn't enough of a thing by itself.

You have to figure out what distribution people are using

and tell them what to do for that.

So we end up punting a lot of that to the distributions to support.

So there is a grub 2 rewrite, started in around 2002.

This is a very rough timeline of it,

as you can see it was a pretty long project, pretty slow project.

Yoshinori K. Okuji, I hope I pronounced his name correctly,

he was the lead grub maintainer at the time.

He started work on what he called:

"Preliminary Universal Programming Architecture for GNU Grub"

or 'PUPA'.

It's GNU so there is a bad pun in the acronym,

a pupa is the next stage along from a larva or grub in an insect's lifecycle.

I'd say it was roughly usable by about 2007,

so there was a long period when it was very experimental.

My pretty biased viewpoint is that distributions started

adopting it properly and started to present it to users in about 2009.

A snowball effect kind of kicked in from there

and it became much better quality quickly,

until we finally got 2.0 out in 2012.

So I also noted in here the point where the first

non-x86 architecture port showed up, that was the PowerPC port

for New World Macs, in 2004.

Because that's a very unusual milestone

in something as architecture specific as bootloaders have historically tended to be.

But right now if you look at some core bits of grub 2,

you can kind of see the echos of bits of grub legacy in there.

There are a few common lines of code

but it was a pretty sweeping rewrite and there isn't much left.

This was a very large project by most standards,

the lead maintainship has changed hands 3 or 4 times along the way,

it took a lot of forward thinking for people to get involved early on.

So the design that we have now, is around a small kernel

that offers core features like initialisation,

a virtual file system layer, a module loader

almost everything is in modules, sound familar?

there is an insmod command,

there is considerable inspiration taken from

full-fledged operating systems here.

You mostly don't have to worry about much of this by hand,

grub-install which is the main installation tool,

works out the bare minimum set of modules you need

to read everything else from /boot/grub,

and builds what we call a core image.

That's the rough equivalent of what stage 1.5 was in grub legacy,

but this time it's built dynamically,

rather than all being shipped statically in the package.

And also at runtime, the loader will load some modules into itself automatically.

So for example if you request a command name that isn't currently loaded,

it will go off and load it for you automatically.

This architecture makes it a lot easier to

construct images that fit into a constrained space,

in a much more flexible way.

We make very heavy use of abstraction layers,

it's rather like the way, not quite identical,

but rather like the way Unix-like systems

present block devices and file systems.

And those are general composable,

you can quite easily boot from XFS on LVM on RAID, whatever.

There's even the loopback module, so you can treat a file as

if it were a disk, much like we have in Linux.

This makes it quite easy to do strange things,

like you can embed an entire Debian installation

in a file on a Windows system,

which we actually did with Ubuntu for a while

and it's quite scary but it largely works.

This design also lets us easily build userspace

tools from very near to the same code,

which is very important and I'll come onto that later.

As you can see from the random stats at the bottom,

there's very little assembly in this,

it's almost all portable C.

Almost all of the C is common,

the assembly is of course a lot more architecture specific

but for a PC BIOS we are only talking about

about 4 and a half thousand lines,

which is considerable but not too much of a maintenance burden.

So here is a brief summary of what architectures we have now,

we have a number of x86 platforms,

the newest of those is that you can now use grub

under Xen paravirtualization, with a bit of effort.

The newest architectures are arm and arm64,

which were added last year.

In practice only some arm32 devices actually work with this,

because they require the platform's Uboot to be built with

the Uboot API so that it can act as enough of a firmware for grub.

A lot of them don't have that turned on, but it's at least a start.

I believe that, in theory,

all of jessie's release architectures other than s390

(no it's s390x now, isn't it?)

have at least some level of grub support.

Which is pretty awesome.

In grub legacy the hardest and one of the most

common problems we had to debug were problems

with reading files from disk in one way or another.

So people had problems loading the kernel and initrd

because their filesystem was in some strange shape.

If you wanted to debug this you were usually stuck with

trying to set up something that roughly matched in an emulator

and either using just crude printf debugging

or in extreme cases trying to attach gdb to the emulated machine over qemu.

Some people in the audience may be familar with this routine,

it's not very much fun, especially without a gdb stub.

So in grub 2, as I said earlier,

we have much of the same code built into utilities called grub-probe and grub-fstest

and these use the operating system's block device as a backend.

So you can ask grub to use its own partition table and file system tools

and parsing code from right there in userspace.

This makes it very much easier to attack lots of common problems;

you can use gdb, you can use valgrind,

you can use the debugging tools of your choice.

Tom ?? was asking me earlier about f2fs and putting that together in grub 2,

it can almost entirely be done in userspace so you can put together a new module,

built a version of grub-probe that's linked against it

and iterate until you get something that works,

rather than having to constantly reboot.

Even having to reboot an emulated machine is a lot of work.

So a similar trick also gave us this spin-off benefit of grub-mount,

that's a FUSE file system implementation that uses grub's filesystem code.

So that gives you a guaranteed true read-only mount,

using the exact same view that the bootloader

will have when it tries to look at your system.

This lets you avoid the caveats that apply to

things like journalling filesystems in Linux,

which it turns out you sometimes can't safely read-only mount.

Or sometimes the kernel will simply refuse

and it's also useful for things like os-prober.

If somebody felt the urge to make that work

as a Hurd translator it would be a pretty good fit too.

Now, you can't do everything in userspace,

at boot time grub gives you a pretty nice bash style interactive

shell with runtime controllable debugging levels.

Set the debug variable to various things and

that will give you different amounts of spew on your console.

So you can often try things out on the fly,

to figure out what's going wrong.

You can do quick, miniature image builds using the grub-mkrescue command,

that gives you an iso image containing the version of grub that you're using,

which you can then boot in an emulator to try out.

A useful trick is to boot your real live system with such an image

with 'qemu -snapshot' so that it won't write anything back

and then you see how the loader that you're working with will boot your laptop,

without actually risking the possibility of breaking anything.

It's easy to pull out bits of configuration files,

run them, write new commands.

There is a Hello World command that's about 30 lines,

so it's quite easy to put new things together.

Getting onto to things that are a little bit move involved and/or broken,

one of the things that was part of debian's grub legacy changes

was the Debian specific update-grub script.

Now this worked by trying to guess which parts of

/boot/grub/menu.lst were user modified,

by way of magic comments and updating everything

else to match the current state of the system.

This was sort of OK, but it caused a lot of complaints,

sometimes it was just because people didn't read the comment

text which said which parts of the file were safe to edit.

But generally, mixing user-editable

and automatically updated content in the same file

usually turns out to be a bad idea

and we've seen that in various other places in Debian.

So for grub 2, my predecessors brought this upstream as grub-mkconfig

and made it generate the whole configuration file from a

small amount of user edited configuration in /etc/default/grub

and a bunch of scripts in /etc/grub.d.

You can still of course write your own grub.cfg directly

if you like, it is about the same length as it would be in grub 1,

but for a general purpose system we would prefer the autogenerated approach.

So far, so good.

Just about everything is customisable,

the problem is that you have to try quite hard in several places.

Anything involved requires editing quite complex shell scripts,

if those are changed then later you'll

have quite a difficult merge resolution to do.

Some changes require things like moving conffiles

around to different positions in the order which isn't

going to be handled well by dpkg conffile resolution in the future.

So all of this probably needs somebody, sadly,

to sit down and design a third iteration of the system

that uses a templating language or something.

but that hasn't really been at all started yet.

Ok, now onto some things that are still genuinely quite hard.

The PC BIOS architecture has, well,

secreted over 30 or 40 years of gradual development.

It's basically pretty awful for modern purposes.

The usual partition table format is called MBR,

for Master Boot Record, or sometimes the msdos partition table.

It doesn't offer any formal space for keeping boot code in,

you can cram a trivial loader into 446 bytes,

that basically gives you the debian mbr package,

which jumps to a loader somewhere else.

There are a few approaches to where you can keep

the rest of, the real meat of, the loader.

You can embed in a file system somewhere,

at an offset that you know won't change.

For instance you put it in a file and trust that

the file system is not going to move that around.

Sadly sometimes file systems do move things around,

you might run fsck or there are some file systems

that will do their own, I think tail packing in reiserfs is one of these,

that will sometimes move blocks around for you

on the fly and that doesn't play very well with a

bootloader that has hardcoded addresses in the MBR.

A few file systems support an embedding area at the start,

I think btrfs does and one or two others,

this is good but not really widespread enough

that we can build the whole installation strategy around it.

You can do what grub generally does now,

you can skate the edge of the specification,

that sort of really doesn't exist anywhere coherent,

and you can use what's sometimes called the boot track

or other names, that's the unallocated space between the MBR and the first partition

and this makes some people itchy, it's a bit nasty.

It means we have to do some alarming things to avoid conflicts

with other software that put things in the boot track.

Fortunately almost all of that software is evil.

[laughter]

There are a few bits of Windows software,

well some of them are backup utilities which I'm not sure

why they put things there, but they probably have a reason.

There are a few things on Windows that like to put a note in a

sector in the boot track to say that they have been installed,

so that you cannot simply uninstall them to work around their 30 day license trial terms,

you need to know to wipe that bit of the boot track aswell.

And that's all terribly nasty.

Grub actually now has error correction on some of it's own code in the core image.

Grub can literally cope with a couple of sectors of the

core image being overwritten with completely random data.

[laughter]

It's horrifying that we need this, but yes that surprisingly works.

Fortunately this is becoming less of a problem,

the alignment requirements on modern disks mean that for decent peformance

you want to have your first partition start at 1 megabyte or sometimes even more,

rather than the traditional 63 sectors.

So we usually now have plenty of space on MBR,

but not quite always.

Things are also unpredictable when you have multiple disks,

you can't tell from Linux which disk the system was actually booted from.

There are some things on some BIOS versions that let you make better guesses,

but it's unfortunately not universal.

You also can't tell what disk it's going to be booted from next time,

it's not necessarily the same.

Sometimes it depends on which order the devices are enumerated

by the PCI bus, even on the BIOS level.

The least bad answer is usually to install to all of the fixed disks on your system,

but then you annoy some people who have complicated multiboot setups,

so you can't really win.

The GUID Partition Table format, or GPT, is much better.

It's probably the best thing to have come out of the UEFI spec.

[knocks down debconf sign]

Excuse me, let me not do that. Right, I'll not do that again.

This gives you allocated space for

the bootloader code in the UEFI system partition,

in a partition type that we were able to safely allocate for

ourselves because now partition types are a GUID, they are ginormous.

We were able to allocate one for ourselves,

even when using that on top of BIOS, which you can do.

There are different intepretations of the spec,

unfortunately this causes some problems.

When you install a system with GPT,

you're supposed to put what's called a protective MBR in place,

that means that anything that trys to parse the disk as MBR

knows that it should stay away

and not try to scribble over the partition table.

The intepretation of that part of the spec is particularly bad.

Apple, at least, used to have a completely incompatible boths ways version,

you were required instead of a single giant partition to do the best job of

representing the GPT partitions in MBR.

That's incompatible both ways, I don't know if that's still the case.

If you're trying to use GPT on BIOS,

some PC class systems require you to set

the active flag on the protective MBR,

which the GPT spec explicitly forbids for some reason.

So you're stuck both ways round.

UEFI is where it's at for PC firmware, apparently.

Even if your new machine looks like it's BIOS,

it's almost certainly a legacy layer

implemented internally on top of UEFI.

The economics for firmware manufacturers

are much more favourable this way.

Instead of having to maintain their own,

I don't know however many thousand lines of code base that have accreted over the years,

they can now fork Intel's TianoCore as their starting point

and just do their driver layer on top of that.

And this seems to have attracted essentially all of the BIOS manufacturers.

We should generally expect even that legacy BIOS layer

to go away soon, the direction that we hear from firmware people is all about that

and we need to cope with that.

Now, grub's core support for UEFI is basically fine,

it has more or less the set of drivers you'd expect

including relatively arcane things like serial support.

Of course the big thing that's been recently

is something called "Secure Boot",

that's a mechanism by which firmware makes sure to

only ever execute signed code, in a pre-boot context.

It's obviously very possible for this to go very wrong,

from the point of view of user freedom.

The FSF calls Secure Boot, "Restricted Boot" for that reason.

But a lot of systems now come with Secure Boot enabled by default,

so we have to figure out how to work with it

in the same way that we've had to figure out

how to work with all kinds of devices over the years,

just as a hardware enablement matter.

But the important thing is to work out how to that

in ways that don't end up impinging on our user's freedom.

and that's been quite a difficult slog.

The community has managed to figure out schemes for this

that don't stop you modifying the operating system on your own computer,

which is the important thing.

We have this working on Ubuntu,

we talked about this at DebConf last year.

To get it working in Debian we need dak to sign

bootloader objects that we submit to it, with the Debian key.

I failed with pushing that forward so that

would be a great project for somebody to take up,

if I've missed it and somebody else is already working on that, brilliant!

I should also mention that there are some outstanding

issues with the layout of the EFI System Partition,

which is UEFI's place for putting things like bootloader code.

The spec proscribes how you're supposed to behave

on fixed disk versus removable disks,

we follow the spec but unfortunately some systems don't

and essentially require the removable layout.

Steve McIntyre's here at the back,

we've gone back and forth a bit on that.

We need some way to select the removable layout

and have that actually persist and ideally detect

that this is a problem in the first place,

so that we don't have to ask an incomprehensible question in the installer.

Now, more cheerily, a number of non-x86 architectures are in a pretty good state.

they get fairly limited testing at the moment.

I know that some people use them because occasionally

I get some bugs when things break but generally they work OK.

powerpc and sparc work fine, we sould probably consider

switching the default bootloader there at some point.

If you're a porter for those architectures,

please get in touch with me.

Some mips-type architectures would well too.

Ryan ?? lent me a Yeeloong laptop a little while back,

so that I could port the debian installer to it

and I found that grub was basically fine.

So I was able to build the installer on top of that.

It was a tenth of the work it might otherwise have been.

There's been a pretty pleasing trend towards having

new arches include a grub port very early on.

arm64, also powerpc64, has had grub working from very early in it's life.

This gives them a pretty full-feature loader

with not a lot of effort, so it actually

works out quite well for the ports now, I think.

The most recent arm64 port, I went back and looked at it,

it was about 2000 lines of patches to do the initial enablement.

And now that got to take the advantage of the arm port

that already existed and also of UEFI code,

so that helps a lot but still I think it

indicates a pretty porting friendly design.

OK, so if I haven't persuaded you already,

why do we default to grub on debian x86?

There are certainly other loaders,

there's the venerable LILO, which still largely works fine.

Syslinux and friends are actively maintained by some very smart people,

including folks who maintain the Linux boot protocol

and there's extlinux which is one of that family

which you can use in the same kind of way that you might use LILO.

There's yaboot and powerpc and so on and so forth.

You can even boot a kernel and an initramfs directly

from the UEFI environment, if you want to.

So some of those are some pretty good bootloaders,

they're almost all smaller and simpler than grub

and that appeals to a lot of people.

I do get the simplicity argument.

But I tend to argue that the result of that

is moving a good deal of complexity elsewhere.

If you have a bootloader that can only handle some setups,

the installer needs to know what those setups are.

It needs to forbid you from doing anything, that you won't be

able to boot, in your partitioner.

You end up with static /boot partitions scattered everywhere.

Having a bootloader that you can trust to handle almost anything

means that you don't have to think too hard when you are moving things around.

You can easily do things like having the bootloader notice

when the last boot failed and behave differently.

All that sort of thing is useful for a general purpose distro to be able to assume.

[Ben]: We used to support some bootloaders on mips,

but they couldn't load an initramfs, they could only load a kernel.

So for that reason the kernel configurations we used on mips

had to be restricted, they don't assume there is an initramfs

and you can't boot off filesystems other than ext2, 3 and 4.

[Colin]: That's CoLo, is it? Or cibyl?

[Ben]: I don't know. We have recently switched over,

but that has been a restriction up to and including wheezy.

[Colin]: Thanks. That's useful ammunition. [laughs]

I think that we do not yet have grub working on

all of the mips big endian architectures,

it's working on little endian,

but I think there are still some problems with big endian.

So we maybe can't save the world just yet,

but it might not be too far off. But thanks.

Plus Debian runs on lots of architectures,

generally we try as an architectural thing

to run the same software across different architectures so

that it all works kind of the same way.

We have the same interfaces, the same tools are available and so on.

And it makes a lot of sense to have that be the case with the bootloader too.

The installer would certainly be simplified by being able to

assume grub-mount is available on all architectures, for instance.

OK, so the important bit, this.

We've had a lot of people involved over the years

Too many to name, I've almost certainly missed some

Robert Millan, Felix Zielcke and Jordi Mallach

have done excellent jobs in Debian a few years ago.

And Vladimir Serbinenko does an excellent job as the upstream maintainer.

But as far as Debian maintenance goes,

it's mostly just me at the moment and has been

for the last couple of years and I can't do it all.

We'd probably have had grub 2 in 2.00

rather than 1.99 in wheezy,

if we had a bit more redundancy there.

I was kind of demotivated by the Secure Boot stuff at the time,

so ended up putting it off until too late

and that's exactly the kind of thing

where having more people involved is more helpful

there are lots of bugs, everybody's problem is critical for them,

quite understandably.

So keeping on top of the release critical list is absolute murder.

But there are a few specific problems I'd like to highlight,

that are more substantial and could really do with

somebody sitting down and thinking quite hard.

I won't go into too much detail,

as I've just had a sign from the video team that I'm low on time.

But you can ask me about any of them if you're interested.

I mentioned earlier that the system for generating

the config file has a bad case of second system effect

and really needs a third system

[laughter]

to make it easier to customise things.

All problems can be solved by another rewrite, right?

[laughter]

On MBR systems, we often have robustness problems

with grub not installing the boot code to the place

that your system actually boots from,

particularly when multiple disks are involved.

This tends to manifest as module loading failures

because what happens is, over time

the core image that you're actually using

that you didn't know about, becomes incompatible with new grub modules

because the ABI changes over time

and eventually becomes incompatible and can't boot anything

I think that needs some kind of overhaul somewhere,

though I'm not quite sure where.

There are the remaining bit of UEFI,

which I mentioned earlier.

There's getting signing sorted out in Debian,

getting a thing called MokManager,

which is part of a seperate project called shim,

nicely integrated to give users control over the whole signing process

which will let us require signed kernels under Secure Boot

and thus make Matthew Garrett want to kill me a little bit less

[laughter]

and there's the issues with EFI System Partition layout

There's some work to be done with upstream Xen

to layout effectively a new boot protocol for PV Grub 2

so we can have Xen guests install the bootloader

in a consistent place in the file system.

In fact, Ian Campbell recently sent me something that

might be useful for this, I didn't have time to read it.

and hopefully this will eventually let us kill off all

of the old strange things that live in Xen, to do this.

Finally, we should take much better advantage of grub's ports

and switch over to them on many more architectures than we have done to date.

I've just got onto questions, so excellent.

[Ian]: One of things I've found difficult getting to grips with grub 1

and grub 2 is that the documentation hasn't always been as good.

LILO has always been exceptional in that it came with

an extremely good document that described

its principles of operation and how to get it to do,

well, almost anything you might want it to.

Is that also something you're looking for help with?

[Colin]: Yes.

About a year or two ago,

I went through and tried to systematically documenting

all of the grub commands and overhauling some other things.

I got about half way through that,

before I ran out of time.

but one of the problems has been with grub 2

that the documentation got out of date during the rewrite

so nobody has an incentive to do it properly for their incremental changes.

So I think getting that into shape

would make it much easier to keep it in shape

It's better than it was in 2010, it's not where it should be.

So, yes.

Anybody else, anything from irc aswell?

[John]: This was a related question to your comment earlier

about how BIOSes are widely inconsistent about

how they choose which disk they're going to boot from.

Is there anything that grub could do to help us

with best practices for failover configurations?

So for example, let's say I have a server

and I want to install two disk that are mirrored,

using lvm or something else.

One of the challenges is, how do I configure grub

on both disk to be configured the right

way, despite all of the weirdness with BIOSes?

To have a reasonable easy to maintain setup,

so that where if one disk actually goes completely offline,

the system could automatically reboot.

[Colin]: One of the things I tried to do,

the first time I systematically

attacked this in Debian grub,

the thing I tried to do was to arrange that we

did as by-uuid install to disks, possibly as by-path, I forget.

So we encourage people to install to all of the disks on a system.

Also the grub-pc.postinst notices when a disk has gone away since it last checked,

and it's supposed to offer you the chance to update this.

But you're right it's a little bit fiddly to manage

particularly if you're in a system that's large enough

so that statistically disks are failing quite often

Then it's a problem.

I think what I'd probably like to do is to make sure that

we install to the disks that are associated with a RAID device or something

so you could just bootstrap off the RAID management.

I think some of that works but isn't hooked up very well in Debian.

But there are several things to do there.

I think there's also a bug in d-i where it doesn't install

to all of the fixed disks in your system but only one.

So there are several things to fix there.

There's a question over there.

[??]: I think my question could be summed up as:

"How tall do you have to be to ride this ride?"

[laughter]

It seems like getting started,

introducing regressions would be a really scary thing.

For someone who wanted to get started with the project

and I'm just wondering what kind of facilities do you have

for before we actually upload a version to

test across the broad range of architectures.

[Colin]: Right well, one of the points of this talk

was to try to emphasise that you don't actually have

to be as tall as people think you do.

But you're right about the need for regression testing.

One thing that really helps is that the different parts

of grub are much more isolated than they used to be.

So you can quite easily change one module,

test changes with that, without having to worry about

strange leakage all over the place.

But there are things that that doesn't cover,

there is some boot testing arrangement in the build system,

so there are some make targets that go off

and do boot checks of real systems against the current version of the code.

And that sort of thing helps a lot,

I would like to have grub hooked up better to some sort of autopkgtest arrangement

so that it does emulated boots across various types

of systems on ci.debian.net, I'd love help with that.

[Steve]: Now of course UEFI, there's a whole slew of things. Tom was asking

about MBR and a reliable fallback, of course. I'm not aware of any UEFI

implementation that actually does fallback for the system partition either.

So that is an utter trainwreck.

[Colin]: I suspect what you're,

maybe you're meant to use hardware RAID or something?

[Steve]: Clearly that's what you're expected to use and it's a mess.

We should definitely get together

and talk about the removable media path.

Again there isn't a good answer but let's try

and make it as not crap as we can.

[Colin]: Do you know of any way to detect that

system even if it's something like a blacklist of broken DMI decoders?

[Steve]: I think that's all we can do.

We had a system, as an example

for the people that may not have come across this,

there are firmware implementiatons out there

that straight after install may not actually recognise

that you've put grub into the path where you're meant to put it.

Once you've booted off a rescue system, however,

and done some not particularly well understood sequence of things,

including boot off a removable media path, reboot a couple more times

shuffle things around, spin twice clockwise...

[laughter]

suddenly they then will recognise that you've put grub there.

But god forbid, you ever want to update it again.

It's painful.

[Colin]: There are some exciting problems on Apple Macs,

that are a shadow of the same class of problem.

[Steve]: And of course Secure Boot,

kibi asked Steven about this a few days ago.

Of course, we've been talking about this for like 2 years.

I feel rubbish as well, that we haven't really got any further with it.

If someone really really wants to help get involved with that, oh absolutely,

there's a whole load of people who would love to see you help.

[Colin]: Not only are there are a whole load of people who would like to see you help,

but there's actually roughly a roadmap of what needs to be done.

You don't have to blaze a trail.

[??]: Scrape the names off the roadmap and put your name on it.

[laughter]

[Colin]: It's fine, we don't really care, we just want to see it done!

The things that need to be done are, as I say,

the next step I think is in dak and then

somebody needs to chase up getting shim into debian

with the right kind of signatures on it and so on

but none of it is actually fundamentally hard,

it just requires time to push all of that forward.

[Steve]: Exactly. I'll pass onto anybody else.

[video team]: Actually, we're out of time.

[Colin]: OK, thank you all very much.

[applause]