I'm trying to use kexec on Guix, which I think should be

kexec -l /run/current-system/kernel/bzImage  --append="$(cat /proc/cmdline)" --initrd=/run/current-system/initrd
kexec -e

However, that results in a blank screen. I can still reboot through alt-printscreen-b, so the (old or new) kernel is still running. The other alt-printscreen-reisub letters don't seem to do anything (not even fans spinning up). As for the XY-problem, I'd like to be able to skip grub. Mainly because the drive is encrypted, and I have to enter the LUKS password twice: for grub and for the kernel. So I hope to save some time by booting directly into Linux and having to decrypt the drive only once. Not sure whether this is actually a Guix problem, or something else.

By default, the Linux kernel frees the memory that was used for an initramfs after its unpack is complete. If the kernel argument retain_initrd is used, then kexec --reuseinitrd becomes available to -- as the name implies -- reuse an initrd that was booted previously; meaning it's still retained in kernel memory. Insofar as an initramfs consists of a series of gzipped cpio archives concatenated to each other, it would be useful to be able to boot into the same initramfs one used previously, but with an additional archive (adding new or different files) either prepended or appended. Is there any stable, supportable way for a privileged/superuser account to access the cpio archive that the current kernel was booted with, if retain_initrd was used? Or alternately, is there a way to prepend or append to that retained content rather than replacing it when using kexec to upload new initrd content?

I'm using kexec-tools to get a crash dump of kernel on kernel panic. However, when I trigger the panic using sysrq-trigger, the system freezes. I have to power off and then power on to restore the system. There is no automatic reboot and no crash dump is available in /var/crash. The following are the configurations and details: - Linux Distro - Debian Buster arm64 - Linux Kernel - 4.19.35 - kexec-tools v2.0.22 (Built from source) - All Kernel Configs specifed here for arm64 enabled: https://www.kernel.org/doc/Documentation/kdump/kdump.txt Both the main kernel and crash kernel are exactly the same. (Although using uncompressed Image as crash kernel) /proc/cmdline = crashkernel=512M nokaslr # Along with other arguments The crash kernel space gets reserved (verified by dmesg) Loading crashkernel to kick-in on a kernel panic: $ sudo kexec -p ./Image --append=" root=/dev/sda1 console=same_as_main_kernel earlycon=same_as_main_kernel rootwait rw 1 max_cpus=1 reset_devices The root fs is same as that used for main kernel. Trigerring Kernel Panic: $ echo c | sudo tee /proc/sysrq-triggger The serial console freezes with standard kernel panic stacktrace. One of the logs specific to Kdump is: [14645.1099571] CPU: 2 PID: 20518 Comm: tee Kdump: loaded Not tainted 4.19.35-g9e41bb234b42 #2 The system however does not reboot. One thing to note is that I can boot into the crash kernel if I want to explicitly: $ sudo kexec -l ./Image --append=" root=/dev/sda1 console=same_as_main_kernel earlycon=same_as_main_kernel rootwait rw 1 max_cpus=1 reset_devices $ sudo kexec -e This boots into the specified kernel. How can I resolve/debug this issue further in which the crash kernel does not seem to kick-in in the event of a kernel panic.

I'm looking to create a setup where an OS image is (automatically) downloaded over the network and then booted into. The obvious way would be to write it to disk, reconfigure grub (or whatever) and reboot, but I'm looking for a way to do this **without any disk writes** at all. The disk would only be used to read the fixed initial image, responsible for downloading the real image and everything after that would run purely from a RAMdisk. After a real reboot (like a shutdown command or disconnected power), I would expect the device to boot back into the initial disk image, which would again start from scratch by downloading the real image, etc. I've heard of netboot for diskless setups, but it seems not appropriate for my use case as I need a full Linux userland running for downloading the image (I want to have the option to download over WiFi, use gpg to verify signatures, etc. which is not feasible from bootloader). I've also looked into kexec, but I'm not sure how it could be used to load a full bootable image.

By checking I mean something quite rock-solid, i. e., trying to analyse loader's configuration or available kernel files and matching to uname's output clearly isn't an option.

I'm working on a project involving kexec. I have it working on some of our hardware platforms. On one platform, I'm getting sudden reboots with no panic dump during SMP setup:

