Bug#973369: linux-image-5.9.0: No network at Banana Pi M3
Hello Vagrant Regarding correction: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts?h=next-20201029&id=57dbe558457bf4042169bc1f334e3b53a8480a1c Currently, i had a look at kernel.org: In kernel 5.9.6, the necessary correction is not included. Also in kernel 5.10-RC3, this correction is not included. Without this correction, the on-board-ethernet of my Banana Pi M3 is not working. An external attached USB-->LAN interface works. Do you think, there is a chance to add the very small correction to the Debian kernel? Best regards and thank you for your great support. Bernhard signature.asc Description: This is a digitally signed message part
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Sun, Nov 08, 2020 at 12:36:50PM +0200, Adrian Bunk wrote:
> On Fri, Jul 10, 2020 at 06:13:58PM +0100, Ben Hutchings wrote:
> > I don't know if this should be a blocker, but the MIPS builders are
> > still extremely slow for kernel builds. In the worst case (mipsel:
> > mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
> > than the next slowest group of builders (armhf: hasse, henze, holby).
> > This can be a problem for getting security updates out promptly.
>
> 12:32 < aurel32> starting now, eberlin, mipsel-aql-01 and mipsel-aql-02
> do not build security anymore
>
> (The 7 faster buildds continue to build security.)
Thanks Aurelien, this is really nice and will be quite helpful for big packages.
Cheers,
Moritz
Bug#974106: initramfs-tools: No hostname for nfs root
Package: initramfs-tools Version: 0.133+deb10u1 Severity: normal X-Debbugs-CC: rossboy...@stanfordalumni.org Dear Maintainer, * What led up to the situation? PXE booting a system with NFS root using isc-dhcp-server and tftpd-hpa, the initrd environment does not know the hostname and does not communicate it to the dhcp server. * What exactly did you do (or not do) that was effective (or ineffective)? Traced through the init scripts and recorded network traffic to better understand the problem. Results reported in "Analysis:" below. Work-around: hard code ddns-hostname in server's dhcpd.conf, ensuring that it matches /etc/hostname in the final system the initrd pivots to. See below for other strategies. * What was the outcome of this action? The work around worked, as long as I don't boot alternate systems. Without the work-around, dhcpd triggered no DNS update, and so the netbooted system was unknown to DNS (bind). A work-around for that problem was to hard code an entry into the bind configuration. * What outcome did you expect instead? I expected that as the system came up it would communicate its hostname to the dhcp server, which could then use that information to update DNS. Analysis: when PXE booting the DHCP server is called twice, first from the system or network card firmware (I assume) to get the initial PXE image pxelinux.0, and second from within the initrd environment. The first problem is that there is no /etc/hostname in that environment. The second is that the scripts invoked klibc's ipconfig. ipconfig, though limited, does allow the specification of a client hostname, but that option is not used. There is no 3rd time the DHCP server is contacted from the "real" OS, in which the hostname is known. It looked as if it might be possible to use the IP= option on the kernel command line to pass the host name in and have the scripts use it, but I've been unable to get that to work (that is, I can't even boot when I do that). _handle_device_vs_ip, called from configure_networking, works with the IP argument. All the work-arounds are ugly, because they all require that the hostnames assigned in several different places (dhcpd or bind configuration file, kernel command line from pxelinux.cfg) match, which they may not. Given that I can select from among different systems at the time I PXE boot, the name of the system may not be known until after that selection, and may not be unique for a given IP. I prepared this bug report inside a chroot for the system that I netboot. So this should be the environment in which new initrd's are generated. I copy them manually so they are available during the PXE boot. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 36M Sep 27 13:54 /boot/initrd.img-4.19.0-11-amd64 -rw-r--r-- 1 root root 36M Oct 19 13:46 /boot/initrd.img-4.19.0-12-amd64 -- /proc/cmdline -- /proc/filesystems -- lsmod -- /etc/initramfs-tools/modules -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=auto KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto RUNSIZE=10% -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: btrfs dmsetup fsck fuse keymap klibc-utils kmod mdadm ntfs_3g plymouth resume thermal udev zz-busybox -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.133+deb10u1 ii linux-base4.6 initramfs-tools recommends no packages. Versions of packages initramfs-tools suggests: pn bash-completion -- no debconf information
Bug#974109: initramfs-tools: dhcp integration for nfs root
Package: initramfs-tools Version: 0.133+deb10u1 Severity: normal X-Debbugs-CC: rossboy...@stanfordalumni.org Dear Maintainer, * What led up to the situation? PXE booting a system with NFS root using isc-dhcp-server and tftpd-hpa, most of the options passed by the dhcp server to the client do not take effect. In particular the domain name and ntp-server arguments do not affect the final system. * What exactly did you do (or not do) that was effective (or ineffective)? Traced through the init scripts and recorded network traffic to better understand the problem. This didn't suggest any ready cures. Manually created /etc/resolv.conf with some of the values dhcp was trying to set. However, hostname --fqdn produces only the unqualified hostname. * What outcome did you expect instead? I expected that the system that finally came up would reflect the options dhcp communicated to it. Analysis: when PXE booting the DHCP server is called twice, first from the system or network card firmware (I assume) to get the initial PXE image pxelinux.0, and second from within the initrd environment. The second invocation is from klibc's ipconfig. 1) It is unclear to me if ipconfig understands the full range of possible dhcp options. Only a few are mentioned as possibilities on the command line in the long form of the interface option as addr:server:gateway:netmask:interface:proto, and only a few are written to the file mentioned next. 2) The initrd process does result in some info from dhcp being written to /run/net-.conf, which is accessible from the final client system (i.e., after the pivot). That does include the domain name (DNSDOMAIN) and search list (DNSSEARCH), but nothing about ntp servers (which are specified in dhcpd.conf in my setup). As far as I can tell, the domain and search list are not actually used in the final client system. It may be that processing the information correctly from /run/net-.conf requires changes in the basic system initialization scripts, rather than, or as well as, changes to this package. Apparently, the final client system does not start dhclient or call dhcp. I think this means that if the client is given a temporary lease it will not defend it. I have avoided that issue by using a permanent fixed IP. I do not know if an nfs root system could survive a change in its own IP address. So there may be good reasons not to have the final system start a dhcp client (aside from the obvious point that it already has an interface up with an IP assigned), but this means that using such a client to get parameters that have been missed in the initrd is not an option. I prepared this bug report inside a chroot for the system that I netboot. So this should be the environment in which new initrd's are generated. I copy those initrds manually so they are available during the PXE boot. I reviewed the changelog for the current sid version, 0.139, and did not see any changes that bore on this behavior. Stepping back, there is a basic tension between the usual way the network comes up and the way it does with an nfs root system. Usually, the final system is already active when the network interfaces come up, and lots of the startup logic can be hung off the event of the interface coming up. With nfs root, the network comes up in the initrd. This is a problem because that limited environment does not have access to the regular tools like dhcp clients and the whole systemd startup machinery. And it is a problem because, since the full system doesn't bring the interface up, all the hooks that are tied to the interface coming up never fire. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 36M Sep 27 13:54 /boot/initrd.img-4.19.0-11-amd64 -rw-r--r-- 1 root root 36M Oct 19 13:46 /boot/initrd.img-4.19.0-12-amd64 -- /proc/cmdline -- /proc/filesystems -- lsmod -- /etc/initramfs-tools/modules -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=auto KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto RUNSIZE=10% -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: btrfs dmsetup fsck fuse keymap klibc-utils kmod mdadm ntfs_3g plymouth resume thermal udev zz-busybox -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.133+deb10u1 ii linux-base4.6 initramfs-tools recommends no packages. Versions of packages initramfs-tools suggests: pn bash-completion -- no debconf information
