Bug#910325: libdebian-installer: Build correctly with Werror=implicit-fallthrough
Package: libdebian-installer Version: 0.110 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic ubuntu-patch Dear Maintainer, it appears that libdebian-installer fails to build in our latest rebuild tests with GCC 7 -- implicit-fallthrough warning / error is in place, which means GCC will complain about src/tree.c's code for rotating trees when adding new nodes. The fix is pretty simple, as the code is straightforward. In Ubuntu, the attached patch was applied to achieve the following: * src/tree.c: Silence GCC's implicit-fallthrough warning by being explicit in this binary tree rotate code that there's not fallthrough; we're covering all tree rotation cases already (all paths in switch() already return(). Thanks for considering the patch. -- System Information: Debian Release: buster/sid APT prefers cosmic-security APT policy: (500, 'cosmic-security'), (500, 'cosmic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru libdebian-installer-0.110ubuntu2/src/tree.c libdebian-installer-0.110ubuntu3/src/tree.c --- libdebian-installer-0.110ubuntu2/src/tree.c 2017-05-04 11:46:32.0 -0400 +++ libdebian-installer-0.110ubuntu3/src/tree.c 2018-10-04 14:22:53.0 -0400 @@ -198,6 +198,7 @@ case 1: return di_tree_node_rotate_right_double (node); } + break; case -1: case 0: case 1:
Re: cdimage?? What should we call it?
On Aug 22, 2015 7:16 PM, "Wouter Verhelst" wrote: > > Hi, > > On Fri, Aug 21, 2015 at 07:20:53AM +0200, Hideki Yamane wrote: > > On Thu, 20 Aug 2015 22:40:32 -0300 > > Lisandro Damián Nicanor Pérez Meyer wrote: > > > And having get.debian.org as canonical maybe? But indeed I like the idea. > > > > Not only canonical but also gentoo does. > > https://get.gentoo.org redirects https://www.gentoo.org/downloads/ > > (and I like their newer website design...) > > I think Lisandro meant "the canonical location," as in, "the normal name > that you'd use, with the others being merely aliases for it," not "the > name that canonical (the company) uses". > And I think Lisandro meant it being the A name, with cdimage staying as a CNAME so it's still reachable, rather than the other way around :-) / Matt
Bug#806900: partman-multipath: correct mpath device detection and bindings
On Wed, Dec 2, 2015 at 6:51 PM, Cyril Brulebois wrote: > Hi, > [...] > > Below you can find a patch that solves both problems. Feedback is > welcome. > > Mathieu mentioned branches a while ago: > https://lists.debian.org/debian-boot/2015/05/msg00271.html > > That's spot on, it's exactly what is needed in partman-multipath. Still, shouldn't we also copy over the wwids file from the installer onto the target? hw-detect needs a similar change, which I've already done at [1], and some changes for the output of multipath -l in partman-base at [2]. [1] http://anonscm.debian.org/cgit/d-i/hw-detect.git/commit/?h=people/cyphermox/mpath-detect [2] http://anonscm.debian.org/cgit/d-i/partman-base.git/log/?h=people/cyphermox/multipath5 Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C 80D3 C7DA A946 DC95 CA5A
Bug#806713: disk-detect/multipath: update checks for changed mpath alias names
On Fri, Feb 10, 2017 at 1:02 PM, Cyril Brulebois wrote: > Hi, > > Hendrik Brueckner (2015-11-30): > > Dear maintainers, > > > > An update in the multipath-tools, [1], changed the naming scheme for > > mpath aliases created when the user friendly names option is specified. > > > > The alias naming changed from mpath0 to mpatha replacing the numeric > > digits with alphabetic letters. The patch below updates the > > disk-detect.sh to correctly detect multipath devices with the new > > naming scheme. > > AFAICT from the current manpage, when this option is not specified, WWID > are used instead, so there's no need to keep the [0-9] part in the > check, right? This seems confirmed by my reading of #806900 so I think > I'll push the patch to master right away. > > That's perhaps right; we could possibly do away with the [0-9] part in the check. The reason for changing it to [a-z] was only to have the smallest amount of changes possible. I don't see what benefit that would really bring though, but I haven't looked at multipath in a while. > > On the people/cyphermox/mpath-detect branch in the d-i/hw-detect > > repository, there is already a patch for the same problem. I could > > not find a bug report for it. So that's why I am opening this one to > > keep this problem in mind. It would be great if you could help me to > > understand the practice on how such problem fixes becomes integrated. > > Unfortunately lack of manpower means patches are sometimes not reviewed > or merged for a long time. :( > I also could have been more proactive at this; I'll update the branches shortly -- there has been further changes to partman-multipath and hw-detect to help with multipath support. > > > Apart from the disk-detect package, the partman-multipath package is > > also affected by mpath naming change. I will open a separate bug report > > and attach a patch to solve the naming there. > > I'll try and look at the various patches after Mathieu's reply in > #806900. I might even propose them through proposed-updates if the next > RC looks good for multipath support. > I'm sorry, I just don't see what I should be replying to? We're really not far from multipath support working (given that it does appear to work reasonably well in Ubuntu). Let me do the merges to get Ubuntu based on the right new versions of Debian, then we can do one round of reviewing all the patches. / Matt
debootstrap InRelease file support
Hi, Looking into a bug in Ubuntu relating to an out of sync proxy, InRelease file support in debootstrap came up. I found out that debootstrap had already had such support in the past (specifically, in 1.0.47 and earlier) and that was removed by Julien Cristau because it also pulled in a fuller gpg, which comes with its own set of potential issues. Seems like we could well put it back in and just replace the bit that extracts the signed data in InRelease (same as is in Release) with using sed and grep to remove the signature text. I did the work and pushed it to git at http://anonscm.debian.org/cgit/d-i/debootstrap.git/log/?h=people/cyphermox/inrelease. As before, this would default to using the InRelease file from the archive first, if available, and otherwise fallback to using the usual Release + Release.gpg. Is there any interest for supporting this again? I would like some feedback on the code branch, then I'd be happy to merge it to master (but I would still need someone to sponsor the upload). Kindly, Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 signature.asc Description: OpenPGP digital signature
Supporting an user-specified initiatorName for iSCSI in d-i
Hi, I've done some work on testing iSCSI recently. One thing that comes up is that on a secured setup which expects a very specific initiatorName, one needs to do some back and forth to figure out what open-iscsi has picked as a random initiatorName, and add that to what's allowed by the iSCSI targets. It would be more obvious for administrators to be able to define valid names on the storage from the start, and entering that value during install (possibly using their own naming scheme which may be different from our default). I've already contacted the iSCSI maintainers to get open-iscsi-udeb to allow the /etc/iscsi/initiatorname.iscsi file to be initialized before iscsid is started, what this needs now is simply prompting the user for an initiatorName, and writing that to the file immediately before starting iscsid. The work is ready for partman-iscsi here: http://anonscm.debian.org/cgit/d-i/partman-iscsi.git/log/?h=people/cyphermox/initiatorname. It depends on an open-iscsi change, but that has been uploaded earlier today: https://tracker.debian.org/news/752405 Thoughts? PS. Also, seems like in Ubuntu we're carrying some extra patches for dealing with preseeding iSCSI and dealing with the case where no disks are detected by hw-detect at all (in which case we may try to login to iSCSI if the user enabled it); I will prepare a code branch for hw-detect that updates the code from cjwatson already in git, if there's anything that has changed since. -- Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 signature.asc Description: OpenPGP digital signature
Bug#826665: libdebian-installer: libd-i EFI detection can pass while efibootmgr's/efivar's will fail
Package: libdebian-installer
Version: 0.102
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch
Dear Maintainer,
EFI detection in libd-i can in some cases pass while efibootmgr will fail to
set BootEntry due to efivar's checks actually looking for efivars or vars
instead of just the existence of /sys/firmware/efi.
In Ubuntu; I'm applying the following patch to libdebian-installer's detection
code:
* src/system/efi.c: validate the presence of efivars *or* vars under
/sys/firmware/efi to decide whether we should show the system as running
in EFI mode; either of these paths is required for efibootmgr to set a
BootEntry at the end of installation.
Admittedly, this can still fail if for some reason efivars or vars are present
but empty, but this isn't any different than for /sys/firmware/efi itself.
/sys/firmware/efi/vars should mostly always be around, as it appears to come
straight from the kernel; /sys/firmware/efi/efivars is typically to be mounted
by the init system (this happens at least in systemd src/core/mount-setup.c).
In Ubuntu this is bug:
https://bugs.launchpad.net/ubuntu/+source/libdebian-installer/+bug/1582320
Thanks for considering the patch.
-- System Information:
Debian Release: stretch/sid
APT prefers yakkety
APT policy: (500, 'yakkety'), (99, 'yakkety-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-23-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libdebian-installer-0.102ubuntu1/src/system/efi.c libdebian-installer-0.102ubuntu2/src/system/efi.c
--- libdebian-installer-0.102ubuntu1/src/system/efi.c 2015-12-23 19:24:26.0 -0500
+++ libdebian-installer-0.102ubuntu2/src/system/efi.c 2016-06-03 21:22:39.0 -0400
@@ -26,8 +26,9 @@
* exists */
int di_system_is_efi(void)
{
- int ret = access("/sys/firmware/efi", R_OK);
- if (ret == 0)
+ int efivars_access = access("/sys/firmware/efi/efivars", R_OK);
+ int vars_access = access("/sys/firmware/efi/vars", R_OK);
+ if (efivars_access == 0 || vars_access == 0)
{
/* Have we been told to ignore EFI in partman-efi? */
ret = access("/var/lib/partman/ignore_uefi", R_OK);
Bug#783977: partman-auto: should create efi partitions as fat32 rather than free
Package: partman-auto
Severity: normal
Tags: patch
Dear Maintainer,
It looks like partman-auto, in the recipe-amd64-efi recipes, uses "free"
rather than say, "fat32" as a partition type for the EFI partitions it tries
to create. This has the unfortunate side-effect of not letting partman-efi do
all that it may try to do, such as setting a name for the EFI partition (see
partman-efi's update.d/efi_sync_flag). This happens because decode_recipe
defaults to using 'ext2' to describe that partition, which doesn't match
partman-efi's checks.
A patch is attached.
-- System Information:
Debian Release: jessie/sid
APT prefers vivid-updates
APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'),
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.19.0-15-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From c717f8418513a268c708b496dccb80422a385eaf Mon Sep 17 00:00:00 2001
From: Mathieu Trudel-Lapierre
Date: Fri, 1 May 2015 14:58:24 -0400
Subject: [PATCH] Initially define efi partitions as fat32 for amd64/i386
---
recipes-amd64-efi/atomic | 2 +-
recipes-amd64-efi/home | 2 +-
recipes-amd64-efi/multi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/recipes-amd64-efi/atomic b/recipes-amd64-efi/atomic
index 2e81c4f..2995fa2 100644
--- a/recipes-amd64-efi/atomic
+++ b/recipes-amd64-efi/atomic
@@ -1,6 +1,6 @@
partman-auto/text/atomic_scheme ::
-538 538 1075 free
+538 538 1075 fat32
$iflabel{ gpt }
$reusemethod{ }
method{ efi }
diff --git a/recipes-amd64-efi/home b/recipes-amd64-efi/home
index ed12a51..77a49b3 100644
--- a/recipes-amd64-efi/home
+++ b/recipes-amd64-efi/home
@@ -1,6 +1,6 @@
partman-auto/text/home_scheme ::
-538 538 1075 free
+538 538 1075 fat32
$iflabel{ gpt }
$reusemethod{ }
method{ efi }
diff --git a/recipes-amd64-efi/multi b/recipes-amd64-efi/multi
index 37e03d6..bb3ff08 100644
--- a/recipes-amd64-efi/multi
+++ b/recipes-amd64-efi/multi
@@ -1,6 +1,6 @@
partman-auto/text/multi_scheme ::
-538 538 1075 free
+538 538 1075 fat32
$iflabel{ gpt }
$reusemethod{ }
method{ efi }
--
2.1.4
New d-i contributor
Hi everyone, I'm Mathieu, from Montreal. I've just subscribed to debian-boot@, but I've already been idling in #debian-boot for a while, I was one of the drivers of the Montreal bid for Debconf16, and I've been taking on d-i work for Ubuntu. I've already been bugging cjwatson every once in a while to review changes or merge git branches for things like grub, but I realise I should reach out more :) There's a few patches we included in d-i partman packages in Ubuntu that I'd like to get in Debian as well now. What would be the preferred method for this? My initial focus will be patches for multipath support that don't appear to have associated BTS bugs. Is it fine to push to git for code to be reviewed (in my own people/cyphermox-guest/xyz branch), or should I file bugs and attach patches? Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C 80D3 C7DA A946 DC95 CA5A
Multipath patches
Hi all, I've made a few git branches with changes we alreday have in Ubuntu that fix issues installing on multipathed disks: - partman-multipath: people/cyphermox-guest/naming - grub-installer: people/cyphermox-guest/multipath-prep - partman-base: people/cyphermox-guest/multipath All three should land together; the idea is to "normalize" on mpathXpY paths for the multipath devices while in d-i so that both parted-created partitions and partitions reused show up with the same names so as not to confuse other bits of the installer. -- Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C 80D3 C7DA A946 DC95 CA5A signature.asc Description: This is a digitally signed message part
Busybox 1.27 breaks kernel cmdline preseeding
Hi, In Ubuntu we recently noticed the following: with busybox 1.27.0; d-i now does not take into account some preseeding that happens at the kernel cmdline. For instance: linux /vmlinux etc. etc. etc. debconf/priority=critical netcfg/get_hostname=blah Here, debconf/priority and netcfg/get_hostname would not be preseeded correctly. On the other hand, using their aliases 'priority' and 'hostname' would work correctly. I investigated this with Adam Conrad and we tracked it down to changes in busybox's handling of /. It was previously permitted in variable names in the environment (cmdline preseeding eventually makes it there, where it gets read by env2debconf), and is no longer acceptable. This is why 'priority' works and 'debconf/priority' does not. It is technically correct to not allow slashes in variable names in the environment. Now, how should we go about fixing this? Adam pointed out we could always just parse /proc/cmdline, but this does not just work on kfreebsd. It's also possible to consider both /proc/cmdline and the environment; or just revert the particular change in busybox. I don't feel strongly either way, but I want to make the solution available in Debian as well... Anybody have a preference? Kindly, Mathieu Trudel-Lapierre > Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
Re: Busybox 1.27 breaks kernel cmdline preseeding
On Fri, Nov 24, 2017 at 9:33 AM, Raphael Hertzog wrote: > Apparently, kfreebsd has a working /proc/cmdline (thanks to linprocfs > mounted > by default) so we might want to switch to that. I don't know about the > hurd though. > Sorry. If I wrote that /proc/cmdline didn't work, I misspoke. What I meant was that I also quickly tried passing parameters on the kernel command-line from grub rather than in the way they were previously passed, and the extra parameters do not show up in kfreebsd. That might be grub behavior, I did not dig in that direction. I'm happy to have a look. As for hurd, /proc/cmdline also exists and includes all the parameters I add using 'set options='. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
Re: Busybox 1.27 breaks kernel cmdline preseeding
On Mon, Nov 27, 2017 at 3:08 PM, Raphael Hertzog wrote: [...] > I pushed a pu/kernel-cmdline-preseed branch implementing the preseeding > out of /proc/cmdline. It's more elaborate than Mathieu's patch > (https://paste.ubuntu.com/26034695/) in that it is able to handle > multi-word values. > > I tested it locally and it fixes the rescue mode for me. For > consistency, I renamed the command and the udeb, but the only place > where it matters is in "debian-installer" itself where we have to update > the package name. > That will work on most arches, but not on kfreebsd/*. That said, the easy fix would be to look at both environment and /proc/cmdline. I *think* you only really need -e 's/\([^ =]*=[^ "]\)/\n\1/g' -e "s/\([^ =]*=[^ ']\)/\n\1/g" to multiline the entries and appropriately handle any multiword. With my limited testing it seemed to work well, and would be less complex than your solution ;) Did I miss some important corner-case? -- Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
Re: Busybox 1.27 breaks kernel cmdline preseeding
On Mon, Nov 27, 2017 at 4:22 PM, Raphael Hertzog wrote: [...] > We wants to stop using the environment because busybox hides it from us... > I don't see the point of continuing to use it. I understand that; I tend to agree, modulo things not being listed in /proc/cmdline as below... > > Can you elaborate on what's wrong with /proc/cmdline on kfreebsd? We know > that it exists. Are you saying that it doesn't contain the actual > parameters passed on the kernel command line at boot time? > Correct; /proc/cmdline exists, but anything set up using: set kFreebsd.priority=high set kFreebsd.auto=true Which appears to me to be the current method for preseeding on the command-line (ie. at boot time; from grub); these options do not show up in /proc/cmdline in my testing. I tried to pass things after boot_one; but did not dig in any farther than that. There probably is another way to get this to work. [...] > At least it does not cope well with parameters without any "=". Try adding > words like "quiet" in the middle of your parameter list. They do not end > up on a line of their own. > > I freely admit that my solution is complex but I was not able to find a > simpler one that works well enough with my test case: > language=fr_FR long?='1 2 3' rescue/enable="true" my/description="un message" > --- quiet Yeah, I didn't have one of those in my test case. Oops. -- Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