[   25.219028] smpboot: CPU0: AMD EPYC 7402 24-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
[   25.228083] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
[   25.237997] ... version:                0
[   25.247996] ... bit width:              48
[   25.257996] ... generic registers:      6
[   25.267996] ... value mask:             0000ffffffffffff
[   25.277996] ... max period:             00007fffffffffff
[   25.287996] ... fixed-purpose events:   0
[   25.297996] ... event mask:             000000000000003f
[   25.308059] rcu: Hierarchical SRCU implementation.
[   25.318046] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[   25.328283] smp: Bringing up secondary CPUs ...
[   25.335543] x86: Booting SMP configuration:
��

This platform boots fine under normal (i.e., non-kexec) circumstances. The primary and kexec kernels are built from the same codebase but linked differently - this is unlikely to be related to the issue because I've already tested this on an Intel platform. Kexec command line:

[    0.000000] Command line: elfcorehdr=0x86000000 ro panic=5 console=ttyS0,9600 loglevel=8 numifbs=0 nf_conntrack.acct=1 nmi_watchdog=1 profile=0 root=/dev/ram0 initrd=/crashfs.gz libata.force=disable

BIOS - may be relevant since one boot is with and one is without the BIOS:

Version 2.20.1275. Copyright (C) 2022 American Megatrends, Inc.
BIOS V1.05(08/26/2022)

I've tracked it down to wakeup_secondary_cpu_via_init in arch/x86/kernel/smpboot.c. The last output I get is just before the first apic_icr_write. I don't know where to even begin debugging this. Could it possibly be the NMI watchdog forcing a reboot because the only available core is hanging for some reason? Seems unlikely since that hung core wouldn't be able to perform NMI checks.

The boot chain here is UEFI -> 6.1.14 kernel built with EFI stub, initramfs loads and checks 5.4.109 kernel, then kexecs it. CPU is a 2-core Intel Atom N6210. When booted this way, at startup when the 5.4 kernel releases the second CPU, it immediately panics with an alignment exception. The same kernel image works fine when booted from EFI, or booted via kexec by the 5.4.109 kernel.

I have a Debian 11 installation with the following partition layout: | path | format | mount point | |------|--------|-------------| | /dev/nvme0n1p7 | ext4 (no encryption) | /boot (Debian 11) | | /dev/nvme0n1p8 | dm-crypt LUKS2 | LVM2 (named vg_main) | | /dev/mapper/vg_main-lv_swap | swap | - | | /dev/mapper/vg_main-lv_debian | ext4 | / (Debian 11) | | /dev/mapper/vg_main-lv_ubuntu | ext4 | / (Ubuntu 22.04) | The /boot for Ubuntu, lives inside its root file system (/dev/mapper/vg_main-lv_ubuntu). I'd like to kexec the Ubuntu kernel after booting the Debian kernel that lives in the unencrypted /boot partition that unlocks the LUKS2 partition. I'd like to use the [systemd kexec strategy described here](https://wiki.archlinux.org/title/kexec#Separate_/boot_partition) . Is there a way to pass any specific kernel parameter to Debian 11 (that I will do in a specially created GRUB2 entry for this) to tell systemd to simple kexec the Ubuntu 22.04 kernel? ----- **Solution:** Worked as per [@telcoM](https://unix.stackexchange.com/posts/704847#704888) suggestion, with just few adjustments: /etc/systemd/system/ubuntu-kexec.target

[Unit]
Description=Ubuntu kexec target
Requires=sysinit.target ubuntu-kexec.service
After=sysinit.target ubuntu-kexec.service
AllowIsolate=yes

/etc/systemd/system/ubuntu-kexec.service

[Unit]
Description=Ubuntu kexec service
DefaultDependencies=no
Requires=sysinit.target
After=sysinit.target
Before=shutdown.target umount.target final.target

[Service]
Type=oneshot
ExecStart=/usr/bin/mount -o defaults,ro /dev/mapper/vg_main-lv_ubuntu /mnt
ExecStart=/usr/sbin/kexec -l /mnt/boot/vmlinuz --initrd=/mnt/boot/initrd.img --command-line="root=/dev/mapper/vg_main-lv_ubuntu resume=UUID=[MY-UUID-HERE] ro quiet splash"
ExecStart=/usr/bin/systemctl kexec

[Install]
WantedBy=ubuntu-kexec.target

I have an application where I need to boot to Linux, execute automated scripts and then automatically boot to Windows. Can I use Kexec to run grub? Another use case would be to boot a Linux kernel to update the processor microcode, and then kexec to GRUB or Syslinux to boot Windows -- because the microcode won't survive a full reboot. I've heard of grub4dos (link (unavailable) , archived version ), but it seems to be discontinued, so is there a way to do it with GRUB2? I would basically need a loadable image of GRUB for kexec. I tried to load the images found in this explanation , but they don't seem to work. Thanks for any hints. ------------ Note: Found this post from back in 2014, which said that this was not yet implemented in kexec.

At boot, the bootloader loads a kernel, let's say vmlinuz1. Is there a way to pass some kind of parameters to it in order to chainload another kernel (let's say vmlinuz2)? I know kexec can load another kernel but I don't know if it can run automatically at boot.

