Sunday, 11 January 2015
Time for another update on my work for UEFI improvements in Jessie!
I've spent more time on the integration of 32-bit grub-efi with a 64-bit Debian system, and just published a new test image on pettersson. I've added:
These remove the manual steps that were necessary for a 64-bit installation with the previous build. I've just used this exact image (and a network mirror) to install a fully-functional 64-bit Gnome system on the X205TA, simply by selecting "64-bit install" from the GRUB menu and following prompts. Yay! Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload3/ to download and test the image.
Now, there's no guarantee that the kernel patch I've submitted to the linux-efi folks will be accepted in its current form, and even if it is I'll have to get it and the other code I've written accepted into the various packages and then into Jessie! But for now this image should work just fine for Bay Trail folks I hope!
WARNING: this CD is provided for testing only. Use at your own risk! If you have appropriate (U)EFI hardware, please try this image and let me know how you get on, via the debian-cd and debian-boot mailing lists.
For now, I'm going to pause development here. The core code I'm using to make these images is all in the debian-cd and d-i repos, and I'll push the other patches once I know they'll work with the kernel. But I've got a slew of other things that I need to work on in the next few weeks, in no particular order:
I'm currently not planning to make all of Debian's amd64 images bootable using 32-bit UEFI like this image - I'm happy to leave this as just an option for our multi-arch i386/amd64 images (netinst or DVD only). I think that's a reasonable compromise here, and it's also the easiest thing for me to do with the current debian-cd build system.
Finally, apologies if you've asked me questions about the earlier images in this series and I've not responded yet. Fixing that ASAP!Tuesday, 06 January 2015
I promised to write about this a long time, ooops... :-)
Another ARM port in Debian - yay!
arm64 is officially a release architecture for Jessie, aka Debian version 8. That's taken a lot of manual porting and development effort over the last couple of years, and it's also taken a lot of CPU time - there are ~21,000 source packages in Debian Jessie! As is often the case for a brand new architecture like arm64 (or AArch64, to use ARM's own terminology), hardware can be really difficult to get hold of. In time this will cease to be an issue as hardware becomes more commoditised, but in Debian we really struggled to get hold of equipment for a very long time during the early part of the port.
First bring-up in Debian Ports
To start with, we could use ARM's own AArch64 software models to build the first few packages. This worked, but only very slowly. Then Chen Baozi and the folks running the Tianhe-2 supercomputer project in Guangzhou, China contacted us to offer access to some arm64 hardware, and this is what Wookey used for bootstrapping the new port in the unofficial Debian Ports archive. This has now become the normal way for new architectures to get into Debian. We got most of the archive built in debian-ports this way, and we could then use those results to seed the initial core set of packages in the main Debian archive.
Second bring-up - moving into the main Debian archive
By the time that first Debian bring-up was done, ARM was starting to produce its own "Juno" development boards, and with the help of my boss^4 James McNiven we managed to acquire a couple of those machines for use as official Debian build machines. The existing machines in China were faster, but for various reasons quite difficult to maintain as official Debian machines. So I set up the Junos as buildds just before going to DebConf in August 2014. They ran very well, and (for dev boards!) were very fast and stable. They built a large chunk of the Debian archive, but as the release freeze for Jessie grew close we weren't quite there. There was a small but persistent backlog of un-built packages that were causing us issues, plus the Juno machines are/were not quite suitable as porter boxes for Debian developers all over the world to use for debugging their packages on the new architecture.
More horsepower - Linaro machines
This is where Linaro came to our aid. Linaro's goal is to help improve Free and Open Source Software on ARM, and one of the more recent projects in Linaro is a cluster of servers that are made available for software developers to use to get early access to ARMv8 (arm64) hardware. It's a great way for people who are interested in this new architecture to try things out, port their software or indeed just help with the general porting effort.
As Debian is seen as such an important part of the FLOSS ecosystem, we managed to negotiate dedicated access to three of the machines in that cluster for Debian's use and we set those up in October, shortly before the freeze for Jessie. Andy Doan spent a lot of his time getting these machines going for us, and then I set up two of them as build machines and one as the porter box we were still needing.
With these extra machines available, we quickly caught up with the ever-busy "Needs-Build" queue and we've got sufficient build power now to keep things going for the Jessie release. We were officially added to the list of release architectures at the Cambridge mini-Debconf in November, and all is looking good now!
And in the future?
I've organised the loan of another arm64 machine from AMD for Debian to use for further porting and/or building. We're also expecting that more and more machines will be coming out soon as vendors move on from prototyping to producing real customer equipment. Once that's happened, more kit will be available and everybody will be able to have arm64-powered computers in the server room, on their desk and even inside their laptop! Mine will be running Debian Jessie... :-)
There's been a lot of people involved in the Debian arm64 bootstrapping at various stages, so many that I couldn't possibly credit them all! I'll highlight some, though. :-)
First of all, Wookey's life has revolved around this port for the last few years, tirelessly porting, fixing and hacking out package builds to get us going. We've had loads of help from other teams in Debian, particularly the massive patience of the DSA folks with getting early machines up and running and the prodding of the ftpmaster, buildd and release teams when we've been grinding our way through ever more package builds and dependency loops. We've also had really good support from toolchain folks in Debian and ARM, fixing bugs as we've found them by stressing new code and new machines. We've had a number of other people helping by filing bugs and posting patches to help us get things built and working. And (last but not least!) thanks to all the folks who've helped us beg and borrow the hardware to make the Debian arm64 port a reality.
Rumours of even more ARM ports coming soon are entirely scurrilous... *grin*
Time for another update on my work for UEFI improvements in Jessie!
I now have a mixed 32- and 64-bit UEFI netinst up and running right now, which will boot and install on the Asus X205TA machine I have. Since the last build, I've added 64-bit (amd64) support and added CONFIG_EFI_MIXED in the kernel so that the 64-bit kernel will also work with a 32-bit UEFI firmware. Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload2/ to download and test the image. There are a few other missing pieces yet for a complete solution, but I'm getting there...!
WARNING: this CD is provided for testing only. Use at your own risk! If you have appropriate (U)EFI hardware, please try this image and let me know how you get on, via the debian-cd and debian-boot mailing lists.Friday, 02 January 2015
Time for another update on my work for UEFI improvements in Jessie!
I've got an i386-only UEFI netinst up and running right now, which will boot and install on the Asus X205TA machine I have. I've got the required i2c modules included in this build so that the installer can use the keyboard and trackpad on the machine - useful...! See #772578 for more details about that. Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload1/ to download and test the image. There are a few other missing pieces of hardware support for this machine yet, but the basics are there. See the wiki for more information.
My initial i386 test CD is not yet going to do an amd64 installation for you, but it should let you get going with Debian on these machines! I'm going to continue working on that 32-64 support next.
WARNING: this CD is provided for testing only. Use at your own risk! If you try this on an early Intel-based Mac, it will not work. Otherwise, this should likely work for most folks using 32-bit x86 hardware just like any other Debian Jessie daily netinst build.
If you have appropriate (U)EFI hardware, please try this image and let me know how you get on, via the debian-cd and debian-boot mailing lists.Sunday, 21 December 2014
I spoke about adding support for installing grub-efi into the removable media path (#746662). That went into Debian's grub packages already, but there were a couple of bugs. First of all, the code could end up prompting people about EFI questions even when they didn't have any grub-efi packages installed. Doh! (#773004). Then there was an unexpected bug with case-insensitive file name handling on FAT/VFAT filesystems (#773092). I've posted (and tested!) patches to fix both, hopefully in an upload any day now.
Next, I mentioned getting i386 UEFI support going again. This is a major feature that a lot of people have been asking for. It's also going to involve quite a bit of effort...
Our existing (amd64) UEFI-capable images in Debian use the standard x86 El Torito CD boot method, with two boot images provided. One of these images gives us the traditional isolinux BIOS-boot support. The second option is an alternate El Torito image, including at a 64-bit version of grub-efi. For most machines, this works just fine - the BIOS or UEFI firmware will automatically pick the correct image and everybody's happy. This even works on our multi-arch i386/amd64 CDs and DVDs - isolinux will boot either kernel from the first El Torito image, or the alternate UEFI image is amd64 only.
However, I can now see that there's been a long-standing issue with those multi-arch images, and it's to do with Macs. On the advice of Matthew Garrett, I've borrowed an old 32-bit Intel Mac to help testing, and it's quite instructive in terms of buggy firmware! The firmware on older 32-bit Intel Macs crashes hard when it detects more than one El Torito boot image, and I've now seen this happen myself. I've not had any bug reports about this, so I can only assume that we haven't had many users try that image. As far as I can tell, they've been using the normal i386 images in BIOS boot mode, and then struggling to get bootloaders working afterwards. There are a number of different posts on the net explaining how to do that. That's OK, but...
If I now start adding 32-bit UEFI support to our standard set of i386 images, this will prevent users of old Macs from installing Debian. I could just say "screw it" and decide to not support those users at all, but that's not a very nice thing to do. If we want to continue to support them and add 32-bit UEFI support, I'll have to add another flavour of i386 image, either a "Mac special" or a "32-bit UEFI special". I'm not keen on doing that if I could avoid it, but the two options are mutually exclusive. Given the Mac problem is only on older hardware which (hopefully!) will be dying out, I'll probably pick that one as the special-case CD, and I'll make an extra netinst flavour only for those users to boot off.
So, I've started playing with i386 UEFI stuff in the last couple of weeks too. I almost immediately found some showstopper behaviour bugs in the i386 versions of efivar and efibootmgr (#773412 and #773007), but I've debugged these with our Debian maintainer (Jared Dominguez) and the upstream developer (Peter Jones) and fixes should be in Jessie very soon.
As I mentioned last month, the machines that most people have been requesting support for are the latest Bay Trail-based laptops and tablets. There are using 64-bit Intel Atom CPUs, but crippled with 32-bit UEFI firmware with no BIOS compatibility mode. This makes for some interesting issues. It's probably impossible to get a true answer why these machines are so broken by design, but there are several rumours. As far as I can see, most of these machines seem to ship with a limited version of 32-bit Windows 8.1. 32-bit Windows is smaller than 64-bit Windows, so fits much better in limited on-board storage space. But 32-bit Windows won't boot from 64-bit UEFI, so the firmware needed buggering to match. Ugh!
To support these Bay Trail machines properly, we'll want to add a 32-bit UEFI installation option to our 64-bit images. I can tweak our CDs so that both 32-bit and 64-bit versions of grub-efi are included, and the on-board UEFI will load the right one needed. Then I'll need to make sure that all the 64-bit images also include grub-efi-ia32-bin from now on. With some extra logic, we'll need to remember that these new machines need that package installing instead of grub-efi-amd64-bin. It shouldn't be too hard, but let's see! :-)
So, I've been out and bought one of these machines, an Asus X205TA. Lucas agreed that Debian will reimburse me (thanks!), so I'm not stuck with spending my own money on an otherwise unwanted machine! I can see via Google that none of the mainstream Linux distros support the Bay Trail machines fully yet, so there's not a lot of documentation yet. Initial boot on the new machine was easy using a quick-hack i386 UEFI image on USB, but from there everything went downhill quickly. I'll need to investigate some more, but the laptop's own keyboard and trackpad are not detected by the installer system. Neither is its built-in WiFi. Yay! I had to go and dig out a USB hub to connect the installer image USB key, a keyboard, mouse and a USB hard drive to the machine, as it only has 2 USB ports. I've taken a complete backup of the on-board 32GB flash before I start experimenting, so I can restore the machine back to its virgin state for future testing.
I guess I now have a project to keep me busy over Christmas...!
In other news, we've been continuing work on UEFI support for and within the new arm64 port. My ARM/Linaro colleague Leif Lindholm has been back-porting upstream kernel features and bug fixes to make d-i work, and filing Debian bugs when silly things break on arm64 because people don't think about other architectures (e.g #773311, doh!). As there are more and more people interested in (U)EFI support these days, I've also proposed that we create a new debian-efi mailing list to help focus discussion. See #773327 and follow up there if you think you'd use the list too!
You can help! Same as 2 years ago, I'll need help testing some of these images. For the 32-bit UEFI support, I now have some relevant hardware myself, but testing on other machines too will be very important! I'll start pushing unofficial Jessie EFI test images shortly - watch this space.Thursday, 20 November 2014
So, my work for Wheezy gave us working amd64 UEFI installer images. Yay! Except: there were a few bugs that remained, and also places where we could deal better with some of the more crappy UEFI implementations out there. But, things have improve since then and we should be better for Jessie in quite a few ways.
First of all, Colin and the other Grub developers have continued working hard and quite a lot of the old bugs in this area look to be fixed. I'm hoping we're not going to see so many "UEFI boot gives me a blank black screen" type of problems now.
For those poor unfortunates with Windows 7 on their machines, using BIOS boot despite having UEFI support in their hardware, I've fixed a long-standing bug (#763127) that could leave people with broken systems, unable to dual boot.
We've fixed a silly potential permissions bug in how the EFI System Partition is mounted: (#770033).
Next up, I'm hoping to add a workaround for some of the broken UEFI implementations, by adding support in our Grub packages (and in d-i) for forcing the installation of a copy of grub-efi in the removable media path. See #746662 for more of the details. It's horrid to be doing this, but it's just about the best thing we can do to support people with broken firmware.
Finally, I've been getting lots of requests for adding i386 (32-bit x86) UEFI support in our official images. Back in the Wheezy development cycle, I had test images that worked on i386, but decided not to push that support into the release. There were worries about potentially critical bugs that could be tickled on some hardware, plus there were only very few known i386 UEFI platforms at the time; the risk of damage outweighed the small proportion of users, IMHO. However, I'm now revisiting that decision. The potentially broken machines are now 2 years older, and so less likely to be in use. Also, Intel have released some horrid platform concoction around the Bay Trail CPU: a 64-bit CPU (that really wants a 64-bit kernel), but running a 32-bit UEFI firmware with no BIOS Compatibility Mode. Recent kernels are able to cope with this mess, but at the moment there is no sensible way to install Debian on such a machine. I'm hoping to fix that next (#768461). It's going to be awkward again, needing changes in several places too.
You can help! Same as 2 years ago, I'll need help testing some of these images. Particularly for the 32-bit UEFI support, I currently have no relevant hardware myself. That's not going to make it easy... :-/
I'll start pushing unofficial Jessie EFI test images shortly.Friday, 14 November 2014
I've been crap about blogging lately. Let's see if I can fix that.
Back in February and March, Jo and I went on vacation for 2 weeks touring California and Nevada. We had an awesome time and we got to see and do lots of fun stuff. I'm not going to go into all the details, as it's a long time ago now...! I've got a massive set of photos online, though.
However, two things struck me as odd when we were there. I'm travelling quite regularly to the US these days due to my work in Linaro, but these still seemed new when I saw them this February/March. These are, admittedly trivial things, but they really stood out for me. Maybe I'm a little weird? :-)
Curved shower curtain tracks
I guess I'm not the only one who's been annoyed by shower curtains sticking to me in the shower, but I'd not really paid much thought to it until now. Suddenly, as of maybe 18 months ago I'm seeing most hotel bathrooms replacing the straight curtain track with a curved one, to stop that happening. This photo shows that process with both tracks visible...
Waterproof/washable TV remotes
This one really surprised me. As Jo will attest, I have a little bit of an obsession with TVs and set-top boxes in hotel rooms. This dates from my time working for Amino where we made set-top boxes, and I got into the habit of checking what products were in the hotels I stayed in. I've seen a range of weird and wonderful setups over the years, but never this one before. In two of the hotels on our trip, they had replaced the normal TV remotes with washable/wipe-down ones. Weird...
Alongside our originally planned general sprint work on Thursday and Friday, the Release Team had their own sprint to work through remaining post-freeze decisions about policies, architectures, naming etc. The rest of us worked through a range of topics all over Debian: installer, admin, ARM arch support etc. We even managed to fix Andy's laptop :-).
Saturday and Sunday were two days devoted to more traditional conference sessions. Our talks covered a wide range of topics: d-i progress and an update from the Release Team, backup software and an arm64 laptop project to name but a few.
I was very happy that the Release Team
Several volunteers from the DebConf video team were on hand too, so our talks were recorded and are already online at http://meetings-archive.debian.net/pub/debian-meetings/2014/mini-debconf-cambridge/webm/. Yay!
Again, the mini-conf went well and feedback from attendees was universally positive. We may run again next year. More importantly, I can confirm that we're definitely planning on bidding to host a full DebConf in Cambridge in the summer of 2017.Monday, 13 October 2014
It's past time I wrote about how Linaro's students fared in this year's Google Summer of Code. You might remember me posting earlier in the year when we welcomed our students. We started with 3 student projects at the beginning of the summer. One of the students unfortunately didn't work out, but the other two were hugely successful.
Gaurav Minocha was a graduate student at the University of British Columbia, Vancouver, Canada. He worked on Linux Flattened Device Tree Self-checking, mentored by Grant Likely from Linaro's Office of the CTO. Gaurav achieved all of his project's goals, and he was invited to Linaro's recent Linaro Connect USAConnect conference in California to meet people and and talk about his project. He and Grant presented a session on their work; it was filmed, and video is online. Grant said he was very happy with Gaurav's "strong, solid performance" during the project.
Varad Gautam was a student at Birla Institute of Technology and Science, Pilani, India. He succeeded in porting UEFI to the BeagleBone Black. Leif Lindholm from the Linaro Enterprise Group was his mentor for the summer. At the end of the summer, Varad delivered a UEFI port ready for booting Linux and his code was included in Linaro's September UEFI release. Leif said that he was "very pleased with Varad's self sufficiency and ability to pick up an entirely new software project very quickly". We were hoping to invite Gaurad to Connect in California also, but travel document delays got in the way. With luck we'll see him at the next Connect in Hong Kong in February 2015.
Well done, guys! It was great to work with these young developers for the summer, and we wish them lots more success in their future endeavours.
Google have also just confirmed that they will be running the Summer of Code program again in 2015. I'm hoping that Linaro will be accepted again next year as a mentoring organisation. I'll post more about that early next year.Tuesday, 22 April 2014
After several weeks of review and discussion, the application and selection period for the 2014 Google Summer of Code is over. 4,420 students proposed a total of 6,313 projects for this summer. From those, 1,307 students have been accepted (more details), and Linaro is one of the 190 Open Source projects that will be working with students this year.
In our first year as a GSOC mentoring organisation, we received 17 applications and Google allocated us 3 slots for student projects. It was quite a challenge to pick just 3 projects from the excellent field, and it's a shame that the limited number of slots meant we had no choice but to disappoint some people. Thanks to all those who applied!
I'm delighted to announce our 3 chosen interns for 2014:
Please join me in welcoming these three new engineers to the Linaro team!
We have a GSOC wiki ready for our students to use at
and hopefully they will start adding content there soon about themselves and their projects (hint!). In the meantime, we have more information about our original proposals and the GSOC program in the main Linaro wiki.
Starting today, the next phase of the program is the so-called "bonding period". Students are encouraged to get to know people within Linaro (especially their mentors!) and prepare to start work on their projects, whatever is needed. The official start of the work period for GSOC is May 19th, and it runs through to August 18th. We will give updates on progress through the summer, and we're hoping to talk about our results at the next Linaro Connect in September.
Good luck, folks!Monday, 25 November 2013
We successfuly ran our mini-conf last weekend. We welcomed roughly 60 people to the ARM offices in Cambridge over the 4 days.
We started off with two days of sprint time, set aside for focussed hacking. We had a selection of ARM development boards on hand that people were playing with, plus a number of other people working on various other projects. The sprint sessions also saw some lively discussions on a couple of topics: the status of the ARM ports in Debian and automated system testing.
Saturday and Sunday saw us move over to the more traditional style of conference session. Two full days of talks covered a wide range of topics: system testing to git tools, Debian ftp team work to bootstrapping the new arm64 port, improving ways of tracking and crediting Debian contributions to dealing with the new world of UEFI. Several volunteers from the DebConf video team were on hand too, so our talks were streamed live and recorded too - look out for them online soon!
The mini-conf went well and feedback from attendees was universally positive, so we're already planning to run another similar event next year and maybe even apply to host a full DebConf in Cambridge soon too. :-)
Many more details about the conference are in the debconf wiki at https://wiki.debconf.org/wiki/Miniconf-UK/2013 . Thanks to the sponsors who helped to make it all happen: ARM, Boston, Open@Citrix/Xen and Codethink/Baserock.
2013-11-25 UPDATE: Videos are now online at http://meetings-archive.debian.net/pub/debian-meetings/2013/mini-debconf-cambridge/ in various formats.Saturday, 30 March 2013
In the Linaro Enterprise Group, my task for the last several weeks was to work through a huge number of packages looking for assembly code. Why? So that we could identify code that would need porting to work well on AArch64, the new 64-bit execution state coming to the ARM world Real Soon Now.
Working with some Ubuntu and Fedora developers, we generated a list of packages included in each distribution that seemed to contain assembly code of some sort. Then I worked through that list, checking to see:
I've written a full report about what I found in the scan, and I'll be writing some more articles based on it shortly.Tuesday, 19 February 2013
My lovely wife Jo has signed up for a charity event in May this year. To help support the UK Fire Fighters Charity, she has committed to a sponsored driving challenge. If she can raise enough funds in sponsorship, she'll get to drive a fire engine, a tractor and (it's rumoured) maybe even a combine harvester too! I've chipped in some money towards the total already; I'm sure Jo would love it if some other nice people pledged on her JustGiving page too.
Go on, it's for a good cause! :-)Tuesday, 13 November 2012
Ever since I passed the age of 18, I've used my legal right in the UK to vote in every poll I could: local council, British Parliament, European Parliament and even the messed-up referendum on the Alternative Vote that we had last year. In each of those cases, I made a point of considering my available options and I voted accordingly. I went along and marked my ballot paper in person where possible, or I filled in a postal vote for the last Westminster election in 2010 as I was on vacation in Florida when it was held.
Unfortunately, it seems that my diligence in voting makes me unusual amongst the UK population these days. The long-term trend for voter turnout is downwards (as you can see).
However, the latest election that's happening in the UK (well, England and Wales outside London) this week is for the newly-created posts of Police and Crime Commissioners. It's a textbook example of how not to organise an election, as pointed out eloquently by the Electoral Reform Society. This election has been incredibly badly managed and publicised by the Government, and lots of early polls are suggesting a tiny turnout of less than 20%. Despite the political crap about "democracy" being spouted by some Tory ministers, it's clear that very few people want this change in how the police are run, and it has simply been imposed from the top. Too few people care about the results of these elections for them to be valid - most people don't want the police politicised.
After a lot of thought about the issue, I've decided how I'm going to vote this time. For the first time ever, I'm explicitly going to turn up and spoil my ballot paper as a protest - I do not want this crap. I urge other people in England and Wales to consider doing the same.Friday, 28 September 2012
We've been thinking about getting a dog for ages, but it's been difficult to work out the logistics when we've been travelling so much. Well, today's the day!
Pepper is a Parson Russell Terrier, and she's 3 years old. We just collected her from the lovely people at Wood Green Animals Shelter. Her previous owner passed away recently, so she was looking for a new home.
We've just brought her home and things are going great - she's very well behaved (so far!) and is loving a new place with lots of fuss and cuddles.
Back at the beginning of September, Jo and I were invited up to Aberdeen for a weekend for a party to celebrate the 50th wedding anniversary of some friends. Then we decided to stay around for a few days - it was our 1st anniversary just two days later. :-)
We had a great time at the party, and had some awesome weather for the weekend (especially considering the time of year!). We travelled around a bit for the next few days, visiting Crathes Castle, John O' Groats and Culloden amongst other places. We stayed in a hotel overlooking Loch Ness for the evening of our own anniversary, but no sign of Nessie! We headed back via Gretna Green and visited the famous (if tacky!) Blacksmith's there, then headed home. Having done both Land's End and John O' Groats in one year, we've covered the length of Great Britain.
We thoroughly enjoyed ourselves for a few days, especially the lovely roads with very few people on them! Also we got to see some very unusual road signs that made us chuckle...
We'll definitely go back again soon!Monday, 03 September 2012
Continuing on from my third EFI progress report...
I've added some i386 EFI support in debian-cd and built new images. Alongside a new amd64 image, we now have an i386 image and a mixed image which should hopefully boot and work on both 32-bit and 64-bit machines. The i386 support is more experimental at this point, and it's more difficult for me to test due to a lack of physical hardware. If you've got an older 32-bit EFI machine, this might work for you...
Grab the images from http://cdimage.debian.org/cdimage/unofficial/efi-development/upload4/ if you'd like to help test. Please do, and let me know via debian-boot/debian-cd how you get on.
As previously, the "bits" subdirectory contains all the tweaked d-i packages I've played with, in both source and binary form. My debian-cd changes are still in my branch but are just about ready for merging I think. I've posted my full set of d-i patches to the debian-boot list for review now, and hopefully we'll be able to get those changes merged in after the Wheezy d-i beta 2 build is done. Full speed ahead for EFI in beta 3!Friday, 24 August 2012
Continuing on from my second EFI progress report...
My second alpha release of a Wheezy netinst CD for amd64 EFI seemed to work OK for me and a few others, but it wasn't 100% good, with (at least) two issues:
In the couple of days since then, I've fixed both of these issues. Yay! Hybrid boot was easier than I expected - I've just added a tiny FAT partition to the image containing the grub EFI bootloader and that seems to work fine. I also found that I made a mistake in the ordering of the El Torito boot records in the last image. BIOS boot seems to be limited to just the first image available on the machines I've tested with, wherease EFI will happily work as a secondary image. I've swapped them around in my code, and things look much better now. So, time for another CD alpha release for testing.
Grab the image from http://cdimage.debian.org/cdimage/unofficial/efi-development/upload3/ if you'd like to help test it. Please do, and let me know via debian-boot/debian-cd how you get on.
As previously, the "bits" subdirectory contains all the tweaked d-i packages I've played with, in both source and binary form. My debian-cd changes are still in my branch but are just about ready for merging I think. I've posted my full set of d-i patches to the debian-boot list for review now, and hopefully we'll be able to get those changes merged in after the Wheezy d-i beta 2 build is done. Full speed ahead for EFI in beta 3!Wednesday, 22 August 2012
Continuing on from my first EFI progress report...
My first alpha release of a Wheezy netinst CD for amd64 EFI worked OK for me and a few others, with reasonable feedback. But it was far from complete, with (at least) three outstanding issues:
In the days since then, I've carried on hacking on things. I've not yet sorted out hybrid boot, but I've fixed the other issues. To make graphics work on the grub boot menu was a simple case of loading the right module from grub.cfg ("insmod png"). Getting grub-efi to work took quite a lot more effort, though. I've been looking through Ubuntu's version of debian-installer code and merged a fair amount of their code into my local builds, adding tweaks as necessary. Result? I've got another CD alpha release ready for testing. Yay!
Grab the image from http://cdimage.debian.org/cdimage/unofficial/efi-development/upload2/ if you'd like to help test it. Please do, and let me know via debian-boot/debian-cd how you get on.
As previously, the "bits" subdirectory contains all the tweaked d-i packages I've played with, in both source and binary form. My debian-cd changes are still in my branch but are just about ready for merging I think. I'll post more d-i patches to the debian-boot list for review shortly.Sunday, 12 August 2012
As promised last month at DebConf, I've been working on adding EFI support to debian-cd and debian-installer, hopefully to get it up and running. At the moment, this is basic support only for booting and setting up the installed system via UEFI. I'm not worrying about "Secure" (better named "Restricted"?) Boot yet - that comes later, and depends on the basic stuff working first.
So, how is it going? Quite well, really. I've got a
branch that I'm working on locally, and with a relatively small
amount of work there I've got a locally-built CD that boots in EFI
mode, using grub-efi as a boot loader. I've borrowed a script
Next step: the installer. At the moment, generic amd64 and i386 machines are assumed to use need dos-style partitioning, and then either lilo or grub as a bootloader. I've patched and rebuilt some of the d-i packages locally to add a new sub-architecture of "efi" for both amd64 and i386, alongside the existing "generic" and "mac" variants. Using that new sub-architecture, it's possible to add checks for amd/efi and i386/efi in various places to make the necessary changes:
Why elilo? It's the default for current ia64 systems, and for EFI Macs. I tried to get grub-efi working with the grub-installer package, but with little success so far. I'll try again with grub-efi, but for now elilo is much simpler and (importantly!) it works for me.
So, I have a netinst CD built that works for me in local testing in a qemu VM using James Bottomley's OVMF build of Tianocore. It's not pretty, but it works fine, covering all the normal Debian installation steps and giving me a UEFI system at the end of the process. I'm about to start testing on real hardware now, so I think it's worth sharing this netinst image with others too. Grab it from http://cdimage.debian.org/cdimage/unofficial/efi-development/upload1/ . The "bits" subdirectory contains all the tweaked d-i packages I've played with, in both source and binary form. If you have an EFI system and would like to help us get it supported well in Debian, please download this image and play with it! Feedback to the debian-cd and/or debian-boot lists, please!