Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #61401 > unrolled thread

Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

Back to article view | Back to linux.debian.kernel

Contents

  Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8 "Michael J. Redd" <micredd@gmail.com> - 2018-07-14 15:50 +0200
    Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8 "Michael J. Redd" <micredd@gmail.com> - 2018-07-14 16:40 +0200
      Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8 Andy Smith <andy@strugglers.net> - 2018-07-14 17:30 +0200
    Bug#903767: 1adc34adc3447c34926994b87db5d929f5ab45b5 confirmed to fix the issue tmc <tmc@vandradlabs.com.au> - 2018-07-17 16:10 +0200
    Bug#903767: 1adc34adc3447c34926994b87db5d929f5ab45b5 confirmed to fix the issue TMC <tmciolek@gmail.com> - 2018-07-17 16:20 +0200

#61401 — Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

Package: linux-image-4.9.0-7-amd64
Version: 4.9.110-1

Description:
============

After installing the latest Stretch kernel, 4.9.110-1, on a server
running Xen Hypervisor 4.8, bootstrapping the kernel fails. GRUB loads
the hypervisor as normal, which then attempts to load the Dom0 kernel.
Once that process starts, the system simply reboots. Nothing is output
to the console after Xen does its thing (screen goes black), so I
cannot offer any insights into what the kernel may be doing before it
fails.

If I roll back to the previous Stretch kernel, linux-image-4.9.0-6-
amd64 (4.9.88-1+deb9u1), the hypervisor starts the Dom0 kernel as
normal and the system boots successfully.

Setup:
======

Xen Hypervisor version: 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
Kernel version: linux-image-4.9.0-7-amd64 (4.9.110-1)

[toc] | [next] | [standalone]

#61403

This also apparently affects at least PV guests. Upgrading a PV domU to
 kernel 4.9.110-1 and rebooting yields the following output via xl's
console:


Loading Linux 4.9.0-6-amd64 ...
Loading Linux 4.9.0-7-amd64 ...
Loading initial ramdisk ...   [ vmlinuz-4.9.0-7-
amd6  2.69MiB  66%  1.67MiB/s ]
[    0.128044] dmi: Firmware registration
failed.a  17.29MiB  100%  9.75MiB/s ]
[    1.408778] dmi-sysfs: dmi entry is absent.
[    1.427758] general protection fault: 0000 [#1] SMP
[    1.427767] Modules linked in:
[    1.427778] CPU: 0 PID: 1 Comm: init Not tainted 4.9.0-7-amd64 #1
Debian 4.9.110-1
[    1.427789] task: ffff88000ee36040 task.stack: ffffc90040068000
[    1.427798] RIP: e030:[<ffffffff81614d4d>]  [<ffffffff81614d4d>]
ret_from_fork+0x2d/0x70
[    1.427815] RSP: e02b:ffffc9004006bf50  EFLAGS: 00010006
[    1.427823] RAX: 00000002175f5000 RBX: ffffffff816076d0 RCX:
ffffea0000310e1f
[    1.427833] RDX: 0000000000000002 RSI: 0000000000000002 RDI:
ffffc9004006bf58
[    1.427840] RBP: 0000000000000000 R08: 0000000000000000 R09:
ffff88000a9e5000
[    1.427847] R10: 8080808080808080 R11: fefefefefefefeff R12:
0000000000000000
[    1.427854] R13: 179f3966a73fde7b R14: 06f99905e8f3edfb R15:
cf60f5f9fd8e4751
[    1.427866] FS:  0000000000000000(0000) GS:ffff88000fc00000(0000)
knlGS:0000000000000000
[    1.427873] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.427879] CR2: 00007ffd37e72eb9 CR3: 000000000a9f4000 CR4:
0000000000042660
[    1.427889] Stack:
[    1.427893]  0000000000000000 0000000000000000 0000000000000000
0000000000000000
[    1.427906]  0000000000000000 0000000000000000 0000000000000000
0000000000000000
[    1.427921]  0000000000000000 0000000000000000 0000000000000000
0000000000000000
[    1.427943] Call Trace:
[    1.427951] Code: c7 e8 b8 fe a8 ff 48 85 db 75 2f 48 89 e7 e8 5b ed
9e ff 50 90 0f 20 d8 65 48 0b 04 25 e0 02 01 00 78 08 65 88 04 25 e7 02
01 00 <0f> 22 d8 58 66 66 90 66 66 90 e9 c1 07 00 00 4c 89 e7 eb 11 e8 
[    1.428148] RIP  [<ffffffff81614d4d>] ret_from_fork+0x2d/0x70
[    1.428160]  RSP <ffffc9004006bf50>
[    1.428168] ---[ end trace cb1a96e88a7c4794 ]---
[    1.428298] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[    1.428298] 
[    1.428316] Kernel Offset: disabled


Note that the guest bootloader being used here is pvGRUB; not sure if
that is relevant but thought I would include it. Similarly, rolling the
domU back to the previous kernel/selecting the previous kernel via
pvGRUB allows the VM to boot normally.

[toc] | [prev] | [next] | [standalone]

#61404

Also same symptoms in a PV guest under Xen 4.10. Works if booted on
previous kernel. Also prevents installation of stable using the
netboot image at e.g.

    <http://ftp.uk.debian.org/debian/dists/stretch/main/installer-amd64/current/images/netboot/xen/vmlinuz>

Cheers,
Andy

[toc] | [prev] | [next] | [standalone]

#61432 — Bug#903767: 1adc34adc3447c34926994b87db5d929f5ab45b5 confirmed to fix the issue

On Tue, 17 Jul 2018 11:11:37 +0200 =?utf-8?Q?Michael_La=C3=9F?= <bevan@bi-co.net> wrote:
> I can confirm that applying 1adc34adc3447c34926994b87db5d929f5ab45b5 on top of
> Debian’s 4.9.110-1 kernel solves the issue here on a Xen PV guest.
> 

[toc] | [prev] | [next] | [standalone]

#61433 — Bug#903767: 1adc34adc3447c34926994b87db5d929f5ab45b5 confirmed to fix the issue

[Multipart message — attachments visible in raw view] — view raw

does commit 1adc34adc3447c34926994b87db5d929f5ab45b5 on top of
Debian’s 4.9.110-1 kernel solvexen dom0 boot issue?


-- 
--
GPG key fingerprint: 07DF B95B DB58 57B6 9656  682E 830A D092 288E F017
GPG public key available on pgp(dot)net key server

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web