Re: Bug#870430: linux-image-4.9.0-3-marvell: Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or /etc/flash-kernel/dtbs
Control: reassign -1 src:flash-kernel 3.79
On Tue, 2017-08-01 at 23:39 +0200, noone never wrote:
> Package: src:linux
> Version: 4.9.30-2+deb9u2
> Severity: important
> Dear Maintainer,
>
> When I dist-upgrade my Sheevaplug from jessie to stretch, I get this error:
> Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or
> /etc/flash-kernel/dtbs
> The file /usr/lib/linux-image-4.9.0-3-marvell does exist in the filesystem.
> [...]
> /usr/share/flash-kernel/functions: line 155: warning: command substitution:
> ignored null byte in input
> I: The initramfs will attempt to resume from /dev/sda3
> I: (UUID=6fcd0aea-6301-4c47-a3fd-9f5eb2c1f8b5)
> I: Set the RESUME variable to override this.
> W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
> /usr/share/flash-kernel/functions: line 155: warning: command substitution:
> ignored null byte in input
> Using DTB: kirkwood-sheevaplug.dtb
> Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or
> /etc/flash-kernel/dtbs
These errors are from the flash-kernel hook rather than the kernel
package. You seem to be running stable so I have tagged it as being in
the stable version (3.79) and reassigned. Please let me know if this is
an incorrect assumption.
It says it is looking for "kirkwood-sheevaplug.dtb" and from [0] the
file /usr/lib/linux-image-4.9.0-3-marvell/kirkwood-sheevaplug.dtb is
present in the package -- I suppose it is also present on your
filesystem?
The message:
Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or
/etc/flash-kernel/dtbs
is interesting since the double space in "DTB in" is supposed to
contain $dtb_name, i.e. the path to look for, but it doesn't not.
Please could you attach the full output of running `sh -x
/usr/sbin/flash-kernel`, maybe that will include a clue as to where
things have gone astray.
There is also the warning from line 155 of `functions` is
`machine="$(get_dt_model)"` where:
PROC_DTMODEL="${FK_PROC_DRMODEL:-/proc/device-tree/model}"
[...]
get_dt_model() {
cat "$PROC_DTMODEL"
}
Assuming you haven't had cause to override FK_PROC_DRMODEL (note typo
in there), does /proc/device-tree/model exist on your system, and if so
what does it contain? The output of `cat -vet /proc/device-tree/model`
might be informative since it will escape any special characters and
make them visible. I suspect this is a harmless trailing nul and it
seems like it is correctly deciding to use kirkwood-sheevaplug.dtb so
this "ignored null byte" message may just be a benign warning.
Ian.
[0]
https://packages.debian.org/stretch/armel/linux-image-4.9.0-3-marvell/filelist
Processed: Re: Bug#870430: linux-image-4.9.0-3-marvell: Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or /etc/flash-kernel/dtbs
Processing control commands: > reassign -1 src:flash-kernel 3.79 Bug #870430 [src:linux] linux-image-4.9.0-3-marvell: Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or /etc/flash-kernel/dtbs Bug reassigned from package 'src:linux' to 'src:flash-kernel'. No longer marked as found in versions linux/4.9.30-2+deb9u2. Ignoring request to alter fixed versions of bug #870430 to the same values previously set Bug #870430 [src:flash-kernel] linux-image-4.9.0-3-marvell: Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or /etc/flash-kernel/dtbs Marked as found in versions flash-kernel/3.79. -- 870430: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870430 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Debian9
Hi, i'm a few days trying to download burn debian 9.1 i did as it was written on the site how to burn debian the problem that version 8 have been able to install 9.1.0 i still can not burn it what i have to do
Bug#867898: debian-installer-netboot-images: debian-installer-9-netboot-amd64 scsi modules missing. Netboot image unusable
Hello all, Steve, what is the suggested resolution then? For testing, I booted the initrd's and kernels extracted from standard DVD and netboot iso's via PXE. While they cannot progress further for obvious reasons, by switching to tty2, /dev/sda does appear in the listing. Those do ship with the correct modules. 1/ What would be the negative aspect of removing the scsi modules from the exclude-udeb-* lists, following the package mergers mentioned before? 2/ Also, I'm not too familiar with how the netboot is constructed, is there another way to have these drivers bundled in the netboot tar.gz (CONF.sh?)? Best regards, Marc
Bug#867898: AW: Bug#867898: debian-installer-netboot-images: debian-installer-9-netboot-amd64 scsi modules missing. Netboot image unusable
Hi Marc, which driver module has been used within your tests? In my version of netboot.tar.gz (initrd), the modules for LSI controllers (mptspi) were missing. So even on a simple VMware VM, no disks have been detected. Regards, Robert -Ursprüngliche Nachricht- Von: Marc N [mailto:de...@rasqual.e4ward.com] Gesendet: Mittwoch, 2. August 2017 13:38 An: Steve McIntyre ; Cyril Brulebois ; 867...@bugs.debian.org Cc: Paschedag, Robert ; debian-ker...@lists.debian.org; debian...@lists.debian.org Betreff: Re: Bug#867898: debian-installer-netboot-images: debian-installer-9-netboot-amd64 scsi modules missing. Netboot image unusable Hello all, Steve, what is the suggested resolution then? For testing, I booted the initrd's and kernels extracted from standard DVD and netboot iso's via PXE. While they cannot progress further for obvious reasons, by switching to tty2, /dev/sda does appear in the listing. Those do ship with the correct modules. 1/ What would be the negative aspect of removing the scsi modules from the exclude-udeb-* lists, following the package mergers mentioned before? 2/ Also, I'm not too familiar with how the netboot is constructed, is there another way to have these drivers bundled in the netboot tar.gz (CONF.sh?)? Best regards, Marc
Bug#867898: debian-installer-netboot-images: debian-installer-9-netboot-amd64 scsi modules missing. Netboot image unusable
Hi Robert, After digging a bit, I think my issue lies with the APT source I used. At work (ESXi host), netboot works because it points to a proper apt- mirror. On the other hand, at home I frankenbuilt mine using the DVD iso and specifying debian-installer/allow_unauthenticated=true. I retried after pointing the APT mirror to, say, deb.debian.org, and everything went back to normal. So my advice is, can you check if your source http://spacewalk- test.swr.ard/ks/dist/org/1/Debian_Stretch/ was done properly? For reference, here were results for booting from borrowed initrd from DVD. In those tests, /dev/sda is successfully listed. in dmesg, after bsg has loaded: - lsilogic: Fusion MPT base driver 3.04.20 Fusion MPT SPI Host driver 3.04.20 - lsisas1068: Fusion MPT base driver 3.04.20 Fusion MPT SAS Host driver 3.04.20 - pvscsi: VMware PVSCSI driver - version 1.0.7.0-k /proc/modules yields a few ata modules, and depending on scsi controller in vmx: - lsilogic: mptspi, scsi_transport_spi, mptscsih, mptbase, scsi_mod - lsisas1068: mptsas, scsi_transport_sas, mptscsih, mptbase, scsi_mod - pvscsi: vmw_pcscsi, scsi_mod - ide0 vmdk attachment (removed SCSI controller): scsi_mod Mit freundlichen gruessen, Marc On Wed, Aug 2, 2017 at 1:42 PM, Paschedag, Robert wrote: > Hi Marc, > > which driver module has been used within your tests? In my version of netboot.tar.gz (initrd), the modules for LSI controllers (mptspi) were missing. > > So even on a simple VMware VM, no disks have been detected. > > Regards, > Robert > > -Ursprüngliche Nachricht- > Von: Marc N [mailto:de...@rasqual.e4ward.com] > Gesendet: Mittwoch, 2. August 2017 13:38 > An: Steve McIntyre ; Cyril Brulebois ; 867...@bugs.debian.org > Cc: Paschedag, Robert ; debian- ker...@lists.debian.org; debian...@lists.debian.org > Betreff: Re: Bug#867898: debian-installer-netboot-images: debian- installer-9-netboot-amd64 scsi modules missing. Netboot image unusable > > Hello all, > > Steve, what is the suggested resolution then? > For testing, I booted the initrd's and kernels extracted from standard DVD and netboot iso's via PXE. While they cannot progress further for obvious reasons, by switching to tty2, /dev/sda does appear in the listing. Those do ship with the correct modules. > > 1/ What would be the negative aspect of removing the scsi modules from the > exclude-udeb-* lists, following the package mergers mentioned before? > > 2/ Also, I'm not too familiar with how the netboot is constructed, is there another way to have these drivers bundled in the netboot tar.gz (CONF.sh?)? > > Best regards, > Marc >
Bug#870448: hw-detect - stop using modprobe -l
On Wed, 2017-08-02 at 12:26 +1000, Vincent McIntyre wrote:
> Package: hw-detect
> Version: 1.124
> Severity: normal
> Tags: patch
>
> I keep seeing this in installer logs, back to jessie.
>
> Aug 2 01:52:11 main-menu[193]: (process:224): modprobe: invalid option -- 'l'
>
>
> I rated this normal rather than minor because the way it is working
> now the is_available() function always returns 1 (failure)
>
> My suggestion is to use modinfo instead.
> This will return multiline output inside the quotes but
> a couple of tests suggests that is ok.
> It does fail with some modules (nvidia), not sure if we care.
>
> diff --git a/hw-detect.sh b/hw-detect.sh
> index 7977814..d8196c1 100755
> --- a/hw-detect.sh
> +++ b/hw-detect.sh
> @@ -43,7 +43,7 @@ is_not_loaded() {
> }
>
> is_available () {
> - [ "$(modprobe -l $1)" ] || return 1
> + [ "$(modinfo $1)" ] || return 1
> }
But this still prints error messages for missing modules. I think the
function should be implemented as:
is_available () {
modprobe -qn "$1"
}
Ben.
> # Module as first parameter, description of device the second.
>
> Kind regards
> Vince
>
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
signature.asc
Description: This is a digitally signed message part
Bug#870448: hw-detect - stop using modprobe -l
On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
>
> But this still prints error messages for missing modules. I think the
> function should be implemented as:
>
> is_available () {
> modprobe -qn "$1"
> }
>
I agreee, much better!
Bug#870574: lowmem: naming of main-menu.d item
Package: lowmem Version: 1.45 Severity: normal Poking around an install environment I looked in /lib/main-menu.d and found these files: 10rescue 5lowmem Then I found the original commit message: commit b9741a97a349f9ed4364b3411c3ab8afc590e385 Author: Joey Hess Date: Fri May 6 01:30:00 2005 - Set a "low memory mode" info message (rescue mode comes after and beats this message). Requires cdebconf-udeb 0.75 and main-menu 1.03. So the file lowmem/main-menu.d/5lowmem should be lowmem/main-menu.d/05lowmem should it not? Vince
