[gl-como] Fwd: Summary of the Debian CD BoF at DC15
Elena ``of Valhalla''
valhalla-l@trueelena.org
Mar 15 Set 2015 20:57:54 CEST
----- Forwarded message from Steve McIntyre <steve@einval.com> -----
Date: Tue, 15 Sep 2015 13:52:20 +0100
From: Steve McIntyre <steve@einval.com>
To: debian-devel-announce@lists.debian.org
Cc: debian-cd@lists.debian.org, debian-boot@lists.debian.org
Subject: Summary of the Debian CD BoF at DC15
Message-ID: <20150915125220.GA31487@einval.com>
[ Please note the cross-post and Reply-To ]
Hi folks,
As promised, here's a quick summary of what was discussed at the BoF
session in Heidelberg. Apologies for the delay - it takes a while to
write these up, especially when struck down with the traditional
post-DebConf plague. :-(
Thanks to the awesome efforts of our video team, the session is
already online [1]. I've taken a copy of the Gobby notes too,
alongside my small set of slides for the session. [2]
Current state
=============
We have a massive number of different images created using debian-cd:
* CDs
* DVDs
* non-free netinsts (including non-free firmware packages)
* non-free firmware bundles
Live images created using live-build etc. from the debian-live team
* including non-free images with firmware
Openstack images using openstack-debian-images
All of these are built on pettersson, our big central CD builder
machine hosted by the nice folks at umu.se.
Plans for images - no new CDs!
==============================
I'm planning to basically stop making *CD* sets for new builds
(testing/stretch onwards).
What do I mean by that? We'll stop building full CD sets of all of
Debian (up to 90 per architecture) for new releases, and testing. And
we'll also kill the differing CD1 options for different
desktops. We'll continue building DVD and BD images. DVD#1 will
continue to be configured to fir on a 4GB USB stick.
We'll *keep* building netinst images as a small handy image type that
many people use, and we'll keep building CD sets and CD1 options for
older releases (Wheezy and Jessie) - we're not going to change tack on
those half-way through.
Why are we doing this? Two main reasons:
* Essentially, approximately nobody is using these images any
more. The chances of anybody actually using (for example) mips CD43
is zero. There's no point in making these any more and wasting the
time, effort and disk space. For those people who are still stuck
on machines that for some reason can't use bigger media, the
netinst will suffice for boot and then use the network or
similar. For anybody actually writing CDs, blank DVD media would be
so much cheaper today that it would be cheaper to use DVDs and buy
a drive!
* It's become less and less useful to install from CD in recent
years. We've had an ever-present problem with the different desktop
environments growing in size as they add more features. For the
last couple of releases, the small subset of Gnome or KDE that
would fit on a single CD is, at best, not a good representation of
the desktop capabilities. At worst, it's been simply non-functional
without adding an extra package source (more discs, or a network
repository).
If users are stuck booting off smaller media, then I'd recommend using
the netinst to boot and then add more package sources later.
Stretch d-i alpha 3 (just released this week) is the last build I
expect to include CDs with.
Live images have mostly been too large to fit on CD for a while
anyway - no plans to change the set there.
I'm open to making more different-sized image types so long as they
make sense - ask!
get.debian.org
==============
With the change to not make CDs, using cdimage.debian.org as the name
for our central distribution site is a little silly! After some
consultation on the mailing lists for a better name, I've picked
get.debian.org as a new name. For the sake of old links etc., the old
name is not going to go away. But for new links, documentation etc. we
should start linking to get.debian.org instead.
For now, the main landing page at get.debian.org is still the same as
that for cdimage.debian.org. We'll work on this shortly. Help would be
lovely!
Non-free images
===============
As mentioned in the firmware talk[3], We make a number of *unofficial*
non-free images alongside our normal installer and live images
today. They're essentially the same as the normal images, but with
non-free firmware included for those people who need it to make their
hardware function correctly. We've deliberately not advertised these
very much in the past, so much so that many people (including lots of
DDs!) don't even know these exist. We're planning to advertise them
some more, and make some detail changes in how we deal with firmware
which will make things easier for people, but we will *not* be
including non-free firmware on official Debian media any time
soon. See the firmware discussion for more details.
New image types
===============
We've recently added official Debian Openstack images. We'd like to
add more types of image in the future. We have the capacity to make
more images available on get.debian.org, and we are currently
specifying a new more powerful server which will make that better
again. Currently I'm thinking of:
* More cloud images (Google, Microsoft, Amazon, Profitbricks, ...),
or using cloud-init or something similar to make single images work
on all the different clouds. Several of the vendors already have
"Debian" images, but we're not 100% sure of their provenance, If
possible, it would be lovely to make official images on
Debian-controlled machines so that people can trust them fully.
* More live images, starting with some for Blends. Iain Learmonth
already has been working on a Debian Hams image, and there are more
coming, I'm sure.
* Live images for non-x86 targets, where they make sense. Many won't
make sense, due to difficulty in booting them, lack of memory,
etc. But some will, and we're thinking of arm64 and (maybe) armhf
as the first targets here.
* Neil Williams has been putting a lot of effort into the
vmdebootstrap tool as a generic way of making a wide variety of
live-style images. A major new addition is UEFI support. \o/
Suggestions and comments from the BoF:
* Add a simple live netboot image (kernel and initramfs) which will
grab and extract a tarball into a tmpfs for general usage
* In Riku's bootable images talk[4] we heard that there are more than
10(!) different image creation tools in common use, just within
Debian. Most of the job is simple, but lots of the tools only do a
small subset of the simple things!
If you're interested in any of this (helping, or ideas for more
images) please talk to us!
Misc questions and discussion
=============================
Q. Multi-architecture CDs - possible?
A. Yes, but it depends massively on the architectures involved. We
already do multi-arch amd64/i386 CDs/DVDs, and we used to have
others: amd64/i386/powerpc, alpha/hppa/ia64 (the HP
special!). There's scope to make more like this, so long as the
architectures don't clash in terms of how their boot support is
configured. Sector 0 is special on lots of different architectures,
and some of them clash in terms of what they want in various
locations in this boot sector.
More important is how useful the resulting images are for
users... :-) The m-a x86 netinst is nice as that way we can ship a
single image/disc which will work on any PC. Didier Raboud has been
hacking on getting auto-detect working again on that
image. As/when/if we get another architecture (arm64?) with enough
users, we may add that to the m-a netinst too.
Q. What should we do to generate and test different cloud images?
A. We need to get some testing infrastructure in place to do some
basic QA on these. At the moment, the Openstack images seem to work
OK (no bad feedback so far!), but we should be doing more. In terms
of reporting issues, at the moment we don't have a specific place
for that. Bug reports should probably go to the debian-cloud
mailing list.
Aside: we have a cdimage.debian.org BTS pseudo-package, and we
clearly should add get.debian.org too. We should use that and
redirect reports appropriately.
We need to get some tests defined and running at build-time. Make
sure that what we produce looks sane and is fit to be
released. Maybe define standard tests for what's allowed to be
called "Debian" in this area? Some discussion apparently happened
in the "What should be allowed to call itself Debian" talk
earlier", but there wasn't a clear agreement there.
First test for cloud images - can we boot one of these images and
ssh in?
We have a framework for testing Debian installer CDs, but it's
never been intergrated fully. :-( Similar story for live images -
initial test implementation has happened, but it's not in use?
"Packer" (I think) was mentioned software written in Go that can
automate creation/testing(?) of various virtualisation image
formats. Would need packaging for us to use it, needs
volunteer(s). This whole area needs more help if it's going to
happen in time for Stretch...
Q. Can we tweak debian-cd to install a full 64-bit CD/system with
*some* 32-bit support included, but not full?
A. People have asked about this kind of thing multiple times in the
past, but no code yet. debian-cd m-a support is currently designed
to include exactly the same level of packages for all the
architectures on a m-a CD. This could be hacked fairly easily to
fix that - just include the base system and some libraries for
secondary architectures. No time to look at this yet, but a
wishlist bug would help! :-)
UEFI
====
We just started a new UEFI team a few weeks back[6]. We're explicitly
looking for bug reports from people. If UEFI does not just work,
please report issues. There's a cross-distro effort now going on to
track these so that we can share information and complain to
manufacturers.
Secure Boot is in progress still. We were hoping to get it working
last year, but for various reasons it didn't happen yet. Hoping to get
something soon, maybe by the end of the year.
We'll be adding support for boot, validating kernel and modules etc.;
at least that's the plan. Still open for debate as to exactly what
we're going to do. We'd love to do SB on x86 and arm64 at the very
least. We aim to have working SB support in d-i, debian-cd, kernel and
bootloaders.
Will derivatives be able to hook in? Honestly not sure - the devil is
in the details here. How far does the trust chain extend?
Will arm64 shim be signed by Microsoft? No idea - it's under
discussion.
kFreeBSD
========
UEFI (and SB) on kFreeBSD is an unknown quantity at this time. I've no
idea how well it might work (or not). Help needed, happy to plumb it
in in Debian if somebody can tell us how!
We may get an unofficial kFreeBSD jessie CD release done - waiting on
information at this point.
Please help!
============
We're always looking for more help, and we're about to add even more
stuff to our TODO list. Also, always looking for more help when
testing images for release etc.
Join us on the debian-cd list, or on #debian-cd.
[1] http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/Debian_CD_discussion.webm
[2] http://www.einval.com/~steve/talks/Debconf15-CDs-are-dead/
[3] https://lists.debian.org/debian-devel/2015/08/msg00622.html
[4] https://summit.debconf.org/debconf15/meeting/246/creating-bootable-debian-images/
[5] https://summit.debconf.org/debconf15/meeting/205/what-should-be-allowed-to-call-itself-debian/
[6] http://blog.einval.com/2015/08/02#new_debian_uefi_team
--
Steve McIntyre, Cambridge, UK. steve@einval.com
The two hard things in computing:
* naming things
* cache invalidation
* off-by-one errors -- Stig Sandbeck Mathisen
----- End forwarded message -----
--
Elena ``of Valhalla''
Maggiori informazioni sulla lista
gl-como