Bug#864536: missing kernel modules in D-I sd-card images
Package: debian-installer Version: 20170525 SD-card image from https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/, doesn't have a kernel module, so mmc and network does'nt work. There was also a thread in debian-arm mailing list about this issue: https://lists.debian.org/debian-arm/2017/01/msg0.html The missing module is i2c_rk3x. Could you add to the image? Thanks in advance. -- Diego Roversi
Bug#864525: flash-kernel: fails on fat32
On Sat, 2017-06-10 at 02:41 +0200, Heinrich Schuchardt wrote: > On 06/10/2017 02:11 AM, Ben Hutchings wrote: > > On Sat, 2017-06-10 at 00:59 +0200, Heinrich Schuchardt wrote: > >> On 06/10/2017 12:31 AM, Martin Michlmayr wrote: > > * Heinrich Schuchardt [2017-06-09 23:18]: > flash-kernel currently fails if the boot partition is FAT32. > > On FAT32 symbolic links cannot be created. > >>> > >>> Unless something has changed, FAT for /boot isn't supported > anyway. > >>> > >>> See https://lists.debian.org/debian-boot/2014/01/msg00188.html > >>> > >> > >> That information seems to be outdated. > > [...] > > > > I think you didn't follow the thread far enough: > > https://lists.debian.org/debian-boot/2014/01/msg00195.html > > > > Ben. > > > > So this further complication stems from function tarobject() in > package > dpgk? FAT* are simply not POSIX compatible filesystems and as such are not supported as /boot (or /, /var, or /usr etc for that matter), irrespective of how it might appear to you to be working under some circumstances. If your device's firmware requires a FAT partition to boot from then you should configure flash-kernel in the mode where it mounts that partition temporarily to copy the boot files to it while /boot remains a POSIX filesystem (ext4 etc). Ian.
Bug#864457: [d-i daily hd-media 20170608] kernel doesn't initialize USB ports inside d-i on a sunxi-based system
On Thu, Jun 08, 2017 at 10:50:57PM +0200, Karsten Merker wrote: > Package: installation-reports > > Boot method: hd-media tarball from USB stick > Image version: > https://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz > Date: 2017-06-08 > > Machine: LeMaker Banana Pi > Processor: Allwinner A20 (2x Cortex A7) > Memory: 1GB [...] > Comments/Problems: > Installation method is a d-i hd-media tarball and a Debian CD/DVD > ISO image on a USB stick. Booting d-i from the stick works fine, > but inside the installer the USB ports are dead and no USB > devices get recognized by the kernel. > > In an installed system on the same hardware (installed with the > netboot image), the USB ports work normally. In the d-i > environment, the ehci platform driver gets loaded, but for some > reason doesn't initialize the actual host controller. All > relevant USB host driver modules appear to be there: > > Module Size Used by > usb_storage45835 0 > phy_generic 4686 1 sunxi > musb_hdrc 113325 1 sunxi > udc_core 26444 1 musb_hdrc > ohci_platform 4786 0 > ohci_hcd 37898 1 ohci_platform > ehci_platform 5462 0 > ehci_hcd 64996 1 ehci_platform > phy_sun4i_usb 8637 1 sunxi > extcon_core13223 2 sunxi,phy_sun4i_usb > usbcore 196310 6 > usb_storage,ehci_hcd,musb_hdrc,ohci_hcd,ehci_platform,ohci_platform > usb_common 3659 5 udc_core,sunxi,musb_hdrc,phy_sun4i_usb,usbcore > > In the d-i environment: > [2.694030] usbcore: registered new interface driver usbfs > [2.699958] usbcore: registered new interface driver hub > [2.703305] SCSI subsystem initialized > [2.716192] usbcore: registered new device driver usb > [2.724836] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [2.736947] sunxi-mmc 1c0f000.mmc: base:0xf08f4000 irq:28 > [2.750665] ehci-platform: EHCI generic platform driver > [2.751130] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > [2.752551] ohci-platform: OHCI generic platform driver > > While on the installed system: > [2.162185] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [2.168314] ehci-platform: EHCI generic platform driver > [6.187194] ehci-platform 1c14000.usb: EHCI Host Controller > [6.187256] ehci-platform 1c14000.usb: new USB bus registered, assigned > bus number 2 > [6.192414] ehci-platform 1c14000.usb: irq 30, io mem 0x01c14000 > [6.205562] ehci-platform 1c14000.usb: USB 2.0 started, EHCI 1.00 > [6.206170] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 > [6.206184] usb usb2: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [6.206191] usb usb2: Product: EHCI Host Controller > [6.206198] usb usb2: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd > [6.206204] usb usb2: SerialNumber: 1c14000.usb > [6.207443] hub 2-0:1.0: USB hub found > [6.207557] hub 2-0:1.0: 1 port detected > [6.209230] ehci-platform 1c1c000.usb: EHCI Host Controller > [6.209289] ehci-platform 1c1c000.usb: new USB bus registered, assigned > bus number 3 > [6.216403] ehci-platform 1c1c000.usb: irq 34, io mem 0x01c1c000 > [6.230524] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00 > [6.231044] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 > [6.231058] usb usb3: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [6.231066] usb usb3: Product: EHCI Host Controller > [6.231072] usb usb3: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd > [6.231079] usb usb3: SerialNumber: 1c1c000.usb > > We might have a problem with the USB port power supply here. > Comparing the available modules between the installed system and > the d-i environment (full list below) and looking for possibly > related modules shows that the "axp20x_regulator" and > "axp20x_usb_power" modules are available in the installed system, > but not in the d-i environment. I am not sure whether > axp20x_usb_power is really responsible for providing power _to_ > the USB hosts ports, though. It could be that it is responsible > for powering the system _from_ a USB-OTG port, so it might be > unrelated to the problem at hand. "axp20x_regulator" would > possibly be a candidate for a power-supply problem. I have also > tried using a powered USB hub between the USB stick and the host > port, but even then no USB device gets recognized, which kind of > speaks against the theory of only a missing 5V-supply on the USB > port as the sole source of the problem. Possibly the ehci/ohci > platform drivers depend on the axp20x PMIC modules for full > initialization, but that is at the moment only a wild guess. > Perhaps somebody at debian-kernel (CCed) can provide further > insight into this. It looks like neither axp20x_regulator nor axp20x_usb_power is the sole source of the prob
Re: Installation guide is not updated in some languages
Hi, Osamu Aoki (2017-06-10): > Hmmm... I don't have shell access but I can run this command via cron. > But it seems problem is resolved iby now as I see: > https://www.debian.org/releases/testing/amd64/index.html.ja > > This is good work around for now. But this is very high CPU load on > debian-www and not a good idea. That's why it is pushed aside to > lessoften. The inherent problem is debian-www is running stable > distribution while the installation-guide source package is mainly > developed on the testing/unstable tool chain. > > The better way is unpack binary packages to build files. Some file name > changes and URL rewrite is needed but that has been done successfully > for debian-handbook debian-handbook_*.deb in often cron script. This is > very light weight. (This time s/html/html.en/ etc. is needed. sed > script for URL is much lighter CPU load than stabdard build process.) > > Even now fetching of the source and binary packages are done in often > cron script using the ftp protocol. It is still working but I don't > know how long we support the ftp protocol. Our mirror stopped using the > ftp protocol. So maybe soon this access may be killed. > > This is not just a problem for installation-guide but almost all other > debian-doc files. Given we're already building docs to ship in binary packages, it seems reasonable to re-use those build results on www-master indeed. There's maybe some history behind building it there but I'm not aware of it. So working on an update of the “build” process looks good to me. Any takers on the debian-boot side? KiBi. signature.asc Description: Digital signature
Bug#864246: os-probe: Also skip over bcache partitions.
Here is an updated copy of this patch.
From 6439f5a40bd4e610a462292c646098eeb4d5bcb1 Mon Sep 17 00:00:00 2001
From: Michael Mestnik
Date: Mon, 5 Jun 2017 11:52:17 -0500
Subject: [PATCH 1/6] Add in bcache devices
---
linux-boot-probes/common/50mounted-tests | 3 +++
os-prober| 10 ++
os-probes/common/50mounted-tests | 3 +++
3 files changed, 16 insertions(+)
diff --git a/linux-boot-probes/common/50mounted-tests b/linux-boot-probes/common/50mounted-tests
index ad68874..937553a 100755
--- a/linux-boot-probes/common/50mounted-tests
+++ b/linux-boot-probes/common/50mounted-tests
@@ -25,6 +25,9 @@ elif [ "$types" = swap ]; then
elif [ "$types" = crypto_LUKS ]; then
debug "$1 is a LUKS partition; skipping"
exit 0
+elif [ "$types" = bcache ]; then
+ debug "$1 is an bcache partition; skipping"
+ exit 0
elif [ "$types" = ntfs ]; then
if type ntfs-3g >/dev/null 2>&1; then
types='ntfs-3g ntfs'
diff --git a/os-prober b/os-prober
index a48863e..ab2dee1 100755
--- a/os-prober
+++ b/os-prober
@@ -45,6 +45,16 @@ partitions () {
fi
done
+ # bcahce
+ for part in /sys/block/bcache*; do
+ if [ -f "$part/inflight" ]; then
+name="$(echo "${part##*/}" | sed 's,[!.],/,g')"
+if [ -e "/dev/$name" ]; then
+ echo "/dev/$name"
+fi
+ fi
+ done
+
# Add Serial ATA RAID devices
if type dmraid >/dev/null 2>&1 && \
dmraid -s -c >/dev/null 2>&1; then
diff --git a/os-probes/common/50mounted-tests b/os-probes/common/50mounted-tests
index fca15cb..09c88b3 100755
--- a/os-probes/common/50mounted-tests
+++ b/os-probes/common/50mounted-tests
@@ -27,6 +27,9 @@ elif [ "$types" = crypto_LUKS ]; then
elif [ "$types" = LVM2_member ]; then
debug "$1 is an LVM member; skipping"
exit 0
+elif [ "$types" = bcache ]; then
+ debug "$1 is an bcache partition; skipping"
+ exit 0
elif [ "$types" = ntfs ]; then
if type ntfs-3g >/dev/null 2>&1; then
types='ntfs-3g ntfs'
--
2.11.0
Bug#688336: os-probe: subvol: patches to provide bootloaders with all the subvolume info.
These patches can be tested from here: https://launchpad.net/~cheako/+archive/ubuntu/boot-subvol Code from here: https://github.com/cheako/os-prober/tree/aggregate
Bug#688336: os-probe: subvol: patches to provide bootloaders with all the subvolume info.
Here are corrected versions of these patches. Filesystem raid is
almost certainly a separate bug.
From 3d4b580dea4592793af3411fc0543af36de0e958 Mon Sep 17 00:00:00 2001
From: Michael Mestnik
Date: Fri, 9 Jun 2017 13:04:05 -0500
Subject: [PATCH 2/6] Process filesystem raid entries
---
common.sh | 14 --
os-prober | 5 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/common.sh b/common.sh
index e1646d4..d6fee58 100644
--- a/common.sh
+++ b/common.sh
@@ -146,12 +146,22 @@ is_dos_extended_partition() {
return 1
}
+canonical_dev () {
+ local dev="${1#/dev/}"
+ local sys="$(find /sys/fs/btrfs -path \*/devices/"$dev")"
+ if [ -e "$sys" ]; then
+ echo /dev/"$(ls "${sys%/$dev}" | head -n1)"
+ else
+ echo "$1"
+ fi
+}
+
parse_proc_mounts () {
while read -r line; do
set -f
set -- $line
set +f
- printf '%s %s %s\n' "$(mapdevfs "$1")" "$2" "$3"
+ printf '%s %s %s\n' "$(canonical_dev "$(mapdevfs "$1")")" "$2" "$3"
done
}
@@ -245,7 +255,7 @@ linux_mount_boot () {
fi
fi
shift
- set -- "$(mapdevfs "$tmppart")" "$@"
+ set -- "$(canonical_dev "$(mapdevfs "$tmppart")")" "$@"
if grep -q "^$1 " "$OS_PROBER_TMP/mounted-map"; then
bindfrom="$(grep "^$1 " "$OS_PROBER_TMP/mounted-map" | head -n1 | cut -d " " -f 2)"
diff --git a/os-prober b/os-prober
index a48863e..e4439a7 100755
--- a/os-prober
+++ b/os-prober
@@ -137,6 +137,11 @@ for partition in $(partitions); do
continue
fi
+ if ! [ "$mapped" = "$(canonical_dev "$mapped")" ]; then
+ log "Device '$mapped' is part of filesystem raid; skipping"
+ continue
+ fi
+
# Skip partitions used in software RAID arrays
if grep -q "^$mapped" "$OS_PROBER_TMP/raided-map" ; then
debug "$partition: part of software raid array"
--
2.11.0
From bd6d7a78e88eba3a03940e84f6e168ab5c8d Mon Sep 17 00:00:00 2001
From: Michael Mestnik
Date: Mon, 5 Jun 2017 11:08:42 -0500
Subject: [PATCH 5/6] Pass subvol data for /boot to bootloadter(s)
---
common.sh | 36 +
linux-boot-prober | 6 +++--
linux-boot-probes/common/50mounted-tests| 3 ++-
linux-boot-probes/mounted/common/40grub2| 3 ++-
linux-boot-probes/mounted/common/90fallback | 5 ++--
linux-boot-probes/mounted/powerpc/40yaboot | 3 ++-
linux-boot-probes/mounted/sparc/50silo | 3 ++-
linux-boot-probes/mounted/x86/40grub| 3 ++-
linux-boot-probes/mounted/x86/50lilo| 3 ++-
9 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/common.sh b/common.sh
index 1001c74..ff278c3 100644
--- a/common.sh
+++ b/common.sh
@@ -253,6 +253,42 @@ linux_mount_boot () {
shift
set -- "$(mapdevfs "$tmppart")" "$@"
+ if bootsubvolid="$(echo "$4" | grep -o 'subvolid=[0-9][0-9]*')"; then
+bootsubvolid="$(echo "$bootsubvolid" | cut -d= -f2-)"
+if mount -o "subvolid=$bootsubvolid" "$1" "$tmpmnt/boot"; then
+ if [ "$bootsubvolid" = "$(get_default_subvolid "$tmpmnt/boot")" ]; then
+ mountboot="$1 1"
+ return
+ else
+ mountboot="$1 1 $bootsubvolid"
+ return
+ fi
+else
+ debug "failed to subvolid-mount $1 onto $tmpmnt/boot"
+ mountboot="$1 0 $bootsubvolid"
+ return
+fi
+ else
+if bootsubvol="$(echo "$4" | grep -o 'subvol=[^,]*')"; then
+ bootsubvol="$(echo "$bootsubvol" | cut -d= -f2-)"
+ bootsubvol="${bootsubvol#/}"
+ if mount -o "subvol=${bootsubvol:=/}" "$1" "$tmpmnt/boot"; then
+ bootsubvolid="$(grep "^/dev/" /proc/mounts | parse_proc_mounts | grep " $tmpmnt/boot " | cut -d ' ' -f 4)"
+ if [ "$bootsubvolid" = "$(get_default_subvolid "$tmpmnt/boot")" ]; then
+ mountboot="$1 1"
+ return
+ else
+ mountboot="$1 1 ${bootsubvolid:-@$bootsubvol}"
+ return
+ fi
+ else
+ debug "failed to subvol-mount $1 onto $tmpmnt/boot"
+ mountboot="$1 0 @$bootsubvol"
+ return
+ fi
+fi
+ fi
+
if grep -q "^$1 " "$OS_PROBER_TMP/mounted-map"; then
bindfrom="$(grep "^$1 " "$OS_PROBER_TMP/mounted-map" | head -n1 | cut -d " " -f 2)"
bindfrom="$(unescape_mount "$bindfrom")"
diff --git a/linux-boot-prober b/linux-boot-prober
index 4a86119..ae34670 100755
--- a/linux-boot-prober
+++ b/linux-boot-prober
@@ -36,19 +36,21 @@ else
mpoint="$(unescape_mount "$mpoint")"
if [ "$mpoint" != "/target/boot" ] && [ "$mpoint" != "/target" ] && [ "$mpoint" != "/" ]; then
type="$(echo "$mrecord" | head -n1 | cut -d ' ' -f 3)"
- if ! grep -q " $mpoint/boot " "$OS_PROBER_TMP/mounted-map"; then
+ if ! bootrecord="$(grep -q " $mpoint/boot " "$OS_PROBER_TMP/mounted-map")"; then
linux_mount_boot "$partition" "$mpoint" "$subvolid"
set -- $mountboot
bootpart="$1"
bootmounted="$2"
+ bootsubvolid="$3"
else
bootpart="$partition"
bootmounted=0
+ bootsubvolid="$(echo "$bootrecord" | head -n1 | cut -d ' ' -f 4)"
fi
for test in /usr/lib/linux-boot-probes/mounted/*; do
if [ -f $
Bug#864562: Installation on Olimex A20-Olinuxino Micro
Package: debian-installer Hello, I'm the new owner of my second Olimex A20-Olinuxino Micro (Rev J) board. I tested the board with a pre-installed Micro-SD card (A20-OLinuXino-MICRO Debian Jessie with kernel 3.4.103+ release 14) and it runs fine. My challenge is to install Debian on this board and, better if possible, to run it from the attached hard disk (without Micro SD card). I choosed to run the installer from a micro-sd card image, made with zcat (with Jessie and Stretch releases, same result). The installer boots fine even if I saw that it is not as complete as a X86/X64 Debian installer. Not a problem. I use a serial port to manage the installation. As it is a network installation, first I plugged the system on my domestic network then directly on my ISP Box. After investigation with my son (who is also qualified on the subject), I think that the problem is about the network interface of the board. Maybe a faulty initialisation or bad handshake with the network port. both NI led blink and the switch port too. Here are the facts : the installer can neither configure itself from DHCP neither communicate with Internet when the network configuration is manualy entered. I did explore the logs from my DHCP server and I didn't find any log about the DHCP request from the installer (I saw some when testing with the pre-installed card). Did you meet this issue before ? Thank you in advance Best regards Jean-Louis
Bug#864536: missing kernel modules in D-I sd-card images
Hi Diego, (adding kernel maintainers to the loop for the fix, and release team for comments about the extra package I think we would need to fix this.) Diego Roversi (2017-06-10): > Package: debian-installer > Version: 20170525 > > SD-card image from > https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/, > doesn't have a kernel module, so mmc and network does'nt work. > > There was also a thread in debian-arm mailing list about this issue: > > https://lists.debian.org/debian-arm/2017/01/msg0.html > > The missing module is i2c_rk3x. Could you add to the image? Looking at linux.git, it seems this driver is built as a module, but there's no i2c-modules udeb for armhf. I don't think this bug is critical enough to have a linux upload before r0 (unless something is in the works already), but I'm a little concerned that postponing a bug fix for r1 wouldn't be too nice… Adding a new binary package in a point release feels wrong. :( KiBi. signature.asc Description: Digital signature
Bug#864457: [d-i daily hd-media 20170608] kernel doesn't initialize USB ports inside d-i on a sunxi-based system
Hi Karsten, Karsten Merker (2017-06-10): > It looks like neither axp20x_regulator nor axp20x_usb_power is > the sole source of the problem. I have built new kernel udebs > including these modules and have tested d-i with them - adding > them doesn't change anything. They can be modprobed successfully > and show up in lsmod, but nothing new shows up in the kernel log > after loading them. > > While checking the list of modules again, I found that these > modules themselves use the i2c subsystem to communicate with the > powermanagement controller, but we don't seem to have an > appropriate i2c controller driver (i2c_mv64xxx) inside d-i. I'll > try building kernel udebs with i2c_mv64xxx included and see > whether that changes anything. I've just stumbled upon something similar following a bug report by Diego Roversi, see my follow-up in: https://bugs.debian.org/864536#10 KiBi. signature.asc Description: Digital signature
