[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Transfering Data from GRUB to userspace?

From: Daniel Kiper
Subject: Re: Transfering Data from GRUB to userspace?
Date: Mon, 28 Oct 2019 17:46:13 +0100
User-agent: NeoMutt/20170113 (1.7.2)

Hi Max,

On Mon, Oct 28, 2019 at 10:58:21AM +0000, Max Tottenham via Grub-devel wrote:
> Hi Folks
> I've often found myself in a position where I've needed to perform some
> debugging of remote hardware that does not have a network accessible KVM
> attached. To that end, being able to remotely log into a machine and
> have some method of accessing GRUB2 boot time debug messages from
> userspace (in my case linux), would be rather useful. It also dawned on
> me that this capability might be the sort of thing that folks upstream
> might be keen on.
> I have done a little thinking and have thought of two possible
> approaches:
> 1. Perform some hacking of the grub environment block (load/save env)
> handling to be able to write log data to either the same file in /boot,
> or perhaps a separate distinct debug log file.

This can be difficult and unreliable.

> 2. Export the debug log to a running kernel as another initrd image. In
> other words, have GRUB2 buffer a bunch of log messages and then append
> that log data as a separate initrd archive. Some early userspace program
> would then be able to copy that archive to the real filesystem, or
> stick it into the kernel log buffer. The logfile in the
> initrd that GRUB generates could have either a configurable name based
> on some setting in grub.cfg, or some well known default name (like
> /grub2-debug.log)
> I initially started with 1, but I dislike the approach of having GRUB2
> write to the filesystem, it's also a little cumbersome to setup,
> Approach 2 seems like it would work (at least for linux, I've no
> experience with the BSDs but presumably any OS that can load multiple
> initrd's would be able to use this approach too), and has the advantage
> that it doesn't have to touch any data on disk.

Yeah, I think you are right. Additionally, please take a look at [1] and
especially at [2]. The series is about to commit and setup_indirect part
can be very useful for you. And I would like to see similar feature in the
Multiboot2 protocol [3].

Additionally, I think you can take a look at ACPI ERST and UEFI variables.
Both can be interesting for you and are used in Linux kernel by something
called pstore (in general "grep -Ir pstore Documentation" will show you
some interesting things, e.g. ramoops). Though this stuff is limited in size.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]