I have built both a kernel from the Raspberry Pi sources and kexec-tools for arm64, and booted my kernel on a Raspberry Pi 4. When I attempt to run kexec, it produces no output, exits with a nonzero return code, and an error message is posted to dmesg. ## The debug output While running kexec normally prints no output, running with --debug to show debug messages shows:

# kexec -s -l /media/sda1/boot/vmlinuz-rpi4barb --initrd /media/sda1/boot/initramfs-rpi4barb --reuse-cmdline --debug
arch_process_options:178: command_line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:09:35:A1 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  modules=loop,squashfs,sd-mod,usb-storage quiet console=tty1 console=ttyS0,115200
arch_process_options:180: initrd: /media/sda1/boot/initramfs-rpi4barb
arch_process_options:182: dtb: (null)
arch_process_options:185: console: (null)
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /media/sda1/boot/vmlinuz-rpi4barb of 65536 bytes failed
elf_arm64_probe: Not an ELF executable.

# echo $?
255

My kernel _did_ boot (so it must be _some_ kind of executable). file claims:

# file /media/sda1/boot/vmlinuz-rpi4barb
/media/sda1/boot/vmlinuz-rpi4barb: Linux kernel ARM64 boot executable Image, little-endian, 4K pages

## The dmesg output When I run kexec, the line Can't kexec: CPUs are stuck in the kernel appears in dmesg. What does it mean that CPUs are stuck in the kernel, and what should I do to resolve this problem? I have googled the message, and found mostly the code that generates it and a few unanswered questions. ## Is this related to PSCI? [One mailing list thread](http://lists.infradead.org/pipermail/kexec/2017-April/018569.html) which did have some replies indicated the problem may lie with something called [PSCI](https://linux-sunxi.org/PSCI) . Running the suggested command dmesg | grep -E 'psci|started in' results in no output, indicating that PSCI is not supported in the kernel that I built. I don't understand that answer. The kernel docs [place PSCI under kvm](https://www.kernel.org/doc/html/latest/virt/kvm/arm/psci.html) , but my kernel is booting to physical hardware. Am I missing something? ## Any help greatly appreciated Have I built my kernel wrong? Are there any docs or posts I've missed showing the right way to do this? Thanks for looking.

