From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 763E133FE07 for ; Wed, 14 Jan 2026 19:08:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768417703; cv=none; b=A/eS3OfmOjeLGpXk6mZ9bdoRCRCSvATnLwvSpa9MDFEYzFiDTOfNJ3pFrd9+nEhdIOBrEY7wL1wdaU5wHwsYFJlGPSNhr2L/OBcT14rRyA0jn1UgvjLXNktJzQz4hIPk+Hozhls0W1tquLB4YUEKKaGAAuuccRTD80wjw4qRSZ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768417703; c=relaxed/simple; bh=rL1mKtzqQfzbgIbEAmKDaAOtTmTs/5Lg60KQErpr7tg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=XY2LOop0BeWOUwOrc14xOpqsBYMVGF8mgs94VRrlASAEUqctKjJGHUWSkvA7u3QIO/hDwh+SpjhzQhRJm4F08Nt2jmtfO94HNrZlarsmuSEtI9k9dQAQvIApI4b1Rsva3Ty8Lpf49i6kBmdzjlqIzdxKlOZPlZokWlKvQOd1HxY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PbyEkIU5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PbyEkIU5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED7E0C4CEF7; Wed, 14 Jan 2026 19:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768417703; bh=rL1mKtzqQfzbgIbEAmKDaAOtTmTs/5Lg60KQErpr7tg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PbyEkIU5tPZh9NXRoJ4l5vH2mFRF3E4ehAdw7jhsFC7QOhdS7yYmGZlmbSy7/hKbV 1OcecXFZpT1MofeCqmKlG0NLG4qA8cQBkWvHkWijm1nr5FqFEOYOCNqu8IvaaI06Ia 4gungsE66v0kv/gk9jMYpMRdvwnkzlu3zl7OED5FJ3E9iBJR9d4Iq5dGXe6RYNUxRa pgxATN4mio0oo6PiHqQATGkatX4gwDtzcdyNZovSV1tKTT7+7RUugEuDUOk9T9duRq 4ZloYoCfiAnlfVVL0ZE08dAGMsROZasHnuiaXSMNpX8G6XvdG12M4JUNswd5+JYQl8 VYenKl2uMNqnA== From: Pratyush Yadav To: Breno Leitao Cc: Pratyush Yadav , Alexander Graf , Mike Rapoport , Pasha Tatashin , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, usamaarif642@gmail.com, rmikey@meta.com, clm@fb.com, riel@surriel.com, kernel-team@meta.com Subject: Re: [PATCH v2 1/2] kexec: history: track previous kernel version In-Reply-To: (Breno Leitao's message of "Mon, 5 Jan 2026 02:47:39 -0800") References: <20260102-kho-v2-0-1747b1a3a1d6@debian.org> <20260102-kho-v2-1-1747b1a3a1d6@debian.org> <86secn7ors.fsf@kernel.org> Date: Wed, 14 Jan 2026 19:08:19 +0000 Message-ID: <2vxz5x94hv18.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Jan 05 2026, Breno Leitao wrote: > Hello Pratyush, > > On Fri, Jan 02, 2026 at 09:17:27PM +0100, Pratyush Yadav wrote: >> > Subject: [PATCH v2 1/2] kexec: history: track previous kernel version >> >> Nit: please use the prefix "kho: " for KHO patches. > > ack. > >> On Fri, Jan 02 2026, Breno Leitao wrote: >> > Add CONFIG_KEXEC_HISTORY to store and display the kernel version from >> > the previous kexec boot. >> > >> > When enabled, the current kernel's release string is saved to the >> > "previous-release" property in the KHO device tree before kexec. On >> > the next boot, if this property exists, the previous kernel version >> > is retrieved and printed during early boot. >> > >> > This helps diagnose bugs that only manifest when kexecing from >> > specific kernel versions, making it easier to correlate crashes with >> > the kernel that initiated the kexec. >> >> Why can't you use journalctl to figure out which kernel was running >> previously? > > This is a good question, this is why this doesn't work for me: > > 1) in some cases you cannot rely on systemd infrastructure. > - This is very common when you have linux as the boot loader, which > basically boot linux (UEFI -> Bootloader/linux -> kexec -> target linux) > - In these cases, the bootloader doesn't have write access to the > filesyste/journal > - This is becoming more and more common. For instance, at Meta, Linux > is the default bootloader. > > 2) in some of the bugs I've listed earlier, the machine doesn't even get > to userspace before the crash. For instance, in the bug fixed by > commit 77d48d39e991 ("efistub/tpm: Use ACPI reclaim memory for event > log to avoid corruption"), the kernel was not reach userspace/init, > thus, it would not be possible to run journalctl. Ideally, you should have external ways to track the kernel history of each machine in your fleet. But I can see that it might not always exist so I can understand the use case. I have some comments on the implementation though. I'll reply on the latest posting. -- Regards, Pratyush Yadav