Bug#682342: Latest patch successfully tested
On 8/16/2019 8:34 PM, Nishanth Aravamudan wrote:
> On 15.08.2019 [17:08:39 +0200], Cyril Brulebois wrote:
>> Nishanth Aravamudan (2019-08-14):
>>> We are able to reproduce this issue at will in Ubuntu Bionic's
>>> installer (not identical to Debian's, but code-wise in this path the
>>> same). While quite a while after the last update from Philipp, we
>>> tested the patch (netcfg_dhcp_domain.patch) after updating it to avoid
>>> a compilation issue, we found it did fix the problem for us.
>>>
>>> I am not sure if I can get Debian into our infrastructure to test
>>> explicitly, but I will work on it; at the same time, the code change
>>> seems straightforward.
>>
>> Thanks for your feedback. Care to share the fixed version? :)
>
> D'oh! I'm sorry, I thought I did. The patch we tested was:
>
> diff -Naur a/dhcp.c b/dhcp.c
> --- a/dhcp.c 2017-10-10 14:01:42.0 +
> +++ b/dhcp.c 2019-08-14 01:04:58.339325357 +
> @@ -590,7 +590,7 @@
> preseed_hostname_from_fqdn(client, buf);
> }
>
> -if (netcfg_get_hostname (client, "netcfg/get_hostname",
> hostname, 1)) {
> +if (netcfg_get_hostname (client, "netcfg/get_hostname",
> hostname, !have_domain)) {
> /*
> * Going back to POLL wouldn't make much sense.
> * However, it does make sense to go to the retry
> diff -Naur a/netcfg-common.c b/netcfg-common.c
> --- a/netcfg-common.c 2017-10-10 14:04:08.0 +
> +++ b/netcfg-common.c 2019-08-13 20:01:13.606510273 +
> @@ -1060,14 +1060,24 @@
> continue;
> }
>
> -if (accept_domain && (s = strchr(hostname, '.'))) {
> -di_info("Detected we have an FQDN; splitting and setting
> domain");
> -if (s[1] == '\0') { /* "somehostname." <- . should be ignored */
> +if ((s = strchr(hostname, '.'))) {
> +di_info("Detected an FQDN in hostname");
> +if (s[1] == '\0') {
> +/* "somehostname." <- . should be ignored */
> *s = '\0';
> -} else { /* assume we have a valid domain name given */
> -strncpy(domain, s + 1, MAXHOSTNAMELEN);
> -debconf_set(client, "netcfg/get_domain", domain);
> -have_domain = 1;
> +di_info("Stripped trailing dot from hostname");
> +} else {
> +/* assume that the domain is valid and copy it if
> + * accept_domain is set; just use the hostname if
> + * it is unset
> + */
> +if (accept_domain) {
> +strncpy(domain, s + 1, MAXHOSTNAMELEN);
> + di_info("Setting domain to %s", domain);
This needs indenting fix-up.
> +debconf_set(client, "netcfg/get_domain", domain);
> +have_domain = 1;
> +}
> +/* strip the domain from the hostname */
> *s = '\0';
> }
> }
>
>> I'm a little reluctant to blindly merging this patch (originally
>> labeled “untested”) without a go from its author. Philipp, should
>> I go ahead?
>
> Totally understood! I just wanted to make sure to revive this issue, as
> I'd also like to get it fixed in Ubuntu! Like I said, I will do my best
> to test and reproduce the fix with stock Debian.
I think this should be fine and we're early in the release cycle to find
potential problems if there are any.
Obviously it'd be great to have a test hardness with a DHCP server
sending various bits and us verifying that netcfg did the right thing.
But I'd surprised to find the time for that myself.
Kind regards and thanks
Philipp Kern
Bug#931195: flash-kernel: Add entry for Olimex A64-Olinuxino
Hello, Attached patch proposes new flash-kernel entry for A64 OLinuXino board with eMMC support. A64 OLinuXino board from Olimex has three variants with onboard eMMC: A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In addition, there are two variants without eMMC. One without eMMC and one with SPI flash. This suggests the need for separate device tree for the three eMMC variants. The Linux kernel upstream has chosen to create and use a separate device tree for the eMMC variants instead of adding eMMC support existing device tree. These changes to Linux kernel are queued for Linux 5.4. https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4=02bb66b347ff8115f53948f86b884e008ba385b9 Thanks, -- Sunil From ea0be10d5de3b7225c9de0b1244046bf79d1fadc Mon Sep 17 00:00:00 2001 From: Sunil Mohan Adapa Date: Thu, 22 Aug 2019 10:17:48 -0700 Subject: [PATCH 2/2] Add entry for Olimex A64-Olinuxino-eMMC A64 OLinuXino board from Olimex has three variants with onboard eMMC: A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In addition, there are two variants without eMMC. One without eMMC and one with SPI flash. This suggests the need for separate device tree for the three eMMC variants. The Linux kernel upstream has chosen to create and use a separate device tree for the eMMC variants instead of adding eMMC support existing device tree. These changes to Linux kernel are queued for Linux 5.4. https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4=02bb66b347ff8115f53948f86b884e008ba385b9 Signed-off-by: Sunil Mohan Adapa --- db/all.db | 7 +++ 1 file changed, 7 insertions(+) diff --git a/db/all.db b/db/all.db index d527fa1..e6cafc5 100644 --- a/db/all.db +++ b/db/all.db @@ -1302,6 +1302,13 @@ Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools +Machine: Olimex A64-Olinuxino-eMMC +Kernel-Flavors: arm64 +DTB-Id: allwinner/sun50i-a64-olinuxino-emmc.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Olimex A64 Teres-I Kernel-Flavors: arm64 DTB-Id: sun50i-a64-teres-i.dtb -- 2.20.1 From 8ae086aef5f08b8dc2e378764fd4b5ac6dffa9d1 Mon Sep 17 00:00:00 2001 From: Sunil Mohan Adapa Date: Wed, 26 Jun 2019 12:27:31 -0700 Subject: [PATCH 1/2] Add entry for Olimex A64-Olinuxino Signed-off-by: Sunil Mohan Adapa --- db/all.db | 7 +++ 1 file changed, 7 insertions(+) diff --git a/db/all.db b/db/all.db index 117a1af..d527fa1 100644 --- a/db/all.db +++ b/db/all.db @@ -1295,6 +1295,13 @@ DTB-Id: sun8i-a33-olinuxino.dtb U-Boot-Script-Name: bootscr.sunxi Required-Packages: u-boot-tools +Machine: Olimex A64-Olinuxino +Kernel-Flavors: arm64 +DTB-Id: allwinner/sun50i-a64-olinuxino.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Olimex A64 Teres-I Kernel-Flavors: arm64 DTB-Id: sun50i-a64-teres-i.dtb -- 2.20.1 signature.asc Description: OpenPGP digital signature
Re: Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
On Aug 19, Aurelien Jarno wrote:
Thank you for expressing your position in more detail.
> usrmerge works by moving all data from /lib into /usr/lib and then
> creating a symlink /lib -> /usr/lib. The same is done for the biarch
> or triarch directories, namely /lib32, /lib64, /libx32 and /libo32
> depending on the architecture. Note that this part is done by usrmerge,
> but doesn't appear in its description, nor in the debconf question
> asked to the user. It is important to note that it is done directly on
> the filesystem and that this change is not known to dpkg.
I do not think that describing this implementation detail would be
generally useful to users, but you are right. This complexity is an
effect of having to keep supporting non-merged systems, but I am not
willing to fight that battle right now.
> There is nothing special done with that regard in the glibc maintainer
> scripts.
Agreed.
> The usrmerge people considers that it has to be fixed in the glibc
> maintainer scripts.
I am not dead set on this, but so far it seems to me that, as long as we
need to keep supporting non-merged systems, such a solution would both
solve all issues and be the simplest one to implement, as long as it is
correctly defined in scope.
> As explained above, it would mean that the preinst
> script is responsible, if usrmerge is activated, to create the
> /lib{32,64,o32,x32} -> /usr/lib{32,64,o32,x32} symlink if it doesn't
> exist. The directory might not be empty as a result of a partial
> conversion to usrmerge (yes those system will exists). In turn this
An half-converted system is (more or less) broken and it is not libc's
responsability to fix it. Pseudocode:
# is this a merged-/usr system?
if [ -L /lib ]; then
# has the link already been created?
if [ -L /lib32/ ]; then
:
# if it has not, is a directory already there?
elif [ ! -d /lib32/ ]; then
# if not, then create it
ln -s /usr/lib32/ /lib32/
# is this needed or not?
[ -d /usr/lib32/ ] || mkdir /usr/lib32/
fi
fi
Implementing this would cover all non-pathological cases and improve on
the current situation.
> directory might be the one of the dynamic linker used for executing
> the maintainer scripts (dash/bash, coreutils). So this means the
> maintainer scripts have to handle the case of moving the dynamic
> linker without breaking the system.
No, it would never attempt to move any file: either e.g. /lib32/ does
not exist, and then libc6-* would create the link, or it does, and that
system is half-converted but it's not libc's fault, and continuing to
install some of the files in / would not break anything.
> In short it means *the most tricky part of usrmerge has to be
> implemented and maintained in the glibc preinst scripts*. This is even
I disagree: only the most basic function would need to be implemented by
the libc packages: creating a symlink if one is needed and it does not
already exist.
I would definitely never propose to move to other packages the migration
support currently implemented in usrmerge.
> more difficult as the preinst script will be executed all the time and
> not when the user ask for that. It won't ask the user for its permission
> before. It doesn't have the option to abort if something looks wrong as
> this will lead to a system difficultly recoverable for many users if
> they are dist-upgrading their system to a new release (usually apt-get
> install -f is not enough).
As explained, I think that this code can always be successful.
> Therefore I really believe the best solution for this issue is to
> make dpkg aware of the symlink, which means creating a package
> containing this symlinks. This could be for example:
> - in base-files, for example by depending on base-files-usrmerge |
> base-files-nousrmerge
I wonder what the base-files and deboostrap maintainers think about
this, since it would require some changes in their packages (non-trivial
ones in deboostrap, I think).
This also has the downside that this way it would be impossible to
delete the /libx32/ etc links when they are not needed, since they would
be created every time the package is updated.
> - in usrmerge after reconsidering that the package can be uninstalled
> after the conversion.
I am not sure that this could actually work: if the converter package is
designed to be installed on a non-merged system to convert it, what
would happen when it tried to install a /lib/ -> /usr/lib/ link in such
a non-merged system, where /lib/ already is a directory?
(It would also have all the downsides of the precedent point and
moreover require installing three extra Perl modules on every Debian
system.)
But let's assume that there would be also a base-files-usrmerge package
just to provide the links, to be installed later: how could this be
automated by the converter package, since dpkg does not support being
invoked by itself?
> - directly in the libc6 and libc6-xxx packages if the TC reconsiders the
>
Bug#935407: Failure to unpack initrd should be handled better
Martin Samuelsson, le jeu. 22 août 2019 13:19:58 +0200, a ecrit: > >[0.564101] Unpacking initramfs... > >[0.634972] Initramfs unpacking failed: write error > > Since this error message appears in the log and attempting to continue after > it will guaranteed yield in strange behaviour, the best thing would likely > be if debian-installer looked for it before attempting to do anything else > and failed hard with a descriptive error message. Doing that can only help indeed. An incomplete unpack can only lead to failures. Samuel
Bug#935407: Failure to unpack initrd should be handled better
Bernhard Übelacker @ 2019-07-16 (Tuesday), 22:01 (+0200) just tried to have a look at the part where steal-ctty is crashing. Thank you Bernhard! Maybe that situation could be detected when the initramfs was not unpacked successfully, but has enough unpacked to attempt starting the installer. I'm no kernel hacker but to the best of my understanding populate_rootfs() seems to be returning zero regardless of whether it fails or not. Reading that source code[1], as well as the relevant documentation[2,3], gives me the impression there is no way to make the kernel fail in any other way than to merely print error message and continue. Right? [0.564101] Unpacking initramfs... [0.634972] Initramfs unpacking failed: write error Since this error message appears in the log and attempting to continue after it will guaranteed yield in strange behaviour, the best thing would likely be if debian-installer looked for it before attempting to do anything else and failed hard with a descriptive error message. Due to Debian BTS harvested addresses being my primary spam source, I'm not monitoring this address. Yet I follow the bug report and my contact info is avaible at https://bugs.debian.org/199392#40 if needed. -- /Martin [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/init/initramfs.c [2] https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html [3] https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
Bug#932149: Question about documented Buster ram requirement (#932149)
Martin Samuelsson, le jeu. 22 août 2019 12:58:41 +0200, a ecrit: > The values seem to come from version 1.47 of lowmem from merely a few months > back. How are they obtained? As described in lowmem's README. But AIUI the Xen case (which I indeed didn't test) requires bigger values. > Since they are significantly lower than those of section 2.5, Yes, section 2.5 provides values for typical use. lowmem is about values for working at all. > and impossible to fit the initrd of buster's debian-installer, On amd64, Buster's text initrd is 19M only. The gtk initrd 45M. > should they really be in the Installation Guide at all? They happen to be what lowmem uses to determine whether to enter lowmem mode or not, so they are supposed to be working. Samuel
Bug#932149: Question about documented Buster ram requirement (#932149)
Dear Samuel Thibault, I was about to prepare a patch to fix #932149 by removing what I understood to be outdated information, but then realized you've actually made recent changes to it and must thus ask for your knowledge. Details below. Martin Samuelsson @ 2019-07-16 (Tuesday), 17:58 (+0200) If increasing the memory allocation for the target machine from 512MB to 1024MB the error goes away. Summary of issue #932149: Debian installer fails with strange errors if attempting to install on less than 550MB, yet the Installation guide states 256MB/512MB/170MB should be sufficient. This is unexpected since the section 3.4 of Buster's Installation Guide for amd64 states that the requirement of an installed system is 256MB, and that the actual installer should require only 170MB. The values seem to come from version 1.47 of lowmem from merely a few months back. How are they obtained? Since they are significantly lower than those of section 2.5, and impossible to fit the initrd of buster's debian-installer, should they really be in the Installation Guide at all? In case they truely belong there, how could section 3.4 be improved to properly describe the requirements for such installations? Fair enough though, there is conflicting information in section 2.5, Memory and Disk Space Requirements, where the figure is 550MB. Would the correct fix be to rephrase the documentation so that it is clear that 3.4 covers the requirement of an installed system, while the higher basic requirements in 2.5 are needed for the actual installation? Attempting to boot with kernel parameter lowmem set to 1 or 2 makes no difference. Insufficient ram results in seg fault and errors about missing console files regardless of lowmem's value. Above section only left for pointing out lowmem parameter changes nothing. Due to Debian BTS harvested addresses being my primary spam source, I'm not monitoring this address. Yet I follow the bug report and my contact info is avaible at https://bugs.debian.org/199392#40 if needed. -- /Martin
Processed: Re: Early segfault in steal-ctty on Xen DomU install
Processing commands for cont...@bugs.debian.org: > clone 932149 -1 Bug #932149 [installation-reports] Buster install requires more ram than documented Bug 932149 cloned as bug 935407 > retitle -1 Failure to unpack initrd should be handled better Bug #935407 [installation-reports] Buster install requires more ram than documented Changed Bug title to 'Failure to unpack initrd should be handled better' from 'Buster install requires more ram than documented'. > thanks Stopping processing here. Please contact me if you need assistance. -- 932149: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932149 935407: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935407 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#932684: buster-pu: package gnupg2/2.2.12-1+deb10u1
Control: tags -1 + confirmed d-i [full quote for KiBi's benefit] On 2019-08-21 20:05, Daniel Kahn Gillmor wrote: On Wed 2019-08-21 18:19:06 +0100, Adam D. Barratt wrote: * We adopt GnuPG's upstream approach of making keyserver access default to self-sigs-only. This means that the keyserver cannot flood the user's keyring by default. (we do *not* adopt upstream's choice of import-clean for keyserver default, see https://dev.gnupg.org/T4628 for more explanation) The introduction of this change in unstable (and since in testing) apparently led to some confusion amongst, and queries from, members of the project, so is likely to have a similar (but quite possibly larger) effect on the wider stable user base. If we are to include it, I think it would therefore be wise to ensure that it is accompanied by a NEWS entry which briefly explains the change and its implications. (Relatedly, the further through the stable cycle we get, the more awkward this would be to introduce.) Thanks, that's entirely reasonable. I've put this NEWS item into the debian/buster branch on salsa. Otherwise, the debdiff is the same. diff --git a/debian/NEWS b/debian/NEWS index 0a6a7440d..3005e935c 100644 --- a/debian/NEWS +++ b/debian/NEWS @@ -1,3 +1,25 @@ +gnupg2 (2.2.12-1+deb10u1) buster; urgency=medium + + In this version we adopt GnuPG's upstream approach of making keyserver + access default to self-sigs-only. This defends against receiving + flooded OpenPGP certificates. To revert to the previous behavior (not + recommended!), add the following directive to ~/.gnupg/gpg.conf: + +keyserver-options no-self-sigs-only + + We also adopt keys.openpgp.org as the default keyserver, since it avoids + the associated bandwidth waste of fetching third-party certifications + that will not be used. To revert to the older SKS keyserver network (not + recommended!), add the following directive to ~/.gnupg/dirmngr.conf: + +keyserver hkps://hkps.pool.sks-keyservers.net + + Note: we do *not* adopt upstream's choice of import-clean for the + keyserver default, since it can lead to data loss, see + https://dev.gnupg.org/T4628 for more details. + + -- Daniel Kahn Gillmor Wed, 21 Aug 2019 14:53:47 -0400 + Let me know if you want me to re-generate a full debdiff, or if you're ok with this plus the previous debdiff (with an updated date on debian/changelog to match debian/NEWS), That's fine, thanks. let me know whether i should go ahead and upload. This will need a d-i ack, so tagging + CCing. Regards, Adam