I tried installing Kali-Win-Kex by following [the official guide](https://www.kali.org/docs/wsl/win-kex/) .

$ sudo apt install kali-win-kex -y
    dpkg: error processing archive /var/cache/apt/archives/kali-win-kex_2.7_amd64.deb (--unpack):
     new kali-win-kex package pre-installation script subprocess returned error exit status 1
    Errors were encountered while processing:
     /var/cache/apt/archives/kali-win-kex_2.7_amd64.deb
    E: Sub-process /usr/bin/dpkg returned an error code (1)

Trying apt install -f solve the problem changes package status from half-installed to uninstalled. Trying to install the package directly leads to the following error:

$ sudo dpkg -i /var/cache/apt/archives/kali-win-kex_2.7_amd64.deb
(Reading database ... 102450 files and directories currently installed.)
Preparing to unpack .../kali-win-kex_2.7_amd64.deb ...
This package is for WSL 2. Nothing to be done here.
dpkg: error processing archive /var/cache/apt/archives/kali-win-kex_2.7_amd64.deb (--install):
 new kali-win-kex package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/kali-win-kex_2.7_amd64.deb

How can I install kali-win-kex?

Windows version: 19042.746
Kali version: 2020.4 (kali-rolling)

*(Posting here rather than the Ubuntu subsite because I don't think it's specifically related to Ubuntu...)* I've previously been successfully using kexec-reboot -lr from the exceptionally useful page here . After an upgrade from 18.04 to 20.04, running this command still reboots the system, but it now does a 'hard' reboot where it drops all the way to EFI/firmware instead of just reloading and restarting the kernel. This adds several minutes to the boot time on my server (and defeats the whole point of using this invocation...) The command that's being run according to the verbose output of kexec-reboot is: Running /sbin/kexec -l /boot/vmlinuz-5.4.0-54-generic --append='root=UUID=69a4d39e-361f-41e7-9ad3-866cb9dae202 ro intel_iommu=on' --initrd=/boot/initrd.img-5.4.0-54-generic Running that command directly (i.e. not from the kexec-reboot convenience script) gives the same behavior. I've checked syslog and dmesg for messages that seem relevant and I can't find anything, but I'm also likely not aware of all the various places I could look. Other than just the verbose flag, what other things can I use to troubleshoot this? Update 11/26: If I manually build the kexec line as describe above and then run kexec -e (As described here ) it does indeed just boot the kernel directly. Looking at the kexec-reboot code shows that the final call there is shutdown -r now, so I'm now trying to figure out why shutdown -r now is different behavior than it was before...

I have been trying to debug random system freezes when running the 4.14.93-rt kernel. To this end, I have enabled the lockup detector in the kernel using the following config: CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y CONFIG_LOCKUP_DETECTOR=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR_PERF=y CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1 CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 The goal is to trigger a kernel panic when a lockup occurs. I also enabled the NMI watchdog on the kernel cmdline: nmi_watchdog=1 Making use of kdump/kexec tools, I have configured the system to generate a kernel crash dump on kernel panic. The mechanism works when triggering a panic manually using: echo c > /proc/sysrq-trigger I can confirm that the system loads a dump-capture kernel in that case. However, when experiencing an actual lockup, the system just reboots when the watchdog kicks in. AFAIK there is no kernel panic occuring. There is no switch to the dump-capture kernel. No core dump, nothing stored in the logs. Note that I enabled all relevant sysctl options: kernel.panic = 1 kernel.panic_on_oops = 1 kernel.unknown_nmi_panic = 1 kernel.panic_on_unrecovered_nmi = 1 kernel.panic_on_io_nmi = 1 kernel.softlockup_panic = 1 kernel.hung_task_panic = 1 I see this behavior when experiencing a real-life system freeze. It also occurs when running a CPU hogging while-loop on all cores with high RT priority. I would expect this to be detected as a hung task and lead to a panic. What could cause a reboot in this case without triggering the panic/kdump mechanism?

Upon installing kexec-tools, on Ubuntu at least, I am asked if I want to use kexec to handle all invocations of reboot. I don't, but there are some occasions that I do want graceful termination of running processes and unmounting of filesystems and then execution of kexec to reboot the system. How can this be achieved? And suppose that I someone has made rebooting with kexec the default. How would someone invoke a normal reboot in that case? Answers should not be restricted to systemd.

I have a passphrase-protected SSH key stored in ~/.ssh/id_rsa. In my .zshrc I have this fragment: if ! ssh-add -l > /dev/null; then ssh-add fi After booting, I usually open the terminal, see the passphrase prompt, then unlock my KeePass 2 DB, copy the passphrase to clipboard and paste it into the terminal to add the key to the agent. A few days ago, I have rebooted the system, logged in, and opened the terminal. To my surprise, the passphrase prompt didn't appear. Surprised, I typed ssh-add -l to see my key already added. That was weird, but I hand-waved it away, thinking that I forgot that I've already typed the password. A moment ago, I ran sudo systemctl kexec, and after logging in, the key was already added again. My KeePass DB was locked. The passphrase is long and random (/[a-zA-Z0-9]{20}/). This time I suspected it's something specific to kexec, but after yet another sudo systemctl kexec, the passphrase prompt appeared, the key wasn't added to the agent. - How come my SSH key is sometimes added to the agent after reboot? - Can it also happen after a cold boot? (yes) - What can I do to prevent it? I'm using Pop!_OS 18.04, booting with UEFI off a GPT disk with LUKS-encrypted / and unencrypted /boot, no LVM if that matters. --- _Edit:_ I've just cold booted after 4 days and the key was already added to agent again.

I have a Linux server on a VM which the reboot does work as powering off due to misconfiguration of a third part provider. I do not have access to VM configuration. The person who installed the system did a mess up with the storage and have irresponsibly mounted one point for each directory (/var, /home, /usr, etc...) leading them to be easely starved for some and empty for others. In order to fix that mess I am reorganizing the mount points, I was able to manage most of them by doing mount --bind / /mnt followed by rsync and then relaunching the process who use them after umount. The problem is the /var and /usr which is used by systemd init process itself. Would systemd-remount-fs does the trick? How could I permorm that? Would be a simple fstab edit followed by rsync be enough? Will it restart all the services? I know which points really does need separate partitions for my case, and it is not the case of /var and /usr at all. The premise is I can not use umount -l as I will have to destroy the partition after remounting the one, and I would like to avoid kexec due to not knowing if it will have the same buggy efect on this misconfigured VM of being unable to bring it up again. I am planning to have a compressed btrfs partition for /var/log and another btrfs or xfs for /var/lib/docker, and put all others together with the minimum required space as possible once they will be almost static. And in the future I may put them as squashfs together with the root one and mount a overlayfs to make it easy to detect misconfigurations. I would like to be able to do all of this without rebooting, though I don't know I will be able to.

Is there a way to kexec reboot a running kernel without having to decrypt an encrypted LUKS root filesystem? I'd imagine not, but I'm not sure if there's a workaround for this.

I'm running Arch Linux and I've set up [kdump](https://wiki.archlinux.org/index.php/Kdump) so that when the current kernel panics(or I manually induce a crash via sysrq+c) then another kernel(the kexec kernel) starts up in order to create a crash dump so that I can later inspect it. The problem is that whether this triggers from console or from within Xorg, the same screen remains on the display for the entire duration of the kexec-ed kernel and I thus cannot see what it's doing. This isn't a problem on a non-i915 laptop that's using AMD/Radeon for example. I've tried the following kernel args for the kexec kernel and they've had no effect on this issue: 1. systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 2. systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 i915.fastboot=0 i915.reset=1 i915.modeset=-1 i915.force_reset_modeset_test=true i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 zram.num_devices=3 zswap.enabled=0 The full ExecStart= line that I'm currently using and has no effect is: ExecStart=/usr/bin/kexec -p /boot/vmlinuz-linux-git --initrd=/boot/initramfs-linux-git.img --reuse-cmdline --reset-vga --console-vga "--append=root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 i915.fastboot=0 i915.reset=1 i915.modeset=-1 i915.force_reset_modeset_test=true i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 zram.num_devices=3 zswap.enabled=0" So when kernel panics, the X or console screen that was present at panic time will remain on the screen until the kexec kernel is done saving the dump file and reboots. When crashkernel= arg for the primary kernel is too low, the kexec kernel can OOM during makedumpfile and thus I've no idea why it didn't reboot after x minutes because I can't see its screen. I guess I need some (working)way to switch to 80x25 mode or some way to tell kexec kernel to reset the i915 video card so it can re-init it again normally? **EDIT:** not using EFI, using grub+MBR also some primary kernel info:

[    0.275493] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux-git root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a rw root_trim=yes rd.luks.allow-discards rd.luks.options=discard ipv6.disable=1 ipv6.disable_ipv6=1 ipv6.autoconf=0 loglevel=15 log_buf_len=16M ignore_loglevel printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=4 memory_corruption_check=1 fbcon=scrollback:4096k fbcon=font:ProFont6x11 net.ifnames=0 nolvm dobtrfs console=tty1 earlyprintk=vga audit=0 systemd.log_target=kmsg systemd.journald.forward_to_console=1 enforcing=0 udev.children-max=1256 rd.udev.children-max=1256 nohz=on oops=panic crashkernel=1024M panic=0 page_poison=1 psi=1 sysrq_always_enabled random.trust_cpu=off logo.nologo lpj=0 mce=bootlog reboot=force,cold noexec=on nohibernate scsi_mod.use_blk_mq=1 consoleblank=120 mitigations=off nospectre_v1 nospectre_v2 spectre_v2=off nospec_store_bypass_disable kvm-intel.vmentry_l1d_flush=never l1tf=off nopti pti=off no_stf_barrier noibrs noibpb ssbd=force-off spectre_v2_user=off noretpoline mds=off rd.log=all noefi cpuidle.governor=menu zram.num_devices=3 zswap.enabled=0 zswap.same_filled_pages_enabled=1 zswap.compressor=zstd zswap.max_pool_percent=40 zswap.zpool=z3fold vsyscall=none i915.enable_fbc=1 i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1
[    0.845622] device: 'fbcon': device_add
[    0.845626] PM: Adding info for No Bus:fbcon
...
[    4.416734] fbcon: i915drmfb (fb0) is primary device
...
[    4.494499] i915 0000:00:02.0: fb0: i915drmfb frame buffer device

Here's a cmdline word diff between primary and kexec kernel:

diff --git a/home/user/logs/pri_kernel.log b/home/user/logs/kexeckernel.log
index e6d2815..9b90a12 100644
--- a/home/user/logs/pri_kernel.log
+++ b/home/user/logs/kexeckernel.log
@@ -1,2 +1,2 @@
 [    0.000000] Command line:
-BOOT_IMAGE=/boot/vmlinuz-linux-git
  root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a rw root_trim=yes rd.luks.allow-discards rd.luks.options=discard ipv6.disable=1 ipv6.disable_ipv6=1 ipv6.autoconf=0 loglevel=15 log_buf_len=16M ignore_loglevel printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=4 memory_corruption_check=1 fbcon=scrollback:4096k fbcon=font:ProFont6x11 net.ifnames=0 nolvm dobtrfs console=tty1 earlyprintk=vga audit=0 systemd.log_target=kmsg systemd.journald.forward_to_console=1 enforcing=0 udev.children-max=1256 rd.udev.children-max=1256 nohz=on oops=panic
-crashkernel=1024M
  panic=0 page_poison=1 psi=1 sysrq_always_enabled random.trust_cpu=off logo.nologo lpj=0 mce=bootlog reboot=force,cold noexec=on nohibernate scsi_mod.use_blk_mq=1 consoleblank=120 mitigations=off nospectre_v1 nospectre_v2 spectre_v2=off nospec_store_bypass_disable kvm-intel.vmentry_l1d_flush=never l1tf=off nopti pti=off no_stf_barrier noibrs noibpb ssbd=force-off spectre_v2_user=off noretpoline mds=off rd.log=all noefi cpuidle.governor=menu zram.num_devices=3 zswap.enabled=0 zswap.same_filled_pages_enabled=1 zswap.compressor=zstd zswap.max_pool_percent=40 zswap.zpool=z3fold vsyscall=none i915.enable_fbc=1 i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 
+root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 i915.fastboot=0 i915.reset=1 i915.modeset=-1 i915.force_reset_modeset_test=true i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 zram.num_devices=3 zswap.enabled=0 acpi_rsdp=0xf05b0 elfcorehdr=2588032K
~
 
~

There's no mention in kexec kernel dmesg of i915 except in cmdline.

I used kexec to successfully load my kernel, but it's just printing dmesg lines. How do I get out of this to drop into the initramfs prompt? Ctrl-Alt-F2 just loads a black screen and ctrl-c does nothing. Here is my kexec commandline: kexec -l $kernel --initrd=$initrd --command-line="root=UUID=... acpi=off ro text earlyshell debug showerr debuginitrd" earlyshell should provide me access to a shell, but it doesn't. Without that commandline, I just end up in a scripting loop that I can't break out of even with ctrl-c.