NetBSD Problem Report #60960

From www@netbsd.org  Wed Nov  4 09:29:21 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1CC991A923B
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  4 Nov 2026 09:29:21 +0000 (UTC)
Message-Id: <20261104092919.92EA41A923C@mollari.NetBSD.org>
Date: Wed,  4 Nov 2026 09:29:19 +0000 (UTC)
From: el@horse64.org
Reply-To: el@horse64.org
To: gnats-bugs@NetBSD.org
Subject: It would be nice to make it easier to know what ramdisk-cgdroot.fs file belongs to which kernel
X-Send-Pr-Version: www-1.0
X-From4GNATS: "el@horse64.org via gnats" <gnats-admin@NetBSD.org>

>Number:         60960
>Category:       install
>Synopsis:       It would be nice to make it easier to know what ramdisk-cgdroot.fs file belongs to which kernel
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    install-manager
>State:          open
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 04 09:30:00 +0000 2026
>Originator:     Ellie
>Release:        11.0
>Organization:
>Environment:
NetBSD ruby-b-s-delly 11.0_STABLE NetBSD 11.0_STABLE (GENERIC) #0: Fri Oct 30 19:02:53 UTC 2026  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
(My apologies if this is the wrong category.)

Sorry if I'm just misunderstanding again, but after playing with sysupgrade auto for a bit, I realized it would be nice to make it easier to know what ramdisk-cgdroot.fs file belongs to which kernel.

It seems like sysupgrade auto doesn't really display what it's upgrading to, it seems to be some daily thing but it's not clear to me if this is 11.0 or 11.1, and it didn't seem to update /etc/release for some reaosn (maybe user error on my end).

In any case, this has left me unsure if I need to update my ramdisk-cgdroot.fs file, and what to.

>How-To-Repeat:
I mean it's not really a problem, but all that needs to happen is you need to be unsure what exact kernel or release sysupgrade auto has left you on.

It also seems to me like it wouldn't be obvious to newcomers from linux that things inside the EFI partition need to be manually updated.
>Fix:
I filed this as a change request since I'm not sure what's the best solution to this anyway, but I can think of two ways to fix this:

1. One solution to this might be actually be to establish the EFI partition being mounted in a known location, for example /efi seems to be common, and to make sysupgrade auto simply copy the new kernel and new ramdisk there without requiring me to do it.

2. Or alternatively, the ramdisk could just be part of some folder of the regular root filesystem, like /netbsd just sits around in the root, where sysupgrade auto can update it along with the kernel. Then the user might know it corresponds to their currently installed kernel.

Home	PR Database Search