Re: debian-installer failure with arm64 (was RE: laxton (softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)
Ian Campbell writes ("Re: debian-installer failure with arm64 (was RE: laxton
(softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)"):
> I suppose this (jessie w/ backports kernel) is the mg-debian-installer-
> update stuff to wedge the backports kernel into the stable installer
> initrd in osstest I wrote way back when?
Yes.
> In that scenario the "Continue the install without loading kernel
> modules?" message is expected and (working from memory here) should be
> preseeded to be ignored.
Ah.
In fact, this preseed is controlled in osstest in the wrong way (by a
host flag, rather than by whether we have made our own d-i image with
modules in it). Bodging that so that this preseed is set correctly
fixes the problem. I will fix this properly once I have it sort of
working...
> If you are still getting the disk not found issue with the backports
> kernel then maybe you need to add some more modules (or directories
> full of modules) to the whitelist in mg-debian-installer-update? Might
> be worth experimenting with a hacked version which includes all modules
> to confirm? If that helps then `lsmod` from the d-i shell might give
> you a clue what is missing.
Yes, this was also a problem. `ptp' (at least) needed including.
Thanks for the tips!
Ian.
Softiron (Overdrive-3000) firmware bugs ?
We have a pair of Overdrive 3000 boxes which we are trying to deploy in the Xen Project's automatic test (CI) system. We do most of our testing with Debian as the host operating system. I am currently using a daily snapshot of debian-installer arm64 stretch. With that, I can get d-i to run to completion and it generates a system which boots. However, I see some alarming messages on the serial console. See below. I'm concerned in particular by: * The `WARNING: CPU: 3 PID: 1' which produces a kernel stack trace * `Disabling lock debugging due to kernel taint' * `[Firmware Bug]: IRQ flags corrupted ' Would any of you like to have an opinion ? (Harry: sorry if you're entirely the wrong person at Softiron to ask this question. Please pass on my enquiry.) Thanks, Ian. Jan 4 18:15:08 laxton0 kernel: [0.00] Booting Linux on physical CPU 0x0 Jan 4 18:15:08 laxton0 kernel: [0.00] Linux version 4.8.0-2-arm64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02) Jan 4 18:15:08 laxton0 kernel: [0.00] Boot CPU: AArch64 Processor [411fd072] Jan 4 18:15:08 laxton0 kernel: [0.00] efi: Getting EFI parameters from FDT: Jan 4 18:15:08 laxton0 kernel: [0.00] efi: EFI v2.40 by American Megatrends Jan 4 18:15:08 laxton0 kernel: [0.00] efi: ACPI 2.0=0x83ff1c5000 SMBIOS 3.0=0x83ff347798 Jan 4 18:15:08 laxton0 kernel: [0.00] On node 0 totalpages: 4194304 Jan 4 18:15:08 laxton0 kernel: [0.00] DMA zone: 16384 pages used for memmap Jan 4 18:15:08 laxton0 kernel: [0.00] DMA zone: 0 pages reserved Jan 4 18:15:08 laxton0 kernel: [0.00] DMA zone: 1048576 pages, LIFO batch:31 Jan 4 18:15:08 laxton0 kernel: [0.00] Normal zone: 49152 pages used for memmap Jan 4 18:15:08 laxton0 kernel: [0.00] Normal zone: 3145728 pages, LIFO batch:31 Jan 4 18:15:08 laxton0 kernel: [0.00] psci: probing for conduit method from DT. Jan 4 18:15:08 laxton0 kernel: [0.00] psci: PSCIv0.2 detected in firmware. Jan 4 18:15:08 laxton0 kernel: [0.00] psci: Using standard PSCI v0.2 function IDs Jan 4 18:15:08 laxton0 kernel: [0.00] psci: MIGRATE_INFO_TYPE not supported. Jan 4 18:15:08 laxton0 kernel: [0.00] percpu: Embedded 22 pages/cpu @8003ffefe000 s50072 r8192 d31848 u90112 Jan 4 18:15:08 laxton0 kernel: [0.00] pcpu-alloc: s50072 r8192 d31848 u90112 alloc=22*4096 Jan 4 18:15:08 laxton0 kernel: [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 Jan 4 18:15:08 laxton0 kernel: [0.00] Detected PIPT I-cache on CPU0 Jan 4 18:15:08 laxton0 kernel: [0.00] CPU features: enabling workaround for ARM erratum 832075 Jan 4 18:15:08 laxton0 kernel: [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 4128768 Jan 4 18:15:08 laxton0 kernel: [0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.8.0-2-arm64 root=/dev/mapper/laxton0--vg-root ro Jan 4 18:15:08 laxton0 kernel: [0.00] PID hash table entries: 4096 (order: 3, 32768 bytes) Jan 4 18:15:08 laxton0 kernel: [0.00] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) Jan 4 18:15:08 laxton0 kernel: [0.00] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) Jan 4 18:15:08 laxton0 kernel: [0.00] software IO TLB [mem 0x80fbfff000-0x80f000] (64MB) mapped at [8000fbfff000-8000efff] Jan 4 18:15:08 laxton0 kernel: [0.00] Memory: 16348292K/16777216K available (6524K kernel code, 1056K rwdata, 2060K rodata, 3264K init, 621K bss, 428924K reserved, 0K cma-reserved) Jan 4 18:15:08 laxton0 kernel: [0.00] Virtual kernel memory layout: Jan 4 18:15:08 laxton0 kernel: [0.00] modules : 0x - 0x0800 ( 128 MB) Jan 4 18:15:08 laxton0 kernel: [0.00] vmalloc : 0x0800 - 0x7dffbfff (129022 GB) Jan 4 18:15:08 laxton0 kernel: [0.00] .text : 0x0808 - 0x086e ( 6528 KB) Jan 4 18:15:08 laxton0 kernel: [0.00] .rodata : 0x086e - 0x088f ( 2112 KB) Jan 4 18:15:08 laxton0 kernel: [0.00] .init : 0x088f - 0x08c2 ( 3264 KB) Jan 4 18:15:08 laxton0 kernel: [0.00] .data : 0x08c2 - 0x08d28200 ( 1057 KB) Jan 4 18:15:08 laxton0 kernel: [0.00].bss : 0x08d28200 - 0x08dc37bc ( 622 KB) Jan 4 18:15:08 laxton0 kernel: [0.00] fixed : 0x7dfffe7fd000 - 0x7dfffec0 ( 4108 KB) Jan 4 18:15:08 laxton0 kernel: [0.00] PCI I/O : 0x7dfffee0 - 0x7de0 (16 MB) Jan 4 18:15:08 laxton0 kernel: [0.00] vmemmap : 0x7e00 - 0x8000 ( 2048 GB maximum) Jan 4
Re: debian-installer failure with arm64 (was RE: laxton (softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)
Lennart Sorensen writes ("Re: debian-installer failure with arm64 (was RE:
laxton (softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)"):
> Stretch in the archive currently has a kernel version of 4.8.11, so an
> installer booted with 4.7.8 is going to have a hard time finding working
> kernel modules.
...
> Maybe these would work better:
> https://d-i.debian.org/daily-images/arm64/daily/netboot/debian-installer/arm64/
Yes, they do, much better, thank you. There are still some alarming
messages on the console which I will take up with the
hardware/firmware folks, but d-i ran to completion and generated a
system which boots.
Is it the case, then, that the images here
> >
> > http://ftp.debian.org/debian//dists/stretch/main/installer-arm64/current/images/netboot//debian-installer/arm64/linux
are simply useless now ? They seemed like the obvious starting point
to me. (The corresponding amd64 installer is what I used to install
stretch on an x86 machine fairly recently.)
Anyway, what I really want is a suitable combination of parts in
backports. Should I expect this all to work if I use a backports
kernel ?
If so then I will try it again more systematically and report what
goes wrong - but IIRC[1] it's probably the same thing: not finding the
kernel modules.
Thanks,
Ian.
[1] If I Recall Correctly.
debian-installer failure with arm64 (was RE: laxton (softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)
(CCing debian-arm, because I think this is now something related to d-i
on ARML.)
Hi. I'm writing with my Xen Project hat on. We have two Softiron
ARM64 servers which I am trying to get up and running in our CI
system.
Right now, I can't get d-i to install on them. I have tried jessie
with a backports kernel, and stretch.
With stretch, d-i bombs out here:
Jan 3 18:00:44.412384 Download installer components
Jan 3 18:00:45.044389 -
Jan 3 18:00:45.052432 Jan 3 18:00:45.052445 No kernel modules were found.
This probably is due to a mismatch between the
Jan 3 18:00:45.060411 kernel used by this version of the installer and the
kernel version available
Jan 3 18:00:45.060450 in the archive.
Jan 3 18:00:45.068415 Jan 3 18:00:45.068427 If you're installing from a
mirror, you can work around this problem by
Jan 3 18:00:45.068458 choosing to install a different version of Debian. The
install will probably
Jan 3 18:00:45.076422 fail to work if you continue without kernel modules.
Jan 3 18:00:45.084417 Continue the install without loading kernel modules?
Jan 3 18:00:45.084448 1: Yes 2: No [*]
If I select `1', it then continues without detecting any hard disks
(`No disk drive was detected').
My kernel image and initrd are:
http://ftp.debian.org/debian//dists/stretch/main/installer-arm64/current/images/netboot//debian-installer/arm64/linux
76ec5622593eeebb7203748530e6b28adedba63a1c23f4e23d086372538fa006 linux
http://ftp.debian.org/debian//dists/stretch/main/installer-arm64/current/images/netboot//debian-installer/arm64/initrd.gz
862e74a54665b1198ee697d8414e19da3ed9b05613cded73db764ea8920aeee5 initrd.gz
My grub.cfg, which I am using to netboot the image, and my preseed
file, are below.
If I boot with `auto' removed from my command line I can quit into a
shell after "No kernel modules were found" and then I see this:
~ # uname -av
Linux laxton0 4.7.0-1-arm64 #1 SMP Debian 4.7.8-1 (2016-10-19) aarch64 GNU/Linux
~ # ls /lib/modules/4.7.0-1-arm64/
kernel modules.builtin.bin modules.order
modules.aliasmodules.dep modules.softdep
modules.alias.binmodules.dep.bin modules.symbols
modules.builtin modules.devname modules.symbols.bin
~ # cat /proc/partitions
~ #
I'm not sure what d-i is looking for and why it isn't finding it.
I also tried jessie with a backports kernel, and that has similar
trouble. Exactly how I construct the initrd.gz is rather complicated
to explain so let's stick with stretch for now. Ultimately, though,
I'm hoping to be able to get this working with jessie.
Ian.
All the files used in the installer setup can be found here, for now:
http://logs.test-lab.xenproject.org/osstest/logs/104013/build-arm64/
But here are the netbooted grub's config, and the preseed file.
set default=0
set timeout=5
menuentry 'overwrite' {
linux /osstest/debian-installer/arm64/2017-01-03-stretch/linux vga=normal
auto=true preseed hw-detect/load_firmware=false DEBCONF_DEBUG=5
DEBIAN_FRONTEND=text hostname=laxton0
url=osstest.test-lab.xenproject.org/~iwj/osstest/laxton0_preseed
netcfg/dhcp_timeout=150 netcfg/choose_interface=auto
domain=test-lab.xenproject.org --
initrd /osstest/tmp/laxton0--initrd.gz
}
d-i debian-installer/locale string en_GB
d-i console-keymaps-at/keymap select gb
d-i keyboard-configuration/xkb-keymap string en_GB
#d-i debconf/frontend string readline
d-i mirror/country string manual
d-i mirror/http/proxy string
d-i clock-setup/utc boolean true
d-i time/zone string UTC
d-i clock-setup/ntp boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman-lvm/confirm boolean true
d-i partman/confirm_nooverwrite true
d-i partman-lvm/confirm_nooverwrite true
d-i partman-md/confirm_nooverwrite true
d-i partman-crypto/confirm_nooverwrite true
#d-i netcfg/disable_dhcp boolean true
d-i netcfg/get_nameservers string 172.16.144.4
d-i netcfg/confirm_static boolean true
d-i netcfg/get_domain string test-lab.xenproject.org
d-i netcfg/wireless_wep string
d-i passwd/root-password password xenroot
d-i passwd/root-password-again password xenroot
d-i passwd/user-fullname string FLOSS Xen Test
d-i passwd/username string osstest
d-i passwd/user-password password osstest
d-i passwd/user-password-again password osstest
console-common console-data/keymap/policy select Don't touch keymap
console-dataconsole-data/keymap/policy select Don't touch keymap
console-dataconsole-data/keymap/family select qwerty
console-data console-data/keymap/template/layout select British
popularity-contest popularity-contest/participate boolean false
tasksel tasksel/first multiselect standard, web-server
d-i grub-installer/only_debian boolean true
# see
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Niels Thykier writes (Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))): On 2013-11-03 16:03, Steven Chamberlain wrote: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 Actually, I meant a real BTS page (e.g. like [1]) rather than just a list of tagged bugs. The list of tagged bugs definitely have it uses, but it does not give me an overview of which bugs should be fixed by the maintainer of the given package and which the porters should fix. I think this would be a good idea. If the psuedo-package had a predictable name which depended only on the architecture, even better. Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21113.13532.963985.569...@chiark.greenend.org.uk
Re: Bits from the Release Team (Jessie freeze info)
Niels Thykier writes (Bits from the Release Team (Jessie freeze info)): Results of porter roll-call === ... Summary table: Arch || DDs || NMs/DMs || Other || Total - ---++-++-++---++-- armel || 5 || 0 || 2 ||7 armhf || 6 || 1 || 2 ||9 hurd-i386 || 5 || 0 || 3 ||8 ia64 || *0* || 0 || 3 ||3 kfreebsd-amd64 || 5 || 0 || 2 ||6 kfreebsd-i386 || 5 || 0 || 2 ||6 mips || 2 || 0 || 1 ||3 mipsel || 2 || 0 || 1 ||3 powerpc[1] || (1) || 0 || 2 || 2.5? s390x || 1 || 0 || 1 ||2 sparc || 1 || 0 || 0 ||1 ... Based on the number of porters, we are considering changing the current requirements of 5 DDs to better reflect the reality of the situation. We will follow up in a future bits on the changes. Thanks. I think it is disappointing to find that we may be dropping architectures where a significant amount of effort is available, simply because the volunteers don't have enough status - specifically, because of a lack of DDs. I'm keen that Debian should continue to support a wide range of architectures. Would it help if I, as a DD, volunteered to sponsor porter uploads for any architecture ? That is I guess I'm volunteering to become a new kind of person - a non-port-specific porter sponsor. Obviously I will review the debdiff etc. I'm an experienced C programmer with some background in C language lawyering and portability stuff, so I should usually be able to do a decent review of a patch even on an unfamiliar architecture. In fact, regardless of what the release team decide for the policy, I would be happy to sponsor porter uploads. Please just email me. Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21103.52917.876297.985...@chiark.greenend.org.uk
Re: Bits from the Release Team (Jessie freeze info)
Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)): On 2013-10-29 16:05, Ian Jackson wrote: I'm keen that Debian should continue to support a wide range of architectures. Would it help if I, as a DD, volunteered to sponsor porter uploads for any architecture ? That is I guess I'm volunteering to become a new kind of person - a non-port-specific porter sponsor. ... I suppose that could help ports without a DD if we allowed such to be in testing. Indeed. However, it is my understanding that our main issue with ports often is that they are not actively maintained (or appears to lack active maintenance). Right. As mentioned we are debating whether the 5 DDs requirement still makes sense. Would you say that we should abolish the requirement for DD porters completely? I.e. Even if there are no (soon to be) DDs, we should consider the porter requirements fulfilled as long as they are enough active porters behind the port[0]? I don't have a good feel for the answer to that question. It's just that if it is the case that a problem with ports is the lack of specifically DDs, rather than porter effort in general, then sponsorship is an obvious way to solve that problem. If you feel that that's not really the main problem then a criterion which counts porters of any status would be better. (Mind you, I have my doubts about a process which counts people promising to do work - it sets up some rather unfortunate incentives. I guess it's easier to judge and more prospective than a process which attempts to gauge whether the work has been done well enough.) As an example I remember having received several complains from e.g. the GCC maintainers in regards to the state of gcc on various ports[1]. Here I would suspect a patch would be sufficient without needing to actually NMU gcc to get the fix in. There are also stuff like the port concerns from DSA that attention. Right. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21103.59120.410686.914...@chiark.greenend.org.uk
