At Fri, 30 May 2025 22:26:48 -0400, Chuck Zmudzinski <frchuckz%gmail.com@localhost> wrote: Subject: Re: Xen boot strangeness (Was: Re: [SOLVED] Re: Xen 4.18.5_20250521nb0 not ELF binary (Was: Re: EFI and Xen)) > > I am sure setting bootdev=hd2d will not work. Those are names of > devices the bootloader understands, not the NetBSD kernel. I was thinking the same thing after I posted.... (Which is yet another example of the legacy of bizarre PC magic....) One of my systems with all GPT partitions doesn't show any "hdNa" names for known disks: hw.disknames = cd0 sd0 dk0 dk1 dk2 dk3 dk4 sd1 sd2 cd1 sd3 data-build scratch-scratch vg0-nbtest.root vg0-nbtest.swap vg0-nbtest.var vg0-nbtest.pkg vg0-tinytest vg0-nb10.root vg0-nb10.swap vg0-nb10.var vg0-nb10.pkg vg0-nbday.root vg0-nbday.var vg0-nbday.pkg vg0-nbday.swap vg0-fezzik.0 vg0-fezzik.1 > > Chuck if you have a plain label (not just UUID) on your root partition, > > maybe you could try: > > > > menu=Boot normally with Xen:dev NAME=rootlabel;load /netbsd-XEN3_DOM0.gz -c console=xencons bootdev=wedge:rootlabel;multiboot /xen.gz dom0_mem=2G dom0_max_vcpus=4 com1=9600,8n1,0x40c0,16,1:0.0 console=com1 cet=no-ibt pv-l1tf=false > > I am not sure if it is easy to replace a plain label on a wedge with > a label. I am surprised the NAME=... form of specifying bootdev did > not work. I may have mis-typed or mis-copied the UUID, I don't know. It shouldn't be a problem to add a name label to any GPT partition. gpt -v label -i 1 -l rootlabel /dev/wd2d (I'm not sure the "1" is correct there for your system, or even the "wd2" -- you need to use "gpt show wd2" (or whatever the disk is) to get the actual index number of the partition.) I use just "/" as the label for the root device, as then in /etc/fstab I can mount it with: NAME=/ / ffs rw,log 1 1 > I think that code to search for the boot device when the actual > root partition, whether it was wd0a or wd0e or whatever is given > to the kernel from boot.cfg is not useless in the legacy case. >[[....]] > So that code is *not* useless on systems using a NetBSD disklabel. In the plain legacy BIOS system case for GENERIC kernels it is of course useful. However for any system running a XEN_DOM0 kernel, including a legacy system, it is unnecessary and confusing. Note that getting rid of it from the XEN_DOM0 kernel could entail needing to add support for a "dumpdev=" kernel command-line option, though that would be secondary if there were support to configure a dump device after boot. FreeBSD has had a dumpon(8) utility since 2.0.5. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpFGvnFwiFUK.pgp
Description: OpenPGP Digital Signature