Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-boot@lists.debian.org
Control: affects -1 + src:netcfg
[ Reason ]
Certain kinds of network architectures in Debian deployments (e.g.
https://phabricator.wikimedia.org/phame/post/view/312/ganeti_on_modern_network_design/,
https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/) are
difficult because the installer doesn't support single-address netmasks
out of the box (https://bugs.debian.org/1064005). You can sort of
handle this with point-to-point preseeding, but that isn't quite
identical and it doesn't work for IPv6.
I've just fixed this in unstable, but it would be helpful to have it in
place for installs of bookworm too.
[ Impact ]
It's possible to work around this without changing netcfg, but it
requires messy and fragile early_command preseeding to defeat netcfg's
behaviour (see #1064005).
[ Tests ]
The change includes automated tests for the changes to the gateway
reachability test. For the changes to the routing table setup and to
confirm that no changes were needed to network configuration in the
installed system, I used libvirt machines with a DHCP server along the
lines of https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/;
Wikimedia has also tested this using their own setup and confirmed that
it now works out of the box.
[ Risks ]
I've taken care that all the new code is guarded by interface->masklen
checks, so it should be obvious that it's a no-op on any system that
isn't using this unusual single-address netmask setup.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
It turns out that fixing this is very straightforward: it's just a
matter of special-casing the gateway reachability test and then telling
the routing table to pretend that the gateway is directly attached to
the relevant link. The installed system (ifupdown, NetworkManager)
already gets this right; it's just the installer that had trouble with
it.
[ Other info ]
This work was requested and sponsored by the Wikimedia Foundation.
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru netcfg-1.187/debian/changelog netcfg-1.187+deb12u1/debian/changelog
--- netcfg-1.187/debian/changelog 2023-05-23 19:24:01.0 +0100
+++ netcfg-1.187+deb12u1/debian/changelog 2024-05-14 11:27:14.0
+0100
@@ -1,3 +1,9 @@
+netcfg (1.187+deb12u1) UNRELEASED; urgency=medium
+
+ * Handle routing for single-address netmasks (closes: #1064005).
+
+ -- Colin Watson Tue, 14 May 2024 11:27:14 +0100
+
netcfg (1.187) unstable; urgency=medium
* Team upload
diff -Nru netcfg-1.187/netcfg-common.c netcfg-1.187+deb12u1/netcfg-common.c
--- netcfg-1.187/netcfg-common.c2022-06-03 19:25:43.0 +0100
+++ netcfg-1.187+deb12u1/netcfg-common.c2024-05-14 11:26:51.0
+0100
@@ -1680,8 +1680,22 @@
inet_pton(interface->address_family, interface->gateway, _addr);
if (interface->address_family == AF_INET) {
+if (interface->masklen == 32) {
+/* Special case for single-address networks. We'll handle
+ * routing manually in this case.
+ */
+return 1;
+}
+
return (gw_addr.in4.s_addr && ((gw_addr.in4.s_addr & mask.in4.s_addr)
== net.in4.s_addr));
} else if (interface->address_family == AF_INET6) {
+if (interface->masklen == 128) {
+/* Special case for single-address networks. We'll handle
+ * routing manually in this case.
+ */
+return 1;
+}
+
if ((ntohs(gw_addr.in6.s6_addr16[0]) & 0xffc0) == (0xfe80 & 0xffc0)) {
return 1;
}
diff -Nru netcfg-1.187/static.c netcfg-1.187+deb12u1/static.c
--- netcfg-1.187/static.c 2021-09-22 19:07:01.0 +0100
+++ netcfg-1.187+deb12u1/static.c 2024-05-14 11:27:14.0 +0100
@@ -338,6 +338,12 @@
di_snprintfcat(buf, sizeof(buf), "%s", interface->ipaddress);
rv |= di_exec_shell_log(buf);
} else if (!empty_str(interface->gateway)) {
+if (interface->masklen == 32) {
+snprintf(buf, sizeof(buf), "route add -interface %s %s",
interface->gateway, interface->ipaddress);
+di_info("executing: %s", buf);
+rv |= di_exec_shell_log(buf);
+}
+
snprintf(buf, sizeof(buf), "route add default %s", interface->gateway);
rv |= di_exec_shell_log(buf);
}
@@ -373,6 +379,8 @@
}
else if (!empty_str(interface->gateway)) {
snprintf(buf, sizeof(buf), "ip route add default via %s",
interface->gateway);
+
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote: > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > > Dumping the encoded keymaps for pc105... > > WARNING: Can not find "caps_switch" in "group". > > WARNING: Can not find "caps_toggle" in "group". > > gzip -9n >/Keyboard/pc105.ekbd > > >/<>/Keyboard/pc105.ekbd.gz > > /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file > > make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 > > make[1]: Leaving directory '/<>' > > make: *** [debian/rules:204: udeb-install] Error 2 > > > >Version 1.223 builds fine in unstable instead. Perhaps this is related > >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd? > > What makes you think, that this has happened? > > There is a merge request that includes the removal of said package, > but it has not yet been merged. It's not in git, but you appear to have built 1.224 from an unclean source tree that had that patch applied. My inclination is to upload 1.225 without that patch for now, as we need to rebuild for the new xkb-data to sort out uninstallability in unstable, and then get the kFreeBSD-removal patch sorted out after that. Objections? -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Moving debootstrap to fully team maintained (drop Uploaders field)
On Tue, Jul 18, 2023 at 09:49:34PM +0100, Luca Boccassi wrote: > debootstrap's d/control lists the Maintainer as the "Debian Install > System Team" - that is great. There are also 3 Uploaders listed: Colin > Watson, Steve McIntyre and Hideki Yamane. > > The last contribution and upload by Colin were in 2021 and 2015, > respectively, by Steve was it was 2016 and 2017, and Hideki and 2021 > and 2020. Again, not a critique, just data! I can't speak for others, but I don't object to being removed from Uploaders here. > So, I want to propose to move the package to exclusively team > maintained, drop the Uploaders field, leave only the Maintainer field > with the current team as-is, and ask anybody who wants to help maintain > it to join the installer-team on Salsa and just send changes as MRs, > help review/merge them, and do normal uploads, without marking them as > NMU nor feeling the need to treat them as NMUs - no need to contact > uploaders to ask permissions, delayed uploads, or anything like that. > > Again, I really can't stress this enough - dropping the Uploaders is > not because I think the uploaders have done anything wrong, or as > punishment, or anything else, but simply and solely to remove all > barriers stopping or hindering anybody else from doing team > maintenance. FWIW, while I don't object to this change for my own part, I also don't have the same understanding as you of what Uploaders means in a team-maintained package. To my mind, Uploaders is just a hint as to which team members are likely to have the most useful context about a package. It makes sense to keep that list up to date, for sure, but a package is no less team-maintained just because it happens to have an Uploaders field. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Success in using cdebconf alone to bootstrap VMs
On Thu, Nov 03, 2022 at 08:33:16AM +0100, Holger Wansing wrote: > Gioele Barabucci wrote (Sun, 28 Aug 2022 09:19:53 +0200): > > you probably have seen the bugs reports [1] and the MRs [2,3] that I > > recently opened related to the creation and the use of `debconf-common`. > > > > With these changes [4,5,6] applied (and a few unrelated changes) I have > > been able to mmdebootstrap a number of VMs in which classic debconf is > > not used at all, neither at installation time nor afterward. > > > > I'm confident that a debconf-free unstable for base systems could be > > achieved before the freeze with little effort. > > > > [1] https://bugs.debian.org/1018261 > > [2] https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/11 > > [3] https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/17 > > [4] https://salsa.debian.org/gioele/debconf/-/commits/debconf-common-pkg > > [5] https://salsa.debian.org/gioele/cdebconf/-/commits/depend-debconf-common > > [6] https://salsa.debian.org/gioele/cdebconf/-/commits/independence > > Any objections against this approach? I commented on https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/11. While I don't have a fundamental objection to it (and indeed have made some attempts towards the same goal in the distant past), and while I definitely applaud attempts to make progress here, I don't think we should try to do it to a deadline. The confmodule-level issues I raised can probably be dealt with relatively easily (though given that they weren't spotted beforehand, I suspect there is a bit of a QA gap here). However, if we're looking at getting cdebconf going fully in installed systems, then somebody really needs to be committing to figuring out full cdebconf compatibility for all the various random features that aren't needed in d-i but that at least some people will be relying on in the installed system - the full range of frontends, databases, protocol details, and so on. We don't even have things like frontend name compatibility where cdebconf has "close enough" frontends to debconf's at the moment; in my mind that would be part of (almost certainly not all of) a bare minimum of compatibility here. I understand that a prototype implementation doesn't strictly need all this stuff for minimal functionality, especially if there isn't much user interaction involved, and so it looks like having cdebconf-only installed systems is just a few patches away. However, as soon as it starts to be possible to install cdebconf-only systems, people will start trying to do so and expect us to support the results, and are likely to complain about the gaps. So I don't think this can be done before the freeze (and honestly I think there's enough to do that me replying more promptly wouldn't have made a significant difference to that), but there's definitely stuff for people to get their teeth into if they want to make progress on this goal that's been open since at least 2003. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 03:27:36PM +0100, Steve McIntyre wrote: > * Check/add support for the non-free-firmware section in various > places: > + debmirror (?) Done in debmirror 1:2.37. I guess we need to cherry-pick this to bullseye too? I know bullseye doesn't have non-free-firmware (which is fine, the new debmirror doesn't object), but most people running mirrors probably run stable rather than testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Some confusion regarding PCMCIA-related changes
On Thu, Sep 22, 2022 at 10:58:21PM +0200, Holger Wansing wrote: > Am 22. September 2022 04:09:42 MESZ schrieb Cyril Brulebois : > >A while back, this ended up in a release announcement > >(https://www.debian.org/devel/debian-installer/News/2021/20210802): > > > > - pcmciautils: > >+ Update /etc/pcmciautils/ dir to /etc/pcmcia/ in udeb (#980271). > > > >and I had a déjà-vu while adding this in the upcoming one > >(https://www.debian.org/devel/debian-installer/News/2022/20220922): > > > > - hw-detect: > >+ Replace /etc/pcmcia/ with /etc/pcmciautils/ (#980271). > > > > > >It would be great if someone could double-check what's going on here. :) > > Everything fine! > That's correct, as it is. > > pcmciautils (moreover its udeb) is the package, > which installs this path, so it's the main target for > this change. But it doesn't. As of your change in pcmciautils 018-13, it uses /etc/pcmcia/ in the udeb as well. /etc/pcmciautils/ is nonexistent and should not be referred to in any way. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Some confusion regarding PCMCIA-related changes
On Thu, Sep 22, 2022 at 04:09:42AM +0200, Cyril Brulebois wrote: > And yes, the year is 2022, and I'm confused about PCMCIA! :) > > A while back, this ended up in a release announcement > (https://www.debian.org/devel/debian-installer/News/2021/20210802): > > - pcmciautils: > + Update /etc/pcmciautils/ dir to /etc/pcmcia/ in udeb (#980271). > > and I had a déjà-vu while adding this in the upcoming one > (https://www.debian.org/devel/debian-installer/News/2022/20220922): > > - hw-detect: > + Replace /etc/pcmcia/ with /etc/pcmciautils/ (#980271). > > > It would be great if someone could double-check what's going on here. :) This seems very weird to me too, and it seems as though the hw-detect change is backwards - the template change there also now disagrees with hw-detect.sh. I don't think I was involved in that side of it though (or I've forgotten), so this one is probably for Holger ... -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1007714: bullseye-pu: package openssh/1:8.4p1-5+deb11u1
On Wed, Jun 29, 2022 at 10:27:01PM +0100, Adam D. Barratt wrote: > On Fri, 2022-03-18 at 08:43 +0100, Cyril Brulebois wrote: > > Adam D. Barratt (2022-03-17): > > > As openssh builds a udeb, I'm CCing KiBi and tagging the bug > > > accordingly. > > > > Making sure upgrades have a chance to work properly seems more > > important > > than any possible regressions at install time, for those deploying > > over > > SSH, so no objections at all. > > Just a quick reminder on this, as the window for getting changes into > 11.4 closes over the coming weekend. Oops, sorry! I've just uploaded this. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#934713: os-prober: missing dependency on mount
On Mon, Jun 28, 2021 at 10:17:10PM +0900, Hideki Yamane wrote: > On Thu, 15 Aug 2019 16:49:46 +0200 Johannes Schauer wrote: > > I was not trying to justify or excuse the omission of the src:util-linux > > maintainers. I can only imagine that os-prober somehow slipped through the > > cracks when the src:util-linux maintainers filed bugs against all packages > > that > > need the mount utilities during the buster release cycle. > > > > I agree that the situation now is unfortunate but I only reported this > > problem > > once I stumbled across it. I was not involved in the decision two years ago. > > Anyway, here's a tiny MR > https://salsa.debian.org/installer-team/os-prober/-/merge_requests/9 > > > If it would be a wrong way to deal with this bug, then close above MR > and remove Tags: patch, please. If not - just merge it and push the package > :D This looks correct to me, thanks. Merged and uploaded. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#729699: debian-installer: apt-setup/multiarch argument amd64 isn't numeric in multiplication debconf-apt-progress
Source: apt
Source-Version: 0.9.13~exp1
Sorry for my extremely long delay in looking at this bug. Fortunately,
it seems to have been fixed long ago, so this has just been a
bookkeeping delay.
On Tue, Mar 11, 2014 at 03:20:15AM +0100, Cyril Brulebois wrote:
> bofh80 (2013-11-16):
> > using cdimage / non-free/ daily / testing
> > To install testing/jessie
> > used apt-setup/multiarch option, which appears to work fine.
> >
> > Get spurious messages all the way through the package install after
> > the initial base setup.
> >
> > The attached preseed as you can see is quite basic, when adding :i386
> > packages you also get messages with amd64 replace with i386. again
> > nothing seems to be broken. installer/syslog will be attached.
> >
> >
> > in-target: Argument "amd64" isn't numeric in multiplication (*) at
> > /usr/bin/debconf-apt-progress line 168, line ##.
>
> AFAICT this is due to the way lines are split up:
> | sub handle_status ($$$) {
> | my ($from, $to, $line) = @_;
> | my ($status, $pkg, $percent, $description) = split ':', $line, 4;
> | …
> | $percent = ($percent * $len / 100 + $min);
>
> multiarch means you get arch-qualified package ($pkg:$arch), which
> breaks the assumption made above. I'm therefore reassigning this bug
> report to debconf. Same code in 1.5.49 (wheezy) and 1.5.42 (current
> sid).
It pretty much has to be apt's responsibility to get the message framing
right here; I don't think it would be reasonable to expect debconf to
guess at how to split up the fields, particularly because the
"description" field at the end continues to the end of the line and
might itself contain colons.
Fortunately, it looks as though this was fixed some time back in apt.
The git history is confusing to me, but it seems to have been this
commit:
https://salsa.debian.org/apt-team/apt/commit/dd640f3cece45693b57b49d90ba7cc4134577070
Notice in particular the 'StringSplit(PackageName, ":")[0]' change.
This seems to have been part of apt 0.9.13~exp1:
apt (0.9.13~exp1) experimental; urgency=low
* Improve the API for APT::Upgrade::Upgrade()
* Re-add "Calculating upgrade..." message
* move upgrade related code into upgrade.{cc,h}
* Move ListUpdate/AcquireUpdate into update.{cc,h}
* Add new apt-pkg/install-progress.h with APT::Progress::PackageManager
progress reporting classes
* Move the status-fd progress reporting out of the pkgDPkgPM class
and into PackageManagerProgressFd
* Fix reading dpkg --status-fd on reinstalls
* Add new APT::Status-deb822-Fd progress output
* add Acquire::http::Proxy-Auto-Detect to the apt.conf.5 manpage
(closes: 726597)
* Fix detection when multiarch packages are reported by dpkg as
disappeared Packages
* test/integration/run-tests: output the failed test names
* Code Cleanup in pkgDPkgPM
* prepare next ABI via #if (APT_PKG_MAJOR >= 4 && APT_PKG_MINOR >= 13)
* add new pid_t ExecFork(std::set KeepFDs)
* Avoid flickering when "apt-get -o DpkgPM::Progress-Fancy=1" is use
* use sysconf(_SC_OPEN_MAX) in ExecFork()
-- Michael Vogt Fri, 01 Nov 2013 10:03:06 +0100
If there's still a similar corner case somewhere that I missed when
looking for this, it should probably be taken up with the apt
maintainers, for the same reason as above.
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#976094: buster-pu: package grub2/2.02+dfsg1-20+deb10u3
On Thu, Dec 31, 2020 at 04:46:43PM +, Adam D. Barratt wrote: > I do have a _slight_ concern that someone with a crazily small /boot > will end up being broken by the new backup code, but agree that it is > better than the current situation. It's true that this is a possibility. I'd like to add that the total size of /boot/grub/ at least on the buster system I have handy here is ~12MB, about a third of the size of an initramfs - so any system that close to the wire will probably be in trouble soon anyway. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#960390: x86_64: No serial port output
Control: reassign -1 debian-installer On Tue, May 12, 2020 at 05:32:51PM +0900, Punit Agrawal wrote: > Package: grub2 > > Grub does not output to serial port when running in a VM launched using > Qemu when run as part of the Debian Installer. This prevents > installation of Debian in a VM when running without a GUI. In this > specific instance, I was trying to install Debian in a VM over ssh. > > To reproduce the problem, run > > $ qemu-system-x86_64 -cdrom debian-10.3.0-amd64-netinst.iso -nographic > > The BIOS / Firmware outputs to the serial port but no further progress > is seen on the serial console. Dropping the `-nographic` shows that > Debian Installer is launched in a graphical window waiting for input. > > Once installed without `-nographic`, the following changes to > /etc/default/grub and running `sudo update-grub` enabled serial output. > > GRUB_TERMINAL=console > GRUB_SERIAL_COMMAND="serial --speed=11520 --unit=0 --word=8 --parity=no > --stop=1 > > The behaviour was seen on both Buster and Bullseye based Debian > Installer images on x86_64. It was also consistent for both legacy and > UEFI firmware. The installer supplies its own GRUB configuration for the installer images themselves; and its "grub-installer" component then has code to at least attempt to configure the installed system's GRUB to use serial output if the installer itself was using serial output. So I think either way this is something that would need to be fixed in the installer. Reassigning there. -- Colin Watson [cjwat...@debian.org]
Bug#959668: os-prober: translated auto-added items in other installs are not recognized as such
On Thu, May 07, 2020 at 04:41:30PM +0200, Cyril Brulebois wrote: > Benno Schulenberg (2020-05-07): > > Right. However... looking at the latest grub POT file > > (https://translationproject.org/POT-files/grub-2.04-pre1.pot), > > it no longer contains the "(on %s)" msgid. In fact, it does > > not contain anything from '30_os-prober.in' at all any more. :| > > > > Did something go wrong in the packaging of grub? Or did they > > eliminate the script? Or were the scripts moved to a separate > > package? > > Let's ask grub2 maintainers (cc'd). :) I think that's the thing I fixed upstream here: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=ac116bd659b295d3b9e116808d3e1d940dc0fd67 -- Colin Watson [cjwat...@debian.org]
Re: user-setup: ok for new upload to unstable?
On Fri, Jan 31, 2020 at 10:25:05PM +0100, Holger Wansing wrote: > I would like to upload user-setup to unstable soon. > > There is one commit where you are involved: > > * Add input, kvm, and render to reserved-usernames > udev.postinst adds these as system groups. > > > Any objections on me uploading this? Go for it. -- Colin Watson [cjwat...@debian.org]
Re: Bug#948695: buster-pu: package openssh/1:7.9p1-10+deb10u2
On Fri, Jan 31, 2020 at 06:49:12PM +, Adam D. Barratt wrote: > On Sat, 2020-01-18 at 19:49 +, Adam D. Barratt wrote: > > That looks fine to me, thanks (modulo the changelog being finalised), > > but will need a d-i ack due to the udebs; tagging and CCing. > > Given how close we are to the freeze for 10.3, feel free to upload and > we'll hold the package in stable-new until KiBi has chance to check it. OK, uploaded. -- Colin Watson [cjwat...@debian.org]
Re: Bug#930420: stretch-pu: package grub2/2.02~beta3-5+deb9u2
On Sat, Jul 27, 2019 at 12:39:40PM +0200, Cyril Brulebois wrote: > Adam D. Barratt (2019-07-26): > > Sorry for the delay in getting back to you regarding this. > > > > While it doesn't sound like the changes should affect d-i, I would > > still appreciate an ack on that side, so tagging and CCing > > appropriately. > > No objections, thanks. Uploaded, thanks. -- Colin Watson [cjwat...@debian.org]
Re: Grub, UEFI Secure Boot and netboot - help!
On Mon, Jun 10, 2019 at 04:15:22PM +0100, Steve McIntyre wrote: > On Mon, Jun 10, 2019 at 02:32:23PM +0100, Ian Campbell wrote: > >On Mon, 2019-06-10 at 03:37 +0100, Steve McIntyre wrote: > >> Any other suggestions on what we could do? Let me know what you > >> think... > > > >Is signing an extra, d-i specific, grubnetXX.efi image out of the > >question? > > Oh, that's a thought. Possibly, I guess. Minor tweaks to the grub > packaging and to the d-i build. That's probably the easiest route, in > fact! Colin - how does that sound for you? > > >Is the hard coded prefix a single prefix or is there a possibility of > >searching a list? > > The prefix variable is very much a single value, yes. It's used and > dereferenced all over the place inside grub as a single const char > *. Not something I'm about to play with! It'd be totally possible to make the grubnet memdisk try multiple prefixes: there's already a memdisk that looks in a couple of locations under $prefix for grub.cfg, so it could separate it into a list and try each one until it finds something usable. However, that approach embeds the debian-installer path even in images that have nothing to do with d-i; so I think on balance I prefer the idea of adding another d-i-specific image. Steve is working on that now. > >It's been a long time since I've played with any of this but I have a > >vague recollection of once upon a time using (or trying to use, maybe > >I'm remembering a failed experiment) a memdisk (builtin to the grub > >image) containing an initial config file which then was a bit more > >flexible about chaining to the next thing. I can't find any evidence > >of that setup in any of the places I thought it might be related to > >though :-/ > > Right. That's how various other things work - it's how we control > things for CD boot, for example. But network boot is a slightly > different configuration. It's simply a single binary rather than a FAT > image containing the binary and config. Moot given the above, but this isn't actually true - search for grub-netboot.cfg and memdisk-netboot.fat in build-efi-images. -- Colin Watson [cjwat...@debian.org]
Re: Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images
On Sun, May 26, 2019 at 11:05:40AM +0100, Chris Lamb wrote: > Dear Colin, > > It would be worth somebody trying out a d-i build on a system with this > > kind of configuration to see if it still breaks > ^ > > Just to clarify, building d-i on a system with [arch=...] foo in its > /etc/apt/sources.list? This is all from dubious memory, but I suspect my setup at the time was roughly an amd64 system with: deb [arch=amd64] deb ... on the grounds that my local partial mirror didn't have space for both amd64 and i386. -- Colin Watson [cjwat...@debian.org]
Re: Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images
On Fri, May 24, 2019 at 06:56:35PM -0700, Vagrant Cascadian wrote:
> Colin Watson removed it back in 2011:
>
>
> https://salsa.debian.org/installer-team/debian-installer/commit/fa965c32ca8bfa2ff14886c6f0dca131532815c7
>
> commit fa965c32ca8bfa2ff14886c6f0dca131532815c7
> Author: Colin Watson
> Date: Mon Mar 14 18:08:25 2011 +
>
> Skip the option field in sources.list lines, if present.
>
>
> diff --git a/build/util/gen-sources.list.udeb
> b/build/util/gen-sources.list.udeb
> index e86b4fa66..9f140100e 100755
> --- a/build/util/gen-sources.list.udeb
> +++ b/build/util/gen-sources.list.udeb
> @@ -36,6 +36,7 @@ get_mirrors() {
> [ -s $file ] || continue
> grep '^deb[[:space:]]' $file | \
>grep -v '^deb[[:space:]]\+cdrom:' | \
>
> + sed 's,^deb \[[^]]*\] ,deb ,' | \
>grep -v
> '\(security.debian.org\|volatile.debian.\(net\|org\)\)' | \
>
>grep '[[:space:]]main' | \
>awk '{print $1 " " $2}' | \
>
>
> Happen to remember what it breaks to have these present? If it was a
> workaround, perhaps it is no longer needed?
I'm not certain even after going through my IRC and email logs around
that time, but given the timing I suspect that it was a workaround for
multiarch systems where sources.list contained some lines with
[arch=...] options to limit them to only some architectures. I don't
remember exactly how this broke the d-i build; I assume it must have
done at the time or I wouldn't have made that change.
It would be worth somebody trying out a d-i build on a system with this
kind of configuration to see if it still breaks, but otherwise I suspect
we can drop this.
--
Colin Watson [cjwat...@debian.org]
Bug#923091: That merged-usr is mandatory is RC
On Sun, May 19, 2019 at 07:22:08AM -0400, Sam Hartman wrote:
> >>>>> "Ian" == Ian Jackson writes:
>
> Ian> (sending this because I got the release team address wrong) Ian
> Ian> Jackson writes ("That merged-usr is mandatory is RC"):
> >> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> >> base-installer option to allow installing buster without
> >> merged-usr.
> >>
> >> Guillem filed the bug as `wishlist' but given the controversy it
> >> seems to me that it should be RC if for no other reasons than
> >> social cohesion.
> >>
> >> CCing the TC FYI (they have already been involved in merged-usr
> >> debates via #914897) and the release team, in case they have an
> >> opinion. FAOD I am not a maintainer of base-files but AFAICT the
> >> base-files maintainer has not expressed an opinion about
> >> severity.
>
> I've been debating doing this, but continue to believe that it's
> important after several days of pondering. So, per constitution 5.1
> (2), I'd like to explicitly lend support to the idea that it would be
> really good if we provide our users a way to install buster without
> merged /usr. I think that if we do not do so now, we need to be open to
> the possibility that if users are stymied in doing their work, we will
> need to do so in a buster point release even if we would not normally
> add something some might consider a feature in a point release.
>
> I'm not speaking to whether I think it should be RC or even whether an
> expert only option is good enough.
> I am simply saying that with my DPL hat on, I think this issue is
> important enough it deserves real consideration.
I've posted
https://salsa.debian.org/installer-team/base-installer/merge_requests/1
to add a low-priority question for this, following Cyril's advice in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923091#10. The text
may not be quite perfect, but I think it's a decent start.
I've deliberately avoided changing the default behaviour in this patch:
its effect is simply to make the behaviour configurable either via
expert mode or using preseeding (by setting base-installer/usrmerge to
false). This is to maximise the chance of being able to get this change
into buster with a minimum of controversy of its own. It is of course
simple to change the default behaviour and/or how prominently the
question is presented by way of follow-up changes, if the project so
chooses.
--
Colin Watson [cjwat...@debian.org]
Bug#925414: debian-installer: fails to install on xfs
Control: reassign -1 src:grub2 2.02+dfsg1-13 Control: close -1 2.02+dfsg1-14 Control: merge 924760 -1 On Sun, Mar 24, 2019 at 06:59:31PM +0100, Cyril Brulebois wrote: > This is with a daily from 2019-03-24 but I'm not sure this is due to > some kernel module mismatch between d-i and the installed system… For future reference, kernel module mismatches can't cause this type of error. The relevant bit of GRUB's filesystem handling runs in userspace, and only needs access to the block device. > Installing with default ext4, with or without encrypted LVM works just > fine, but grub fails when trying to install on plain xfs: > > Mar 24 17:35:57 grub-installer: info: Installing grub on '/dev/sda' > Mar 24 17:35:57 grub-installer: info: grub-install does not support > --no-floppy > Mar 24 17:35:57 grub-installer: info: Running chroot /target grub-install > --force "/dev/sda" > Mar 24 17:35:57 grub-installer: Installing for i386-pc platform. > Mar 24 17:35:58 grub-installer: grub-install: error: > Mar 24 17:35:58 grub-installer: > Mar 24 17:35:58 grub-installer: unknown filesystem > Mar 24 17:35:58 grub-installer: . > Mar 24 17:35:58 grub-installer: error: Running 'grub-install --force > "/dev/sda"' failed. The syslog shows that 2.02+dfsg1-13 was installed. I already fixed this in 2.02+dfsg1-14 - it's just not in testing yet: grub2 (2.02+dfsg1-14) unstable; urgency=medium * Make signed packages depend on a matching version of grub-common, in an attempt to prevent incorrect testing migrations (closes: #924814). * Cherry-pick from upstream: - xfs: Accept filesystem with sparse inodes (closes: #924760). * Minimise writes to EFI variable storage (closes: #891434). -- Colin Watson Sat, 23 Mar 2019 09:47:10 + Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#924760: logfiles...
Control: reassign -1 src:grub2 2.02+dfsg1-13 On Sun, Mar 17, 2019 at 11:31:46PM +0100, Samuel Thibault wrote: > Ok. It looks like os-prober finds the sda1 EFI partition fine, and > apparently "dummy" is correct for EFI platforms. Yes. (Actually it's just ignored, but having it there makes grub-installer's code a little simpler.) > But then > > grub-installer: info: Running chroot /target grub-install --force "dummy" > grub-installer: Installing for x86_64-efi platform. > grub-installer: grub-install: error: unknown filesystem. > > so I guess somehow the grub2 package doesn't manage to find its way with > an xfs filesystem for '/', thus Cc-ing grub2 maintainers, just > reassigning to grub-installer for now. Looks very much like the bug fixed upstream here: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=cda0a857dd7a27cd5d621747464bfe71e8727fff I'll cherry-pick that patch. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#923675: debian-installer: delays when using an https mirror due to rng
I don't have much advice on fixing it, but I expect that network-console has a similar problem since it also needs randomness in order to deal with SSH. -- Colin Watson [cjwat...@debian.org]
Re: [debian-installer packages] upload of pending changings?
On Sun, Dec 23, 2018 at 02:49:23PM +0100, Holger Wansing wrote: > there are some packages with pending 'coding' changings (other than > translation > changings), which we would want to be uploaded for Buster. > > Since there are also pending translation changings in some of that packages, > I would like to have uploads for those, but ask for an extra confirmation, if > the coding changings are uncritical for me to upload. As far as I know all the ones where you've listed my name are fine to upload. -- Colin Watson [cjwat...@debian.org]
Bug#902924: debootstrap: doesn't mount /proc when building chroot inside LXD container
Package: debootstrap Version: 1.0.105 Severity: important User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic All the automatic builds of Ubuntu live filesystems started failing today. I tracked this down to changes in debootstrap 1.0.105. Here's how to reproduce it locally: $ lxc launch images:debian/sid/amd64 debootstrap-test $ lxc exec debootstrap-test -- apt -y install debootstrap $ lxc exec debootstrap-test -- debootstrap cosmic /build-cosmic http://archive.ubuntu.com/ubuntu [...] W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /build-cosmic/debootstrap/debootstrap.log for details (possibly the package rsyslog is at fault) I: Configuring rsyslog... W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /build-cosmic/debootstrap/debootstrap.log for details (possibly the package rsyslog is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /build-cosmic/debootstrap/debootstrap.log for details (possibly the package rsyslog is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /build-cosmic/debootstrap/debootstrap.log for details (possibly the package rsyslog is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /build-cosmic/debootstrap/debootstrap.log for details (possibly the package rsyslog is at fault) I understand that it may be tempting to write this off as an Ubuntu bug (and by the time you try to reproduce this it may well be that rsyslog has been changed to work around this), but I don't think it is. Bootstrapping Debian sid seems to work OK, but I think that's just luck. The problem appears to be that setup_proc detects that it's running inside a LXC container (actually LXD in this case, but it's still container=lxc) and decides that this means that it doesn't need to mount /proc or /sys; I think the original problem was perhaps that it couldn't mount them due to lack of permissions. The original history seems to be from #731802, in which the second stage was being run inside LXC and the container environment had already mounted /proc, or something like that. But the fix for that problem isn't correct in this case. debootstrap happens to be running inside a LXD container, sure, but we aren't using separate first and second stages, so the container environment clearly can't be responsible for mounting /proc and /sys inside the newly-created chroot. At minimum, I'd suggest that the special handling for container environments should be restricted to the case where debootstrap is running with a separate second stage. Furthermore, I'd have thought that, even if debootstrap is running with a separate second stage inside a LXC/LXD container, it should at least still check whether /proc and /sys are mounted and mount them if they aren't, rather than assuming that they must be mounted. Thanks, -- Colin Watson [cjwat...@ubuntu.com]
Bug#893300: cdebconf: Adding support for a pkg.cdebconf.nogtk build-profile
On Mon, Mar 26, 2018 at 12:50:26PM +0200, Karsten Merker wrote: > On Mon, Mar 26, 2018 at 12:47:18AM +0100, Colin Watson wrote: > > I think this would be clearer reversed, i.e.: > > > > DEB_FRONTENDS=passthrough text newt > > UDEB_FRONTENDS=passthrough text newt > > > > ifeq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),) > > DEB_FRONTENDS+=gtk > > UDEB_FRONTENDS+=gtk > > endif > > That's probably a matter of taste :-). I found it clearer to > have the primary DEB_FRONTENDS and UDEB_FRONTENDS assignments to > always represent the default case when no build-profiles are > enabled and only modify them in the "non-standard" case of having > a build-profile set. If you have a strong preference for the > "additive" version instead of the "subtractive" version, please > let me know and I'll change that. It's not a strong preference; feel free to disregard my comment if you have a strong preference the other way. -- Colin Watson [cjwat...@debian.org]
Bug#893300: cdebconf: Adding support for a pkg.cdebconf.nogtk build-profile
On Sat, Mar 17, 2018 at 09:09:11PM +0100, Karsten Merker wrote: > I would like to add support for a "pkg.cdebconf.nogtk" build-profile > to cdebconf. Background for that is that cdebconf (in particular > libdebconfclient0) is needed rather early in the process of > bootstrapping a new Debian architecture, but getting it built during > early architecture bootstrap is difficult due to its build-dependency > on gtk+cairo, which pulls in an enormous list of transitive > build-dependencies that are effectively impossible to fullfill in a > bootstrap scenario. This approach and patch looks good to me. I'm OK with you committing and uploading it, modulo the comments below. > diff --git a/debian/rules b/debian/rules > index b2b35f4d..8b85a7af 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -21,6 +21,11 @@ LIBDEBCONF=libdebconfclient0 > DEB_FRONTENDS=passthrough text newt gtk > UDEB_FRONTENDS=passthrough text newt gtk > > +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),) > +DEB_FRONTENDS:=$(filter-out gtk,$(DEB_FRONTENDS)) > +UDEB_FRONTENDS:=$(filter-out gtk,$(UDEB_FRONTENDS)) > +endif I think this would be clearer reversed, i.e.: DEB_FRONTENDS=passthrough text newt UDEB_FRONTENDS=passthrough text newt ifeq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),) DEB_FRONTENDS+=gtk UDEB_FRONTENDS+=gtk endif > +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),) > + dh_install -plibdebconfclient0-dev > src/modules/frontend/gtk/cdebconf_gtk.h usr/include/cdebconf/ > +endif I think I may understand what this is doing now after some confusion, but it's pretty opaque and definitely needs at least a comment. I think you're trying to keep the package contents identical regardless of build profile, since the main build system won't handle it in this case due to the change in *_FRONTENDS? Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#885712: libdebian-installer should not use -Werror
On Sat, Dec 30, 2017 at 06:08:30PM +0100, Cyril Brulebois wrote: > Karsten Merker <mer...@debian.org> (2017-12-30): > > while -Werror can help in finding bugs, I agree with Helmut that > > it makes the job of bootstrapping a lot harder than it already is > > without that. The use of -Werror is therefore always a tradeoff, > > and in this case I don't think that the advantages of having > > -Werror enabled by default justify the costs, so I would like to > > apply the patch unless one of you objects. > > Having had to strip a bunch of them earlier, I can see how annoying that > can be. No objections, but I'd be happy to hear about other uploaders. No objections here either. -- Colin Watson [cjwat...@debian.org]
Re: Permission to commit and upload?
On Tue, Oct 24, 2017 at 04:52:08PM +0200, Raphael Hertzog wrote: > On Thu, 12 Oct 2017, Cyril Brulebois wrote: > > Raphael Hertzog <hert...@debian.org> (2017-10-09): > > > I have a few pending patches that I'd like to commit and upload... but > > > since I'm only an occasional d-i contributor, I would like to double > > > check that nobody has any objection. > > > > > > My current list is: > > > - #868848: debian-installer-utils > > > - #868852: debian-installer: hd-media images > > > - #868859: iso-scan and LVM > > > - #868900: iso-scan: should be able to copy the ISO into RAM before mount > > > - #875858: integrate unattended-upgrades in pkgsel > > > > > > The first four bugs are closely related (the first two are dependencies of > > > the third) as they allow hd-media images to find an ISO image to use > > > within a logical volume. > > > > I really want someone who's worked with the ISO/hd-media codepath in the > > past to double check these. Earlier attempts at forcing these features > > onto us weren't convincing, to say the least. FWIW, this sort of strongly-worded but non-specific remark isn't particularly helpful to other reviewers (or indeed to the patch submitter, since it seems that they weren't the same person as was working on similar features last time round); it leaves us with the vague notion that something might be wrong, but no clue as to what. If you know more about the history of these features it would be good to give us slightly more in the way of details. > So I pushed and uploaded pkgsel 0.46 for #875858. For the remaining four > bugs, I have nothing against a review but I hope it does not end up > being stalled because nobody wants to review those changes. It's not clear > to me who is that person. In the iso-scan changelog, you are the last > non-translation committer and before that it was Otavio Salvador/Colin > Watson in 2012... in the hd-media image definition, many people committed > fixes for changes to udeb but I see no clear owner of that image either. > > Colin, could you review the patches I sent in the above bug reports and > let me know if you think they are suitable to be committed ? You made > similar changes to mine in debian-installer-utils and you have a broad > knowledge of debian-installer. I've left a few UX and code review comments in #868848, #868859, and #868900. Without having tried actually running them or anything, they seem reasonable to me otherwise. I don't see anything wrong with #868852, but I haven't done much with image building for some years so I don't know if there are any size concerns or whatever. If that's not an issue then it's probably fine. -- Colin Watson [cjwat...@debian.org]
Bug#868900: iso-scan: should be able to copy the ISO into RAM before mount
On Wed, Jul 19, 2017 at 05:19:21PM +0200, Raphael Hertzog wrote:
> When you use an ISO image stored on a disk, it makes it impossible to
> re-use that disk in the installation process (e.g. for automatic
> partitioning).
>
> In order to avoid this limitation, I would like iso-scan to be able
> to copy the ISO image into RAM and to mount it from there. The attached
> patch implements precisely when the debconf question
> "iso-scan/copy_iso_to_ram"
> returns true.
>
> It would be nice to see this merged (the patch applies cleanly on top
> of the one in #868859, but you can also merge it separately if you drop
> the changelog entry).
>
> Let me know if there's anything to improve before it's ready to be merged
> (notably on the debconf template, etc.).
This generally seems like a nice feature to have. A couple of general
UX comments:
* Would it be worth doing an explicit check of how much free memory is
available and either warning the user or just refusing outright to do
the copy-to-RAM operation if they don't have enough (size of image
plus fudge factor)? As it is, the user really doesn't have much
information to go on when answering this question; they'd have to
switch to a shell just to find out how much free memory they have.
Normally this sort of test would be very unreliable, but in the
context of d-i I think it could be made somewhat reasonable.
* We should warn the user that, if they opt to copy the image into RAM,
then they mustn't reboot between partitioning and the end of the
installation as their installation media may be made unusable.
(Wordsmithing this into something comprehensible is left as an
exercise for the reader.)
diff --git a/debian/iso-scan.postinst b/debian/iso-scan.postinst
index e34f329..1109ba5 100755
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -203,9 +203,26 @@ use_this_iso () {
local iso_device=$2
local RET
+ db_input low iso-scan/copy_iso_to_ram || true
+ db_go
+ db_get iso-scan/copy_iso_to_ram
+
mount -t auto -o ro $iso_device /hd-media 2>/dev/null
cd /hd-media
- mount -t iso9660 -o loop,ro,exec $iso_to_try /cdrom 2>/dev/null
+
+ if [ "$RET" = false ]; then
+ # Direct mount
+ log "Mounting /hd-media/$iso_to_try on /cdrom"
+ mount -t iso9660 -o loop,ro,exec $iso_to_try /cdrom 2>/dev/null
+ else
+ # We copy the ISO to RAM before mounting it
+ log "Copying /hd-media/$iso_to_try to /installer.iso"
+ cp $iso_to_try /installer.iso
+ log "Mounting /installer.iso on /cdrom"
+ mount -t iso9660 -o loop,ro,exec /installer.iso /cdrom
+2>/dev/null
+ cd /
+ umount /hd-media
+ fi
analyze_cd
The directory-changing here is messy, and left me wondering whether
analyze_cd might depend on the current directory, which is now different
depending on which option you select. I don't think it does, but I had
to read that function to make sure. I'd suggest simplifying this
section of code by mounting or copying by absolute path, i.e.
"/hd-media/$iso_to_try", rather than relying on it being in the current
directory; you then won't need either "cd /hd-media" or "cd /" in this
function.
--
Colin Watson [cjwat...@debian.org]
Bug#868859: iso-scan: should also scan LVM logical volumes
On Wed, Jul 19, 2017 at 11:48:48AM +0200, Raphael Hertzog wrote: > With this patch, I ensure that we activate LVM logical volumes so that > they are visible by "list-devices" and so that they can be scanned too. > > That way we are also able to identify ISO images stored within LVM > logical volumes. Seems basically OK. > Obviously this has implications on the rest of the installation process. > The logical volume will be in use and the partitioning step will have > to preserve the logical volume and its parent volume group. > > But partman is perfectly able to cope with the logical volumes being > already activated so it should be fine to do this here. I agree that it ought to work, but what testing have you done of this? Have you confirmed that the LV is marked as locked in partman and can't be changed using manual partitioning operations? What happens with automatic partitioning? (iso-scan will already provoke this kind of situation for ordinary partitions, of course, but LVM partitioning is different enough that I'd like to know that it's been explicitly checked.) > + if type vgchange >/dev/null; then Nit: it's worth ">/dev/null 2>&1" here, as "type" writes to stderr if the command isn't available, and that's probably just noise in the logs. -- Colin Watson [cjwat...@debian.org]
Bug#868848: debian-installer-utils: "list-devices partition" should report LVM logical volumes too
On Wed, Jul 19, 2017 at 10:29:59AM +0200, Raphael Hertzog wrote: > Just like "list-devices partition" reports back RAID partitions, it should > also report LVM logical volumes. The attached patch does this. I think this is basically a reasonable thing to do, but it seems to me that it's going to cause rescue-mode to list LVs twice (see the choose_root function). Could you fix that? A sensible approach would probably be to exclude entries from LVMPARTS that are already in PARTITIONS, and we can simplify that later once the new list-devices is in place. > My goal is to extend the "hd-media" image to be able to find the ISO image > within an LVM logical volume too. This is a preliminary step in this > project. > > Currently, I'm not hiding the partitions used by the various volume > groups. This is unlike what has been done for RAID partitions. But > I don't know all the places where list-devices is used "mr grep" is useful here, as there aren't all that many. > and I'm not convinced that it's really required either (it's not a > requirement for iso-scan at least). I'm ccing Colin, he might have > some insight to share on this. I could go either way on this, but I think it would probably make most sense to exclude partitions already in use by VGs. "list-devices partition" is generally used to offer menus of partitions to find various files on, for which in-use PVs aren't going to be eligible; and the LVM assembly code uses its own code to find partitions. -- Colin Watson [cjwat...@debian.org]
Re: debootstrap bashisms
Control: tag 860545 pending On Mon, Jul 24, 2017 at 04:11:49PM +0200, Sven Joachim wrote: > On 2017-07-24 15:06 +0100, Colin Watson wrote: > > On Sat, Jul 22, 2017 at 08:17:37PM -0400, Drew DeVault wrote: > >> Looks like debootstrap uses bashisms, but is shebanged to /bin/sh. > >> Should probably just be /usr/bin/env bash. > > > > debootstrap can't use bashisms: it runs in the Debian installer > > environment where bash doesn't exist. What bashisms have you observed? > > There is the 'type' bashism which prevents debootstrap from running > under posh, see #860545. I am not aware of any others. (I somewhat disagree with referring to XSI extensions as bashisms.) Thanks; I've applied your patch from #860545, with a few further adjustments on top. I haven't yet had a chance to test and upload it, but that'll happen at some point. -- Colin Watson [cjwat...@debian.org]
Re: debootstrap bashisms
On Sat, Jul 22, 2017 at 08:17:37PM -0400, Drew DeVault wrote: > Looks like debootstrap uses bashisms, but is shebanged to /bin/sh. > Should probably just be /usr/bin/env bash. debootstrap can't use bashisms: it runs in the Debian installer environment where bash doesn't exist. What bashisms have you observed? -- Colin Watson [cjwat...@debian.org]
Re: [PATCH] Cope with more unset/disabled root password options
On Fri, Jul 07, 2017 at 04:20:10PM +0100, Steve McIntyre wrote:
> Recognise and cope with a different *disabled* root password ("!*") in
> /etc/shadow as well as the normal unset one ("*"). Closes: #866206,
> fixing a major bug in the live installer.
Looks good to me, though at this point it might be worth refactoring
that conditional a bit to assign the grep output to a local variable to
avoid the repeated subprocess invocations.
--
Colin Watson [cjwat...@debian.org]
Bug#861300: cdrom-detect: Please merge changes from Ubuntu
On Thu, Apr 27, 2017 at 09:42:47AM +0200, Balint Reczey wrote:
> Please merge changes from the delta carried by Ubuntu:
For the record, this does not have my approval even though some of the
commits are in my name. It would generally be polite to at least try to
ask people named as committers before you send patches attributed to
them (and also e.g. ask what email addresses they prefer to be used for
the patches you've generated in their name: I never use
colin.wat...@canonical.com except in situations where it's been chosen
for me and I have no alternative).
> commit 44dc46c133fa5e87d27eeef4c936e44cb886602b
> Author: Balint Reczey <balint.rec...@canonical.com>
> Date: Wed Apr 26 21:07:42 2017 +0200
>
> Show Ubuntu name on Ubuntu
>
> Build depend on dpkg-dev (>= 1.15.1) and patch to do so.
This is thoroughly gross in a native package, and I don't think it
should be accepted. Branding patches are annoying but basically a
necessary reality.
The only sensible way to avoid carrying these patches in downstream
distributions is to debrand altogether, i.e. not mention Debian in d-i
strings. In some cases that's reasonable, but I don't think it can be
done everywhere.
(And no, db_subst isn't a solution in the general case: while it isn't a
problem in this specific case, in general, different proper names are
translated in various ways in different languages, may undergo
declension, etc. My stock example of this is "a Debian image" vs. "an
Ubuntu image", but there's a wide range of complexity here.)
If I were putting the effort into figuring out how to merge this
properly rather than just forwarding patches directly, I'd work out a
rephrasing of the log messages that was more generic and didn't require
branding, and I'd generate the cdrom/suite template at build time in a
way that's reasonably easy to maintain (.in files or similar).
Committing a patch file like this is right out: not only are they highly
unconventional in native packages but in practice they're a pain to
maintain and tend to bitrot.
> commit 08cfa29937f3dfbe796cab4d7e05bf2dd8808f40
> Author: Colin Watson <colin.wat...@canonical.com>
> Date: Wed Apr 26 20:08:41 2017 +0200
>
> Update translations for using hdparm
>
> Those changes should be done in d-i master po files
This should be disregarded and should not have been sent. These are
translations I fetched from Launchpad, and they may have different
vocabulary standards etc. d-i manages its own translations, and d-i
translators are unlikely to thank you for committing unchecked
translations to their languages.
If the underlying hdparm change were committed (but see below), then it
might make sense to send copies of the various translated strings to the
list as a courtesy so that translators could use them as a reference if
they wanted to, but not to commit them.
> commit 5f509c6af43f90f8800490ae87287d69678c5445
> Author: Colin Watson <colin.wat...@canonical.com>
> Date: Wed Apr 26 20:02:14 2017 +0200
>
> Optionally set CD-ROM drive parameters with hdparm
I have mixed feelings about this. It's a low-priority question,
probably of pretty limited use nowadays as apparently nobody ever
thought to enable it on amd64, and I suspect it's largely unused. It
made some difference in 2004 but now it's 2017. My inclination would be
to just drop this from Ubuntu, which would substantially reduce the size
of our delta.
> commit c061fc52c2b5ff1dc2f720df7dc795d0e0b121a9
> Author: Colin Watson <colin.wat...@canonical.com>
> Date: Wed Apr 26 19:10:44 2017 +0200
>
> Extend device-scan delay to wait for usb-partition and mmc-partition
>
> commit 2ea63bb2703436cfa7695fe27ce5042d1eaf67fd
> Author: Loïc Minier <l...@dooz.org>
> Date: Wed Apr 26 19:08:40 2017 +0200
>
> Also check SD/MMC partitions ("list-devices mmc-partition")
>
> Closes: LP: #364604
These rely (in part in the case of c061fc52, and in its entirety in the
case of 2ea63bb2) on a change to debian-installer-utils, which you
haven't forwarded.
> commit 5414150bde29d7f1432ae91eeb62c5dad8e0e3a2
> Author: Colin Watson <colin.wat...@canonical.com>
> Date: Wed Apr 26 18:37:29 2017 +0200
>
> Copy /cdrom/.disk/info to /var/log/media-info
>
> in order that we get /var/log/installer/media-info on the installed
> system; doing this in save-logs is too late because /cdrom is already
> unmounted by that point.
>
> Closes: LP: #364649
This is probably vaguely reasonable.
--
Colin Watson [cjwat...@ubuntu.com]
Bug#861237: main-menu: Please show "Ubuntu installer ..." on ubuntu
On Wed, Apr 26, 2017 at 01:59:37PM +0200, Balint Reczey wrote: > Please show "Ubuntu installer ..." or the localized string when > building the package for Ubuntu. > Please find the attached patches solving this. I don't think this is OK. Patch files committed to native packages tend to bitrot quite quickly because there's little in the way of tooling to support them, so instead of a three-minute merge job (seriously, I've done this a lot and with practice that's what it is) suddenly it's a longer and much less predictable/automatable job of figuring out what's gone wrong with the patch and fixing it up. Not a great tradeoff. It's also actively worse in the long run to have the Ubuntu translations *added* to the Debian translations as you've done, rather than being in-place modifications. This means that Ubuntu translations will fail to pick up corrections to the Debian translations: even in a string as simple as this, that can and does happen. > Maybe Debian could provide the localized strings. I don't think that's a fair request to make of Debian translators, which is why I never made it in over ten years of carrying forward this patch. I'm not going to close this with my Ubuntu hat on, but I think that d-i folks should decline this patch. For the reasons given above, it's worse for both Debian and Ubuntu. -- Colin Watson [cjwat...@ubuntu.com]
Re: Bug#857741 closed by Emilio Pozuelo Monfort <po...@respighi.debian.org> (unblock openssh)
Control: reopen -1
Control: retitle -1 unblock: openssh/1:7.4p1-9
I'm afraid that 1:7.4p1-8 caused a CI failure, and on investigation this
was a real problem easily reproduced in a local adt-run. Sorry for not
noticing this earlier. I've uploaded 1:7.4p1-9 to fix this with the
following diff. This will presumably need another d-i ack, and
certainly an adjustment to the existing hint.
diff -Nru openssh-7.4p1/debian/.git-dpm openssh-7.4p1/debian/.git-dpm
--- openssh-7.4p1/debian/.git-dpm 2017-03-14 13:41:39.0 +
+++ openssh-7.4p1/debian/.git-dpm 2017-03-16 13:42:23.0 +
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-a0f9daa9c3cc2b37b9707b228263eb717d201371
-a0f9daa9c3cc2b37b9707b228263eb717d201371
+35b2ea77a74348b575d680061f35ec7992b26ec8
+35b2ea77a74348b575d680061f35ec7992b26ec8
971a7653746a6972b907dfe0ce139c06e4a6f482
971a7653746a6972b907dfe0ce139c06e4a6f482
openssh_7.4p1.orig.tar.gz
diff -Nru openssh-7.4p1/debian/changelog openssh-7.4p1/debian/changelog
--- openssh-7.4p1/debian/changelog 2017-03-14 13:49:14.0 +
+++ openssh-7.4p1/debian/changelog 2017-03-16 13:43:15.0 +
@@ -1,3 +1,10 @@
+openssh (1:7.4p1-9) unstable; urgency=medium
+
+ * Fix null pointer dereference in ssh-keygen; this fixes an autopkgtest
+regression introduced in 1:7.4p1-8.
+
+ -- Colin Watson <cjwat...@debian.org> Thu, 16 Mar 2017 13:43:15 +
+
openssh (1:7.4p1-8) unstable; urgency=medium
* Fix ssh-keygen -H accidentally corrupting known_hosts that contained
diff -Nru openssh-7.4p1/debian/patches/series
openssh-7.4p1/debian/patches/series
--- openssh-7.4p1/debian/patches/series 2017-03-14 13:41:39.0 +
+++ openssh-7.4p1/debian/patches/series 2017-03-16 13:42:23.0 +
@@ -32,3 +32,4 @@
restore-authorized_keys2.patch
ssh-keygen-hash-corruption.patch
ssh-keyscan-hash-port.patch
+ssh-keygen-null-deref.patch
diff -Nru openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch
openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch
--- openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch1970-01-01
01:00:00.0 +0100
+++ openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch2017-03-16
13:42:23.0 +
@@ -0,0 +1,31 @@
+From 35b2ea77a74348b575d680061f35ec7992b26ec8 Mon Sep 17 00:00:00 2001
+From: "dtuc...@openbsd.org" <dtuc...@openbsd.org>
+Date: Mon, 6 Mar 2017 02:03:20 +
+Subject: upstream commit
+
+Check l->hosts before dereferencing; fixes potential null
+pointer deref. ok djm@
+
+Upstream-ID: 81c0327c6ec361da794b5c680601195cc23d1301
+
+Origin:
https://anongit.mindrot.org/openssh.git/commit/?id=18501151cf272a15b5f2c5e777f2e0933633c513
+Last-Update: 2017-03-16
+
+Patch-Name: ssh-keygen-null-deref.patch
+---
+ ssh-keygen.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ssh-keygen.c b/ssh-keygen.c
+index 0833ee61..a7c1e80b 100644
+--- a/ssh-keygen.c
b/ssh-keygen.c
+@@ -1082,7 +1082,7 @@ known_hosts_hash(struct hostkey_foreach_line *l, void
*_ctx)
+ struct known_hosts_ctx *ctx = (struct known_hosts_ctx *)_ctx;
+ char *hashed, *cp, *hosts, *ohosts;
+ int has_wild = l->hosts && strcspn(l->hosts, "*?!") != strlen(l->hosts);
+- int was_hashed = l->hosts[0] == HASH_DELIM;
++ int was_hashed = l->hosts && l->hosts[0] == HASH_DELIM;
+
+ switch (l->status) {
+ case HKF_STATUS_OK:
unblock openssh/1:7.4p1-9
Thanks,
--
Colin Watson [cjwat...@debian.org]
signature.asc
Description: Digital signature
Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
On Sun, Feb 26, 2017 at 06:30:31PM +, Steven Chamberlain wrote: > The regression in Bug#856215 in cdebootstrap: > "since SHA1 removal from Release file, only MD5sums are used" > could only be fixed by adding support for the SHA256 fields. Just FYI, since it's not clear from https://wiki.debian.org/InstallerDebacle that you know this, the installer in fact uses debootstrap rather than cdebootstrap to install the base system. AFAIK debootstrap has supported SHA256 since version 1.0.28 in 2011. > An open question is whether to preserve any support for MD5. > Keeping it would: > > + reduce potential for breakage (in case MD5 is "good enough" for some > use-case or SHA256 is still impractical) > + allow verifiers to check both MD5 *and* SHA256, for even stronger > authentication in case one or both algorithms are broken Checking both adds only negligible security (look up "multicollisions") and is a waste of time. The usual reason to keep support for older hash algorithms is just to make transitions to newer ones less painful. -- Colin Watson [cjwat...@debian.org]
Re: os-prober top level directory change
On Wed, Feb 15, 2017 at 08:02:06PM +0300, Andrei Borzenkov wrote: > Up to 1.70 it had top level directory as os-prober-$version and 1.74 has > top level directory simply as os-prober. I'm fine either way but is it > permanent and intentional change? It is not mentioned in changelog. This depends on how the uploader happened to invoke the Debian source package building tools. You should be prepared to cope with either. -- Colin Watson [cjwat...@debian.org]
Thoughts on os-prober 2.0
whose conditions are satisfied. This would be easy to test: since this would be separate from device manipulations, we could feed it a directory tree and/or some simulated parser output and let it go from there. The existing documented command-line interface would be preserved exactly as it is. The only integration issue for d-i would be that we'd need a libyaml udeb, which shouldn't be a big deal (os-prober is only used quite late, when it's used in the installer environment at all). Does anyone object to this outline plan, or have other considerations I haven't taken into account? I propose to prototype this in Python (in my copious free time of course ...) and then translate it to C once the general shape of things is working. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#808514: os-prober: Does no longer recognize Windows 7
On Sun, Dec 20, 2015 at 04:21:32PM +0100, Andreas Tscharner wrote: > I updated my system (about two weeks ago, e.g. at the beginnig of > december 2015) and grup was also updated. After that it had no longer > an entry for Windows 7. My Windows partition is /dev/sda2, but > os-prober says: > > Dec 20 15:59:03 shannara 20microsoft: debug: /dev/sda2 is a FUSE partition > Dec 20 15:59:03 shannara os-prober: debug: running > /usr/lib/os-probes/mounted/30utility on mounted /dev/sda2 > Dec 20 15:59:03 shannara 30utility: debug: /dev/sda2 is not a FAT partition: > exiting > > As written above: It worked until about two weeks ago. Is there a "bootmgr" file (regardless of case) at the top level of the Windows file system? Can you attach the "/boot/bcd" file (again, regardless of case) from the Windows file system? Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#674561: A patch to improve parsing yaboot.conf
On Fri, May 25, 2012 at 05:14:49PM +0430, Hedayat Vatankhah wrote: > os-prober assumes that there is no space around '=' sign for append > directive in yaboot.conf, while there can be. Therefore, both append="some > options" and append = "some options" are valid in yaboot.conf. This patch > fixes this parsing bug. I don't really understand why this only applies to the "append" option (I suspect that in fact it doesn't), but whatever - this will do for now. I converted your patch to POSIX sed syntax and applied it. Thanks, -- Colin Watson [cjwat...@debian.org]
Re: Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*
Source: grub2 Source-Version: 2.02~beta3-1 On Sat, Nov 26, 2016 at 09:56:46PM +0100, Cyril Brulebois wrote: > Colin Watson <cjwat...@debian.org> (2016-11-26): > > Yep, as Thomas said, this changed back to the original state in > > 2.02~beta3. I think that in fact allows us to close #741656 if you also > > revert your previous workaround in d-i, but please confirm. Compare: > > > > > > https://anonscm.debian.org/cgit/pkg-grub/grub.git/commit/?id=496cca85259c77b5fc8ad39a9064c83c3a39b7a6 > > > > (Sorry, I forgot that d-i had worked around this.) > > (No worries.) > > Yeah, a revert was what I had in mind, but I thought I'd double check > anyway. Just pushed it, triggered a build on falla and fischer, and > builds seem happier now. Thanks! > > I think this bug report should be closed now? Indeed, thanks. Done with this message. -- Colin Watson [cjwat...@debian.org]
Re: Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*
On Sat, Nov 26, 2016 at 06:17:28AM +0100, Cyril Brulebois wrote: > kfreebsd-* builds are now failing to build with: > | # Create the ISO with Joliet extensions, needed for win32-loader.ini > | # NOTE: "-- -J" is a workaround for #741656 in grub-common > | grub-mkrescue --output=./tmp/netboot-10/mini.iso ./tmp/netboot-10/cd_tree > -- -J > | xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project. > | > | xorriso : FAILURE : Not a known command: '-J' > | > | xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' > | install -m 644 -D ./tmp/netboot-10/mini.iso dest/netboot-10/mini.iso > | install: cannot stat './tmp/netboot-10/mini.iso': No such file or directory > | Makefile:798: recipe for target 'dest/netboot-10/mini.iso' failed > > I think that started with grub2 (2.02~beta3-1) reaching unstable: > https://tracker.debian.org/news/805858 > > as upload timing would match the start of the FTBFS according to graphs > on the summary page: > https://d-i.debian.org/daily-images/daily-build-overview.html > > Also, util/grub-mkrescue.c's argument handling got changed between grub2 > 2.02~beta2-36 and 2.02~beta3-1. Yep, as Thomas said, this changed back to the original state in 2.02~beta3. I think that in fact allows us to close #741656 if you also revert your previous workaround in d-i, but please confirm. Compare: https://anonscm.debian.org/cgit/pkg-grub/grub.git/commit/?id=496cca85259c77b5fc8ad39a9064c83c3a39b7a6 (Sorry, I forgot that d-i had worked around this.) -- Colin Watson [cjwat...@debian.org]
Re: Build dependencies of debian-installer source package in Jessie
On Thu, Jul 21, 2016 at 05:33:57PM +0800, river wrote: > I just found that in Jessie, package glibc-pic in the build dependencies of > debian-installer actually doesn't exists. It's a virtual package, provided by (depending on architecture) libc6-pic or similar. -- Colin Watson [cjwat...@debian.org]
Re: Frustration working with i18n/l10n
On Sat, Jul 02, 2016 at 12:18:52PM +0100, Steve McIntyre wrote: > When I can see that the changes I've made can be very easily > mechanically updated in po files too, I *want* to be able to make > those updates too. Especially in cases where the existing translations > are obvious going to be wrong/incorrect, I'd like to be able to update > them where I can. How exactly do I do that? Translations are still in Subversion, at svn+ssh://svn.debian.org/svn/d-i in the packages/po directory, broken up by sublevel. The master .po files there get propagated to packages by the cron job you ran into. > [1] http://d-i.alioth.debian.org/doc/i18n/ http://d-i.alioth.debian.org/doc/i18n/ch01s04.html#idm45330184357456 is the bit that's particularly relevant here, I think. -- Colin Watson [cjwat...@debian.org]
Bug#610206: partman-auto: please make larger newworld bootblock by default (maybe 5MiB?)
On Sun, May 29, 2016 at 02:56:41PM +0200, Mathieu Malaterre wrote: > https://anonscm.debian.org/cgit/d-i/partman-auto.git/commit/?id=a22ea6526cd3d77f8fe931c59e29a94fb386ab30 > > But I fail to understand the syntax for this file ? Where is the > documentation for the syntax. https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/doc/devel/partman-auto-recipe.txt -- Colin Watson [cjwat...@debian.org]
Re: removing ftp:// from mirrors lists
On Thu, Apr 14, 2016 at 08:50:11PM +0100, David Precious wrote: > FTP is, after all, designed for file transfers, and programatically > fetching file lists cleanly from an FTP server is easier than HTTP > mirrors, so is probably easier for e.g. a netboot installer or other > client to make use of, no? Despite the name, HTTP is a superior file transfer protocol to FTP in just about every way, except in some situations for the lack of reliable directory listings. It is a particularly unfortunate source of confusion that FTP has the name it does. Yes, it was designed for file transfers, but that was over three decades ago and things like HTTP pipelining make a big difference if there's any amount of latency involved. But to address your last suggestion: no, FTP is not in fact any easier from that point of view. For installers and apt-style clients in general, the lack of directory listings makes exactly no difference at all. They always start by fetching index files from a known location, and then use those to determine the URLs to the various other files they need to fetch. All these operations are essentially trivial uses of HTTP, and FTP's directory listing support offers no advantage at all. -- Colin Watson [cjwat...@debian.org]
Re: Simultaneous EFI and Legacy bootloader installation
On Tue, Mar 29, 2016 at 07:50:27PM -0500, mario_limoncie...@dell.com wrote:
> I was briefly discussing this with Steve McIntyre and wanted to bring
> it to a wider discussion. Currently users need to make a selection at
> installation time whether to install in UEFI mode or in Legacy mode.
In fact pre-installation, because it depends on how they told the
firmware to boot the installer. I'd expect modern systems to have
defaults that lead to UEFI mode, and for this to predominantly be an
issue on older systems, which means that we need to give more weight to
considerations that apply to older systems.
> If they installed in legacy mode and later discovered that their
> system supported extra features in UEFI mode (For example firmware
> updates) they are penalized and need to redo the installation in order
> to switch modes.
>
> I'd like to propose changing this and by default install both legacy
> and UEFI bootloaders on architectures that support both regardless of
> which mode the system is running in at installation.
I'm pretty wary about this because it seems likely to exacerbate the
already far too common problems where people end up booting from a GRUB
installation they don't realise they're booting from, and then at some
point in the future something changes so that some subset of the
installed GRUB instances don't get updated properly and then everything
explodes mysteriously. (Usually I find out about this when I upload
GRUB and then get dozens of bug reports that are in fact due to some bug
in the installer from years back that's now next to impossible to track
down.) Being able to say that UEFI installations just don't need to
worry about this class of problems is a significant benefit.
> Making this change has a few obvious implications:
> * The installation disk would always be formatted GPT.
On the whole I think this is a good direction to go as it's a much
better partition table type, but a lot of BIOSes object to this in
practice unless the disk is very specifically and delicately formatted.
parted allows setting the necessary flag ("pmbr_boot"), but I don't
believe that partman has support for it as yet, and it violates the UEFI
specification so it's possible that doing this unconditionally would
cause problems later.
> * An ESP would always be created.
And, I think, also a BIOS Boot Partition, which starts feeling like a
lot of overhead on modern systems.
> * If the user is in legacy at installation time, it's not possible to
> create an EFI boot entry since EFI runtime services aren't present.
> The removable media fallback path (\efi\boot\boot$ARCH.efi) will need
> to be used to boot the system at this point and at some point create a
> "debian" NVRAM boot entry
Indeed, and this is exactly the scenario you specifically mentioned
being interested in. But this is another way that the system can work
after the initial installation but then be broken by later updates
because we change the boot path, which to my mind is much worse than not
working after the initial installation because the user has put more
effort into their system by that point.
> I'm not aware of any modern systems that are unable to boot a GPT
> partitioned disk. If there are systems like this in the wild, it
> would be worthwhile to leave support to install in MBR mode when doing
> an expert install so that people can still use them.
Remember that very many Debian installations happen on systems that are
already partitioned and frequently already have other operating systems
on them. In those cases we're stuck with the partition table type
that's already in use.
So, I'm very unconvinced about the plan to have more than one boot
loader instance think that it's responsible for booting the computer. I
think that's likely to lead to difficult-to-diagnose problems down the
line. How about a compromise? If we could at least get to the point
where we install systems with GPT and an ESP where we can even if we
aren't going to install grub-efi-amd64, then it would at least be
reasonably straightforward to switch mode by just installing
grub-efi-amd64 and removing grub-pc; you wouldn't need to redo the
installation.
That would give most of the benefits you're looking for, albeit at the
cost of a bit of documentation, without needing to break the "only one
installed boot loader thinks that it owns the system boot process" rule.
--
Colin Watson [cjwat...@debian.org]
Re: Archive changes
On Wed, Mar 16, 2016 at 12:54:03AM +0100, Cyril Brulebois wrote: > Pretty sure this breaks (will break, when the change is propagated outside > experimental) d-i as it stands, due to the check on all 3 checksums in > net-retriever. Looking at the code, I don't think that's true. It skips checksums that are missing from Release, and it stops after the first checksum that it successfully finds. Unless I'm looking at the wrong bit of net-retriever? -- Colin Watson [cjwat...@debian.org]
Re: Access to repos blocked
On Mon, Mar 07, 2016 at 02:12:59PM +0700, MH wrote: > Recently ran into a problem with aptitude. I get the following message: > > E: The method driver /usr/lib/apt/methods/https could not be found > > Since I am not using ANY HTTPS repos, I should not be getting the above > error. Are you absolutely sure? Check /etc/apt/sources.list.d/* as well as /etc/apt/sources.list. apt won't try to use that method driver unless it needs to. > Still, after searching the Internet for similar problems I installed the apt- > transport-https package. I got a different error. What specifically was that different error? > I tried to submit a request for help on the Debian forums, but when I tried > to > register I received a warning that my ISP had been blocked as a source of > spamming networks. > > I'm guessing the two issues are related, since I can still access > non-official > repositories, including Kubuntu repositories (VM) without a problem. While I > can sympathize with a need to fight spam, I don't think blocking access to > security updates is the best way to go about this. I think it's unlikely that registration issues on the forums have anything to do with access to security updates, and it's even less likely that there's any kind of unified consistent ISP blocking across all Debian mirrors (there are lots, hosted on a wide variety of different sites with different administrators). It's pretty hard to tell exactly what's going on without the exact text of the error message you're seeing, though. Regards, -- Colin Watson [cjwat...@debian.org]
Re: mangled conditional statement breaks debian in chroots
On Mon, Jan 25, 2016 at 08:06:41AM +0100, Cyril Brulebois wrote: > Maybe that was done on purpose so as not to lose the code entirely, This is what revision control is for. I've seen too many codebases that were an utter mess due to the approach of keeping stuff around in the current tree just in case it might be needed in future, iterated over years; better to nip that in the bud and trust that you can get the history from revision control if you need it. A comment explaining where to look in the case of missing device nodes would be more helpful than the current dubious-looking state. -- Colin Watson [cjwat...@debian.org]
Bug#801161: anna: handle multiple udeb versions in Packages file
free, free);
+ xregcomp (_re, "^Package:[[:space:]]+(.*)",
+ REG_EXTENDED | REG_ICASE | REG_NEWLINE);
+ xregcomp (_re, "^Version:[[:space:]]+(.*)",
+ REG_EXTENDED | REG_ICASE | REG_NEWLINE);
+ line_alloc = 0;
+ line.string = NULL;
+ entry_alloc = 4096;
+ entry.string = di_malloc (entry_alloc);
+ entry.size = 0;
+
+ while ((line_size = getline (, _alloc, stdin)) >= 0) {
+ line.size = (di_ksize_t) line_size;
+ if (*line.string && *line.string != '\n') {
+ di_ksize_t new_size;
+
+ new_size = entry.size + line.size + 1;
+ if (new_size > entry_alloc) {
+ while (new_size > entry_alloc)
+ entry_alloc *= 2;
+ entry.string = di_realloc (entry.string,
+ entry_alloc);
+ }
+ memcpy (entry.string + entry.size, line.string,
+ line.size + 1);
+ entry.size += line.size;
+ } else {
+ deduplicate_one ();
+ *entry.string = '\0';
+ entry.size = 0;
+ }
+ }
+ if (ferror (stdin)) {
+ perror ("getline");
+ ret = 1;
+ goto out;
+ }
+ if (entry.size)
+ deduplicate_one ();
+ output ();
+ ret = 0;
+
+out:
+ di_hash_table_destroy (versions);
+ di_hash_table_destroy (entries);
+ regfree (_re);
+ regfree (_re);
+ return ret;
+}
diff -Nru net-retriever-1.39/net-retriever
net-retriever-1.39ubuntu1/net-retriever
--- net-retriever-1.39/net-retriever2014-03-03 10:26:08.0 +
+++ net-retriever-1.39ubuntu1/net-retriever 2014-11-17 16:30:25.0
+
@@ -86,6 +86,12 @@
exit 1
}
+# Nasty hack to remove duplicates in Packages file.
+deduplicate () {
+ /usr/lib/net-retriever/deduplicate <"$1" >"$1.new"
+ mv "$1.new" "$1"
+}
+
cmd="$1"
shift
--
Colin Watson [cjwat...@debian.org]
Re: Integrate fully partman-reiser4 into d-i
On Sun, Sep 20, 2015 at 07:40:37AM -0700, Jose R R wrote: > I have realized that although partman-reiser4 udeb enables Reiser4 to > be listed as an option during the Debian-Installer routine of a > netboot ISO image, the lack of support for reiser4 in GNU Parted > (Debian's libparted) prevents installation from the GUI interface. It should be pretty easy to add that to parted, since nowadays the only filesystem support it has is probing support. I suggest preparing a patch against git://git.sv.gnu.org/parted.git master that adds the ability to detect existing reiser4 partitions and sending it upstream; it should only be on the order of a hundred lines. I'd be happy to cherry-pick such a patch into the Debian packaging once it has been committed upstream. -- Colin Watson [cjwat...@debian.org]
Bug#791794: UUID not found for root
On Thu, Jul 16, 2015 at 10:05:48AM -0400, Martin Michlmayr wrote: * Peter Nagel peter.na...@kit.edu [2015-07-08 15:12]: The problem seems to appear only when jessie is installed to RAID (e.g. RAID1)! Error message: flash-kernel-installer does not find UUID (see the two lines of syslog below): in-target: UUID eeb34bbe-375a-4dc1-939d-f56b801a4c75 doesn't exist in /dev/disk/by-uuid in-target: Warning: root device /dev/disk/by-uuid/eeb34bbe-375a-4dc1-939d-f56b801a4c75 does not exist I received several reports about this recently. I'm surprised because this used to work just fine. I didn't have time to investigate, but I noticed the following partman errors in the syslog of those affected. Colin, do you know what this is about? Jul 1 10:22:40 partman: mke2fs 1.42.12 (29-Aug-2014) Jul 1 10:22:45 kernel: [ 8083.996693] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: errors=remount-ro Jul 1 10:22:47 apt-install: Queueing package e2fsprogs for later installation Jul 1 10:22:47 main-menu[1537]: (process:5300): /lib/partman/choose_partition/60partition_tree/do_option: Jul 1 10:22:47 main-menu[1537]: (process:5300): line 88: Jul 1 10:22:47 main-menu[1537]: (process:5300): /lib/partman/active_partition/copy/choices: not found The copy operation was removed from partman because parted 3 no longer supports filesystem operations. However, I can't find any references to it in partman code any more. Is this perhaps coming from a preseeded partman recipe or something? Do you have a more complete syslog, preferably with DEBCONF_DEBUG=developer? On a related note, flash-kernel waits for user input when the UUID of root is not found, which makes sense in an installed system, but not in d-i -- for the user, d-i will just hang with no obvious error. Is there a good way to solve this? In particular, is there a way for a postinst in /target to detect that it's run from within d-i? KiBi doesn't know a way. I guess a debconf prompt is the way to go? I think trying to add debconf prompting to an initramfs hook would probably be unwise. flash-kernel already seems to check for DEBIAN_FRONTEND=noninteractive, so you could just set that in flash-kernel-installer.postinst when calling flash-kernel. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150716142722.gk23...@riva.ucam.org
Bug#781233: unblock: parted/3.2-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package parted; this fixes a crash when trying to resize
fat16 filesystems. CCing debian-boot since this would need a d-i ack
too.
diff -Nru parted-3.2/debian/.git-dpm parted-3.2/debian/.git-dpm
--- parted-3.2/debian/.git-dpm 2014-09-19 15:41:38.0 +0100
+++ parted-3.2/debian/.git-dpm 2014-11-06 12:21:49.0 +
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-5e4e122454ac8ecf5b5fc006c0b03f0e8adc6c7c
-5e4e122454ac8ecf5b5fc006c0b03f0e8adc6c7c
+bdfd201a2f5b8090c7ba1208fe5531d0dceecf49
+bdfd201a2f5b8090c7ba1208fe5531d0dceecf49
a3803540db7f12359a111d6449159b91032c253f
a3803540db7f12359a111d6449159b91032c253f
parted_3.2.orig.tar.xz
diff -Nru parted-3.2/debian/changelog parted-3.2/debian/changelog
--- parted-3.2/debian/changelog 2014-09-19 15:44:41.0 +0100
+++ parted-3.2/debian/changelog 2015-03-19 10:58:59.0 +
@@ -1,3 +1,15 @@
+parted (3.2-7) unstable; urgency=medium
+
+ [ Phillip Susi ]
+ * Cherry pick upstream patch to fix a crash when resizing fat16
+(LP: #1342255).
+
+ [ Colin Watson ]
+ * Drop libparted2's alternative Suggests on nparted, which has not been in
+Debian for a decade or so.
+
+ -- Colin Watson cjwat...@debian.org Thu, 19 Mar 2015 10:58:55 +
+
parted (3.2-6) unstable; urgency=medium
[ Steven Chamberlain ]
diff -Nru parted-3.2/debian/control parted-3.2/debian/control
--- parted-3.2/debian/control 2014-09-19 15:38:08.0 +0100
+++ parted-3.2/debian/control 2015-03-19 10:52:48.0 +
@@ -68,7 +68,7 @@
Section: libs
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: parted | nparted, libparted-dev, libparted-i18n (= ${source:Version})
+Suggests: parted, libparted-dev, libparted-i18n (= ${source:Version})
Conflicts: parted ( 1.4.13+14pre1), libparted1 ( 2.2)
Replaces: libparted0 ( 2.2-4), libparted1 ( 2.2), libparted1.4 (
1.4.24-2)
Provides: libparted
diff -Nru parted-3.2/debian/patches/fat16-resize-crash.patch
parted-3.2/debian/patches/fat16-resize-crash.patch
--- parted-3.2/debian/patches/fat16-resize-crash.patch 1970-01-01
01:00:00.0 +0100
+++ parted-3.2/debian/patches/fat16-resize-crash.patch 2014-11-06
12:21:49.0 +
@@ -0,0 +1,56 @@
+From bdfd201a2f5b8090c7ba1208fe5531d0dceecf49 Mon Sep 17 00:00:00 2001
+From: Mike Fleetwood mike.fleetw...@googlemail.com
+Date: Sun, 28 Sep 2014 16:15:48 +0100
+Subject: lib-fs-resize: Prevent crash resizing FAT16 file systems
+
+Resizing FAT16 file system crashes in libparted/fs/r/fat/resize.c
+create_resize_context() because it was dereferencing NULL pointer
+fs_info-info_sector to copy the info_sector.
+
+Only FAT32 file systems have info_sector populated by fat_open() -
+fat_info_sector_read(). FAT12 and FAT16 file systems don't have an
+info_sector so pointer fs_info-info_sector remains assigned NULL from
+fat_alloc(). When resizing a FAT file system create_resize_context()
+was always dereferencing fs_info-info_sector to memory copy the
+info_sector, hence it crashed for FAT12 and FAT16.
+
+Make create_resize_context() only copy the info_sector for FAT32 file
+systems.
+
+Reported by Christian Hesse in
+https://bugzilla.gnome.org/show_bug.cgi?id=735669
+
+Origin: upstream,
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=1e9e770f4bc7f3d80e09ecd1df58575fad064163
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=735669
+Last-Update: 2014-11-06
+
+Patch-Name: fat16-resize-crash.patch
+---
+ libparted/fs/r/fat/resize.c | 12 +---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/libparted/fs/r/fat/resize.c b/libparted/fs/r/fat/resize.c
+index 919acf0..bfe60a0 100644
+--- a/libparted/fs/r/fat/resize.c
b/libparted/fs/r/fat/resize.c
+@@ -668,11 +668,17 @@ create_resize_context (PedFileSystem* fs, const
PedGeometry* new_geom)
+
+ /* preserve boot code, etc. */
+ new_fs_info-boot_sector = ped_malloc (new_geom-dev-sector_size);
+- new_fs_info-info_sector = ped_malloc (new_geom-dev-sector_size);
+ memcpy (new_fs_info-boot_sector, fs_info-boot_sector,
+ new_geom-dev-sector_size);
+- memcpy (new_fs_info-info_sector, fs_info-info_sector,
+- new_geom-dev-sector_size);
++ new_fs_info-info_sector = NULL;
++ if (fs_info-fat_type == FAT_TYPE_FAT32)
++ {
++ PED_ASSERT (fs_info-info_sector != NULL);
++ new_fs_info-info_sector =
++ ped_malloc (new_geom-dev-sector_size);
++ memcpy (new_fs_info-info_sector, fs_info-info_sector,
++ new_geom-dev-sector_size);
++ }
+
+ new_fs_info-logical_sector_size = fs_info-logical_sector_size;
+ new_fs_info-sector_count = new_geom-length;
diff -Nru parted-3.2/debian/patches/series parted-3.2/debian/patches/series
--- parted-3.2/debian/patches/series2014-09-19 15:38
Re: grub2 for testing?
On Thu, Mar 05, 2015 at 06:05:02AM +0100, Cyril Brulebois wrote: Should we unblock grub2 2.02~beta2-21 as it stands, or are there any possible issues that should be tackled before we consider unblocking it? Yes, this should be fine. I've filed an unblock request (#780018). -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308092334.gr3...@riva.ucam.org
Bug#780018: unblock: grub2/2.02~beta2-21
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock grub2. Niels and Cyril have both asked about this
recently, and it makes sense: one RC bug fix for powerpc, one important
bug fix requested by the CD team, and one cherry-pick to fix load_env if
the grubenv file spans more than one block. I'm not aware of any new
issues caused by this.
diff -Nru grub2-2.02~beta2/debian/.git-dpm grub2-2.02~beta2/debian/.git-dpm
--- grub2-2.02~beta2/debian/.git-dpm2015-01-03 12:21:02.0 +
+++ grub2-2.02~beta2/debian/.git-dpm2015-01-27 20:33:00.0 +
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-cbc80b2e595a7c4938dabd8264c2ff6a26eb4863
-cbc80b2e595a7c4938dabd8264c2ff6a26eb4863
+9d4f1601e187894da565f4573b5d174dcf586cd6
+9d4f1601e187894da565f4573b5d174dcf586cd6
e8f07821cce1bd0ab6d5622c2a42440f15f4fd71
e8f07821cce1bd0ab6d5622c2a42440f15f4fd71
grub2_2.02~beta2.orig.tar.xz
diff -Nru grub2-2.02~beta2/debian/changelog grub2-2.02~beta2/debian/changelog
--- grub2-2.02~beta2/debian/changelog 2015-01-03 12:39:53.0 +
+++ grub2-2.02~beta2/debian/changelog 2015-01-27 20:37:09.0 +
@@ -1,3 +1,20 @@
+grub2 (2.02~beta2-21) unstable; urgency=medium
+
+ [ Mathieu Trudel-Lapierre ]
+ * Fix overlap check in check_blocklists for load_env (backported patch
+from upstream commit 1f6af2a9; LP: #1311247).
+
+ [ Steve McIntyre ]
+ * Add support for running a 64-bit Linux kernel on a 32-bit EFI (closes:
+#775202).
+
+ [ Colin Watson ]
+ * Use mtmsr rather than mtmsrd in ppc64el-disable-vsx.patch, since the
+VSX Available bit is in the lower half of the MSR anyway, and mtmsrd
+faults on 32-bit systems (closes: #776400).
+
+ -- Colin Watson cjwat...@debian.org Tue, 27 Jan 2015 20:37:04 +
+
grub2 (2.02~beta2-20) unstable; urgency=medium
[ Colin Watson ]
diff -Nru grub2-2.02~beta2/debian/patches/check_blocklists_overlap_fix.patch
grub2-2.02~beta2/debian/patches/check_blocklists_overlap_fix.patch
--- grub2-2.02~beta2/debian/patches/check_blocklists_overlap_fix.patch
1970-01-01 01:00:00.0 +0100
+++ grub2-2.02~beta2/debian/patches/check_blocklists_overlap_fix.patch
2015-01-27 20:33:00.0 +
@@ -0,0 +1,47 @@
+From 2a54e1b19aa1e080f9795a00d7381c0be85b2a4b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=20=D0=9F=D0=B5=D1=85=D0=BE?=
+ =?UTF-8?q?=D0=B2?= roman_pekhov
+Date: Sun, 22 Jun 2014 03:51:50 +0400
+Subject: * grub-core/commands/loadenv.c (check_blocklists): Fix overlap check.
+
+Bug: http://savannah.gnu.org/bugs/?42134
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1311247
+Origin: upstream,
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=1f6af2a9f8b02a71f213b4717d8e62c8a6b14fc5
+Last-Update: 2015-01-23
+
+Patch-Name: check_blocklists_overlap_fix.patch
+---
+ grub-core/commands/loadenv.c | 13 ++---
+ 1 file changed, 2 insertions(+), 11 deletions(-)
+
+diff --git a/grub-core/commands/loadenv.c b/grub-core/commands/loadenv.c
+index 6af8112..acd93d1 100644
+--- a/grub-core/commands/loadenv.c
b/grub-core/commands/loadenv.c
+@@ -263,7 +263,7 @@ check_blocklists (grub_envblk_t envblk, struct blocklist
*blocklists,
+ for (q = p-next; q; q = q-next)
+ {
+ grub_disk_addr_t s1, s2;
+-grub_disk_addr_t e1, e2, t;
++grub_disk_addr_t e1, e2;
+
+ s1 = p-sector;
+ e1 = s1 + ((p-length + GRUB_DISK_SECTOR_SIZE - 1)
GRUB_DISK_SECTOR_BITS);
+@@ -271,16 +271,7 @@ check_blocklists (grub_envblk_t envblk, struct blocklist
*blocklists,
+ s2 = q-sector;
+ e2 = s2 + ((q-length + GRUB_DISK_SECTOR_SIZE - 1)
GRUB_DISK_SECTOR_BITS);
+
+-if (s2 s1)
+- {
+-t = s2;
+-s2 = s1;
+-s1 = t;
+-t = e2;
+-e2 = e1;
+-e1 = t;
+- }
+- if (e1 s2)
++if (s1 e2 s2 e1)
+ {
+ /* This might be actually valid, but it is unbelievable that
+ any filesystem makes such a silly allocation. */
diff -Nru grub2-2.02~beta2/debian/patches/gettext-print-typo.patch
grub2-2.02~beta2/debian/patches/gettext-print-typo.patch
--- grub2-2.02~beta2/debian/patches/gettext-print-typo.patch2015-01-03
12:21:00.0 +
+++ grub2-2.02~beta2/debian/patches/gettext-print-typo.patch2015-01-27
20:33:00.0 +
@@ -1,4 +1,4 @@
-From 20886bef9351d5c20a9de1fb3339fe40114f01d1 Mon Sep 17 00:00:00 2001
+From 34411ff593136ce78ab5c21706dfb7ae3655a16f Mon Sep 17 00:00:00 2001
From: Andrey Borzenkov arvidj...@gmail.com
Date: Thu, 14 Aug 2014 21:02:31 +0400
Subject: Fix typo (gettext_print instead of gettext_printf)
diff -Nru grub2-2.02~beta2/debian/patches/grub-install-extra-removable.patch
grub2-2.02~beta2/debian/patches/grub-install-extra-removable.patch
--- grub2-2.02~beta2/debian/patches/grub-install-extra-removable.patch
2015-01-03
Bug#766459: debootstrap/base-passwd: #767999 and #766459 should really be fixed in base-passwd
On Thu, Nov 06, 2014 at 02:06:07PM +, Michael Tautschnig wrote: At least Santiago's and my opinion diverge on whether base-passwd is presently in line with policy on 3.8 Essential packages. Therefore the route from here appears to hinge on interpreting policy in one of two ways: my point is that base-passwd, at present, is not providing its functionality after just being unpacked - it does require postinst having been run. Santiago claims, if I interpret this correctly, that every package has to be configured at least once before being useful at all (irrespective of whether it is essential or not). On the one hand, I agree with Santiago's policy interpretation here, and have long maintained this in pretty much the same terms. I have always read that policy directive as being for the purpose of requiring Essential packages to behave safely during upgrades so that the problem of upgrading entire systems is tractable. That said, I don't particularly feel the need to stand on a precise interpretation here, and it's true that this problem can be dealt with easily enough in base-passwd. Michael's patch is textually longer than a debootstrap change, it's true, but it doesn't introduce any particular maintenance burden, and it weakens the constraints on configuring the Essential set correctly, which is something I'm generally in favour of. I've therefore gone ahead and uploaded this base-passwd change (after local testing): base-passwd (3.5.37) unstable; urgency=medium * Debconf translations: - Dutch (thanks, Frans Spiesschaert; closes: #765361). - Danish (thanks, Joe Hansen; closes: #765853). * Copy /etc/passwd and /etc/group from the master files in the preinst on initial install, to be more tolerant of bootstrapping tools that configure the Essential set in slightly different orders (based on a patch from Michael Tautschnig; see #766459 and #767999). -- Colin Watson cjwat...@debian.org Fri, 07 Nov 2014 15:44:29 + This doesn't preclude fixing this in depth in other ways (e.g. a debootstrap change in stable), so I'm not closing these bugs. I'll leave it to others to decide when/whether to do that. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107154809.gs5...@riva.ucam.org
Bug#768329: grub-common: Please enable splash for jessie
Control: reassign -1 grub-common On Thu, Nov 06, 2014 at 04:11:11PM +0100, Christian Hofstaedtler wrote: * Colin Watson cjwat...@debian.org [141106 16:06]: On Thu, Nov 06, 2014 at 03:53:58PM +0100, Christian Hofstaedtler wrote: Please add the splash option to the Linux default command line, as just installing plymouth otherwise has no effect, and plymouth is the recommended solution for fixing bootup multiplexing issues (f.e. password prompting for encrypted disks). This is supposed to be handled by grub-installer, which is part of d-i. I do want to note that the grub packaging appears to have default command line handling for different distributions, and adding splash there would have the benefit(?) of everybody getting it, regardless how the system was installed (d-i, (grml-)debootstrap, etc.) Hm, right, I guess that is grub2's responsibility. Sorry for my misunderstanding. In principle this makes sense; I'm just a bit nervous about this at this point, and changing this will cause a ucf prompt for large numbers of people, so I want to get it right first time. CCing debian-devel; does anyone know of reasons why adding splash to the default command line would be a bad thing? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106153206.gq5...@riva.ucam.org
Re: Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode
On Sun, Sep 28, 2014 at 06:14:30PM +0100, Steve McIntyre wrote: That sounds better to me too, assuming we can sensibly do a question at that point. Is that allowed? I honestly don't know... :-/ While isinstallable scripts can talk to debconf, they should not ask questions, as main-menu will run the isinstallable script for a given package potentially many times. Also, partman-efi isn't a main-menu item so any isinstallable script added to it will never be run. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928185038.ga20...@riva.ucam.org
Bug#762694: partman-partitioning: Partitions are not aligned
On Wed, Sep 24, 2014 at 04:04:01PM +0200, Vladislav Kurz wrote: partitions created by debian installer are not aligned to cylinders (MBR), or 1MiB (GPT). Could you please provide a partman log from a d-i run that fails to do this? (It should be in /var/log/installer/partman after installation.) As far as I knew I'd fixed all this a long time ago ... Please note that partitions should be aligned to 1MiB or more on MBR too. Regardless of the partition table format, cylinder alignment hasn't been necessary for a decade or two now, and it produces suboptimal performance on modern disks. There may of course still be fdisk-style tools that are behind the times on this, but that's their problem. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927083112.ga13...@riva.ucam.org
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
On Thu, Sep 11, 2014 at 09:33:13AM +0200, Cyril Brulebois wrote: I disagree that reusing package names across package types is a nice thing to do. I very strongly disagree that it's OK to try that when we're close to the freeze (and not at the very beginning of the release cycle, where it hurts less to upload disruptive changes). So, I think the best way to handle this longer-term would be: * upload hw-detect with a transitional package archdetect (Package-Type: udeb) Depends: archdetect-udeb * make sure everything copes well with that * at some later point (e.g. in jessie+1) introduce archdetect as a .deb I would like to have archdetect as a .deb; the archdetect-deb name I made up a while back in Ubuntu sucks and I wouldn't like to perpetuate it; I don't think there's a fundamental problem with reusing package names across package types, but in cases like this where it has coordination issues we should make some effort to smooth the transition rather than just going straight for it. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911103024.ga20...@riva.ucam.org
Re: xattr support in live-installer?
On Wed, Apr 09, 2014 at 11:30:45PM +0100, Colin Watson wrote: I uploaded this live-installer patch to Ubuntu. It should be straightforward to apply in Debian once my attr patch or similar is applied. * Copy extended attributes to target system (LP: #1302192). My attr patch has been applied in unstable, so I've pushed this to live-installer.git. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909102038.ga15...@riva.ucam.org
Bug#709017: /e/n/i getting overwritten after late_command of preseed
On Mon, Feb 10, 2014 at 12:12:53PM +0100, Roberto Carlos Morano wrote: I've came across with the same problem and I think that the attached patch could do the job to fix this weird scenario. It looks if file already exists and only overwrites it in-target if it doesn't. Since '/e/n/i' is already written by 'debian-installer' itself in previous steps, I think it makes no sense to overwrite it again when installation is almost complete. It doesn't make sense neither if the file already exists for any reason (in e.g.: you create it in any other installation step like the case mentioned in 'debian-users' list [1]), so the only case I think it makes sense to set the '/e/n/i' file at that installation stage is if there isn't one already. This is wrong, I'm afraid. /etc/network/interfaces will *always* exist at this stage, because it's copied by netcfg's base-installer hook. However, the finish-install hook is explicitly using netcfg write_loopback in some cases to make sure that /etc/network/interfaces contains only the loopback entry. Declining to copy this to the target system would break those cases. What I'll do instead is copy /etc/network/interfaces only for the netcfg/target_network_config settings that require it. Then this may just work for you if you don't have network-manager installed, and otherwise you can use: d-i netcfg/target_network_config select ifupdown -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140828190355.ga12...@riva.ucam.org
Bug#751704: partman-base 173: partman overwrites parts of u-boot
On Wed, Aug 13, 2014 at 12:38:58AM +0200, Karsten Merker wrote: If there are no objections, I would like apply it to the partman-base git repository. Please adhere to local coding style, including indentation, spacing, and use or otherwise of tabs; it really makes things easier to follow later. PedDisk.needs_clobber is marked as office use only in parted; I interpret that as meaning that it really shouldn't be fiddled with outside parted, even though it's technically exposed. Could you please look at fixing parted to avoid clobbering the firmware area instead? I think that would be more correct. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812224551.gl5...@riva.ucam.org
Re: Bug#757417: libparted2-udeb: breaks auto-lvm in d-i
On Sun, Aug 10, 2014 at 08:26:56AM +0200, Petter Reinholdtsen wrote: Hi. Could this issue also affect the grub installer udeb? Not directly. But of course it's possible you manually partitioned wrongly in some way. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810082405.gd5...@riva.ucam.org
Re: Bug#757417: libparted2-udeb: breaks auto-lvm in d-i
On Sun, Aug 10, 2014 at 09:24:05AM +0100, Colin Watson wrote: On Sun, Aug 10, 2014 at 08:26:56AM +0200, Petter Reinholdtsen wrote: Hi. Could this issue also affect the grub installer udeb? Not directly. But of course it's possible you manually partitioned wrongly in some way. Well, it's possible that ensure-active might be failing, actually, in which case http://anonscm.debian.org/cgit/parted/debian/parted.git/commit/?id=6b352883e20e7eb998e0acfeab9a7c6edbe2b3fa would fix it. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810082945.ga2...@riva.ucam.org
Re: Bug#757417: libparted2-udeb: breaks auto-lvm in d-i
clone 757417 -1 -2 -3 -4 -5 -6 reassign -1 partman-auto-lvm retitle -1 partman-auto-lvm: cope with automatic creation of partitions in loop labels reassign -2 partman-base retitle -2 partman-base: make tests cope with automatic creation of partitions in loop labels severity -2 normal reassign -3 partman-crypto retitle -3 partman-crypto: cope with automatic creation of partitions in loop labels reassign -4 partman-lvm retitle -4 partman-lvm: cope with automatic creation of partitions in loop labels reassign -5 partman-md retitle -5 partman-md: cope with automatic creation of partitions in loop labels reassign -6 partman-zfs retitle -6 partman-zfs: cope with automatic creation of partitions in loop labels thanks On Fri, Aug 08, 2014 at 12:53:07AM +0200, Cyril Brulebois wrote: 3.2-2 fixes the non-LVM case, while it doesn't fix the second one, since we're now getting a different issue, apparently about primary partition count. I'll try to post more details soon. There are two problems here, both caused by apparently-intentional upstream changes: 1) parted 3.2 now automatically creates a partition when you create a loop label. Various bits of partman expect there to be free space after creating a loop label, and fail or misbehave when this isn't the case. 2) parted 3.2 no longer probes LVM logical volumes, or indeed any device-mapper devices other than dmraid whole disks. As a result, those devices never show up in partman at all. 2) is a distinctly unhelpful change at least in the context of d-i, although I guess it might be helpful elsewhere (parted -l tends to be pretty noisy if you have device-mapper devices present). For now I'm reverting it since it's a one-line change to undo just this bit. However, 1) is trickier. Reverting that change to parted results in different breakage, and it looks like I would have to do some quite complicated disentangling to revert it successfully. I'm not convinced this would result in something more stable. On the other hand, the end result is actually more convenient for d-i because it needs to do less work, so I'm minded to leave it in place and adjust the calling code instead. I've successfully tested changes to partman-auto-lvm and partman-lvm; as indicated by the control commands above there are a few other things to change too. Given this particular bug was also present in 3.2-1 (even if masked by the alignment issue), I'm versioning it as found in 3.2-1, so that 3.2-2 has a chance to migrate when it's old enough. If that doesn't sound like a good idea, please adjust version [and explain why ;)]. That sounds quite sensible, yes. Apologies for the inconvenience casued by all this; I clearly didn't test the new upstream version of parted well enough. I will sort all this out as quickly as I can. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810095637.ge5...@riva.ucam.org
Re: Bug#757417: libparted2-udeb: breaks auto-lvm in d-i
On Fri, Aug 08, 2014 at 03:26:23AM +0200, Cyril Brulebois wrote: [ Except for the stupid log function name and logger tag, it might be handy to merge such a patch into partman-auto-lvm to ease further debugging; comments welcome. ] I don't object, but it's generally simpler to just look at /var/log/partman, which has a full trace of all the parted_server commands issued, the replies to them, and various other information. I tracked this down quite quickly using that by reference to the code. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810095821.gf5...@riva.ucam.org
Bug#738923: parted3 preparations
On Fri, Feb 14, 2014 at 08:09:56AM +0300, Cyril Brulebois wrote: Phillip Susi ps...@ubuntu.com (2014-02-13): In preparation for the parted3 transition, this patch removes support for filesystem creation and checking from parted_server. The dependency and linker flag changes can be left out for now and it should still build against parted2. They can be added after parted3 has been uploaded to actually make the switch. This basically looks fine, thanks, but I think I'll hold off on applying it until we've started the parted transition. I'll file a separate bug against release.d.o for that. --- partman-base-172/debian/control 2013-07-13 03:07:32.0 -0400 +++ partman-base-173/debian/control 2014-02-12 11:57:06.0 -0500 … -Build-Depends: debhelper (= 9), dh-di (= 2), po-debconf (= 0.5.0), libparted0-dev (= 2.2) +Build-Depends: debhelper (= 9), dh-di (= 2), po-debconf (= 0.5.0), libparted2-dev The parted3 transition is about transitioning from libparted0 to libparted2? Anyway, why is the -dev package versioned at all? Unless you keep several source packages in the archive for a while, there's no use for having a versioned -dev package. Yeah, this is (to me) a historical mistake. I'm staging the parted 3.1 merge in http://anonscm.debian.org/gitweb/?p=parted/debian/parted.git;a=shortlog;h=refs/heads/v3, and I've removed the pointless -dev versioning there, so it will just be libparted-dev. On Fri, 14 Feb 2014 at 09:21:45AM -0500, Phillip Susi wrote: I believe the reason is that for a long time, upstream did not manage their soname versioning correctly, leaving it at zero despite breaking ABI, and finally with parted 3.0, jumped to 2 since they removed the filesystem apis. So debian packaged the library as -0debian1. Close but not quite; libparted.so.0 appeared in parted 2.2 when upstream switched to libtool's versioning system, from a previous scheme along the lines of libparted-2.1.so.0. Unfortunately there'd briefly been a SONAME version of 0 back in 2000, and as a result there were some unversioned Conflicts: libparted0 lying around. I applied versions to those once I noticed the problem (can probably remove them entirely at some point), but lacking a time machine I couldn't call the package libparted0 without breaking upgrades, so I renamed to libparted0debian1 as an ugly workaround. That should no longer be an issue now - I fixed the unversioned Conflicts four years ago - so the parted 3.1 packaging will just use libparted2 rather than libparted2debian1. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711125510.ga6...@riva.ucam.org
Bug#650414: grub-installer: Change --set to --set=root in 30_otheros
clone 650414 -1 retitle 650414 grub-installer: stop using otheros.sh and just require os-prober? thanks On Tue, Nov 29, 2011 at 01:51:58PM -0400, Joey Hess wrote: Brian Potkin wrote: There is no error message when --set is altered to --set=root in the line above. --set=root is already in the 'search' line for the OS on the USB stick and used when os-prober is installed and run from it with update-grub. Would it not be consistent to have it also in 30_otheros? I agree with this and will make this change. Apologies for the delay. grub-installer's use of os-prober seems overly complicated. If grub uses os-prober itself, why does grub-installer redundantly use os-prober to generate a grub configuration? The answer seems to be that, in normal operations with recommends enabled and grub-pc installed, grub-installer does that, but then throws the configuration away, since it sees os-prober is installed and relies on grub-pc having used it. In the edge cases where grub-legacy is used, the configuration is used, as grub-legacy (apparently) does not use os-prober. I tend to agree with this too, but it's a somewhat more substantial (and potentially controversial, IME) change. I'm cloning off a separate bug for that so that I can apply the bug-fix above without losing this discussion. AFAICS, the grub configuration generated by otheros.sh is entirely grub-legacy syntax. If it ever worked with grub-pc it was due to luck or compatability hacks in grub-pc. So I suspect my patch fixes this bug, and that modifying otheros to use --set=root is unnecessary, and would break it when used with grub-legacy. This is mistaken, though. The search lines in question are unambiguously GRUB 2 syntax, and moreover they're in grub2_* functions as opposed to grub_*. No compatibility hacks in GRUB 2 are involved here. Changes to the grub2_* functions can't break GRUB Legacy. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712083858.ga24...@riva.ucam.org
Bug#738922: [PATCH 2/3] Use dosfstools to format/check fat instead of libparted
OK, I had to refactor this somewhat before landing: patch 2 and 3 weren't very well split up (patch 2 introduced a syntax error!), and patch 3 introduced a lot of duplicated code which I wasn't happy with. However, having sat on this patch series for four months it would hardly have been fair to kick it back to you, so I just fixed that up locally. Furthermore, patch 2 didn't use the name for dosfsck found in the current dosfstools-udeb package and tried to use the entirely nonexistent mkfs.fat16 and mkfs.fat32. I replaced these bits with code from the current Ubuntu package. Pushed to master after an installation test, thanks. I'll work on the other bits of this ASAP as well. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140706003229.ga1...@riva.ucam.org
Bug#738922: [PATCH 2/3] Use dosfstools to format/check fat instead of libparted
Control: tag -1 pending On Thu, Mar 13, 2014 at 01:59:26PM -0400, Phillip Susi wrote: --- check.d/check_basicfilesystems | 15 +++--- commit.d/format_basicfilesystems | 45 +--- debian/changelog | 2 ++ debian/control | 2 +- 4 files changed, 25 insertions(+), 39 deletions(-) Thanks, applied to master. It's a shame to remove a feature, but there doesn't seem to be an obvious alternative at the moment. It can of course return if somebody figures out the necessary code to deal with the necessary resizing operations; I suspect it would end up needing to be filesystem-specific. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140706005738.gb1...@riva.ucam.org
Bug#738922: [PATCH 2/3] Use dosfstools to format/check fat instead of libparted
On Sun, Jul 06, 2014 at 01:57:38AM +0100, Colin Watson wrote: On Thu, Mar 13, 2014 at 01:59:26PM -0400, Phillip Susi wrote: --- check.d/check_basicfilesystems | 15 +++--- commit.d/format_basicfilesystems | 45 +--- debian/changelog | 2 ++ debian/control | 2 +- 4 files changed, 25 insertions(+), 39 deletions(-) Thanks, applied to master. It's a shame to remove a feature, but there doesn't seem to be an obvious alternative at the moment. It can of course return if somebody figures out the necessary code to deal with the necessary resizing operations; I suspect it would end up needing to be filesystem-specific. Whoops, sent this to the wrong bug. Will resend ... -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140706011305.ga1...@riva.ucam.org
Bug#738864: Remove copy operation for parted3 transition
Control: tag -1 pending [Resent to the right bug this time!] On Thu, Feb 13, 2014 at 11:45:00AM -0500, Phillip Susi wrote: This patch removes the copy operation from the partman menu in preparation for the parted3 transition, which no longer supports this. Thanks, applied to master. It's a shame to remove a feature, but there doesn't seem to be an obvious alternative at the moment. It can of course return if somebody figures out the necessary code to deal with the necessary resizing operations; I suspect it would end up needing to be filesystem-specific. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140706011521.ga1...@riva.ucam.org
Bug#739136: debootstrap: Sync deb support with latest dpkg-deb
Control: tag -1 pending On Sun, Feb 16, 2014 at 02:10:21AM +0100, Guillem Jover wrote: When using the fallback code instead of dpkg-deb the implementation is missing support for uncompressed data.tar and control.tar and control.tar.xz. Although this should not be needed in Debian for the base system, it might be needed by downstreams, or when a user includes a package manually. And I think it does not harm to have deb support in sync with what dpkg-deb supports. The attached two patches implement this. Although I've only tested the functions in isolation, not as part of a debootstrap run with such packages. Thanks; I've applied these patches to git. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140506083623.ga...@riva.ucam.org
Re: parted regression with FAT filesystems
On Mon, Apr 14, 2014 at 08:02:53PM +0200, Cyril Brulebois wrote: Colin Watson cjwat...@debian.org (2014-04-14): I heard about a parted regression this morning and fixed it more or less immediately: parted (2.3-20) unstable; urgency=medium * Fix crash when opening FAT file systems (LP: #1306704). -- Colin Watson cjwat...@debian.org Mon, 14 Apr 2014 11:44:43 +0100 This was a consequence of the fix in 2.3-19, though (which was itself a fix for #743816, grumble), and 2.3-19 just migrated to testing despite the newer upload on its way into unstable. So this is just a heads-up that you may see some reports of parted_server segfaults in d-i due to this. Thanks for the notice. If you feel it deserves a higher urgency than medium, it can still be overriden (talking to me or the release team should work). Given the number of tries it has taken to get this right, I was happy enough with a little extra testing time. :-) 2.3-20 is in testing now. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421203442.ga11...@riva.ucam.org
parted regression with FAT filesystems
I heard about a parted regression this morning and fixed it more or less immediately: parted (2.3-20) unstable; urgency=medium * Fix crash when opening FAT file systems (LP: #1306704). -- Colin Watson cjwat...@debian.org Mon, 14 Apr 2014 11:44:43 +0100 This was a consequence of the fix in 2.3-19, though (which was itself a fix for #743816, grumble), and 2.3-19 just migrated to testing despite the newer upload on its way into unstable. So this is just a heads-up that you may see some reports of parted_server segfaults in d-i due to this. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140414170247.go7...@riva.ucam.org
xattr support in live-installer?
Hi, https://launchpad.net/bugs/1302192 reports ping not being setuid root after installation from squashfs-based media. I've reproduced this with the Ubuntu server installer, which uses live-installer to install the base system (much faster than running debootstrap). I haven't explicitly tested Debian live media, but I suspect they'll suffer from the same problem. The question is what to do about it. live-installer uses busybox tar to shovel files around, and busybox tar doesn't support xattr. We could do something with getcap/setcap - indeed getcap supports recursive search and setcap can read capabilities in bulk from standard input, so this shouldn't need to be too slow - but we don't have those tools in d-i right now. Would it make sense to modify attr to build udebs, then change live-installer to do a getcap/setcap run after transferring files with tar? I think this is probably going to be simpler than adding xattr support to busybox tar (in GNU tar that depends on a specific archive format, so I'm guessing it's not exactly trivial). Even if we did go for the latter approach instead, we'd probably still need at least a libattr1-udeb. Thoughts? Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409130912.ga7...@riva.ucam.org
Re: xattr support in live-installer?
On Wed, Apr 09, 2014 at 03:19:12PM +0200, Cyril Brulebois wrote: Colin Watson cjwat...@debian.org (2014-04-09): Would it make sense to modify attr to build udebs, then change live-installer to do a getcap/setcap run after transferring files with tar? I think this is probably going to be simpler than adding xattr support to busybox tar (in GNU tar that depends on a specific archive format, so I'm guessing it's not exactly trivial). Even if we did go for the latter approach instead, we'd probably still need at least a libattr1-udeb. It seems to me that attr is sufficiently small for us not to worry too much about adding udebs there and using them in d-i. Patching busybox indeed looks less straightforward, and possibly more error-prone. OK, good, that was my thought too. In fact getcap/setcap are actually in libcap2, not attr (I'm an idiot), but that's also tiny. getfattr/setfattr are more general and seem to have a more convenient interface from d-i's point of view, though. The main thing to take care about will be to make sure that we don't fail to install if the target filesystem doesn't support extended attributes. I think this will unfortunately mean that /bin/ping won't have its setuid bit restored, at least not without lots of special-casing, but that's still better than a failed install. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409133610.ga9...@riva.ucam.org
Bug#744037: attr: please build udebs for use by live-installer
Package: attr
Version: 1:2.4.47-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty
Hi,
The following patch adds udebs to attr which can be used in
live-installer to copy extended attributes. We need this because some
packages have started to configure themselves in their postinsts to use
xattrs, which they do while we're building the squashfs, and then we
fail to copy the xattrs to the target system so we get bugs like
/bin/ping only being usable by root (see
https://lists.debian.org/debian-boot/2014/04/msg00061.html).
* Add attr-udeb and libattr1-udeb binary packages, for use by
live-installer to copy extended attributes.
diff -Nru attr-2.4.47/debian/control attr-2.4.47/debian/control
--- attr-2.4.47/debian/control 2012-06-13 09:36:50.0 +0100
+++ attr-2.4.47/debian/control 2014-04-09 14:51:46.0 +0100
@@ -50,3 +50,19 @@
Description: Extended attribute shared library
Contains the runtime environment required by programs that make use
of extended attributes.
+
+Package: attr-udeb
+Package-Type: udeb
+Depends: ${shlibs:Depends}, ${misc:Depends}, libattr1-udeb (=
${binary:Version})
+Section: debian-installer
+Architecture: any
+Multi-Arch: foreign
+Description: Utilities for manipulating filesystem extended attributes
+
+Package: libattr1-udeb
+Package-Type: udeb
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Section: debian-installer
+Architecture: any
+Multi-Arch: same
+Description: Extended attribute shared library
diff -Nru attr-2.4.47/debian/rules attr-2.4.47/debian/rules
--- attr-2.4.47/debian/rules2013-05-20 12:40:01.0 +0100
+++ attr-2.4.47/debian/rules2014-04-09 14:58:38.0 +0100
@@ -13,13 +13,19 @@
package = attr
develop = lib$(package)1-dev
library = lib$(package)1
+udeb= $(package)-udeb
+libudeb = $(library)-udeb
dirme = debian/$(package)
dirdev = debian/$(develop)
dirlib = debian/$(library)
+diru = debian/$(udeb)
+dirlu = debian/$(libudeb)
pkgme = DIST_ROOT=`pwd`/$(dirme); export DIST_ROOT;
pkgdev = DIST_ROOT=`pwd`/$(dirdev); export DIST_ROOT;
pkglib = DIST_ROOT=`pwd`/$(dirlib); export DIST_ROOT;
+pkgu = DIST_ROOT=`pwd`/$(diru); export DIST_ROOT;
+pkglu = DIST_ROOT=`pwd`/$(dirlu); export DIST_ROOT;
stdenv = @GZIP=-q; export GZIP;
options = export DEBUG=-DNDEBUG DISTRIBUTION=debian \
@@ -57,7 +63,7 @@
$(checkdir)
-rm -f built .census
$(MAKE) distclean
- -rm -rf $(dirme) $(dirdev) $(dirlib) debian/tmp
+ -rm -rf $(dirme) $(dirdev) $(dirlib) $(diru) $(dirlu) debian/tmp
-rm -f debian/*substvars debian/files* debian/*.debhelper
binary-indep:
@@ -69,6 +75,8 @@
$(pkgme) $(MAKE) -C . install
$(pkgdev) $(MAKE) -C . install-dev
$(pkglib) $(MAKE) -C . install-lib
+ $(pkgu) $(MAKE) -C . install
+ $(pkglu) $(MAKE) -C . install-lib
$(pkgme) $(MAKE) -C package src-manifest
rm -f $(dirdev)/usr/lib/$(DEB_HOST_MULTIARCH)/libattr.la
@@ -79,6 +87,8 @@
-rm -rf $(dirlib)/usr/share/locale
-rm -rf $(dirlib)/usr/share/man
-rm -rf $(dirlib)/usr/bin
+ -rm -rf $(diru)/usr/share
+ -rm -rf $(dirlu)/usr
dh_installdocs
dh_installchangelogs
@@ -86,7 +96,7 @@
dh_compress
dh_fixperms
dh_makeshlibs -N $(library)
- dh_makeshlibs -p $(library) -V 'libattr1 (= 1:2.4.46-8)'
+ dh_makeshlibs -p $(library) -V 'libattr1 (= 1:2.4.46-8)' --add-udeb
libattr1-udeb
dh_installdeb
dh_shlibdeps
dh_gencontrol
@@ -94,7 +104,7 @@
dh_md5sums
dh_builddeb -p$(package) -- -Zbzip2 -z9
dh_builddeb -p$(develop) -- -Zbzip2 -z9
- dh_builddeb -p$(library)
+ dh_builddeb -p$(library) -p$(udeb) -p$(libudeb)
binary: binary-indep binary-arch
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140409140537.ga7...@riva.ucam.org
Re: xattr support in live-installer?
I uploaded this live-installer patch to Ubuntu. It should be
straightforward to apply in Debian once my attr patch or similar is
applied.
* Copy extended attributes to target system (LP: #1302192).
=== modified file 'debian/control'
--- debian/control 2013-07-14 13:17:07 +
+++ debian/control 2014-04-09 14:23:28 +
@@ -14,7 +14,7 @@ Package: live-installer
Package-Type: udeb
Architecture: any
Depends:
- ${shlibs:Depends}, archdetect, base-installer (= 1.105),
+ ${shlibs:Depends}, archdetect, attr-udeb, base-installer (= 1.105),
busybox-udeb (= 1:1.13.3), cdebconf-udeb, created-fstab, mounted-partitions
Provides: installed-base, kernel-installer
XB-Installer-Menu-Item: 6490
=== modified file 'debian/live-installer.postinst'
--- debian/live-installer.postinst 2013-09-08 10:03:20 +
+++ debian/live-installer.postinst 2014-04-09 14:27:34 +
@@ -81,6 +81,9 @@ install_live_system () {
)
exec 04
IFS=$OLD_IFS
+ getfattr --dump --no-dereference --match=- --recursive . | \
+ (cd /target setfattr --no-dereference --restore=-) \
+ || true
chdir /
eval ${SUPPORT}_teardown
Cheers,
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140409223045.ga25...@riva.ucam.org
Re: Time to drop ia64 from src:installation-guide?
On Sun, Apr 06, 2014 at 03:55:45AM +0200, Cyril Brulebois wrote: any objection to dropping ia64 from this package? Commenting it like that was done for hppa would seem the way to go (at least to me), but I'm happy to read any comments about that. Sounds sensible to me. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409223113.gb25...@riva.ucam.org
Re: Bug#743353: libparted0-udeb: broken encrypted LVM autopartioning in d-i
Source: parted Source-Version: 2.3-18 On Wed, Apr 02, 2014 at 01:14:54AM +0200, Cyril Brulebois wrote: thanks to Sebastian Beyer for his report on #debian-boot, here are the details for the regression I've just tracked down: trying to select auto partitioning with encrypted LVM no longer works in the Debian Installer. Sorry for not forwarding this to the BTS. Phillip and I worked this out earlier today, and I just uploaded the fix: parted (2.3-18) unstable; urgency=medium * Fix LVM handling regressions caused by fix-loop-labels.patch (LP: #1300072): - Initialise dev-loop in ped_disk_new_fresh rather than ped_disk_new. - Temporarily set disk-dev-loop to 0 while removing partitions, so that we can remove previously-existing non-loop partitions (thanks, Phillip Susi). -- Colin Watson cjwat...@debian.org Wed, 02 Apr 2014 00:01:13 +0100 -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140401233126.gq6...@riva.ucam.org
Re: Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*
On Sat, Mar 15, 2014 at 02:22:05AM +0100, Cyril Brulebois wrote: Cyril Brulebois k...@debian.org (2014-03-15): so there are some grub-* packages used in debian-installer's build-deps, and grub-common is among them, since grub-mkrescue is used on kfreebsd-*. It apparently lost its -J flag, making debian-installer FTBFS on those architectures. Excerpt from a daily build log after 2014-03-10: | # Create the ISO with Joliet extensions, needed for win32-loader.ini | grub-mkrescue --output=./tmp/netboot-9/mini.iso ./tmp/netboot-9/cd_tree -J | grub-mkrescue: invalid option -- 'J' | Try 'grub-mkrescue --help' or 'grub-mkrescue --usage' for more information. | make[2]: *** [arch_miniiso] Error 64 That this option gets rejected isn't entirely surprising given we previously had a pass-through for unknown options: Right. Can you try -- -J instead? (We've talked about changing the behaviour back upstream, but the thread petered out a bit and I don't believe it's done yet.) [BTW the tag for -7 isn't to be found in the git repository right now.] Sure is, it's just called debian/2.02.beta2-7 because git. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140315081734.gi6...@riva.ucam.org
Re: Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*
On Sat, Mar 15, 2014 at 12:37:17PM +0100, Cyril Brulebois wrote: After having downgraded the installed grub-* packages, I've checked that using this syntax wouldn't work with past versions: | grub-mkrescue --output=./tmp/netboot-9/mini.iso ./tmp/netboot-9/cd_tree -- -J | Enabling BIOS support ... | xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project. | | xorriso : FAILURE : Not a known command: '-J' I'm tempted to commit the '--' addition in debian-installer for now anyway, including a comment pointing here, and to lower the severity to important (since other callers might be affected as well). Does that look OK to you? It's not ideal, but I think it's reasonable for now, yes. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140315130852.gj6...@riva.ucam.org
Bug#738922: parted3 preparation
/swap_check_failed true - db_input critical partman-basicfilesystems/swap_check_failed || true - db_go || true - db_get partman-basicfilesystems/swap_check_failed - if [ $RET = true ]; then - exit 1 - fi - fi - fi - done -done - -if ! $swap; then - db_input critical partman-basicfilesystems/no_swap || true - db_go || true - db_get partman-basicfilesystems/no_swap - if [ $RET = true ]; then - exit 1 - fi -fi While it may be reasonable to remove the CHECK_FILE_SYSTEM bits, it isn't reasonable to remove the check that you have a swap partition at all. Please put this file back and instead just delete the parts from '[ ! -f $id/format ] || continue' to the end of the enclosing for loop. diff -Nru partman-basicfilesystems-90/commit.d/format_basicfilesystems partman-basicfilesystems-91/commit.d/format_basicfilesystems --- partman-basicfilesystems-90/commit.d/format_basicfilesystems 2011-01-18 23:57:21.0 -0500 +++ partman-basicfilesystems-91/commit.d/format_basicfilesystems 2014-02-13 14:59:35.0 -0500 [...] fat16|fat32) name_progress_bar $template - open_dialog CREATE_FILE_SYSTEM $id $filesystem - read_line status - close_dialog - sync + if log-output -t partman --pass-stdout \ + mkfs.$filesystem $device /dev/null; then + status=OK + else + status=failed + fi + db_progress STOP ;; esac Again, you need to actually create a progress bar here. name_progress_bar doesn't do so - all it does is set things up so that the exception handler knows what to do on the next timer event, which now won't arrive at all here - and we shouldn't have unbalanced db_progress START/STOP calls. You could use commit.d/format_swap for comparison here, since it's done reasonably enough there. I think it would be a good idea to keep the sync call in place, at least in the event that mkfs succeeds. -Template: partman-basicfilesystems/text/noatime -Type: text -# :sl2: -# Note to translators: Please keep your translations of this string below -# a 65 columns limit (which means 65 characters in single-byte languages) -_Description: noatime - do not update inode access times at each access Even aside from my comments about moving ext2 support, you must not remove all these mount option templates. select_mountoptions always picks up the templates from partman-basicfilesystems/text/$op, and these mount options are made available for various different file systems. Really, I don't think you should need to make any template changes in partman-basicfilesystems as part of preparing for parted 3. But this in particular would have broken quite a lot of things. Could you fix these problems and post a corrected version? It should be much shorter. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140312133434.ga6...@riva.ucam.org
Bug#738919: parted3 preparations
On Thu, Feb 13, 2014 at 04:46:36PM -0500, Phillip Susi wrote: In preparation for the parted3 transition, this patch adds ext2 support to partman-ext3, since my other patch removes ext2 from partman-basicfilesystems. As I said as part of my comments on #738922, I think this is needless churn that just makes the transition more complicated. Unless there is a reason beyond aesthetics to move ext2 support, I think we should leave it where it is. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140312133554.ga7...@riva.ucam.org
Bug#739006: Switch to mkdosfs instead of libparted
On Fri, Feb 14, 2014 at 03:49:56PM -0500, Phillip Susi wrote:
diff -Nru partman-efi-39/commit.d/format_efi
partman-efi-40/commit.d/format_efi
--- partman-efi-39/commit.d/format_efi2012-09-20 10:45:15.0
-0400
+++ partman-efi-40/commit.d/format_efi2014-02-14 15:40:50.0
-0500
@@ -54,10 +54,13 @@
db_subst $template PARTITION $num
db_subst $template DEVICE $(humandev $(cat device))
name_progress_bar $template
- open_dialog CREATE_FILE_SYSTEM $id $new_efi_fs
- read_line status
- close_dialog
- sync
+ if log-output -t partman --pass-stdout \
+ mkfs.vfat -F 32 $device /dev/null; then
+ status=OK
+ else
+ status=failed
+ fi
+ db_progress STOP
if [ $status != OK ]; then
db_subst partman-basicfilesystems/create_failed
TYPE efi
This has the same kind of problem I noted in #738922; you have
unbalanced db_progress calls, and you should probably drop the
now-useless name_progress_bar call and explicitly create a progress bar.
You've silently dropped a sync call, which seems an unwise thing to
bundle into this already fairly complex transition; I would suggest
keeping it at least in the case when mkfs.vfat returns successfully.
The top of format_efi selects fat32 or fat16 depending on the
architecture, but you ignore that here. I'd recommend using -F
${new_efi_fs#fat} instead of hardcoding 32.
diff -Nru partman-efi-39/debian/changelog partman-efi-40/debian/changelog
--- partman-efi-39/debian/changelog 2013-09-08 10:29:40.0 -0400
+++ partman-efi-40/debian/changelog 2014-02-14 15:45:19.0 -0500
@@ -1,3 +1,9 @@
+partman-efi (40) unstable; urgency=low
+
+ * Switch to using mkdosfs instead of libparted
+
+ -- Phillip Susi ps...@ubuntu.com Fri, 14 Feb 2014 15:44:22 -0500
+
partman-efi (39) unstable; urgency=low
[ Updated translations ]
Just as general good practice, it's a good idea to submit changelog
patches with the distribution set to UNRELEASED rather than
unstable; we only set it to unstable when tagging and releasing. Or
you can even just supply the changelog entry separately without the
header/trailer lines and let the committer fill that in, to reduce the
probability of conflicts.
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140312134543.ga7...@riva.ucam.org
Bug#738922: parted3 preparation
On Wed, Mar 12, 2014 at 10:02:16AM -0400, Phillip Susi wrote: On 3/12/2014 9:34 AM, Colin Watson wrote: I think it would be very helpful to split up the logical chunks of this. Moving ext2 support means that we need to make sure that partman-basicfilesystems and partman-ext3 land in unstable and testing at the same time, and derived distributions need to do that too. Given the general lack of tool support for this sort of lockstep change in udebs, I'm uncomfortable with bundling it into this change. Was there a good reason for that or did you just think it was tidier? If the latter, I think it would in fact be better avoided. The purpose of the patch is to stop depending on libparted. The existing ext2 support thus needed removed and transitioned to the code that is currently in partman-ext3. I suppose I could have copied and pasted that code into partman-basicfilesystems, but needlessly duplicating code seemed silly. Please do it anyway - moving this around is going to be a pain. I think it would be a good idea to keep the sync call in place, at least in the event that mkfs succeeds. What for? If the system crashes 3 seconds later, who cares if the disk was properly formatted or not? In the past there've been some problems with things like udev not picking changes up properly, I think. Memory is fuzzy. In any event, my point is that you should be decoupling things from the parted 3 transition when at all possible. We can always try removing syncs later; if it's done separately it will be easier to see when problems are down to that, rather than a giant debugging nightmare. -Template: partman-basicfilesystems/text/noatime -Type: text -# :sl2: -# Note to translators: Please keep your translations of this string below -# a 65 columns limit (which means 65 characters in single-byte languages) -_Description: noatime - do not update inode access times at each access Even aside from my comments about moving ext2 support, you must not remove all these mount option templates. select_mountoptions always picks up the templates from partman-basicfilesystems/text/$op, and these mount options are made available for various different file systems. It looks to me like these templates were duplicated in basicfilesystems and -ext3 because both ext2 and ext[34] needed them. With ext2 removed from basicfilesystems, they seem to be unreferenced cruft now. If the system always looks for them in -basicfilesystems, then why are they duplicated in -ext3? I'm pretty sure I checked the menu and they still showed up properly. There's no noatime template in -ext3, so I don't know what you're talking about here. Please just put these templates back; they are absolutely *not* unreferenced cruft. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140312141900.gh6...@riva.ucam.org
Bug#739989: debian-installer-utils: log-output change breaks speech synthesis
On Tue, Feb 25, 2014 at 09:10:38AM +0300, Cyril Brulebois wrote: Did you see my follow-up mail[1]? It looks to me it does not only trigger the espeakup hang, but a whole bunch of other hangs. I did, but without data I didn't have time to trawl through looking for them. I'm not asserting that the cause for this is by any means unique to espeakup. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225092158.gs6...@riva.ucam.org
Bug#739989: debian-installer-utils: log-output change breaks speech synthesis
clone 739989 -1 -2 reassign -1 espeakup: rebuild against latest espeak severity -1 important reassign -2 espeak: build proper library udeb so that espeakup doesn't have to be statically linked and hence break on upstream version changes severity -2 important thanks On Mon, Feb 24, 2014 at 09:17:19PM +0300, Cyril Brulebois wrote: the change below breaks speech synthesis, as reported here: https://lists.debian.org/debian-accessibility/2014/02/msg00093.html and suspected here: https://lists.debian.org/debian-accessibility/2014/02/msg00102.html I've checked that building d-i against testing udebs lets me reproduced this issue, and that adding d-i-utils' binaries to localudebs after having reverted this change fixes speech synthesis. commit 9c6685364a56697ea9c590e1bc93a73ade88b679 Author: Colin Watson cjwat...@debian.org Date: Fri Feb 7 17:07:46 2014 + log-output: Always install a no-op SIGCHLD handler This copes with the case where the subsidiary process starts a daemon which does not fully disconnect its standard file descriptors (LP: #1021293). See also the changelog for 1.46. (http://anonscm.debian.org/gitweb/?p=d-i/debian-installer-utils.git;a=commit;h=9c6685364a56697ea9c590e1bc93a73ade88b679) OK. Thanks for the notice. So, this change was in response to a bug that was pretty painful to reproduce (referenced above, https://launchpad.net/bugs/1021293), so while I understand the need to fix the regression, I certainly wouldn't want to just revert without chasing it down properly. As indicated by the comments, I knew at the time that this was a bit of a shonky fix. The effect is essentially to disconnect from the subsidiary process after it exits, even if it has spawned some child processes. It was extending a workaround that was previously only active with the --pass-stdout option; it was technically wrong there in much the same way, but the corner cases are very rare so we've lived with it quite happily for nearly seven years. Some strace analysis later: what's happening here is that espeakup.restart runs log-output -t espeakup espeakup -V en, the subsidiary espeakup -V en forks, exits, and the child setsids but does *not* do the usual daemonisation thing of redirecting stdin/stdout/stderr to /dev/null (it calls daemon(0, 1)). This then tries to print the following to stderr: Wrong version of espeak-data 0x14709 (expects 0x14600) at /usr/lib/i386-linux-gnu/espeak-data Since stderr is now disconnected, this causes espeakup to get SIGPIPE, at which point everything falls over. Oops. (I'm assuming that it would normally have gone on to close those file descriptors or similar a bit later, otherwise this would never have worked at all.) Reuploading espeakup against the latest version of espeak (changelog date 2013-06-19 - how did it take us so long to notice this?) should get rid of this stderr output, clearly ought to happen anyway, and may well work around this bug, so I'm cloning this bug for that. The situation where we have to occasionally rebuild espeakup due to new upstream versions of espeak is clearly far from ideal, and I'm making another clone for that. That still leaves the log-output problem, and in some ways it's amazing it took us so long to run into this. It's obviously wrong to leave a program running with disconnected file descriptors; we only did that because I couldn't think of a better option. However, one trick does come to mind: if we get SIGCHLD to indicate that the child has exited, then log-output could daemonise itself to match (this time a full daemonisation, reopening its standard file descriptors onto /dev/null), and only exit for real once the other ends of the polled pipes close. I think this is actually the correct answer. The problem is that there's no straightforward way to implement this: log-output uses di_exec, there's no hook in that at the point where it's received SIGCHLD, and it would clearly be inappropriate for library code to daemonise. We could maybe figure out some gross hack with the existing handlers, but it would be very fragile. We could add another handler, but it would be hard to do that without breaking ABI or ending up proliferating the di_exec* family of functions even further; the approach of doing this all in a single gigantic function call is not really a very good design but it would be a pain to change now. I am at least half-tempted to just clone and hack the relevant bits of di_internal_exec into log-output, given that its use of it is rather different from most other uses of di_exec* in d-i, and then log-output could do whatever it wants on SIGCHLD. That seems like it should require some discussion rather than JFDI, though. What do people think? In the meantime, I'm reverting my change from 1.103 for now since this is all pretty tricky, although I'm fairly convinced that this is just masking other bugs. So be it, I suppose. Cheers, -- Colin Watson
Bug#739989: debian-installer-utils: log-output change breaks speech synthesis
On Tue, Feb 25, 2014 at 12:12:43AM +, Colin Watson wrote: In the meantime, I'm reverting my change from 1.103 for now since this is all pretty tricky, although I'm fairly convinced that this is just masking other bugs. So be it, I suppose. Uploaded: debian-installer-utils (1.106) unstable; urgency=high [ Wouter Verhelst ] * resolv.c: move here from partman-nbd, and install into di-utils. [ Colin Watson ] * Revert change in 1.103 to install no-op SIGCHLD handler even outside the --pass-stdout case, since if a process daemonises without closing its standard file descriptors and then tries to write to them it will receive SIGPIPE, and that breaks speech synthesis in d-i (see #739989). -- Colin Watson cjwat...@debian.org Tue, 25 Feb 2014 00:12:49 + I'll downgrade this once that's otherwise ready for testing. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140225004338.ga22...@riva.ucam.org
HTTPS metadata in Mirrors.masterlist?
Hi, I'm working on adding HTTPS support to d-i. Now, I know that we already have integrity by way of the GPG signature chain, but this isn't for that; this is in response to feedback Canonical has had from some Ubuntu customers (typically of the large and corporate variety) that they want to do all of their apt traffic over HTTPS to avoid people snooping on which packages various machines are installing. We already have some minimal support for this by way of Joey's change in debootstrap 1.0.56: * When deboostrapping Debian, and the debian-archive-keyring is not available, switch the default mirror to a https url. This way at least the CA level of security is available even for users who have no way to check gpg keys in the WoT. The https mirror is currently https://mirrors.kernel.org/debian. Now, the next thing on my list to work on is choose-mirror: you should be able to pass mirror/protocol=https and have it offer you HTTPS mirrors if it knows about any, and otherwise just ask you to enter mirror information manually. I suspect that in reality most users of this feature would have an internal mirror, but it would be good to offer public mirrors where we know about them too. Would it be possible, then, to add Archive-https: /debian/ to the Site: mirrors.kernel.org stanza in Mirrors.masterlist, and perhaps start maintaining Archive-https fields for other mirrors willing to participate? That would at least get a minimal list started for this mode. (And yes, I know that this is only of any actual use if we do certificate checks. Right now the way I have things hooked up is that you can add certificates to the d-i initramfs, either by rebuilding with SSL_CERTS set in build/config/local or by concatenating another initramfs-format archive of c_rehash-ed certificates unpacking to /usr/lib/ssl/certs; or else debian-installer/allow_unauthenticated=false will imply no certificate checking. You have to supply GNU wget anyway, since busybox wget doesn't speak HTTPS. If more people than I suspect want to use this then we might want to consider something with ca-certificates, but I felt that was overkill for now and it certainly involved more thinking about policy than I wanted to do.) Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140211130429.ga18...@riva.ucam.org
Re: HTTPS metadata in Mirrors.masterlist?
On Tue, Feb 11, 2014 at 01:04:29PM +, Colin Watson wrote: I'm working on adding HTTPS support to d-i. Now, I know that we already have integrity by way of the GPG signature chain, but this isn't for that; this is in response to feedback Canonical has had from some Ubuntu customers (typically of the large and corporate variety) that they want to do all of their apt traffic over HTTPS to avoid people snooping on which packages various machines are installing. We already have some minimal support for this by way of Joey's change in debootstrap 1.0.56: * When deboostrapping Debian, and the debian-archive-keyring is not available, switch the default mirror to a https url. This way at least the CA level of security is available even for users who have no way to check gpg keys in the WoT. The https mirror is currently https://mirrors.kernel.org/debian. Now, the next thing on my list to work on is choose-mirror: you should be able to pass mirror/protocol=https and have it offer you HTTPS mirrors if it knows about any, and otherwise just ask you to enter mirror information manually. I suspect that in reality most users of this feature would have an internal mirror, but it would be good to offer public mirrors where we know about them too. Would it be possible, then, to add Archive-https: /debian/ to the Site: mirrors.kernel.org stanza in Mirrors.masterlist, and perhaps start maintaining Archive-https fields for other mirrors willing to participate? That would at least get a minimal list started for this mode. (And yes, I know that this is only of any actual use if we do certificate checks. Right now the way I have things hooked up is that you can add certificates to the d-i initramfs, either by rebuilding with SSL_CERTS set in build/config/local or by concatenating another initramfs-format archive of c_rehash-ed certificates unpacking to /usr/lib/ssl/certs; or else debian-installer/allow_unauthenticated=false will imply no certificate checking. You have to supply GNU wget anyway, since busybox wget doesn't speak HTTPS. If more people than I suspect want to use this then we might want to consider something with ca-certificates, but I felt that was overkill for now and it certainly involved more thinking about policy than I wanted to do.) I managed to typo debian-mirr...@lists.debian.org as debian-mirr...@lists.kernel.org, bafflingly. Following up with full quoting so that both lists have it ... Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140211134553.ga20...@riva.ucam.org
Re: HTTPS metadata in Mirrors.masterlist?
On Tue, Feb 11, 2014 at 03:05:44PM +0100, Mattias Wadenstein wrote: On Tue, 11 Feb 2014, Colin Watson wrote: On Tue, Feb 11, 2014 at 01:04:29PM +, Colin Watson wrote: I'm working on adding HTTPS support to d-i. Now, I know that we already have integrity by way of the GPG signature chain, but this isn't for that; this is in response to feedback Canonical has had from some Ubuntu customers (typically of the large and corporate variety) that they want to do all of their apt traffic over HTTPS to avoid people snooping on which packages various machines are installing. Let me suggest that if they want to keep it a secret from people able to snoop on their network traffic, they might want to consider the much stronger protection of running their own mirror. I'm not sure how much detail I'm allowed to go into, but in the specific cases at hand, I believe they *are* running their own internal mirror, but they want to make some efforts to conceal information from their own employees who might be able to snoop on the network. At least this is as far as I've been able to tell, and I can see how it'd make sense for sufficiently large organisations. Having metadata about the public mirror network is mostly a nicety so that we don't just drop people straight into manual mirror selection; it seems like something we might as well track if mirror operators are willing, though. That said, I don't mind more giving the users what they want, but I also see no way in which our mirror could provide usable HTTPS, so the mirror selection would likely be much smaller. Right, I expected as much. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140211143107.go6...@riva.ucam.org
Re: HTTPS metadata in Mirrors.masterlist?
On Tue, Feb 11, 2014 at 05:22:26PM +0100, Matus UHLAR - fantomas wrote: On 11.02.14 15:56, Colin Watson wrote: All I have left to say is that the admins in question are my customers, so, the company is not your customer, but its admins are? Oh, whatever. I'm not interested in this kind of word game. I've already exhausted all the avenues of protest you suggest, and they still tell me this is something they need. Based on the work I've done so far I don't think this is a particularly onerous thing to support in d-i at least as an option, I'm prepared to do the work, and all I'm asking for here is a bit of metadata in the mirror masterlist. If the latter can't be provided because we don't think Debian mirrors will accept the load or whatever, that's fine, I can always make it manual-only or whatever, but at this point it is easier for me to support HTTPS than to argue about it. :-) You can of course configure HTTPS on your server. It's their server, not mine. MAybe you could configure HTTPS proxy for them. Finally, if they are your customers, it's up to you to provide the servicem isn't it? Which is what I'm doing by doing this work in d-i! Of course I could just do it in Ubuntu but it seems better to have the code in Debian too; it can always be mostly disabled by default so that only people who want to turn it on need to care. Note that HTTPS clients verify the servers' certificate and multiple debian mirrors with different hostnames can not have the same certificate, nor it's sane to maintain different certificates for each hostname on each mirror ... Well aware of that, thanks. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140211175911.ga28...@riva.ucam.org
Re: HTTPS metadata in Mirrors.masterlist?
On Tue, Feb 11, 2014 at 06:40:22PM +0100, Kurt Roeckx wrote: So the first question I have about this if we can get ftp.TLD.debian.org certificates for this, and what happens when that host is down and DNS gets pointed to a different host? I have to guess that we should only do that on the hostname that is not ftp.TLD.debian.org, while I think it now only shows that name? Yeah. It's not clear that this makes sense for role name hosting across trust domains ... -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140211180003.gb28...@riva.ucam.org
