9:59:59.000,9:59:59.000 Hi, I'm Colin Watson, this is a recruitment drive. 9:59:59.000,9:59:59.000 I'm glad to see quite so many people here, that's very useful. 9:59:59.000,9:59:59.000 [video team]: (inaudible) 9:59:59.000,9:59:59.000 [Colin]: There's a little bit of feedback? 9:59:59.000,9:59:59.000 Okay, is that any better? 9:59:59.000,9:59:59.000 [video team]: (inaudible) 9:59:59.000,9:59:59.000 [Colin]: Alright. 9:59:59.000,9:59:59.000 Somehow over the years I've found myself 9:59:59.000,9:59:59.000 as the de facto GRUB maintainer in debian 9:59:59.000,9:59:59.000 and I'm also a GRUB developer over the years 9:59:59.000,9:59:59.000 and I'm here to persuade you all that this is a fun thing to do 9:59:59.000,9:59:59.000 and that can you help, because I need more people 9:59:59.000,9:59:59.000 So yay 9:59:59.000,9:59:59.000 grub has moved on a long way from it's beginnings 9:59:59.000,9:59:59.000 It's called the GRAND UNIFIED BOOT LOADER 9:59:59.000,9:59:59.000 which is a bit of an aspirational name 9:59:59.000,9:59:59.000 and certainly was an aspirational name 9:59:59.000,9:59:59.000 back in 1995 and back then most us of just 9:59:59.000,9:59:59.000 used it over LILO which is the really traditional 9:59:59.000,9:59:59.000 x86 loader, because you didn't have to remember to reinstall 9:59:59.000,9:59:59.000 your bootloader when you installed a new kernel which was really 9:59:59.000,9:59:59.000 annoying, but even so quite a few debian developers have 9:59:59.000,9:59:59.000 hacked on grub over the years and nowadays it's a very powerful 9:59:59.000,9:59:59.000 bootloader, it's been ported to many architectures 9:59:59.000,9:59:59.000 it's actually quite rewarding to hack on 9:59:59.000,9:59:59.000 so I'll be giving you a tour of its history 9:59:59.000,9:59:59.000 and of its design and suggesting a some particular areas 9:59:59.000,9:59:59.000 where we could really do with help 9:59:59.000,9:59:59.000 Now the grub project; this is grub 1 9:59:59.000,9:59:59.000 it was originally just called grub and now 9:59:59.000,9:59:59.000 we call it grub legacy, but it was started in 1995 by Erich Boleyn, 9:59:59.000,9:59:59.000 he was initally trying to build something to boot GNU/Hurd 9:59:59.000,9:59:59.000 and among the loaders of the day it was quite unusual in that 9:59:59.000,9:59:59.000 you know, you could edit its menus on the fly and 9:59:59.000,9:59:59.000 that sort of thing. It had an emacs or bash style interface to that. 9:59:59.000,9:59:59.000 Other loaders usually just let you append kernel line options and that was 9:59:59.000,9:59:59.000 about all you got 9:59:59.000,9:59:59.000 and grub even then had a reasonably capable file system 9:59:59.000,9:59:59.000 interface as well 9:59:59.000,9:59:59.000 so it was by and large good enough, so many people adopted it as it was. 9:59:59.000,9:59:59.000 and of course it was originally designed for the Hurd 9:59:59.000,9:59:59.000 to start with so it started out with a focus on a new boot method 9:59:59.000,9:59:59.000 they designed which is called multiboot and the history file says 9:59:59.000,9:59:59.000 they were determined not to add to the large number of mutually 9:59:59.000,9:59:59.000 incompatible PC boot methods 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 Yes, well. 9:59:59.000,9:59:59.000 grub did soon become a little bit more generic 9:59:59.000,9:59:59.000 it supported the methods for booting linux and such 9:59:59.000,9:59:59.000 and I am being a bit unfair 9:59:59.000,9:59:59.000 multiboot has been genuinely useful to people doing academic experiments 9:59:59.000,9:59:59.000 with kernels written from scratch and custom payloads 9:59:59.000,9:59:59.000 because they don't have to do all of that work from scratch 9:59:59.000,9:59:59.000 anyway I won't cover multiboot further. 9:59:59.000,9:59:59.000 This is a rough layout of grub legacy back in the day 9:59:59.000,9:59:59.000 You had stage 1, this was a tiny thing that fitted 9:59:59.000,9:59:59.000 in the 512 byte master boot record. 9:59:59.000,9:59:59.000 It just knew how to read the first sector of the next 9:59:59.000,9:59:59.000 stage along, stage 1.5, from a fixed location, and jump to it. 9:59:59.000,9:59:59.000 That was all it could do, it was really stupid. 9:59:59.000,9:59:59.000 There was a seperate stage 1.5 for each separate file 9:59:59.000,9:59:59.000 system type that grub understood. 9:59:59.000,9:59:59.000 And that had enough file system code to 9:59:59.000,9:59:59.000 read stage 2 from an ordinary file system. 9:59:59.000,9:59:59.000 So it's the usual kind of bootstrap your way gradually up the stack. 9:59:59.000,9:59:59.000 The real meat of the loader lived in stage 2 and that included 9:59:59.000,9:59:59.000 all the command line commands, configuration file parsing 9:59:59.000,9:59:59.000 and the code to actually boot a payload, 9:59:59.000,9:59:59.000 like a Linux kernel image, 9:59:59.000,9:59:59.000 which is probably what you wanted to do with it. 9:59:59.000,9:59:59.000 So far, so good. 9:59:59.000,9:59:59.000 But there were quite a few problems with the design 9:59:59.000,9:59:59.000 as it was initially put together. 9:59:59.000,9:59:59.000 The file system abstraction was pretty ad-hoc. 9:59:59.000,9:59:59.000 It was achieved by building a seperate stage 1.5 blob 9:59:59.000,9:59:59.000 for each file system that grub knew about 9:59:59.000,9:59:59.000 and shipping that in the package. 9:59:59.000,9:59:59.000 The terminal abstraction was pretty reasonable aswell, 9:59:59.000,9:59:59.000 but other than that there wasn't much in the way of 9:59:59.000,9:59:59.000 internal expressive par(sing??) going on. 9:59:59.000,9:59:59.000 So it was very difficult to extend it safely. 9:59:59.000,9:59:59.000 It's hard to work out how grub legacy could ever 9:59:59.000,9:59:59.000 have been taught to handle LVM, for instance, 9:59:59.000,9:59:59.000 because you would then have to have a stage 1.5 that knew 9:59:59.000,9:59:59.000 about each of the file systems on LVM and so on. 9:59:59.000,9:59:59.000 You end up with a combinatorial explosion. 9:59:59.000,9:59:59.000 So it wasn't very elegant, from that point of view. 9:59:59.000,9:59:59.000 There were lots of PC BIOS assumptions aswell. 9:59:59.000,9:59:59.000 It may have been grand and unified, 9:59:59.000,9:59:59.000 but it wasn't particularly portable at that point. 9:59:59.000,9:59:59.000 Fedora did manage to get it to work with UEFI. 9:59:59.000,9:59:59.000 Actually, probably Red Hat then managed to get it 9:59:59.000,9:59:59.000 to work with UEFI, but it wasn't at all 9:59:59.000,9:59:59.000 a straight-forward exercise and it was very hacky. 9:59:59.000,9:59:59.000 So as time went on, upstream maintenance kind of 9:59:59.000,9:59:59.000 fell by the way side, it was such a pain to work 9:59:59.000,9:59:59.000 on and even though there wasn't really anything newer 9:59:59.000,9:59:59.000 that was usable, nobody wasn really interested in the 9:59:59.000,9:59:59.000 upstream so the distributions did what they had to do. 9:59:59.000,9:59:59.000 This meant we have ended up with grub legacy packages 9:59:59.000,9:59:59.000 in Debian and Ubuntu and Fedora and SUSE and all the rest, 9:59:59.000,9:59:59.000 that are actually completely different products. 9:59:59.000,9:59:59.000 I don't just mean have a different patch set, 9:59:59.000,9:59:59.000 in the usual way that you get, 9:59:59.000,9:59:59.000 they have completely different installation 9:59:59.000,9:59:59.000 and configuration tools that don't exist in 9:59:59.000,9:59:59.000 other multiple branches. 9:59:59.000,9:59:59.000 So today it's impossible if someone comes to us upstream, 9:59:59.000,9:59:59.000 to support grub 0.97, because it just isn't enough of a thing by itself. 9:59:59.000,9:59:59.000 You have to figure out what distribution people are using 9:59:59.000,9:59:59.000 and tell them what to do for that. 9:59:59.000,9:59:59.000 So we end up punting a lot of that to the distributions to support. 9:59:59.000,9:59:59.000 So there is a grub 2 rewrite, started in around 2002. 9:59:59.000,9:59:59.000 This is a very rough timeline of it, 9:59:59.000,9:59:59.000 as you can see it was a pretty long project, pretty slow project. 9:59:59.000,9:59:59.000 Yoshinori K. Okuji, I hope I pronounced his name correctly, 9:59:59.000,9:59:59.000 he was the lead grub maintainer at the time. 9:59:59.000,9:59:59.000 He started work on what he called: 9:59:59.000,9:59:59.000 "Preliminary Universal Programming Architecture for GNU Grub" 9:59:59.000,9:59:59.000 or 'PUPA'. 9:59:59.000,9:59:59.000 It's GNU so there is a bad pun in the acronym, 9:59:59.000,9:59:59.000 a pupa is the next stage along from a larva or grub in an insect's lifecycle. 9:59:59.000,9:59:59.000 I'd say it was roughly usable by about 2007, 9:59:59.000,9:59:59.000 so there was a long period when it was very experimental. 9:59:59.000,9:59:59.000 My pretty biased viewpoint is that distributions started 9:59:59.000,9:59:59.000 adopting it properly and started to present it to users in about 2009. 9:59:59.000,9:59:59.000 A snowball effect kind of kicked in from there 9:59:59.000,9:59:59.000 and it became much better quality quickly, 9:59:59.000,9:59:59.000 until we finally got 2.0 out in 2012. 9:59:59.000,9:59:59.000 So I also noted in here the point where the first 9:59:59.000,9:59:59.000 non-x86 architecture port showed up, that was the PowerPC port 9:59:59.000,9:59:59.000 for New World Macs, in 2004. 9:59:59.000,9:59:59.000 Because that's a very unusual milestone 9:59:59.000,9:59:59.000 in something as architecture specific as bootloaders have historically tended to be. 9:59:59.000,9:59:59.000 But right now if you look at some core bits of grub 2, 9:59:59.000,9:59:59.000 you can kind of see the echos of bits of grub legacy in there. 9:59:59.000,9:59:59.000 There are a few common lines of code 9:59:59.000,9:59:59.000 but it was a pretty sweeping rewrite and there isn't much left. 9:59:59.000,9:59:59.000 This was a very large project by most standards, 9:59:59.000,9:59:59.000 the lead maintainship has changed hands 3 or 4 times along the way, 9:59:59.000,9:59:59.000 it took a lot of forward thinking for people to get involved early on. 9:59:59.000,9:59:59.000 So the design that we have now, is around a small kernel 9:59:59.000,9:59:59.000 that offers core features like initialisation, 9:59:59.000,9:59:59.000 a virtual file system layer, a module loader 9:59:59.000,9:59:59.000 almost everything is in modules, sound familar? 9:59:59.000,9:59:59.000 there is an insmod command, 9:59:59.000,9:59:59.000 there is considerable inspiration taken from 9:59:59.000,9:59:59.000 full-fledged operating systems here. 9:59:59.000,9:59:59.000 You mostly don't have to worry about much of this by hand, 9:59:59.000,9:59:59.000 grub-install which is the main installation tool, 9:59:59.000,9:59:59.000 works out the bare minimum set of modules you need 9:59:59.000,9:59:59.000 to read everything else from /boot/grub, 9:59:59.000,9:59:59.000 and builds what we call a core image. 9:59:59.000,9:59:59.000 That's the rough equivalent of what stage 1.5 was in grub legacy, 9:59:59.000,9:59:59.000 but this time it's built dynamically, 9:59:59.000,9:59:59.000 rather than all being shipped statically in the package. 9:59:59.000,9:59:59.000 And also at runtime, the loader will load some modules into itself automatically. 9:59:59.000,9:59:59.000 So for example if you request a command name that isn't currently loaded, 9:59:59.000,9:59:59.000 it will go off and load it for you automatically. 9:59:59.000,9:59:59.000 This architecture makes it a lot easier to 9:59:59.000,9:59:59.000 construct images that fit into a constrained space, 9:59:59.000,9:59:59.000 in a much more flexible way. 9:59:59.000,9:59:59.000 We make very heavy use of abstraction layers, 9:59:59.000,9:59:59.000 it's rather like the way, not quite identical, 9:59:59.000,9:59:59.000 but rather like the way Unix-like systems 9:59:59.000,9:59:59.000 present block devices and file systems. 9:59:59.000,9:59:59.000 And those are general composable, 9:59:59.000,9:59:59.000 you can quite easily boot from XFS on LVM on RAID, whatever. 9:59:59.000,9:59:59.000 There's even the loopback module, so you can treat a file as 9:59:59.000,9:59:59.000 if it were a disk, much like we have in Linux. 9:59:59.000,9:59:59.000 This makes it quite easy to do strange things, 9:59:59.000,9:59:59.000 like you can embed an entire Debian installation 9:59:59.000,9:59:59.000 in a file on a Windows system, 9:59:59.000,9:59:59.000 which we actually did with Ubuntu for a while 9:59:59.000,9:59:59.000 and it's quite scary but it largely works. 9:59:59.000,9:59:59.000 This design also lets us easily build userspace 9:59:59.000,9:59:59.000 tools from very near to the same code, 9:59:59.000,9:59:59.000 which is very important and I'll come onto that later. 9:59:59.000,9:59:59.000 As you can see from the random stats at the bottom, 9:59:59.000,9:59:59.000 there's very little assembly in this, 9:59:59.000,9:59:59.000 it's almost all portable C. 9:59:59.000,9:59:59.000 Almost all of the C is common, 9:59:59.000,9:59:59.000 the assembly is of course a lot more architecture specific 9:59:59.000,9:59:59.000 but for a PC BIOS we are only talking about 9:59:59.000,9:59:59.000 about 4 and a half thousand lines, 9:59:59.000,9:59:59.000 which is considerable but not too much of a maintenance burden. 9:59:59.000,9:59:59.000 So here is a brief summary of what architectures we have now, 9:59:59.000,9:59:59.000 we have a number of x86 platforms, 9:59:59.000,9:59:59.000 the newest of those is that you can now use grub 9:59:59.000,9:59:59.000 under Xen paravirtualization, with a bit of effort. 9:59:59.000,9:59:59.000 The newest architectures are arm and arm64, 9:59:59.000,9:59:59.000 which were added last year. 9:59:59.000,9:59:59.000 In practice only some arm32 devices actually work with this, 9:59:59.000,9:59:59.000 because they require the platform's Uboot to be built with 9:59:59.000,9:59:59.000 the Uboot API so that it can act as enough of a firmware for grub. 9:59:59.000,9:59:59.000 A lot of them don't have that turned on, but it's at least a start. 9:59:59.000,9:59:59.000 I believe that, in theory, 9:59:59.000,9:59:59.000 all of jessie's release architectures other than s390 9:59:59.000,9:59:59.000 (no it's s390x now, isn't it?) 9:59:59.000,9:59:59.000 have at least some level of grub support. 9:59:59.000,9:59:59.000 Which is pretty awesome. 9:59:59.000,9:59:59.000 In grub legacy the hardest and one of the most 9:59:59.000,9:59:59.000 common problems we had to debug were problems 9:59:59.000,9:59:59.000 with reading files from disk in one way or another. 9:59:59.000,9:59:59.000 So people had problems loading the kernel and initrd 9:59:59.000,9:59:59.000 because their filesystem was in some strange shape. 9:59:59.000,9:59:59.000 If you wanted to debug this you were usually stuck with 9:59:59.000,9:59:59.000 trying to set up something that roughly matched in an emulator 9:59:59.000,9:59:59.000 and either using just crude printf debugging 9:59:59.000,9:59:59.000 or in extreme cases trying to attach gdb to the emulated machine over qemu. 9:59:59.000,9:59:59.000 Some people in the audience may be familar with this routine, 9:59:59.000,9:59:59.000 it's not very much fun, especially without a gdb stub. 9:59:59.000,9:59:59.000 So in grub 2, as I said earlier, 9:59:59.000,9:59:59.000 we have much of the same code built into utilities called grub-probe and grub-fstest 9:59:59.000,9:59:59.000 and these use the operating system's block device as a backend. 9:59:59.000,9:59:59.000 So you can ask grub to use its own partition table and file system tools 9:59:59.000,9:59:59.000 and parsing code from right there in userspace. 9:59:59.000,9:59:59.000 This makes it very much easier to attack lots of common problems; 9:59:59.000,9:59:59.000 you can use gdb, you can use valgrind, 9:59:59.000,9:59:59.000 you can use the debugging tools of your choice. 9:59:59.000,9:59:59.000 Tom ?? was asking me earlier about f2fs and putting that together in grub 2, 9:59:59.000,9:59:59.000 it can almost entirely be done in userspace so you can put together a new module, 9:59:59.000,9:59:59.000 built a version of grub-probe that's linked against it 9:59:59.000,9:59:59.000 and iterate until you get something that works, 9:59:59.000,9:59:59.000 rather than having to constantly reboot. 9:59:59.000,9:59:59.000 Even having to reboot an emulated machine is a lot of work. 9:59:59.000,9:59:59.000 So a similar trick also gave us this spin-off benefit of grub-mount, 9:59:59.000,9:59:59.000 that's a FUSE file system implementation that uses grub's filesystem code. 9:59:59.000,9:59:59.000 So that gives you a guaranteed true read-only mount, 9:59:59.000,9:59:59.000 using the exact same view that the bootloader 9:59:59.000,9:59:59.000 will have when it tries to look at your system. 9:59:59.000,9:59:59.000 This lets you avoid the caveats that apply to 9:59:59.000,9:59:59.000 things like journalling filesystems in Linux, 9:59:59.000,9:59:59.000 which it turns out you sometimes can't safely read-only mount. 9:59:59.000,9:59:59.000 Or sometimes the kernel will simply refuse 9:59:59.000,9:59:59.000 and it's also useful for things like os-prober. 9:59:59.000,9:59:59.000 If somebody felt the urge to make that work 9:59:59.000,9:59:59.000 as a Hurd translator it would be a pretty good fit too. 9:59:59.000,9:59:59.000 Now, you can't do everything in userspace, 9:59:59.000,9:59:59.000 at boot time grub gives you a pretty nice bash style interactive 9:59:59.000,9:59:59.000 shell with runtime controllable debugging levels. 9:59:59.000,9:59:59.000 Set the debug variable to various things and 9:59:59.000,9:59:59.000 that will give you different amounts of spew on your console. 9:59:59.000,9:59:59.000 So you can often try things out on the fly, 9:59:59.000,9:59:59.000 to figure out what's going wrong. 9:59:59.000,9:59:59.000 You can do quick, miniature image builds using the grub-mkrescue command, 9:59:59.000,9:59:59.000 that gives you an iso image containing the version of grub that you're using, 9:59:59.000,9:59:59.000 which you can then boot in an emulator to try out. 9:59:59.000,9:59:59.000 A useful trick is to boot your real live system with such an image 9:59:59.000,9:59:59.000 with 'qemu -snapshot' so that it won't write anything back 9:59:59.000,9:59:59.000 and then you see how the loader that you're working with will boot your laptop, 9:59:59.000,9:59:59.000 without actually risking the possibility of breaking anything. 9:59:59.000,9:59:59.000 It's easy to pull out bits of configuration files, 9:59:59.000,9:59:59.000 run them, write new commands. 9:59:59.000,9:59:59.000 There is a Hello World command that's about 30 lines, 9:59:59.000,9:59:59.000 so it's quite easy to put new things together. 9:59:59.000,9:59:59.000 Getting onto to things that are a little bit move involved and/or broken, 9:59:59.000,9:59:59.000 one of the things that was part of debian's grub legacy changes 9:59:59.000,9:59:59.000 was the Debian specific update-grub script. 9:59:59.000,9:59:59.000 Now this worked by trying to guess which parts of 9:59:59.000,9:59:59.000 /boot/grub/menu.lst were user modified, 9:59:59.000,9:59:59.000 by way of magic comments and updating everything 9:59:59.000,9:59:59.000 else to match the current state of the system. 9:59:59.000,9:59:59.000 This was sort of OK, but it caused a lot of complaints, 9:59:59.000,9:59:59.000 sometimes it was just because people didn't read the comment 9:59:59.000,9:59:59.000 text which said which parts of the file were safe to edit. 9:59:59.000,9:59:59.000 But generally, mixing user-editable 9:59:59.000,9:59:59.000 and automatically updated content in the same file 9:59:59.000,9:59:59.000 usually turns out to be a bad idea 9:59:59.000,9:59:59.000 and we've seen that in various other places in Debian. 9:59:59.000,9:59:59.000 So for grub 2, my predecessors brought this upstream as grub-mkconfig 9:59:59.000,9:59:59.000 and made it generate the whole configuration file from a 9:59:59.000,9:59:59.000 small amount of user edited configuration in /etc/default/grub 9:59:59.000,9:59:59.000 and a bunch of scripts in /etc/grub.d. 9:59:59.000,9:59:59.000 You can still of course write your own grub.cfg directly 9:59:59.000,9:59:59.000 if you like, it is about the same length as it would be in grub 1, 9:59:59.000,9:59:59.000 but for a general purpose system we would prefer the autogenerated approach. 9:59:59.000,9:59:59.000 So far, so good. 9:59:59.000,9:59:59.000 Just about everything is customisable, 9:59:59.000,9:59:59.000 the problem is that you have to try quite hard in several places. 9:59:59.000,9:59:59.000 Anything involved requires editing quite complex shell scripts, 9:59:59.000,9:59:59.000 if those are changed then later you'll 9:59:59.000,9:59:59.000 have quite a difficult merge resolution to do. 9:59:59.000,9:59:59.000 Some changes require things like moving conffiles 9:59:59.000,9:59:59.000 around to different positions in the order which isn't 9:59:59.000,9:59:59.000 going to be handled well by dpkg conffile resolution in the future. 9:59:59.000,9:59:59.000 So all of this probably needs somebody, sadly, 9:59:59.000,9:59:59.000 to sit down and design a third iteration of the system 9:59:59.000,9:59:59.000 that uses a templating language or something. 9:59:59.000,9:59:59.000 but that hasn't really been at all started yet. 9:59:59.000,9:59:59.000 Ok, now onto some things that are still genuinely quite hard. 9:59:59.000,9:59:59.000 The PC BIOS architecture has, well, 9:59:59.000,9:59:59.000 secreted over 30 or 40 years of gradual development. 9:59:59.000,9:59:59.000 It's basically pretty awful for modern purposes. 9:59:59.000,9:59:59.000 The usual partition table format is called MBR, 9:59:59.000,9:59:59.000 for Master Boot Record, or sometimes the msdos partition table. 9:59:59.000,9:59:59.000 It doesn't offer any formal space for keeping boot code in, 9:59:59.000,9:59:59.000 you can cram a trivial loader into 446 bytes, 9:59:59.000,9:59:59.000 that basically gives you the debian mbr package, 9:59:59.000,9:59:59.000 which jumps to a loader somewhere else. 9:59:59.000,9:59:59.000 There are a few approaches to where you can keep 9:59:59.000,9:59:59.000 the rest of, the real meat of, the loader. 9:59:59.000,9:59:59.000 You can embed in a file system somewhere, 9:59:59.000,9:59:59.000 at an offset that you know won't change. 9:59:59.000,9:59:59.000 For instance you put it in a file and trust that 9:59:59.000,9:59:59.000 the file system is not going to move that around. 9:59:59.000,9:59:59.000 Sadly sometimes file systems do move things around, 9:59:59.000,9:59:59.000 you might run fsck or there are some file systems 9:59:59.000,9:59:59.000 that will do their own, I think tail packing in reiserfs is one of these, 9:59:59.000,9:59:59.000 that will sometimes move blocks around for you 9:59:59.000,9:59:59.000 on the fly and that doesn't play very well with a 9:59:59.000,9:59:59.000 bootloader that has hardcoded addresses in the MBR. 9:59:59.000,9:59:59.000 A few file systems support an embedding area at the start, 9:59:59.000,9:59:59.000 I think btrfs does and one or two others, 9:59:59.000,9:59:59.000 this is good but not really widespread enough 9:59:59.000,9:59:59.000 that we can build the whole installation strategy around it. 9:59:59.000,9:59:59.000 You can do what grub generally does now, 9:59:59.000,9:59:59.000 you can skate the edge of the specification, 9:59:59.000,9:59:59.000 that sort of really doesn't exist anywhere coherent, 9:59:59.000,9:59:59.000 and you can use what's sometimes called the boot track 9:59:59.000,9:59:59.000 or other names, that's the unallocated space between the MBR and the first partition 9:59:59.000,9:59:59.000 and this makes some people itchy, it's a bit nasty. 9:59:59.000,9:59:59.000 It means we have to do some alarming things to avoid conflicts 9:59:59.000,9:59:59.000 with other software that put things in the boot track. 9:59:59.000,9:59:59.000 Fortunately almost all of that software is evil. 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 There are a few bits of Windows software, 9:59:59.000,9:59:59.000 well some of them are backup utilities which I'm not sure 9:59:59.000,9:59:59.000 why they put things there, but they probably have a reason. 9:59:59.000,9:59:59.000 There are a few things on Windows that like to put a note in a 9:59:59.000,9:59:59.000 sector in the boot track to say that they have been installed, 9:59:59.000,9:59:59.000 so that you cannot simply uninstall them to work around their 30 day license trial terms, 9:59:59.000,9:59:59.000 you need to know to wipe that bit of the boot track aswell. 9:59:59.000,9:59:59.000 And that's all terribly nasty. 9:59:59.000,9:59:59.000 Grub actually now has error correction on some of it's own code in the core image. 9:59:59.000,9:59:59.000 Grub can literally cope with a couple of sectors of the 9:59:59.000,9:59:59.000 core image being overwritten with completely random data. 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 It's horrifying that we need this, but yes that surprisingly works. 9:59:59.000,9:59:59.000 Fortunately this is becoming less of a problem, 9:59:59.000,9:59:59.000 the alignment requirements on modern disks mean that for decent peformance 9:59:59.000,9:59:59.000 you want to have your first partition start at 1 megabyte or sometimes even more, 9:59:59.000,9:59:59.000 rather than the traditional 63 sectors. 9:59:59.000,9:59:59.000 So we usually now have plenty of space on MBR, 9:59:59.000,9:59:59.000 but not quite always. 9:59:59.000,9:59:59.000 Things are also unpredictable when you have multiple disks, 9:59:59.000,9:59:59.000 you can't tell from Linux which disk the system was actually booted from. 9:59:59.000,9:59:59.000 There are some things on some BIOS versions that let you make better guesses, 9:59:59.000,9:59:59.000 but it's unfortunately not universal. 9:59:59.000,9:59:59.000 You also can't tell what disk it's going to be booted from next time, 9:59:59.000,9:59:59.000 it's not necessarily the same. 9:59:59.000,9:59:59.000 Sometimes it depends on which order the devices are enumerated 9:59:59.000,9:59:59.000 by the PCI bus, even on the BIOS level. 9:59:59.000,9:59:59.000 The least bad answer is usually to install to all of the fixed disks on your system, 9:59:59.000,9:59:59.000 but then you annoy some people who have complicated multiboot setups, 9:59:59.000,9:59:59.000 so you can't really win. 9:59:59.000,9:59:59.000 The GUID Partition Table format, or GPT, is much better. 9:59:59.000,9:59:59.000 It's probably the best thing to have come out of the UEFI spec. 9:59:59.000,9:59:59.000 [knocks down debconf sign] 9:59:59.000,9:59:59.000 Excuse me, let me not do that. Right, I'll not do that again. 9:59:59.000,9:59:59.000 This gives you allocated space for 9:59:59.000,9:59:59.000 the bootloader code in the UEFI system partition, 9:59:59.000,9:59:59.000 in a partition type that we were able to safely allocate for 9:59:59.000,9:59:59.000 ourselves because now partition types are a GUID, they are ginormous. 9:59:59.000,9:59:59.000 We were able to allocate one for ourselves, 9:59:59.000,9:59:59.000 even when using that on top of BIOS, which you can do. 9:59:59.000,9:59:59.000 There are different intepretations of the spec, 9:59:59.000,9:59:59.000 unfortunately this causes some problems. 9:59:59.000,9:59:59.000 When you install a system with GPT, 9:59:59.000,9:59:59.000 you're supposed to put what's called a protective MBR in place, 9:59:59.000,9:59:59.000 that means that anything that trys to parse the disk as MBR 9:59:59.000,9:59:59.000 knows that it should stay away 9:59:59.000,9:59:59.000 and not try to scribble over the partition table. 9:59:59.000,9:59:59.000 The intepretation of that part of the spec is particularly bad. 9:59:59.000,9:59:59.000 Apple, at least, used to have a completely incompatible boths ways version, 9:59:59.000,9:59:59.000 you were required instead of a single giant partition to do the best job of 9:59:59.000,9:59:59.000 representing the GPT partitions in MBR. 9:59:59.000,9:59:59.000 That's incompatible both ways, I don't know if that's still the case. 9:59:59.000,9:59:59.000 If you're trying to use GPT on BIOS, 9:59:59.000,9:59:59.000 some PC class systems require you to set 9:59:59.000,9:59:59.000 the active flag on the protective MBR, 9:59:59.000,9:59:59.000 which the GPT spec explicitly forbids for some reason. 9:59:59.000,9:59:59.000 So you're stuck both ways round. 9:59:59.000,9:59:59.000 UEFI is where it's at for PC firmware, apparently. 9:59:59.000,9:59:59.000 Even if your new machine looks like it's BIOS, 9:59:59.000,9:59:59.000 it's almost certainly a legacy layer 9:59:59.000,9:59:59.000 implemented internally on top of UEFI. 9:59:59.000,9:59:59.000 The economics for firmware manufacturers 9:59:59.000,9:59:59.000 are much more favourable this way. 9:59:59.000,9:59:59.000 Instead of having to maintain their own, 9:59:59.000,9:59:59.000 I don't know however many thousand lines of code base that have accreted over the years, 9:59:59.000,9:59:59.000 they can now fork Intel's TianoCore as their starting point 9:59:59.000,9:59:59.000 and just do their driver layer on top of that. 9:59:59.000,9:59:59.000 And this seems to have attracted essentially all of the BIOS manufacturers. 9:59:59.000,9:59:59.000 We should generally expect even that legacy BIOS layer 9:59:59.000,9:59:59.000 to go away soon, the direction that we hear from firmware people is all about that 9:59:59.000,9:59:59.000 and we need to cope with that. 9:59:59.000,9:59:59.000 Now, grub's core support for UEFI is basically fine, 9:59:59.000,9:59:59.000 it has more or less the set of drivers you'd expect 9:59:59.000,9:59:59.000 including relatively arcane things like serial support. 9:59:59.000,9:59:59.000 Of course the big thing that's been recently 9:59:59.000,9:59:59.000 is something called "Secure Boot", 9:59:59.000,9:59:59.000 that's a mechanism by which firmware makes sure to 9:59:59.000,9:59:59.000 only ever execute signed code, in a pre-boot context. 9:59:59.000,9:59:59.000 It's obviously very possible for this to go very wrong, 9:59:59.000,9:59:59.000 from the point of view of user freedom. 9:59:59.000,9:59:59.000 The FSF calls Secure Boot, "Restricted Boot" for that reason. 9:59:59.000,9:59:59.000 But a lot of systems now come with Secure Boot enabled by default, 9:59:59.000,9:59:59.000 so we have to figure out how to work with it 9:59:59.000,9:59:59.000 in the same way that we've had to figure out 9:59:59.000,9:59:59.000 how to work with all kinds of devices over the years, 9:59:59.000,9:59:59.000 just as a hardware enablement matter. 9:59:59.000,9:59:59.000 But the important thing is to work out how to that 9:59:59.000,9:59:59.000 in ways that don't end up impinging on our user's freedom. 9:59:59.000,9:59:59.000 and that's been quite a difficult slog. 9:59:59.000,9:59:59.000 The community has managed to figure out schemes for this 9:59:59.000,9:59:59.000 that don't stop you modifying the operating system on your own computer, 9:59:59.000,9:59:59.000 which is the important thing. 9:59:59.000,9:59:59.000 We have this working on Ubuntu, 9:59:59.000,9:59:59.000 we talked about this at DebConf last year. 9:59:59.000,9:59:59.000 To get it working in Debian we need dak to sign 9:59:59.000,9:59:59.000 bootloader objects that we submit to it, with the Debian key. 9:59:59.000,9:59:59.000 I failed with pushing that forward so that 9:59:59.000,9:59:59.000 would be a great project for somebody to take up, 9:59:59.000,9:59:59.000 if I've missed it and somebody else is already working on that, brilliant! 9:59:59.000,9:59:59.000 I should also mention that there are some outstanding 9:59:59.000,9:59:59.000 issues with the layout of the EFI System Partition, 9:59:59.000,9:59:59.000 which is UEFI's place for putting things like bootloader code. 9:59:59.000,9:59:59.000 The spec proscribes how you're supposed to behave 9:59:59.000,9:59:59.000 on fixed disk versus removable disks, 9:59:59.000,9:59:59.000 we follow the spec but unfortunately some systems don't 9:59:59.000,9:59:59.000 and essentially require the removable layout. 9:59:59.000,9:59:59.000 Steve McIntyre's here at the back, 9:59:59.000,9:59:59.000 we've gone back and forth a bit on that. 9:59:59.000,9:59:59.000 We need some way to select the removable layout 9:59:59.000,9:59:59.000 and have that actually persist and ideally detect 9:59:59.000,9:59:59.000 that this is a problem in the first place, 9:59:59.000,9:59:59.000 so that we don't have to ask an incomprehensible question in the installer. 9:59:59.000,9:59:59.000 Now, more cheerily, a number of non-x86 architectures are in a pretty good state. 9:59:59.000,9:59:59.000 they get fairly limited testing at the moment. 9:59:59.000,9:59:59.000 I know that some people use them because occasionally 9:59:59.000,9:59:59.000 I get some bugs when things break but generally they work OK. 9:59:59.000,9:59:59.000 powerpc and sparc work fine, we sould probably consider 9:59:59.000,9:59:59.000 switching the default bootloader there at some point. 9:59:59.000,9:59:59.000 If you're a porter for those architectures, 9:59:59.000,9:59:59.000 please get in touch with me. 9:59:59.000,9:59:59.000 Some mips-type architectures would well too. 9:59:59.000,9:59:59.000 Ryan ?? lent me a Yeeloong laptop a little while back, 9:59:59.000,9:59:59.000 so that I could port the debian installer to it 9:59:59.000,9:59:59.000 and I found that grub was basically fine. 9:59:59.000,9:59:59.000 So I was able to build the installer on top of that. 9:59:59.000,9:59:59.000 It was a tenth of the work it might otherwise have been. 9:59:59.000,9:59:59.000 There's been a pretty pleasing trend towards having 9:59:59.000,9:59:59.000 new arches include a grub port very early on. 9:59:59.000,9:59:59.000 arm64, also powerpc64, has had grub working from very early in it's life. 9:59:59.000,9:59:59.000 This gives them a pretty full-feature loader 9:59:59.000,9:59:59.000 with not a lot of effort, so it actually 9:59:59.000,9:59:59.000 works out quite well for the ports now, I think. 9:59:59.000,9:59:59.000 The most recent arm64 port, I went back and looked at it, 9:59:59.000,9:59:59.000 it was about 2000 lines of patches to do the initial enablement. 9:59:59.000,9:59:59.000 And now that got to take the advantage of the arm port 9:59:59.000,9:59:59.000 that already existed and also of UEFI code, 9:59:59.000,9:59:59.000 so that helps a lot but still I think it 9:59:59.000,9:59:59.000 indicates a pretty porting friendly design. 9:59:59.000,9:59:59.000 OK, so if I haven't persuaded you already, 9:59:59.000,9:59:59.000 why do we default to grub on debian x86? 9:59:59.000,9:59:59.000 There are certainly other loaders, 9:59:59.000,9:59:59.000 there's the venerable LILO, which still largely works fine. 9:59:59.000,9:59:59.000 Syslinux and friends are actively maintained by some very smart people, 9:59:59.000,9:59:59.000 including folks who maintain the Linux boot protocol 9:59:59.000,9:59:59.000 and there's extlinux which is one of that family 9:59:59.000,9:59:59.000 which you can use in the same kind of way that you might use LILO. 9:59:59.000,9:59:59.000 There's yaboot and powerpc and so on and so forth. 9:59:59.000,9:59:59.000 You can even boot a kernel and an initramfs directly 9:59:59.000,9:59:59.000 from the UEFI environment, if you want to. 9:59:59.000,9:59:59.000 So some of those are some pretty good bootloaders, 9:59:59.000,9:59:59.000 they're almost all smaller and simpler than grub 9:59:59.000,9:59:59.000 and that appeals to a lot of people. 9:59:59.000,9:59:59.000 I do get the simplicity argument. 9:59:59.000,9:59:59.000 But I tend to argue that the result of that 9:59:59.000,9:59:59.000 is moving a good deal of complexity elsewhere. 9:59:59.000,9:59:59.000 If you have a bootloader that can only handle some setups, 9:59:59.000,9:59:59.000 the installer needs to know what those setups are. 9:59:59.000,9:59:59.000 It needs to forbid you from doing anything, that you won't be 9:59:59.000,9:59:59.000 able to boot, in your partitioner. 9:59:59.000,9:59:59.000 You end up with static /boot partitions scattered everywhere. 9:59:59.000,9:59:59.000 Having a bootloader that you can trust to handle almost anything 9:59:59.000,9:59:59.000 means that you don't have to think too hard when you are moving things around. 9:59:59.000,9:59:59.000 You can easily do things like having the bootloader notice 9:59:59.000,9:59:59.000 when the last boot failed and behave differently. 9:59:59.000,9:59:59.000 All that sort of thing is useful for a general purpose distro to be able to assume. 9:59:59.000,9:59:59.000 [Ben]: We used to support some bootloaders on mips, 9:59:59.000,9:59:59.000 but they couldn't load an initramfs, they could only load a kernel. 9:59:59.000,9:59:59.000 So for that reason the kernel configurations we used on mips 9:59:59.000,9:59:59.000 had to be restricted, they don't assume there is an initramfs 9:59:59.000,9:59:59.000 and you can't boot off filesystems other than ext2, 3 and 4. 9:59:59.000,9:59:59.000 [Colin]: That's CoLo, is it? Or cibyl? 9:59:59.000,9:59:59.000 [Ben]: I don't know. We have recently switched over, 9:59:59.000,9:59:59.000 but that has been a restriction up to and including wheezy. 9:59:59.000,9:59:59.000 [Colin]: Thanks. That's useful ammunition. [laughs] 9:59:59.000,9:59:59.000 I think that we do not yet have grub working on 9:59:59.000,9:59:59.000 all of the mips big endian architectures, 9:59:59.000,9:59:59.000 it's working on little endian, 9:59:59.000,9:59:59.000 but I think there are still some problems with big endian. 9:59:59.000,9:59:59.000 So we maybe can't save the world just yet, 9:59:59.000,9:59:59.000 but it might not be too far off. But thanks. 9:59:59.000,9:59:59.000 Plus Debian runs on lots of architectures, 9:59:59.000,9:59:59.000 generally we try as an architectural thing 9:59:59.000,9:59:59.000 to run the same software across different architectures so 9:59:59.000,9:59:59.000 that it all works kind of the same way. 9:59:59.000,9:59:59.000 We have the same interfaces, the same tools are available and so on. 9:59:59.000,9:59:59.000 And it makes a lot of sense to have that be the case with the bootloader too. 9:59:59.000,9:59:59.000 The installer would certainly be simplified by being able to 9:59:59.000,9:59:59.000 assume grub-mount is available on all architectures, for instance. 9:59:59.000,9:59:59.000 OK, so the important bit, this. 9:59:59.000,9:59:59.000 We've had a lot of people involved over the years 9:59:59.000,9:59:59.000 Too many to name, I've almost certainly missed some 9:59:59.000,9:59:59.000 Robert Millan, Felix Zielcke and Jordi Mallach 9:59:59.000,9:59:59.000 have done excellent jobs in Debian a few years ago. 9:59:59.000,9:59:59.000 And Vladimir Serbinenko does an excellent job as the upstream maintainer. 9:59:59.000,9:59:59.000 But as far as Debian maintenance goes, 9:59:59.000,9:59:59.000 it's mostly just me at the moment and has been 9:59:59.000,9:59:59.000 for the last couple of years and I can't do it all. 9:59:59.000,9:59:59.000 We'd probably have had grub 2 in 2.00 9:59:59.000,9:59:59.000 rather than 1.99 in wheezy, 9:59:59.000,9:59:59.000 if we had a bit more redundancy there. 9:59:59.000,9:59:59.000 I was kind of demotivated by the Secure Boot stuff at the time, 9:59:59.000,9:59:59.000 so ended up putting it off until too late 9:59:59.000,9:59:59.000 and that's exactly the kind of thing 9:59:59.000,9:59:59.000 where having more people involved is more helpful 9:59:59.000,9:59:59.000 there are lots of bugs, everybody's problem is critical for them, 9:59:59.000,9:59:59.000 quite understandably. 9:59:59.000,9:59:59.000 So keeping on top of the release critical list is absolute murder. 9:59:59.000,9:59:59.000 But there are a few specific problems I'd like to highlight, 9:59:59.000,9:59:59.000 that are more substantial and could really do with 9:59:59.000,9:59:59.000 somebody sitting down and thinking quite hard. 9:59:59.000,9:59:59.000 I won't go into too much detail, 9:59:59.000,9:59:59.000 as I've just had a sign from the video team that I'm low on time. 9:59:59.000,9:59:59.000 But you can ask me about any of them if you're interested. 9:59:59.000,9:59:59.000 I mentioned earlier that the system for generating 9:59:59.000,9:59:59.000 the config file has a bad case of second system effect 9:59:59.000,9:59:59.000 and really needs a third system 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 to make it easier to customise things. 9:59:59.000,9:59:59.000 All problems can be solved by another rewrite, right? 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 On MBR systems, we often have robustness problems 9:59:59.000,9:59:59.000 with grub not installing the boot code to the place 9:59:59.000,9:59:59.000 that your system actually boots from, 9:59:59.000,9:59:59.000 particularly when multiple disks are involved. 9:59:59.000,9:59:59.000 This tends to manifest as module loading failures 9:59:59.000,9:59:59.000 because what happens is, over time 9:59:59.000,9:59:59.000 the core image that you're actually using 9:59:59.000,9:59:59.000 that you didn't know about, becomes incompatible with new grub modules 9:59:59.000,9:59:59.000 because the ABI changes over time 9:59:59.000,9:59:59.000 and eventually becomes incompatible and can't boot anything 9:59:59.000,9:59:59.000 I think that needs some kind of overhaul somewhere, 9:59:59.000,9:59:59.000 though I'm not quite sure where. 9:59:59.000,9:59:59.000 There are the remaining bit of UEFI, 9:59:59.000,9:59:59.000 which I mentioned earlier. 9:59:59.000,9:59:59.000 There's getting signing sorted out in Debian, 9:59:59.000,9:59:59.000 getting a thing called MokManager, 9:59:59.000,9:59:59.000 which is part of a seperate project called shim, 9:59:59.000,9:59:59.000 nicely integrated to give users control over the whole signing process 9:59:59.000,9:59:59.000 which will let us require signed kernels under Secure Boot 9:59:59.000,9:59:59.000 and thus make Matthew Garrett want to kill me a little bit less 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 and there's the issues with EFI System Partition layout 9:59:59.000,9:59:59.000 There's some work to be done with upstream Xen 9:59:59.000,9:59:59.000 to layout effectively a new boot protocol for PV Grub 2 9:59:59.000,9:59:59.000 so we can have Xen guests install the bootloader 9:59:59.000,9:59:59.000 in a consistent place in the file system. 9:59:59.000,9:59:59.000 In fact, Ian Campbell recently sent me something that 9:59:59.000,9:59:59.000 might be useful for this, I didn't have time to read it. 9:59:59.000,9:59:59.000 and hopefully this will eventually let us kill off all 9:59:59.000,9:59:59.000 of the old strange things that live in Xen, to do this. 9:59:59.000,9:59:59.000 Finally, we should take much better advantage of grub's ports 9:59:59.000,9:59:59.000 and switch over to them on many more architectures than we have done to date. 9:59:59.000,9:59:59.000 I've just got onto questions, so excellent. 9:59:59.000,9:59:59.000 [Ian]: One of things I've found difficult getting to grips with grub 1 9:59:59.000,9:59:59.000 and grub 2 is that the documentation hasn't always been as good. 9:59:59.000,9:59:59.000 LILO has always been exceptional in that it came with 9:59:59.000,9:59:59.000 an extremely good document that described 9:59:59.000,9:59:59.000 its principles of operation and how to get it to do, 9:59:59.000,9:59:59.000 well, almost anything you might want it to. 9:59:59.000,9:59:59.000 Is that also something you're looking for help with? 9:59:59.000,9:59:59.000 [Colin]: Yes. 9:59:59.000,9:59:59.000 About a year or two ago, 9:59:59.000,9:59:59.000 I went through and tried to systematically documenting 9:59:59.000,9:59:59.000 all of the grub commands and overhauling some other things. 9:59:59.000,9:59:59.000 I got about half way through that, 9:59:59.000,9:59:59.000 before I ran out of time. 9:59:59.000,9:59:59.000 but one of the problems has been with grub 2 9:59:59.000,9:59:59.000 that the documentation got out of date during the rewrite 9:59:59.000,9:59:59.000 so nobody has an incentive to do it properly for their incremental changes. 9:59:59.000,9:59:59.000 So I think getting that into shape 9:59:59.000,9:59:59.000 would make it much easier to keep it in shape 9:59:59.000,9:59:59.000 It's better than it was in 2010, it's not where it should be. 9:59:59.000,9:59:59.000 So, yes. 9:59:59.000,9:59:59.000 Anybody else, anything from irc aswell? 9:59:59.000,9:59:59.000 [John]: This was a related question to your comment earlier 9:59:59.000,9:59:59.000 about how BIOSes are widely inconsistent about 9:59:59.000,9:59:59.000 how they choose which disk they're going to boot from. 9:59:59.000,9:59:59.000 Is there anything that grub could do to help us 9:59:59.000,9:59:59.000 with best practices for failover configurations? 9:59:59.000,9:59:59.000 So for example, let's say I have a server 9:59:59.000,9:59:59.000 and I want to install two disk that are mirrored, 9:59:59.000,9:59:59.000 using lvm or something else. 9:59:59.000,9:59:59.000 One of the challenges is, how do I configure grub 9:59:59.000,9:59:59.000 on both disk to be configured the right 9:59:59.000,9:59:59.000 way, despite all of the weirdness with BIOSes? 9:59:59.000,9:59:59.000 To have a reasonable easy to maintain setup, 9:59:59.000,9:59:59.000 so that where if one disk actually goes completely offline, 9:59:59.000,9:59:59.000 the system could automatically reboot. 9:59:59.000,9:59:59.000 [Colin]: One of the things I tried to do, 9:59:59.000,9:59:59.000 the first time I systematically 9:59:59.000,9:59:59.000 attacked this in Debian grub, 9:59:59.000,9:59:59.000 the thing I tried to do was to arrange that we 9:59:59.000,9:59:59.000 did as by-uuid install to disks, possibly as by-path, I forget. 9:59:59.000,9:59:59.000 So we encourage people to install to all of the disks on a system. 9:59:59.000,9:59:59.000 Also the grub-pc.postinst notices when a disk has gone away since it last checked, 9:59:59.000,9:59:59.000 and it's supposed to offer you the chance to update this. 9:59:59.000,9:59:59.000 But you're right it's a little bit fiddly to manage 9:59:59.000,9:59:59.000 particularly if you're in a system that's large enough 9:59:59.000,9:59:59.000 so that statistically disks are failing quite often 9:59:59.000,9:59:59.000 Then it's a problem. 9:59:59.000,9:59:59.000 I think what I'd probably like to do is to make sure that 9:59:59.000,9:59:59.000 we install to the disks that are associated with a RAID device or something 9:59:59.000,9:59:59.000 so you could just bootstrap off the RAID management. 9:59:59.000,9:59:59.000 I think some of that works but isn't hooked up very well in Debian. 9:59:59.000,9:59:59.000 But there are several things to do there. 9:59:59.000,9:59:59.000 I think there's also a bug in d-i where it doesn't install 9:59:59.000,9:59:59.000 to all of the fixed disks in your system but only one. 9:59:59.000,9:59:59.000 So there are several things to fix there. 9:59:59.000,9:59:59.000 There's a question over there. 9:59:59.000,9:59:59.000 [??]: I think my question could be summed up as: 9:59:59.000,9:59:59.000 "How tall do you have to be to ride this ride?" 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 It seems like getting started, 9:59:59.000,9:59:59.000 introducing regressions would be a really scary thing. 9:59:59.000,9:59:59.000 For someone who wanted to get started with the project 9:59:59.000,9:59:59.000 and I'm just wondering what kind of facilities do you have 9:59:59.000,9:59:59.000 for before we actually upload a version to 9:59:59.000,9:59:59.000 test across the broad range of architectures. 9:59:59.000,9:59:59.000 [Colin]: Right well, one of the points of this talk 9:59:59.000,9:59:59.000 was to try to emphasise that you don't actually have 9:59:59.000,9:59:59.000 to be as tall as people think you do. 9:59:59.000,9:59:59.000 But you're right about the need for regression testing. 9:59:59.000,9:59:59.000 One thing that really helps is that the different parts 9:59:59.000,9:59:59.000 of grub are much more isolated than they used to be. 9:59:59.000,9:59:59.000 So you can quite easily change one module, 9:59:59.000,9:59:59.000 test changes with that, without having to worry about 9:59:59.000,9:59:59.000 strange leakage all over the place. 9:59:59.000,9:59:59.000 But there are things that that doesn't cover, 9:59:59.000,9:59:59.000 there is some boot testing arrangement in the build system, 9:59:59.000,9:59:59.000 so there are some make targets that go off 9:59:59.000,9:59:59.000 and do boot checks of real systems against the current version of the code. 9:59:59.000,9:59:59.000 And that sort of thing helps a lot, 9:59:59.000,9:59:59.000 I would like to have grub hooked up better to some sort of autopkgtest arrangement 9:59:59.000,9:59:59.000 so that it does emulated boots across various types 9:59:59.000,9:59:59.000 of systems on ci.debian.net, I'd love help with that. 9:59:59.000,9:59:59.000 [Steve]: Now of course UEFI, there's a whole slew of things. Tom was asking 9:59:59.000,9:59:59.000 about MBR and a reliable fallback, of course. I'm not aware of any UEFI 9:59:59.000,9:59:59.000 implementation that actually does fallback for the system partition either. 9:59:59.000,9:59:59.000 So that is an utter trainwreck. 9:59:59.000,9:59:59.000 [Colin]: I suspect what you're, 9:59:59.000,9:59:59.000 maybe you're meant to use hardware RAID or something? 9:59:59.000,9:59:59.000 [Steve]: Clearly that's what you're expected to use and it's a mess. 9:59:59.000,9:59:59.000 We should definitely get together 9:59:59.000,9:59:59.000 and talk about the removable media path. 9:59:59.000,9:59:59.000 Again there isn't a good answer but let's try 9:59:59.000,9:59:59.000 and make it as not crap as we can. 9:59:59.000,9:59:59.000 [Colin]: Do you know of any way to detect that 9:59:59.000,9:59:59.000 system even if it's something like a blacklist of broken DMI decoders? 9:59:59.000,9:59:59.000 [Steve]: I think that's all we can do. 9:59:59.000,9:59:59.000 We had a system, as an example 9:59:59.000,9:59:59.000 for the people that may not have come across this, 9:59:59.000,9:59:59.000 there are firmware implementiatons out there 9:59:59.000,9:59:59.000 that straight after install may not actually recognise 9:59:59.000,9:59:59.000 that you've put grub into the path where you're meant to put it. 9:59:59.000,9:59:59.000 Once you've booted off a rescue system, however, 9:59:59.000,9:59:59.000 and done some not particularly well understood sequence of things, 9:59:59.000,9:59:59.000 including boot off a removable media path, reboot a couple more times 9:59:59.000,9:59:59.000 shuffle things around, spin twice clockwise... 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 suddenly they then will recognise that you've put grub there. 9:59:59.000,9:59:59.000 But god forbid, you ever want to update it again. 9:59:59.000,9:59:59.000 It's painful. 9:59:59.000,9:59:59.000 [Colin]: There are some exciting problems on Apple Macs, 9:59:59.000,9:59:59.000 that are a shadow of the same class of problem. 9:59:59.000,9:59:59.000 [Steve]: And of course Secure Boot, 9:59:59.000,9:59:59.000 kibi asked Steven about this a few days ago. 9:59:59.000,9:59:59.000 Of course, we've been talking about this for like 2 years. 9:59:59.000,9:59:59.000 I feel rubbish as well, that we haven't really got any further with it. 9:59:59.000,9:59:59.000 If someone really really wants to help get involved with that, oh absolutely, 9:59:59.000,9:59:59.000 there's a whole load of people who would love to see you help. 9:59:59.000,9:59:59.000 [Colin]: Not only are there are a whole load of people who would like to see you help, 9:59:59.000,9:59:59.000 but there's actually roughly a roadmap of what needs to be done. 9:59:59.000,9:59:59.000 You don't have to blaze a trail. 9:59:59.000,9:59:59.000 [??]: Scrape the names off the roadmap and put your name on it. 9:59:59.000,9:59:59.000 [laughter] 9:59:59.000,9:59:59.000 [Colin]: It's fine, we don't really care, we just want to see it done! 9:59:59.000,9:59:59.000 The things that need to be done are, as I say, 9:59:59.000,9:59:59.000 the next step I think is in dak and then 9:59:59.000,9:59:59.000 somebody needs to chase up getting shim into debian 9:59:59.000,9:59:59.000 with the right kind of signatures on it and so on 9:59:59.000,9:59:59.000 but none of it is actually fundamentally hard, 9:59:59.000,9:59:59.000 it just requires time to push all of that forward. 9:59:59.000,9:59:59.000 [Steve]: Exactly. I'll pass onto anybody else. 9:59:59.000,9:59:59.000 [video team]: Actually, we're out of time. 9:59:59.000,9:59:59.000 [Colin]: OK, thank you all very much. 9:59:59.000,9:59:59.000 [applause] 9:59:59.000,9:59:59.000