Re: Last chance for d-i changes in stretch
On Fri, 2017-05-26 at 19:04 +0200, Cyril Brulebois wrote: > Hi, > > You might have noticed final preparations for d-i Stretch RC 4 are > underways. A new debian-installer upload (or a binNMU) will need to > happen before the first stretch release (aka. r0). If there's anything > you want or would like to include in r0, now is the time to mention it. [...] I want to apply the change sent as <20170423005601.gp4...@decadent.org.uk>, but still haven't found the time to test it yet. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#860304: flash-kernel: Incorrect installation path for dtbs
On 2017-05-26, Heinrich Schuchardt wrote: > On 05/26/2017 08:58 PM, Vagrant Cascadian wrote: >> On 2017-05-26, Cyril Brulebois wrote: > I recently created file /etc/flash-kernel/ubootenv.d/fdtfile with > > setenv fdtfile meson-gxbb-odroidc2.dtb Oh, I didn't even know/remember that feature, that's really useful! >> I think the best thing to do would be to install in both >> /boot/dtbs/VERSION/FDTFILE and /boot/boot/dtbs/VERSION/SUBDIR/*.dtb, or >> create symlinks (if supported by the filesystem) if the file is found in >> a subdir... hopefully that won't require mangling the code too much; >> I'll take a look at it... or feel free to beat me to it! :) >> > > /boot/boot/dtbs/VERSION/SUBDIR/*.dtb is what my patch does if a subdir > is provided in /usr/share/flash-kernel/db/all.db. It looks like your patches only copies it to the SUBDIR, but I think it would be safer to copy it twice in both /boot/dtbs/VERSION/FDTFILE as well as /boot/dtbs/VERSION/SUBDIR/FDTFILE, as different versions of u-boot may support inside or outside the SUBDIR. That said, bootscr.uboot-generic *should* fall back to the /boot/dtb-VERSION or /boot/dtb symlinks, after it fails to find the file based on $fdtfile, which *should* work around the problem entirely, even if a bit ugly. > If we want a more radical redesign: > > Why do we rely on environment variable fdtfile at all? > > The current device tree supplies file /proc/device-tree/model. > We read all.db to find the name of the dtb with this model name and than > install just this dtb from the Kernel installation. > So there is not much of a choice for U-Boot to pass different values of > fdtfile which will be of use when booting. > > Couldn't we simply write the dtb file name from all.db to /boot/boot.scr? Overall, I like this idea, but not all boot scripts work the same way... they may not even load a .dtb at all. Also, using what's requested from the bootloader would help if you've transferred the image to a compatible system that loads a different .dtb (e.g. wandboard-revc vs. wandboard-revb). > Should the dtb file name or the model string change between two Kernel > releases we are anyway in deep trouble when upgrading (unfortunately > this may happen, cf. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d59561479e6f91d5905db37f668e1cbfdac2). Which is why I'd like to implement a feature to copy all .dtb files for boards with a sufficiently large /boot ... but it's a bit late in the freeze to implement such a thing... live well, vagrant signature.asc Description: PGP signature
Bug#860304: flash-kernel: Incorrect installation path for dtbs
On 05/26/2017 08:58 PM, Vagrant Cascadian wrote: > On 2017-05-26, Cyril Brulebois wrote: >> And thanks for being persistent. > > Indeed, I've been working around this issue locally rather than doing > the right things by filing bugs and writing patches... :) I recently created file /etc/flash-kernel/ubootenv.d/fdtfile with setenv fdtfile meson-gxbb-odroidc2.dtb on my Odroid C2 as workaround. But that is not a good permanent solution. > I think the best thing to do would be to install in both > /boot/dtbs/VERSION/FDTFILE and /boot/boot/dtbs/VERSION/SUBDIR/*.dtb, or > create symlinks (if supported by the filesystem) if the file is found in > a subdir... hopefully that won't require mangling the code too much; > I'll take a look at it... or feel free to beat me to it! :) > /boot/boot/dtbs/VERSION/SUBDIR/*.dtb is what my patch does if a subdir is provided in /usr/share/flash-kernel/db/all.db. --- If we want a more radical redesign: Why do we rely on environment variable fdtfile at all? The current device tree supplies file /proc/device-tree/model. We read all.db to find the name of the dtb with this model name and than install just this dtb from the Kernel installation. So there is not much of a choice for U-Boot to pass different values of fdtfile which will be of use when booting. Couldn't we simply write the dtb file name from all.db to /boot/boot.scr? Should the dtb file name or the model string change between two Kernel releases we are anyway in deep trouble when upgrading (unfortunately this may happen, cf. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d59561479e6f91d5905db37f668e1cbfdac2). Best regards Heinrich Schuchardt
Bug#854801: Network Manager, Stretch and ipv6
On Fri, May 26, 2017 at 06:58:03PM +0200, Julien Cristau wrote: > +rdisc6 maintainer > > > IMO we should change d-i/netcfg to just never install rdnssd. I guess > > that might negatively impact systems on ipv6-only networks that don't > > have any other means to pick up name servers, but that seems strictly > > better than installing a package which conflicts with NM. I'm fine with that change. I had offered to | I can fix the latter by removing the conflicts and changing the hook | again to be a no-op if network-manager is installed. but I think that's too late in the release cycle. Bernhard signature.asc Description: Digital signature
Bug#863435: open-iscsi-udeb: finish-install script always thinks that iSCSI is used
Package: open-iscsi-udeb Version: 2.0.874-2 Severity: important Affects: debian-installer X-Debbugs-Cc: debian-boot@lists.debian.org, k...@debian.org Control: tags -1 + stretch sid Dear Maintainer, As reported on debian-release@/debian-boot@ recently, a recent change in how the initiator name was generated in the package causes finish-install to assume iSCSI is always used. This has two consequences: - update-initramfs -k all -u is needlessly called on all Debian installations, even those without iSCSI (looses a couple of seconds time, on _really_ slow systems possibly even a minute) - clutters every new installation with /etc/iscsi/initiatorname.iscsi, even those that don't use iSCSI This is harmless (nothing breaks), but can be annoying. Also, for Buster this risks that other installer components start relying on the fact that the initramfs is regenerated late in the installation process - which they shouldn't. It probably hasn't affected anything in Stretch yet, but this should be fixed really early in the Buster cycle to avoid any such problems. KiBi said that for Stretch this should be fixed in the first point release, so the plan is to open a p-u bug once this is fixed in sid after the Stretch release. Regards, Christian -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Last chance for d-i changes in stretch
On 05/26/2017 09:30 PM, Cyril Brulebois wrote: >> I've looked at that for a bit, and found out that this is my own >> fault: one of the uploads of open-iscsi I did before the freeze >> changed the logic on how the initiatorname was generated within the >> installer, (due to feedback from Ubuntu people IIRC) ensuring that >> /etc/iscsi always contains files, and the check in the finish-install >> script now thinks that iSCSI is used in _all_ installations. (It >> checks for /etc/iscsi/* [1].) For this reason it regenerates the >> initramfs on all installations, which takes a couple of seconds. >> >> The effect here is totally harmless (it just unnecessarily calls >> update-initramfs -k all -u), but it might be annoying. >> >> KiBi: I suspect you don't want to change this so close to the >> release, but in case you do, I'd be happy to upload a targeted fix >> for that. > > I think it would be best to postpone considering such a fix for the > first point release, instead of aiming for r0. Let's look at this once > r0 is out, so as to avoid generating noise for the release team? I've > added an item on my d-i task list so that I don't forget about it. Sure, perfectly fine with me. If I don't open a p-u bug after the release of Stretch myself, feel free to ping me. (Btw. I also just noticed from reading the code that the additional time is not the only side-effect: it will clutter every new installation with a small file in /etc/iscsi. The file is harmless, and won't cause any problems, but I wanted to mention it so you know about it.) Regards, Christian
Re: Last chance for d-i changes in stretch
Christian Seiler (2017-05-26): > Sure, perfectly fine with me. If I don't open a p-u bug after the > release of Stretch myself, feel free to ping me. > > (Btw. I also just noticed from reading the code that the additional > time is not the only side-effect: it will clutter every new > installation with a small file in /etc/iscsi. The file is harmless, > and won't cause any problems, but I wanted to mention it so you know > about it.) Yeah, I gathered that from your first message. :) But thanks for underlining the point just in case. Feel free to start by opening up a bug report against the udeb, which I can then reference as a known bug in errata. KiBi. signature.asc Description: Digital signature
Re: Last chance for d-i changes in stretch
On 05/26/2017 07:04 PM, Cyril Brulebois wrote: > You might have noticed final preparations for d-i Stretch RC 4 are > underways. A new debian-installer upload (or a binNMU) will need to > happen before the first stretch release (aka. r0). If there's anything > you want or would like to include in r0, now is the time to mention it. While installing a Debian 9 system a couple of days ago, I noticed that at the end of the installation it took a couple of seconds for doing finalizing actions related to open-iscsi - even though the system I installed didn't use iSCSI at all. I've looked at that for a bit, and found out that this is my own fault: one of the uploads of open-iscsi I did before the freeze changed the logic on how the initiatorname was generated within the installer, (due to feedback from Ubuntu people IIRC) ensuring that /etc/iscsi always contains files, and the check in the finish-install script now thinks that iSCSI is used in _all_ installations. (It checks for /etc/iscsi/* [1].) For this reason it regenerates the initramfs on all installations, which takes a couple of seconds. The effect here is totally harmless (it just unnecessarily calls update-initramfs -k all -u), but it might be annoying. KiBi: I suspect you don't want to change this so close to the release, but in case you do, I'd be happy to upload a targeted fix for that. Regards, Christian [1] https://sources.debian.net/src/open-iscsi/2.0.874-2/debian/open-iscsi-udeb.finish-install/
Re: Last chance for d-i changes in stretch
Hi, Christian Seiler (2017-05-26): > While installing a Debian 9 system a couple of days ago, I noticed > that at the end of the installation it took a couple of seconds for > doing finalizing actions related to open-iscsi - even though the > system I installed didn't use iSCSI at all. Oh, I had been wondering a bit about this, since timing seemed to have changed a bit with my automated tests; but I ended up bumping the max delay, thinking the initial setting was borderline, instead of investigating. > I've looked at that for a bit, and found out that this is my own > fault: one of the uploads of open-iscsi I did before the freeze > changed the logic on how the initiatorname was generated within the > installer, (due to feedback from Ubuntu people IIRC) ensuring that > /etc/iscsi always contains files, and the check in the finish-install > script now thinks that iSCSI is used in _all_ installations. (It > checks for /etc/iscsi/* [1].) For this reason it regenerates the > initramfs on all installations, which takes a couple of seconds. > > The effect here is totally harmless (it just unnecessarily calls > update-initramfs -k all -u), but it might be annoying. > > KiBi: I suspect you don't want to change this so close to the > release, but in case you do, I'd be happy to upload a targeted fix > for that. I think it would be best to postpone considering such a fix for the first point release, instead of aiming for r0. Let's look at this once r0 is out, so as to avoid generating noise for the release team? I've added an item on my d-i task list so that I don't forget about it. Thanks for your input! KiBi. signature.asc Description: Digital signature
Bug#860304: flash-kernel: Incorrect installation path for dtbs
On 2017-05-26, Cyril Brulebois wrote: > And thanks for being persistent. Indeed, I've been working around this issue locally rather than doing the right things by filing bugs and writing patches... :) > Heinrich Schuchardt (2017-05-25): >> In >> https://patchwork.ozlabs.org/patch/753871/ >> I suggested to change U-Boot environment variable fdtfile to >> meson-gxbb-odroidc2.dtb for the Odroid C2. >> >> Unfortunately this patch was not accepted. >> >> So we will need flash-kernel to accommodate U-Boot having >> a directory path in fdtfile. For the Odroid C2 this is: >> fdtfile=amlogic/meson-gxbb-odroidc2.dtb >> >> Kindly review the patch to flash-kernel I have proposed: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860304#20 >> >> Best regards >> >> Heinrich Schuchardt > > vagrant, any opinion on this topic? Too little flash-kernel knowledge > locally to decide on this. ARM64 boards all appear to have the .dtb in a sub-dir, but the fun part is u-boot may not consistantly include the subdir when setting the fdtfile variable. I think the best thing to do would be to install in both /boot/dtbs/VERSION/FDTFILE and /boot/boot/dtbs/VERSION/SUBDIR/*.dtb, or create symlinks (if supported by the filesystem) if the file is found in a subdir... hopefully that won't require mangling the code too much; I'll take a look at it... or feel free to beat me to it! :) live well, vagrant signature.asc Description: PGP signature
netcfg_1.143_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 May 2017 18:55:29 +0200 Source: netcfg Binary: netcfg netcfg-static Architecture: source Version: 1.143 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Cyril Brulebois Description: netcfg - Configure the network (udeb) netcfg-static - Configure a static network (udeb) Closes: 854801 Changes: netcfg (1.143) unstable; urgency=medium . * Stop queueing rdnssd's installation with IPv6 setups. This component conflicts with network-manager and installing it from the network configuration step might prevents large parts of desktop environments from being installed. This isn't a perfect solution but this should be way better than the current status quo (Closes: #854801). Checksums-Sha1: d4c3b1a0a921b3241732d23804d3fdcdd720274a 1893 netcfg_1.143.dsc 4ed1c0ec0d9bc4999ef9445702a01bc65f2ef64e 392472 netcfg_1.143.tar.xz Checksums-Sha256: ce9d1d52585e495492f41c607cb9eca4e35cddfcd1ab3487d760e787474e1a08 1893 netcfg_1.143.dsc 126fa48f2ae948c418fc12f83ad30dd03902cf1e4ca80b51bc604ca0079b80d3 392472 netcfg_1.143.tar.xz Files: 372277b0c21d2d44602797c0af924216 1893 debian-installer optional netcfg_1.143.dsc 3b948f66e691b3db78e9d584c2e0a1e5 392472 debian-installer optional netcfg_1.143.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJZKGEkAAoJEP+RSvDCs1UgR20P/1s4Ykge3pEH0ImqMxlfO+Xg xUI9Agj69hFeXerOE/kmw/pW7/j9lLpZY8k4xi3mJkI0GjBZ8fOnwXF6cq4h6KlW CgYN60j6B8yKLTaRqvqJdoNh8QZjzeapyQm2G51Aq5xianu2GOF+RWZGAavfFk9M oEQwLKOIoyAmHkuPzsOiFihZ40fuX8Mezu9CLWmYexkSb9VhlXAqahSO584JhZ29 3hWCUUu2r8a57hyNZVegveyqRtV26JucMnoLVfGMNITPmcxlfTjNSWwPxdsvfkzl M9rAvq8B+s1lKikCo9up4QvaTmWel/OE4LFNqSwvKiL9OTK0U/Tf4/0RxEFkmyTO hl88Lnzo9cemYys+F8SsWrxtnRaY+shWmzZFf+69EVQ28p3GdIe1N20XiAbvVlZn 401Kze2/6UnAg6j8MCEFn5hInWxEuwKHJt89GHTtXAR+8nMOTKVycoJQEoq11gR3 Zo/8UbWA00XxEsgLoYwiGMngft9SxHyiI5N4BPqdSmzJM4oxKsBUcEtesTbFiS4l tcVBZMDgWEEGHY44fi48ry2bsUiBXR/mbs1KYFIcXAhXMTyXeA92SGBZgZionqPW WdGREF8LTUzsPtGvQ+xi3jv7ejRTTCc7mbttF231c2zKUrb/wLR3Dv+ehHE5UrIB suMTNgcblJLAusLt8RAA =OlmB -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of netcfg_1.143_source.changes
netcfg_1.143_source.changes uploaded successfully to localhost along with the files: netcfg_1.143.dsc netcfg_1.143.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#854801: marked as done (No network after netinst Stretch RC2)
Your message dated Fri, 26 May 2017 17:21:09 + with message-id and subject line Bug#854801: fixed in netcfg 1.143 has caused the Debian Bug report #854801, regarding No network after netinst Stretch RC2 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.) -- 854801: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Boot method: CD Image version: https://cdimage.debian.org/cdimage/stretch_di_rc2/amd64/iso-cd/debian-stretch-DI-rc2-amd64-netinst.iso Date: 2017-02-09 07:30 UTC Machine: Acer Aspire E5-571-32NU Processor: Intel Core i3-4005U Memory: 4 GB Partitions: DateisystemTyp 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf udev devtmpfs 1974400 0 19744000% /dev tmpfs tmpfs 397148 112883858603% /run /dev/sda4 ext4 131586052 3461216 1213976203% / tmpfs tmpfs 1985732 0 19857320% /dev/shm tmpfs tmpfs 5120 4 51161% /run/lock tmpfs tmpfs 1985732 0 19857320% /sys/fs/cgroup /dev/sda2 ext4 131976676 4847212 1204021964% /mnt/deb08 /dev/sda1 vfat523244 1325231121% /boot/efi tmpfs tmpfs 397144 123971321% /run/user/1000 Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 0b) Subsystem: Acer Incorporated [ALI] Haswell-ULT DRAM Controller [1025:0866] Kernel driver in use: hsw_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) Subsystem: Acer Incorporated [ALI] Haswell-ULT Integrated Graphics Controller [1025:0866] Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 0b) Subsystem: Acer Incorporated [ALI] Haswell-ULT HD Audio Controller [1025:0866] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) Subsystem: Acer Incorporated [ALI] 8 Series USB xHCI HC [1025:0866] Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 [8086:9c3a] (rev 04) Subsystem: Acer Incorporated [ALI] 8 Series HECI [1025:0866] Kernel driver in use: mei_me Kernel modules: mei_me 00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller [8086:9c20] (rev 04) Subsystem: Acer Incorporated [ALI] 8 Series HD Audio Controller [1025:0866] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 [8086:9c14] (rev e4) Kernel driver in use: pcieport Kernel modules: shpchp 00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 4 [8086:9c16] (rev e4) Kernel driver in use: pcieport Kernel modules: shpchp 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series USB EHCI #1 [8086:9c26] (rev 04) Subsystem: Acer Incorporated [ALI] 8 Series USB EHCI [1025:0866] Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller [8086:9c45] (rev 04) Subsystem: Acer Incorporated [ALI] 8 Series LPC Controller [1025:0866] Kernel driver in use: lpc_ich Kernel modules: lpc_ich 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] [8086:9c03] (rev 04) Subsystem: Acer Incorporated [ALI] 8 Series SATA Controller 1 [AHCI mode] [1025:0866] Kernel driver in use: ahci Kernel modules: ahci 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] (rev 04) Subsystem: Acer Incorporated [ALI] 8 Series SMBus Controller [1025:0866] Kernel driver in use: i801_smbus Kernel modules: i2c_i801 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader [10ec:5287] (rev 01) Subsystem: Acer Incorporated [ALI] RTL8411B PCI Express Card Reader [1025:0866] Kernel driver in use: rtsx_pci Kernel modules: rtsx_pci 01:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Ex
Bug#862416: marked as done (installation-reports: stretch standard installation does not install a network manager)
Your message dated Fri, 26 May 2017 17:21:09 + with message-id and subject line Bug#854801: fixed in netcfg 1.143 has caused the Debian Bug report #854801, regarding installation-reports: stretch standard installation does not install a network manager 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.) -- 854801: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Severity: normal Tags: d-i Dear Maintainer, after a standard install from the debian-stretch-DI-rc3-amd64-DVD-1.iso, (with xfce or mate chosen as desktop environment) no network manager is installed. network-manager is in conflict with the preinstalled package rdnssd. Expected behavior: Basic Installation should provide a network manager. Best wishes, Daniel Auth -- Package-specific info: Boot method: DVD hybrid Image on USB flashdrive Image version: debian-stretch-DI-rc3-amd64-DVD-1.iso Date: Machine: Desktop PC Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o] Detect network card:[o] Configure network: [o] Detect CD: [ ] Load installer modules: [o] Clock/timezone setup: [o] User/password setup:[o] Detect hard drives: [o] Partition hard drives: [o] Install base system:[o] Install tasks: [o] Install boot loader:[o] Overall install:[e] Comments/Problems: none of any network manager installed -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="9 (stretch) - installer build 20170407" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian-p4 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 01) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 01) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 2 [8086:27d2] (rev 01) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 01) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 01) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 01) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 01) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:3010] lspci -knn: Kernel driver in use: ehci-pci lspci -knn:
Last chance for d-i changes in stretch
Hi, You might have noticed final preparations for d-i Stretch RC 4 are underways. A new debian-installer upload (or a binNMU) will need to happen before the first stretch release (aka. r0). If there's anything you want or would like to include in r0, now is the time to mention it. Right now, the last upload/binNMU will be needed: - to account for updated keys in debian-archive-keyring; - to include pending netcfg changes (IPv6 vs. rdnssd); - to possibly include a last choose-mirror update; Independently of the debian-installer upload/binNMU, installation-guide can also be uploaded again if there are any new changes. In which case: sooner is better than later. Reminder: It was confirmed in the last release team meeting that we're again going for a full week with absolutely no changes except for critical fixes. installation-guide doesn't qualify; and d-i should get its last update before we enter that no-changes week. Thanks for your attention. KiBi. signature.asc Description: Digital signature
Bug#854801: Network Manager, Stretch and ipv6
+rdisc6 maintainer On 05/26/2017 06:49 PM, Julien Cristau wrote: > On 05/26/2017 06:33 PM, Cyril Brulebois wrote: >> Hi, >> >> Michael Biebl (2017-05-23): >>> Control: severity 854801 serious >>> Control: reassign 854801 netcfg >>> >>> Hi >>> >>> This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801 >>> >>> Since this issue is now cropping up regularly, I'd say it's something >>> which needs to be fixed for stretch, thus marking the bug as RC. >>> >>> Regards, >>> Michael >> >> This issue is indeed (too) well known, but I need to grow a better >> understanding of various IPv6 configurations to get this fixed properly >> in stable suites. (I'm making progress on this front but I have a few >> busy weeks in front of me before getting back to this.) >> >> In any case, this feels like something that might need to wait until >> after r0 (can-defer in release team speak IIRC, cc'd). >> > IMO we should change d-i/netcfg to just never install rdnssd. I guess > that might negatively impact systems on ipv6-only networks that don't > have any other means to pick up name servers, but that seems strictly > better than installing a package which conflicts with NM. > > Cheers, > Julien >
Bug#854801: Network Manager, Stretch and ipv6
Julien Cristau (2017-05-26):
> On 05/26/2017 06:33 PM, Cyril Brulebois wrote:
> > Hi,
> >
> > Michael Biebl (2017-05-23):
> >> Control: severity 854801 serious
> >> Control: reassign 854801 netcfg
> >>
> >> Hi
> >>
> >> This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801
> >>
> >> Since this issue is now cropping up regularly, I'd say it's something
> >> which needs to be fixed for stretch, thus marking the bug as RC.
> >>
> >> Regards,
> >> Michael
> >
> > This issue is indeed (too) well known, but I need to grow a better
> > understanding of various IPv6 configurations to get this fixed properly
> > in stable suites. (I'm making progress on this front but I have a few
> > busy weeks in front of me before getting back to this.)
> >
> > In any case, this feels like something that might need to wait until
> > after r0 (can-defer in release team speak IIRC, cc'd).
> >
> IMO we should change d-i/netcfg to just never install rdnssd. I guess
> that might negatively impact systems on ipv6-only networks that don't
> have any other means to pick up name servers, but that seems strictly
> better than installing a package which conflicts with NM.
Based on Julien's feedback (which matches my initial impressions from
last time I looked into this), I've moved to preparing a new netcfg
upload with the attached change. Leaving a debug message behind will
make it possible to figure out what happens when users complain about
the lack of this rdnssd package, so that we might adjust if needed.
IIRC this issue is also affecting jessie so I'll make a note for
possibly pushing this for a later point release.
KiBi.
From ee0a5467181ff2f3a816ecc1230ba5e60bb5926b Mon Sep 17 00:00:00 2001
From: Cyril Brulebois
Date: Fri, 26 May 2017 18:52:26 +0200
Subject: [PATCH] Stop queueing rdnssd's installation with IPv6 setups (Closes:
#854801).
This component conflicts with network-manager and installing it from the
network configuration step might prevents large parts of desktop
environments from being installed. This isn't a perfect solution but
this should be way better than the current status quo.
---
autoconfig.c | 2 +-
debian/changelog | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/autoconfig.c b/autoconfig.c
index a603f62..f254cf3 100644
--- a/autoconfig.c
+++ b/autoconfig.c
@@ -470,7 +470,7 @@ int netcfg_autoconfig(struct debconfclient *client, struct netcfg_interface *int
if (ipv6) {
read_rdnssd_nameservers(interface);
if (nameserver_count(interface) > 0) {
- di_exec_shell_log("apt-install rdnssd");
+ di_debug("Not queueing rdnssd installation to make sure not to interfere with network-manager");
}
}
diff --git a/debian/changelog b/debian/changelog
index 9132b33..6aa71b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+netcfg (1.143) UNRELEASED; urgency=medium
+
+ * Stop queueing rdnssd's installation with IPv6 setups. This component
+conflicts with network-manager and installing it from the network
+configuration step might prevents large parts of desktop environments
+from being installed. This isn't a perfect solution but this should be
+way better than the current status quo (Closes: #854801).
+
+ -- Cyril Brulebois Fri, 26 May 2017 18:45:55 +0200
+
netcfg (1.142) unstable; urgency=medium
* IPv6 autoconfiguration: fix NTP server name handling, which would be
--
2.1.4
signature.asc
Description: Digital signature
Bug#854801: Network Manager, Stretch and ipv6
On 05/26/2017 06:33 PM, Cyril Brulebois wrote: > Hi, > > Michael Biebl (2017-05-23): >> Control: severity 854801 serious >> Control: reassign 854801 netcfg >> >> Hi >> >> This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801 >> >> Since this issue is now cropping up regularly, I'd say it's something >> which needs to be fixed for stretch, thus marking the bug as RC. >> >> Regards, >> Michael > > This issue is indeed (too) well known, but I need to grow a better > understanding of various IPv6 configurations to get this fixed properly > in stable suites. (I'm making progress on this front but I have a few > busy weeks in front of me before getting back to this.) > > In any case, this feels like something that might need to wait until > after r0 (can-defer in release team speak IIRC, cc'd). > IMO we should change d-i/netcfg to just never install rdnssd. I guess that might negatively impact systems on ipv6-only networks that don't have any other means to pick up name servers, but that seems strictly better than installing a package which conflicts with NM. Cheers, Julien
Re: Bug#862992: systemd: avoid attempt to re-create /etc/mtab by systemd-tmpfiles-setup.service
Hi,
Michael Biebl (2017-05-19):
> In jessie we handled this slightly differently [1]. We had a dedicated
> service unit which checked if /etc/mtab was a symlink. So we didn't run
> into the issue there, that the symlink can be absolute or relative and
> point to either /proc/mounts or /proc/self/mounts.
>
> We chose ../proc/self/mounts in debian.conf since that's also what's
> used by systemd upstream [2], i.e. we are consistent with other distros
> in that aspect.
>
> Maybe we can change debootstrap to use ../proc/self/mounts or is there a
> good reason why it should point to ../proc/mounts?
>
> CCed the debootstrap maintainers for their input.
I'm not exactly sure about the situation you describe, d-i does this
through a finish-install script (finish-install.d/70mtab):
| #! /bin/sh
|
| # some things inside d-i will make an /etc/mtab file, but it shouldn't
| # be there in the installed system. Systemd will be desperately unhappy.
| if [ -f /target/etc/mtab ]; then
| ln -sf /proc/self/mounts /target/etc/mtab
| fi
debootstrap itself does this:
| clear_mtab () {
| if [ -f "$TARGET/etc/mtab" ] && [ ! -h "$TARGET/etc/mtab" ]; then
| rm -f "$TARGET/etc/mtab"
| fi
| }
[ which matches its changelog entry → “On Linux, clear out /etc/mtab on
exit if it's not a symlink.” ]
and there's no /proc/*mounts in debootstrap's code.
Back to the original bug report:
Just performed a stretch debootststrap from a jessie system (with 1.0.67
version), no /etc/mtab afterwards. Did the same with debootstrap upgraded
to 1.0.90, same story.
Both times, with this command:
sudo debootstrap stretch /scratch/stretch http://localhost/debian
with /scratch being a tmpfs and localhost being my local, partial mirror.
Maximilian: If you're seeing a /etc/mtab inside a debootstrap'd
environment, you'll have to be more specific about the way you're
generating it.
KiBi.
signature.asc
Description: Digital signature
Bug#860304: flash-kernel: Incorrect installation path for dtbs
Hi, And thanks for being persistent. Heinrich Schuchardt (2017-05-25): > In > https://patchwork.ozlabs.org/patch/753871/ > I suggested to change U-Boot environment variable fdtfile to > meson-gxbb-odroidc2.dtb for the Odroid C2. > > Unfortunately this patch was not accepted. > > So we will need flash-kernel to accommodate U-Boot having > a directory path in fdtfile. For the Odroid C2 this is: > fdtfile=amlogic/meson-gxbb-odroidc2.dtb > > Kindly review the patch to flash-kernel I have proposed: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860304#20 > > Best regards > > Heinrich Schuchardt vagrant, any opinion on this topic? Too little flash-kernel knowledge locally to decide on this. KiBi. signature.asc Description: Digital signature
Bug#854801: Network Manager, Stretch and ipv6
Hi, Michael Biebl (2017-05-23): > Control: severity 854801 serious > Control: reassign 854801 netcfg > > Hi > > This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801 > > Since this issue is now cropping up regularly, I'd say it's something > which needs to be fixed for stretch, thus marking the bug as RC. > > Regards, > Michael This issue is indeed (too) well known, but I need to grow a better understanding of various IPv6 configurations to get this fixed properly in stable suites. (I'm making progress on this front but I have a few busy weeks in front of me before getting back to this.) In any case, this feels like something that might need to wait until after r0 (can-defer in release team speak IIRC, cc'd). KiBi. signature.asc Description: Digital signature
Re: Preparation for d-i RC4?
Niels Thykier (2017-05-25): > Samuel Thibault: > > Could we have an unblock for installation-guide=20170525 to be in > > d-i RC4, to be uploaded soon? > > Done. Thanks for the swift turnaround from both of you. KiBi. signature.asc Description: Digital signature
Re: Please get ready for copy-installer 20170525
Ansgar Burchardt (2017-05-25): > Cyril Brulebois writes: > > FTPmasters, I've just uploaded d-i 20170525 to the archive, and need to > > leave for the day, so it would be nice if you could please sync the > > installer from sid to testing when all builds are ready: > > > > dak copy-installer 20170525 > > Done. I was worried about pettersson's status when I got home and forgot to: thank you! cdimage builds are running right now. KiBi. signature.asc Description: Digital signature
