Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
David Kalnischkies (2015-11-28): > Mhh. apt is run as root (as we don't reach this codepath with uid != > 0), but it has all the groups of kibi and a setgroups is silently > ignored… wtf… Hmmm, there's fakeroot in the middle! | ifneq ($(shell id -u),0) | ROOTCMD ?= fakeroot | endif | | # Useful command sequences | define submake | $(ROOTCMD) $(MAKE) --no-print-directory -j1 | endef which probably explains why copying/pasting the command line worked, as opposed to running make and submakes, the last ones being under fakeroot? > The code is if someone wants to look: > https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc#n2264 > I will go to bed now, maybe I have an epiphany tomorrow. > (or manage to reproduce this for a start) > > > > While I've been experimenting with adding/removing myself from the said > > groups, I'm noticed this a few times, without being able to figure out > > what exactly causes this… > > | W: No sandbox user '_apt' on the system, can not drop privileges > > > > In which case, going back to apt.git and "sudo debi -u" to reinstall all > > packages I've built seems to fix the issue. > > As mentioned briefly schroot copies users & groups from your host > system, so if your host system has no _apt user, the _apt user in your > schroot will "disappear" next time it is copied over. Ah, right. That explains why running adduser/deluser from within/outside the chroot made little difference, given the culprit was my leaving and re-entering the chroot session… I'm not sure how buildds are set up, and whether _apt will stick there (not really a reasonable hour to go look it up though); there are different flavours/profiles in the sbuild and schroot worlds anyway, so hopefully that's going to “just work”. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
On Sat, Nov 28, 2015 at 12:30:52AM +0100, Cyril Brulebois wrote: > Now if I log out of the schroot session, remove my user 'kibi' from the > cdrom group and re-enter a schroot session, I'm now getting a failure on > the next group: > | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build > build_netboot-gtk USE_UDEBS_FROM=sid > | make: Entering directory '/home/kibi/debian-installer/installer/build' > | Using generated sources.list.udeb: > |deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ > localudebs/ > |deb http://localhost/debian sid main/debian-installer > | make[2]: 'sources.list.udeb' is up to date. > | Reading package lists... Done > | E: Method gave invalid 400 URI Failure message: Could not switch group, > user _apt is still in group 25 > | E: Method gave invalid 400 URI Failure message: Could not switch group, > user _apt is still in group 25 > | E: Method copy has died unexpectedly! > | E: Sub-process copy returned an error code (112) > | > | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ getent group floppy > | floppy:x:25:kibi > | > | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ groups > | kibi floppy audio dip video plugdev sbuild kvm libvirt > > Iterating again, I'm now failing because of the audio group… Mhh. apt is run as root (as we don't reach this codepath with uid != 0), but it has all the groups of kibi and a setgroups is silently ignored… wtf… The code is if someone wants to look: https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc#n2264 I will go to bed now, maybe I have an epiphany tomorrow. (or manage to reproduce this for a start) > While I've been experimenting with adding/removing myself from the said > groups, I'm noticed this a few times, without being able to figure out > what exactly causes this… > | W: No sandbox user '_apt' on the system, can not drop privileges > > In which case, going back to apt.git and "sudo debi -u" to reinstall all > packages I've built seems to fix the issue. As mentioned briefly schroot copies users & groups from your host system, so if your host system has no _apt user, the _apt user in your schroot will "disappear" next time it is copied over. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#805321: [Reproducible-builds] Bug#805321: debian-installer: builds unreproducible netboot images
Hi,
Cyril Brulebois wrote:
> I've cherry-picked 3 patches from there onto master locally and I'm
> currently running diffoscope to see how that goes (and it's taking
> ages…):
I'm guessing the initrd would differ if the Linux tool to generate it
stores timestamps. If its compressed size varies much due to those
differences, the .iso block numbers may vary as a result.
> FWIW, I'm not exactly entirely convinced by the exporting of the
> SOURCE_DATE_EPOCH variable from debian/rules; all other variables have
> been passed without exporting so I'm wondering if we shouldn't adapt
> this to behave like other variables, reducing possible surprise for
> users.
Just to explain that -- if it's defined in the environment, it requires
no special handling and doesn't need to be (re-)exported. I think this
is maybe the case now for dpkg-buildpackage in sid?
If the dpkg-buildpackage environment doesn't have SOURCE_DATE_EPOCH
(e.g. jessie), debian/rules sets it to the correct value, and so must
export that.
Or (for jessie or sid), in case build/Makefile is used directly, outside
of a package build, we set SOURCE_DATE_EPOCH to a dummy value ("now") if
undefined (since ../debian/changelog may not exist), which we need
when calling makefs from within that Makefile. We export it for use by
gen-tarball to avoid duplication there.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
Cyril Brulebois (2015-11-27): > ACK, will test in a few moments. Results: | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build build_netboot-gtk USE_UDEBS_FROM=sid | make: Entering directory '/home/kibi/debian-installer/installer/build' | Using generated sources.list.udeb: |deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ localudebs/ |deb http://localhost/debian sid main/debian-installer | make[2]: 'sources.list.udeb' is up to date. | Reading package lists... Done | E: Method gave invalid 400 URI Failure message: Could not switch group, user _apt is still in group 24 | E: Method gave invalid 400 URI Failure message: Could not switch group, user _apt is still in group 24 | E: Method copy has died unexpectedly! | E: Sub-process copy returned an error code (112) | E: Method http has died unexpectedly! | E: Sub-process http returned an error code (112) | | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ getent group cdrom | cdrom:x:24:kibi | | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ groups | kibi cdrom floppy audio dip video plugdev sbuild kvm libvirt so this seems to be failing with the first non-primary group? Now if I log out of the schroot session, remove my user 'kibi' from the cdrom group and re-enter a schroot session, I'm now getting a failure on the next group: | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build build_netboot-gtk USE_UDEBS_FROM=sid | make: Entering directory '/home/kibi/debian-installer/installer/build' | Using generated sources.list.udeb: |deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ localudebs/ |deb http://localhost/debian sid main/debian-installer | make[2]: 'sources.list.udeb' is up to date. | Reading package lists... Done | E: Method gave invalid 400 URI Failure message: Could not switch group, user _apt is still in group 25 | E: Method gave invalid 400 URI Failure message: Could not switch group, user _apt is still in group 25 | E: Method copy has died unexpectedly! | E: Sub-process copy returned an error code (112) | | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ getent group floppy | floppy:x:25:kibi | | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ groups | kibi floppy audio dip video plugdev sbuild kvm libvirt Iterating again, I'm now failing because of the audio group… While I've been experimenting with adding/removing myself from the said groups, I'm noticed this a few times, without being able to figure out what exactly causes this… | W: No sandbox user '_apt' on the system, can not drop privileges In which case, going back to apt.git and "sudo debi -u" to reinstall all packages I've built seems to fix the issue. > > Given that schroot is involved mentioning if your host has an _apt user > > or not might also help. As I learned today schroot is copying users and > > groups into the schroot which makes all of this kinda strange… (#565613) > > [two years of testing and you are still surprised on release…] > > > > btw: To not block anyone: You can use the config option > > Debug::NoDropPrivs to true to disable privilege dropping for the moment. > > Thanks, I'll try that and maybe temporarily switch debian-installer to > using it so that we get our daily builds back until the apt side is > figured out. This seems to work fine as a last resort option, thanks. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
David Kalnischkies (2015-11-27): > On Fri, Nov 27, 2015 at 09:08:35PM +0100, Cyril Brulebois wrote: > > | E: Method gave invalid 400 URI Failure message: Could not get new groups > > - getgroups (22: Invalid argument) > > | E: Method copy has died unexpectedly! > > | E: Sub-process copy returned an error code (112) [ BTW, for completeness, the bug report I had in mind was filed against sbuild rather than schroot: https://bugs.debian.org/728422 ] > So, getgroups gets called there to verify that we really lost all groups > (beside the one _apt is in: nogroup). A few lines above we set the list > of (supplementary) groups containing only this group, then we switch uid > and gid (the later isn't enough for group switching aka we would be > still in root without the setgroups before). > > So, us calling getgroups should really only return one group. Getting an > EINVAL suggests we get more than one… that is probably bad, but I have > a slight glimmer of hope that its just two times the same group – even > if that makes no sense… anyway, I can't reproduce this at the moment, so > it would be nice if someone could try the attached patch which could at > least tell us in which groups we remain (or it just works if we really > see duplicated groups here). Everything is possible I guess. ACK, will test in a few moments. > Given that schroot is involved mentioning if your host has an _apt user > or not might also help. As I learned today schroot is copying users and > groups into the schroot which makes all of this kinda strange… (#565613) > [two years of testing and you are still surprised on release…] > > btw: To not block anyone: You can use the config option > Debug::NoDropPrivs to true to disable privilege dropping for the moment. Thanks, I'll try that and maybe temporarily switch debian-installer to using it so that we get our daily builds back until the apt side is figured out. Mraw, KiBi. signature.asc Description: Digital signature
Re: Broken EFI grub.cfg on stretch images
Samuel Thibault (2015-11-27): > Cyril Brulebois, on Fri 27 Nov 2015 23:32:03 +0100, wrote: > > Are we talking about possibly moving stuff from: > > - build/tmp/netboot-gtk/ to build/tmp/netboot/gtk? > > - build/tmp/netboot-gtk/ to build/tmp/netboot-gtk/gtk? > > > > where stuff means initrd.gz (only)? > > Yes. Honestly, I don't understand why they are not in gtk/, that only > brings confusion as to whether the image is gtk-ish or not. > > > I'm not too fond of moving files around, especially since serving the > > right files from the right places is sometimes hard/long to set up; so > > I don't think you're “less than ideal” commit as you call it is too bad. > > I'm fine with keeping this special-casing, I just feel that simply > keeping gtk files in gtk/ would lead to less special-casing overall. I meant to mention I don't feel strongly one way or the other. Having stuff where they make sense is of course a good idea. Especially so if that means fewer hacks/easier maintenance. Just wanted to emphasize that moving user-facing files/locations around has a cost, for users. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
On Fri, Nov 27, 2015 at 09:08:35PM +0100, Cyril Brulebois wrote:
> | E: Method gave invalid 400 URI Failure message: Could not get new groups -
> getgroups (22: Invalid argument)
> | E: Method copy has died unexpectedly!
> | E: Sub-process copy returned an error code (112)
So, getgroups gets called there to verify that we really lost all groups
(beside the one _apt is in: nogroup). A few lines above we set the list
of (supplementary) groups containing only this group, then we switch uid
and gid (the later isn't enough for group switching aka we would be
still in root without the setgroups before).
So, us calling getgroups should really only return one group. Getting an
EINVAL suggests we get more than one… that is probably bad, but I have
a slight glimmer of hope that its just two times the same group – even
if that makes no sense… anyway, I can't reproduce this at the moment, so
it would be nice if someone could try the attached patch which could at
least tell us in which groups we remain (or it just works if we really
see duplicated groups here). Everything is possible I guess.
Given that schroot is involved mentioning if your host has an _apt user
or not might also help. As I learned today schroot is copying users and
groups into the schroot which makes all of this kinda strange… (#565613)
[two years of testing and you are still surprised on release…]
btw: To not block anyone: You can use the config option
Debug::NoDropPrivs to true to disable privilege dropping for the moment.
Best regards
David Kalnischkies
diff --git a/apt-pkg/contrib/fileutl.cc b/apt-pkg/contrib/fileutl.cc
index 46de634..f754b31 100644
--- a/apt-pkg/contrib/fileutl.cc
+++ b/apt-pkg/contrib/fileutl.cc
@@ -2322,12 +2322,17 @@ bool DropPrivileges() /*{{{*/
return _error->Errno("seteuid", "Failed to seteuid");
#endif
- // Verify that the user has only a single group, and the correct one
- gid_t groups[1];
- if (getgroups(1, groups) != 1)
- return _error->Errno("getgroups", "Could not get new groups");
- if (groups[0] != pw->pw_gid)
- return _error->Error("Could not switch group");
+ // Verify that the user isn't still in any supplementary groups
+ long const ngroups_max = sysconf(_SC_NGROUPS_MAX);
+ std::unique_ptr gidlist(new gid_t[ngroups_max]);
+ if (unlikely(gidlist == NULL))
+ return _error->Error("Allocation of a list of size %lu for getgroups failed", ngroups_max);
+ ssize_t gidlist_nr;
+ if ((gidlist_nr = getgroups(ngroups_max, gidlist.get())) < 0)
+ return _error->Errno("getgroups", "Could not get new groups (%lu)", ngroups_max);
+ for (ssize_t i = 0; i < gidlist_nr; ++i)
+ if (gidlist[i] != pw->pw_gid)
+ return _error->Error("Could not switch group, user %s is still in group %d", toUser.c_str(), gidlist[i]);
// Verify that gid, egid, uid, and euid changed
if (getgid() != pw->pw_gid)
signature.asc
Description: PGP signature
Re: Broken EFI grub.cfg on stretch images
Cyril Brulebois, on Fri 27 Nov 2015 23:32:03 +0100, wrote: > Samuel Thibault (2015-11-27): > > That looks like the trigger, yes, because it restores spk.cfg. I > > hadn't noticed that ./util/syslinux-cfgs lists *all* .cfg files when > > used for cdrom targets. I have now blacklisted spk.cfg there. I > > agree that this is less than ideal, but this is a consequence of the > > choice of putting the initrd of gtk-only netboot images at the root > > instead of gtk/ Perhaps that could be changed? > > Are we talking about possibly moving stuff from: > - build/tmp/netboot-gtk/ to build/tmp/netboot/gtk? > - build/tmp/netboot-gtk/ to build/tmp/netboot-gtk/gtk? > > where stuff means initrd.gz (only)? Yes. Honestly, I don't understand why they are not in gtk/, that only brings confusion as to whether the image is gtk-ish or not. > I'm not too fond of moving files around, especially since serving the > right files from the right places is sometimes hard/long to set up; so > I don't think you're “less than ideal” commit as you call it is too bad. I'm fine with keeping this special-casing, I just feel that simply keeping gtk files in gtk/ would lead to less special-casing overall. Samuel
Re: Broken EFI grub.cfg on stretch images
Samuel Thibault (2015-11-27): > That looks like the trigger, yes, because it restores spk.cfg. I > hadn't noticed that ./util/syslinux-cfgs lists *all* .cfg files when > used for cdrom targets. I have now blacklisted spk.cfg there. I > agree that this is less than ideal, but this is a consequence of the > choice of putting the initrd of gtk-only netboot images at the root > instead of gtk/ Perhaps that could be changed? Are we talking about possibly moving stuff from: - build/tmp/netboot-gtk/ to build/tmp/netboot/gtk? - build/tmp/netboot-gtk/ to build/tmp/netboot-gtk/gtk? where stuff means initrd.gz (only)? I'm not too fond of moving files around, especially since serving the right files from the right places is sometimes hard/long to set up; so I don't think you're “less than ideal” commit as you call it is too bad. Mraw, KiBi. signature.asc Description: Digital signature
Re: Broken EFI grub.cfg on stretch images
Hello, Cyril Brulebois, on Thu 26 Nov 2015 01:31:19 +0100, wrote: > Steve McIntyre (2015-11-26): > > KiBi/Didier: I've now noticed the there's a slight issue with the > > menus we have at the moment. Not sure if it's an artifact of the > > multi-arch setup or not, but in the menus we're now getting two > > different versions of the installer with speech both veing shown with > > the exact same label text and the same shortcut: > > > > label installspk > > menu label Install with ^speech synthesis > > kernel /install.amd/vmlinuz > > append vga=788 initrd=/install.amd/initrd.gz speakup.synth=soft --- > > quiet > > > > label installspk > > menu label Install with ^speech synthesis > > kernel /install.amd/vmlinuz > > append vga=788 initrd=/install.amd/gtk/initrd.gz speakup.synth=soft > > --- quiet > > > > and this is showing up in the grub menus I'm generating too. We should > > probably just pick one that we want? > > Wild guess, side effect of the following commit (src:debian-installer)? > | commit d14db6ad4079b3e4d996f67ffd36292b18e6b15b > | Author: Samuel Thibault > | Date: Tue Sep 15 01:31:14 2015 +0200 > | > | Restore actually-used non-gtk speech synthesis entries > | > | - Otherwise netboot/gtk/mini.iso (which is gtk only) does not > contain the > | speech entry. > | - Avoid including them on non-gtk netboot image, though. > > https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?id=d14db6ad4079b3e4d996f67ffd36292b18e6b15b > > (Adding youpi to the loop accordingly.) Thanks for the Cc. That looks like the trigger, yes, because it restores spk.cfg. I hadn't noticed that ./util/syslinux-cfgs lists *all* .cfg files when used for cdrom targets. I have now blacklisted spk.cfg there. I agree that this is less than ideal, but this is a consequence of the choice of putting the initrd of gtk-only netboot images at the root instead of gtk/ Perhaps that could be changed? Samuel
[PATCH:di-autobuild] buildscript: Detect running sessions to avoid spawning a new one
An apt hang was spotted during d-i's build (through daily build crontab
entries), and even if the immediate issue is going away (I killed all
schroot sessions manually, and apt now returns an issue instead of
hanging forever), it might be nice to try and detect when a session
already exists, to avoid starting too many of them. The following patch,
tested on barriere, seems to do the trick.
---
buildscript | 6 ++
1 file changed, 6 insertions(+)
diff --git a/buildscript b/buildscript
index f787db4..8166bb3 100755
--- a/buildscript
+++ b/buildscript
@@ -87,6 +87,12 @@ cleanup () {
}
create_session() {
+ echo "INFO: checking for running sessions"
+ if schroot-list-sessions | grep "^sid_${ARCH}-dchroot"; then
+echo "ERROR: Existing sessions found, aborting"
+exit 1
+ fi
+
echo "INFO: creating schroot"
SID="$(schroot -b -c chroot:sid_${ARCH}-dchroot)"
echo "INFO: session $SID created"
--
2.1.4
Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
Cyril Brulebois (2015-11-27):
> We're currently missing d-i daily builds, apparently because apt-get is
> stuck. Trying to replicate the issue in one of my devel schroots, it
> seems to be trying to call select with strange parameters:
> | 9996 select(1, [], [], NULL, {0, 498491}) = 0 (Timeout)
> | 9996 rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
> | 9996 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> | 9996 write(1, "\r0% [Working]", 13)= 13
> | 9996 select(1, [], [], NULL, {0, 50}) = 0 (Timeout)
> | 9996 rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
> | 9996 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> | 9996 write(1, "\r0% [Working]", 13)= 13
> | 9996 select(1, [], [], NULL, {0, 50}) = 0 (Timeout)
> | 9996 rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
> | 9996 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> | 9996 write(1, "\r0% [Working]", 13)= 13
> | 9996 select(1, [], [], NULL, {0, 50}) = 0 (Timeout)
This part seems to be fixed with:
| apt (1.1.1) unstable; urgency=medium
| .
|[ Michael Vogt ]
|* Deal with killed acquire methods properly instead of hanging
| (Closes: #806406)
that I grabbed from incoming.
I'm now getting this with an http://localhost/debian deb line in my
sources.list (which gets used to determine what to put in the local
sources.list.udeb used in d-i's build system):
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build
build_netboot-gtk USE_UDEBS_FROM=sid
| make: Entering directory '/home/kibi/debian-installer/installer/build'
| Using generated sources.list.udeb:
|deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/
localudebs/
|deb http://localhost/debian sid main/debian-installer
| make[2]: 'sources.list.udeb' is up to date.
| Running APT_GET (else)
| Reading package lists... Done
| E: Method gave invalid 400 URI Failure message: Could not get new groups -
getgroups (22: Invalid argument)
| E: Method gave invalid 400 URI Failure message: Could not get new groups -
getgroups (22: Invalid argument)
| E: Method copy has died unexpectedly!
| E: Sub-process copy returned an error code (112)
and slightly differently with a file:///srv/mirrors/debian deb line:
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build
build_netboot-gtk USE_UDEBS_FROM=sid
| make: Entering directory '/home/kibi/debian-installer/installer/build'
| Using generated sources.list.udeb:
|deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/
localudebs/
|deb copy:///srv/mirrors/debian sid main/debian-installer
| make[2]: 'sources.list.udeb' is up to date.
| Running APT_GET (else)
| Reading package lists... Done
| E: Method gave invalid 400 URI Failure message: Could not get new groups -
getgroups (22: Invalid argument)
| E: Method copy has died unexpectedly!
| E: Sub-process copy returned an error code (112)
Coming to think of it, I vaguely remember groups-related issues below
schroot from the early systemd days (I kept sysvinit for a while because
of this), but that disappeared a long while ago.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Backport fix for #789600?
Steve McIntyre (2015-11-27): > Yup, makes sense. I'll double-check the latest daily later on when I'm > home. Except daily builds are missing; investigating. Mraw, KiBi. signature.asc Description: Digital signature
base-installer_1.158_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 27 Nov 2015 07:13:36 +0100 Source: base-installer Binary: base-installer bootstrap-base Architecture: source all i386 Version: 1.158 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: base-installer - base system installation framework (udeb) bootstrap-base - Install the base system (udeb) Closes: 806218 Changes: base-installer (1.158) unstable; urgency=medium . [ Cyril Brulebois ] * Use -arch variant for both dh_install and dh_installdebconf overrides, fixing FTBFS with -A (Closes: #806218). Checksums-Sha1: f03888bc8c0199f0a37ecbd96e2e7189419d7057 1897 base-installer_1.158.dsc 9120105587e85fdf7e3ad673145f9738a8967d6e 254496 base-installer_1.158.tar.xz c070dbe68dfdc4a87022fce275e13556dffe49cd 47536 base-installer_1.158_all.udeb d338f93a704366e8321f51335560e2ed2ca4faca 195350 bootstrap-base_1.158_i386.udeb Checksums-Sha256: 1ca3da6d20aacdfa7bb487750857f7b80ef8517f21008075c0c80d4a71dd6258 1897 base-installer_1.158.dsc 86336225965c5f95f74ed3c1fe2d11a43e310be3f789fa7b75a155e011ee174a 254496 base-installer_1.158.tar.xz 905e90aff1cfd09c630807affd4026b78bc9b6e0c9aa73f9c7c7e0455934f6e9 47536 base-installer_1.158_all.udeb 84cebf3f814eb9720655b495a41d81a2e9f63d9b514f3866cf7787899a611cd5 195350 bootstrap-base_1.158_i386.udeb Files: f4841ec80a8b9e43196536b03c5c5854 1897 debian-installer required base-installer_1.158.dsc d2213d12674613c24e0d69773ba592c9 254496 debian-installer required base-installer_1.158.tar.xz 11ad097bd66a6aac6fcac4f2756b538a 47536 debian-installer required base-installer_1.158_all.udeb 6fbb2d61eab44ecda13f96323a35760e 195350 debian-installer required bootstrap-base_1.158_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWWIrIAAoJEIcvcCxNbiWoTYAP/2DZI/GPqp0vBK2OYw7TTgTi pipLaLQkMChOk+MIA3Dx3UtAFmg3SLUUcLDYKxWhjNUP33IyTAkgEqueUa3GcOMi VmwvrlGZPP3migM9QN3T7ffd6tChBlqDpJ7s/sBgugz/6TApWsJYFilxKesaRBEK XMJqjFDE7GtY7ltEU4LozjSc2eI4ndgnoX3qjR4hyS/k8niHbE44lCqmdDSypj/K tEbh72FvJjMc7JKAb0Hw7kOzFUS8UM5GoGfytYUF7CNrVuu3X/+srvxYD8YJuGkM Y46vEPm0rUJ1DMfM/7KpcRwfCKE9MZFg4dMsDkY+XlOreplrUx0pAWMHxINOJilC x2uXd4P+MhpQ5PqGyMhIch9mJa0Q2IKGEyFGyBivZxFvnRR+ReIlSFqnvSsyk6iU 9At48GzQsXRHzN+hRgZxx9PLU5C7ocNRBJtpPP7uGVLg4UxxIX4rre/SMyVQu9mj x+H5HoRvKx0GX165o7VKXbIbik6csTNOv4oPyxuGuvaluvQGDndL7AoDPSc5FZoC jz8LX0PRci2yvwZSQYh2apQVKnu6TJmnrWbs1d26thEvuI0AtXzmfsIcK5UmH/s1 ZC9hTNLNCM+j1QUXA/h8GAZJKwVN6QQUmji7qjHYAb/rYxendAVaJCdfXBz9DL4s +vHCFVJI4xOvPd1vm6wT =Lvx9 -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of base-installer_1.158_i386.changes
base-installer_1.158_i386.changes uploaded successfully to localhost along with the files: base-installer_1.158.dsc base-installer_1.158.tar.xz base-installer_1.158_all.udeb bootstrap-base_1.158_i386.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org)
Processing of base-installer_1.158_i386.changes
base-installer_1.158_i386.changes uploaded successfully to ftp-master.debian.org along with the files: base-installer_1.158.dsc base-installer_1.158.tar.xz base-installer_1.158_all.udeb bootstrap-base_1.158_i386.udeb Greetings, Your Debian queue daemon (running on host coccia.debian.org)
Bug#806218: marked as done (base-installer: FTBFS when built with dpkg-buildpackage -A (Directory nonexistent))
Your message dated Fri, 27 Nov 2015 17:04:00 + with message-id and subject line Bug#806218: fixed in base-installer 1.158 has caused the Debian Bug report #806218, regarding base-installer: FTBFS when built with dpkg-buildpackage -A (Directory nonexistent) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 806218: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806218 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:base-installer Version: 1.157 User: sanv...@debian.org Usertags: binary-indep Severity: important Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed: [...] debian/rules build-indep dh build-indep dh_testdir -i dh_auto_configure -i debian/rules override_dh_auto_build make[1]: Entering directory '/<>' debian/templates-build.pl amd64 < debian/templates-arch > debian/templates.gen # give the new templates file the same mtime as the input file, so # that po2debconf doesn't decide that it needs to run # debconf-updatepo touch -mr debian/templates-arch debian/templates.gen /usr/bin/make small [... snipped ...] armeb: 6 passes, 0 failures. armel: 92 passes, 0 failures. armhf: 104 passes, 0 failures. hppa: 36 passes, 0 failures. i386: 314 passes, 0 failures. ia64: 22 passes, 0 failures. m68k: 14 passes, 0 failures. mips: 97 passes, 0 failures. mipsel: 85 passes, 0 failures. powerpc: 134 passes, 0 failures. ppc64el: 16 passes, 0 failures. s390x: 7 passes, 0 failures. sh4: 20 passes, 0 failures. sparc: 36 passes, 0 failures. kfreebsd-amd64: 16 passes, 0 failures. kfreebsd-i386: 32 passes, 0 failures. make[2]: Leaving directory '/<>/kernel' make[1]: Leaving directory '/<>' fakeroot debian/rules binary-indep dh binary-indep dh_testroot -i dh_prep -i dh_auto_install -i debian/rules override_dh_install make[1]: Entering directory '/<>' dh_install if [ -e "kernel/amd64.sh" ]; then \ install -D -m644 "kernel/amd64.sh" \ debian/bootstrap-base/usr/lib/base-installer/kernel.sh; \ fi make[1]: Leaving directory '/<>' dh_installdocs -i dh_installchangelogs -i debian/rules override_dh_installdebconf make[1]: Entering directory '/<>' dh_installdebconf (echo ; cat debian/templates.gen) >> debian/bootstrap-base/DEBIAN/templates /bin/sh: 1: cannot create debian/bootstrap-base/DEBIAN/templates: Directory nonexistent debian/rules:40: recipe for target 'override_dh_installdebconf' failed make[1]: *** [override_dh_installdebconf] Error 2 make[1]: Leaving directory '/<>' debian/rules:3: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 Sorry not to have a fix, as I am reporting many bugs similar to this one. In this case, I see that you are using "dh", which allow (independently) optional targets override_dh_foo-arch and override_dh_foo-indep (for several values of "foo"). Maybe using them this problem could be fixed. Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work properly, the package would be suitable to be uploaded in source-only form if you wish. Thanks. --- End Message --- --- Begin Message --- Source: base-installer Source-Version: 1.158 We believe that the bug you reported is fixed in the latest version of base-installer, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 806...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated base-installer package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 27 Nov 2015 07:13:36 +0100 Source: base-installer Binary: base-installer bootstrap-base Architecture: source all i386 Version: 1.158 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: base-installer - base system installation framework (udeb)
Bug#806443: disk-detect/multipath: default path selector is not loaded
On Fri, Nov 27, 2015 at 03:33:39PM +, Ben Hutchings wrote: > On Fri, 2015-11-27 at 15:39 +0100, Hendrik Brueckner wrote: > [...] > > --- a/disk-detect.sh > > +++ b/disk-detect.sh > > @@ -202,7 +202,7 @@ fi > > db_get disk-detect/multipath/enable > > if [ "$RET" = true ]; then > > > > if anna-install multipath-udeb; then > > -> > > MODULES="dm-mod dm-multipath dm-round-robin dm-emc" > > +> > > MODULES="dm-mod dm-multipath dm-service-time dm-round-robin > > dm-emc" > > > > > # We need some dm modules... > > > > > depmod -a >/dev/null 2>&1 || true > > > > > for MODULE in $MODULES; do > > At least dm-service-time and dm-round-robin will be automatically > loaded by the kernel when needed. I'm not sure about the others. Just tried it out... the dm-multipath must be loaded manually, otherwise: ~ # multipath Nov 27 16:42:37 | DM multipath kernel driver not loaded ~ # modprobe dm-multipath ~ # multipath create: 36005076307ffc5e382db undef IBM,2107900 size=20G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef |- 0:0:0:1088110722 sda 8:0 undef ready running `- 1:0:0:1088110722 sde 8:64 undef ready running Loading the module and running multipath automatically loads the other kernel modules: ~ # lsmod Module Size Used by dm_round_robin 16384 4 dm_multipath 32768 5 dm_round_robin scsi_dh20480 1 dm_multipath dm_mod139264 5 dm_multipath sd_mod 49152 8 qeth_l245056 1 fuse 122880 0 qeth 122880 1 qeth_l2 ccwgroup 20480 1 qeth zfcp 122880 8 scsi_transport_fc 69632 1 zfcp scsi_mod 241664 4 zfcp,scsi_transport_fc,scsi_dh,sd_mod dasd_eckd_mod 110592 0 dasd_mod 98304 1 dasd_eckd_mod multipath automatically tries to load its default path selector module. In the example, I modified the multipath.conf to use round-robin. So strictly this patch is not necessary but at least consistent regarding the manual loading of the other modules. I leave the change up to the maintainer of the hw-detect/disk-detect package. Thanks for your help. Kind regards, Hendrik pgpo4MzMgypJ0.pgp Description: PGP signature
Re: Backport fix for #789600?
On Fri, Nov 27, 2015 at 05:34:58PM +0100, Cyril Brulebois wrote: >Steve McIntyre (2015-11-27): >> AFAICS it should just work (TM) - the existing code there is just >> listing on the grub-mkimage command line the modules that we want >> built-in. As we're already clearly using part_msdos, part_gpt is built >> at the same level so should get picked up in the same way. > >OK. Would still love to see a confirmation that it's actually working >before pushing this to the jessie branch. Yup, makes sense. I'll double-check the latest daily later on when I'm home. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: Backport fix for #789600?
Steve McIntyre (2015-11-27): > AFAICS it should just work (TM) - the existing code there is just > listing on the grub-mkimage command line the modules that we want > built-in. As we're already clearly using part_msdos, part_gpt is built > at the same level so should get picked up in the same way. OK. Would still love to see a confirmation that it's actually working before pushing this to the jessie branch. Mraw, KiBi. signature.asc Description: Digital signature
Re: Backport fix for #789600?
On Fri, Nov 27, 2015 at 01:57:28AM +0100, Cyril Brulebois wrote: >Steve McIntyre (2015-11-26): >> I've pushed a trivial fix for this today, so new unstable/testing >> d-i builds should be more useful for folks on GPT media. What do you >> think about adding this for new Jessie builds? (And how's the best way >> to do that?) > >Ah, I initially looked at debian-cd, but that's just debian-installer. >Apart from a missing changelog entry, I'm happy to cherry-pick the said >commit into the jessie branch for a later upload for a point release: >| commit c9e26e4e97b72fefd6c1ea894aba33750fdded53 >| Author: Steve McIntyre >| Date: Thu Nov 26 16:20:37 2015 + >| >| Add the part_gpt module into the core grub image >| >| Make it easier for users doing slightly different things with our >| images; include support for GPT partition tables as well as msdos >| Closes: #789600 >| > >I'm not familiar with this area. Is it sufficient to add it to some >search command to make it available? I mean: will the grub module be >where it's expected, or is some pre-existing copy step needed for that >to work? (I see it's available in various grub-* packages, and a >suitable grub-* package will likely be installed at this point, so I >suppose the addition to the search command might be sufficient, but >let's be sure.) AFAICS it should just work (TM) - the existing code there is just listing on the grub-mkimage command line the modules that we want built-in. As we're already clearly using part_msdos, part_gpt is built at the same level so should get picked up in the same way. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Bug#806443: disk-detect/multipath: default path selector is not loaded
On Fri, 2015-11-27 at 15:39 +0100, Hendrik Brueckner wrote: [...] > --- a/disk-detect.sh > +++ b/disk-detect.sh > @@ -202,7 +202,7 @@ fi > db_get disk-detect/multipath/enable > if [ "$RET" = true ]; then > >> if anna-install multipath-udeb; then > ->> > MODULES="dm-mod dm-multipath dm-round-robin dm-emc" > +>> > MODULES="dm-mod dm-multipath dm-service-time dm-round-robin > dm-emc" > >> > # We need some dm modules... > >> > depmod -a >/dev/null 2>&1 || true > >> > for MODULE in $MODULES; do At least dm-service-time and dm-round-robin will be automatically loaded by the kernel when needed. I'm not sure about the others. Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman, Secretary of the US Navy 1981-1987 signature.asc Description: This is a digitally signed message part
Bug#806447: win32-loader: ftbfs, convert: command not found
source: win32-loader version: 0.7.10 severity: serious Hi, win32-loader fails to build from source like this: [...] # Build the cdrom version OUTFILE_NAME=win32-loader.exe \ BUILD_DATE="Wed, 29 Apr 2015 09:25:43 +0200" \ dh_auto_build make -j1 make[2]: Entering directory '/var/lib/jenkins/jobs/d-i_build_win32-loader/workspace' convert templates/gtk_orig.png -resize 107x80 BMP3:templates/gtk.bmp bash: convert: command not found Makefile:122: recipe for target 'templates/gtk.bmp' failed make[2]: *** [templates/gtk.bmp] Error 127 make[2]: Leaving directory '/var/lib/jenkins/jobs/d-i_build_win32-loader/workspace' dh_auto_build: make -j1 returned exit code 2 debian/rules:42: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/var/lib/jenkins/jobs/d-i_build_win32-loader/workspace' debian/rules:38: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 full log available at https://jenkins.debian.net/job/d-i_build_win32-loader/25/consoleFull cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#806443: disk-detect/multipath: default path selector is not loaded
Package: disk-detect Version: 1.114 Severity: normal Tags: d-i patch Dear Maintainers, I am about to configure and install on multipath devices. The multipath program can create mappings but fails to load the mappings into the kernel. The problem is that the mulitpath program included in multipath-udeb_0.5.0+git1.656f8865 uses the service-time as default path selector for some time. See also git commit: https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/libmultipath/defaults.h?id=1bcf07988d7dc026099242a2a787178fdd27f8d1 The attached patch updates the disk-detect.sh script to the dm-service-time.ko kernel module. Note that I have already opened the below Debian bug to include the dm-service-time.ko module into the multipath-module package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806131 So this bug report slightly depends on the above. A possible workaround is to create the multipath.conf file with round-robin as default path selector. This might be a good choice for a jessie backport if it is required. Thanks and kind regards, Hendrik -- Hendrik Brueckner brueck...@linux.vnet.ibm.com | IBM Deutschland Research & Development GmbH Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen >From aab885128205ce9a29741e3c8578d4b79e9d3d88 Mon Sep 17 00:00:00 2001 From: Hendrik Brueckner Date: Fri, 27 Nov 2015 11:28:05 +0100 Subject: [PATCH] disk-detect/multipath: load service-time path selector module Load the dm-service-time.ko kernel module to make the service-time path selector available. Note that service-time is the default path selector for some years. See also https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/libmultipath/defaults.h?id=1bcf07988d7dc026099242a2a787178fdd27f8d1 Depends on Debian Bug #806131 Signed-off-by: Hendrik Brueckner --- disk-detect.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/disk-detect.sh b/disk-detect.sh index 8498f4f..88f67c6 100755 --- a/disk-detect.sh +++ b/disk-detect.sh @@ -202,7 +202,7 @@ fi db_get disk-detect/multipath/enable if [ "$RET" = true ]; then if anna-install multipath-udeb; then - MODULES="dm-mod dm-multipath dm-round-robin dm-emc" + MODULES="dm-mod dm-multipath dm-service-time dm-round-robin dm-emc" # We need some dm modules... depmod -a >/dev/null 2>&1 || true for MODULE in $MODULES; do -- 2.6.2
Re: More cdebconf improvements
Hi again,
On 17/11/15 00:07, Cyril Brulebois wrote:
> Regis Boudin (2015-11-16):
>> That's a different patch indeed, which I won't push without a minimum of
>> coordination as it changes the API/ABI of the plugin inteface. Also the
>> patch is more intrusive, and I would probably need to review it again
>> before pushing it.
>
> OK, thanks for confirming/clarifying. Feel free to push to a
> pu/$something branch once you have polished it for review and
> coordination.
So, I've split the patchinto several bits, which I pushed under
pu/qflags. The most critical commit is
2cebed019dde395db6432ed1232db144da3c004b, which converts question.flags
from uint to a linked list of strings. The reason being that there is no
limit in the spec to which flags might or might not exist, nor is there
such limitation in the perl implementation. This is what caused #666530.
As we discussed at Debconf, the main issue with this patch is that it
changes the API/ABI for the plugins. Fortunately, the plugins
(cdebconf-terminal and cdebconf-entropy) don't use this parameter in the
structure, so a simple binNMU would be enough.
It also breaks the text db format ; but I don't believe this one is
actually used anyway, as it's only build for non-d-i, is not the one
used by default, and I doubt anyone has bothered changing it.
Besides the missing debconf-apt-progress, this is the only remaining
difference with the perl implementation I'm aware of.
For curious people, I've attached my patch to debootstrap, which checks
for the DEBOOTSTRAP_USE_CDEBCONF environment veriable to run cdebconf
instead of debconf from the beginning.
I think that's enough rambling for now. As usual, any comments/feedback
is very welcome. And don't worry too much if I'm not very responsive, as
I'll be moving a lot over the next month.
Regis
From ea2b242f48749e42f373ed46b4afbcbea9b90299 Mon Sep 17 00:00:00 2001
From: Regis Boudin
Date: Thu, 26 Apr 2012 20:52:50 +0200
Subject: [PATCH] Check environment variable to force use of cdebconf
If DEBOOTSTRAP_USE_CDEBCONF is set, force cdebconf as part of the required
packages, and set DEBCONF_USE_CDEBCONF during bootstrap
---
scripts/sid | 15 +++
1 file changed, 15 insertions(+)
diff --git a/scripts/sid b/scripts/sid
index bf3404f..3509e61 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -18,6 +18,10 @@ esac
work_out_debs () {
required="$(get_debs Priority: required)"
+ if [ "$DEBOOTSTRAP_USE_CDEBCONF" ]; then
+ required="$required cdebconf"
+ fi
+
if doing_variant - || doing_variant fakechroot; then
#required="$required $(get_debs Priority: important)"
# ^^ should be getting debconf here somehow maybe
@@ -96,6 +100,13 @@ second_stage_install () {
DEBCONF_NONINTERACTIVE_SEEN=true
export DEBIAN_FRONTEND DEBCONF_NONINTERACTIVE_SEEN
+ if [ "$DEBOOTSTRAP_USE_CDEBCONF" ]; then
+ DEBCONF_USE_CDEBCONF=1
+ export DEBCONF_USE_CDEBCONF
+ else
+ unset DEBCONF_USE_CDEBCONF
+ fi
+
baseprog=0
bases=7
@@ -199,6 +210,10 @@ echo \"Warning: Fake start-stop-daemon called, doing nothing\"" > "$TARGET/sbin/
mv "$TARGET/sbin/start-stop-daemon.REAL" "$TARGET/sbin/start-stop-daemon"
rm -f "$TARGET/usr/sbin/policy-rc.d"
+ if [ "$DEBOOTSTRAP_USE_CDEBCONF" ]; then
+ echo "DEBCONF_USE_CDEBCONF=1" > "$TARGET/etc/profile.d/use_cdebconf.sh"
+ fi
+
progress $bases $bases CONFBASE "Configuring base system"
info BASESUCCESS "Base system installed successfully."
}
--
2.6.2
