| View previous topic :: View next topic |
| Author |
Message |
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
 Posted: Fri Jan 26, 2024 3:36 am Post subject: [SOLVED]Where To Post re: vmlinuz-6.6.13-gentoo |
 |
|
[START EDIT 1/29/24]
Beware that the topic started off focusing on LVM when, in fact, it should have been focused on Xen's block devices. With that confusion, read with care what follows as the problem ended up being that the kernel did not provision for Xen block devices for the guest domain.
[END EDIT 1/29/24]
I run a Xen based server and use LVM.
| Code: | snucDom0 /etc/xen # eix xen -I
[I] app-emulation/xen
Available versions: 4.16.6_pre1^st 4.16.6_pre2^st ~4.17.3_pre1^st ~4.17.3^st {+boot-symlinks debug flask secureboot uefi}
Installed versions: 4.16.6_pre2^st(11:33:41 AM 01/25/2024)(boot-symlinks -debug -flask -uefi)
Homepage: https://xenproject.org
Description: The Xen virtual machine monitor
[I] app-emulation/xen-tools
Available versions: 4.15.4-r1(0/4.15)^t[1] ~4.16.3(0/4.16)^t[1] 4.16.6_pre1(0/4.16)^t 4.16.6_pre1-r1(0/4.16)^t 4.16.6_pre2(0/4.16)^t ~4.17.3_pre1(0/4.17)^t ~4.17.3_pre1-r1(0/4.17)^t ~4.17.3(0/4.17)^t {api debug doc +hvm +ipxe lzma ocaml ovmf pygrub python +qemu +qemu-traditional +rombios screen sdl selinux static-libs system-ipxe system-qemu system-seabios systemd zstd PYTHON_SINGLE_TARGET="(+)python3_10 python3_11"}
Installed versions: 4.16.6_pre2(0/4.16)^t(11:22:46 AM 01/25/2024)(hvm ipxe ovmf python qemu qemu-traditional rombios -api -debug -doc -lzma -ocaml -pygrub -screen -sdl -selinux -static-libs -system-ipxe -system-qemu -system-seabios -systemd -zstd PYTHON_SINGLE_TARGET="python3_11 -python3_10")
Homepage: https://xenproject.org
Description: Xen tools including QEMU and xl
[1] "localrepo" /var/db/repos/localrepo
Found 2 matches
snucDom0 /etc/xen # |
Today, I upgraded my kernel from vmlinuz-6.1.57-gentoo-x86_64 to vmlinuz-6.6.13-gentoo. Dom0 works fine, lvm works and the mappings duly appear. If I launch a DomU which shares the same kernel, e.g. vmlinuz-6.1.57-gentoo-x86_64, the logical volumes specified in my configuration files are duly found an mapped and the guest domain launches.
If I simply rem out the old kernel/initramfs at lines 3 & 4 below and actives lines 12 & 13, my boot process fails stating it cannot find specified root, e.g. /dev/xvda3.
| Code: | 1 #
2 # 1/24/2024 jlpoole: upgraded kernel to 6.6.13
3 #
4 kernel = "/boot/vmlinuz-6.1.57-gentoo-x86_64"
5 ramdisk = "/boot/initramfs-6.1.57-gentoo-x86_64.img"
6
7 #snucDom0 /etc/xen # ls -la /boot/*6.6*-gentoo*
8 #-rw-r--r-- 1 root root 13615144 Jan 25 11:01 /boot/initramfs-6.6.13-gentoo.img
9 #-rw-r--r-- 1 root root 6349874 Jan 25 10:04 /boot/System.map-6.6.13-gentoo
10 #-rw-r--r-- 1 root root 11756192 Jan 25 10:05 /boot/vmlinuz-6.6.13-gentoo
11 #snucDom0 /etc/xen #
12 #kernel = "/boot/vmlinuz-6.6.13-gentoo"
13 #ramdisk = "/boot/initramfs-6.6.13-gentoo.img"
14 |
The new kernel has LVM built in, that's indicated by the fact that Dom0 has lvm running and the volumes all show up. So switching between the two kernel/initramfs above results in the logical volumes not being found. I figured it must be an initramfs, so I rebuilt the initramfs:
| Code: | snucDom0 /etc/xen # date; time genkernel --lvm --install initramfs # after LVM="yes" modification in /etc/genkernel.conf
Thu Jan 25 04:56:13 PM PST 2024
* Gentoo Linux Genkernel; Version 4.3.10
* Using genkernel configuration from '/etc/genkernel.conf' ...
* Running with options: --lvm --install initramfs
* Working with Linux kernel 6.6.13-gentoo for x86_64
* Using kernel config file '/etc/kernels/kernel-config-6.6.13-gentoo' ...
* Current kernel's LOCALVERSION is set to ''; Will ignore set --kernel-localversion value '-x86_64' because kernel was not built ...
* initramfs: >> Initializing ...
* >> Appending devices cpio data ...
* >> Appending base_layout cpio data ...
* >> Appending util-linux cpio data ...
* >> Appending eudev cpio data ...
* >> Appending devicemanager cpio data ...
* >> Appending auxiliary cpio data ...
* >> Appending busybox cpio data ...
* >> Appending lvm cpio data ...
* >> Appending modprobed cpio data ...
* >> Appending modules cpio data ...
* >> Deduping cpio ...
* >> Pre-generating initramfs' /etc/ld.so.cache ...
* >> Compressing cpio data (.xz) ...
xz: Reduced the number of threads from 16 to 1 to not exceed the memory usage limit of 1912 MiB
*
* You will find the initramfs in '/boot/initramfs-6.6.13-gentoo.img'.
* WARNING... WARNING... WARNING...
* Additional kernel parameters that *may* be required to boot properly:
* - Add "dolvm" for LVM support
* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
*
* Make sure you have the latest ~arch genkernel before reporting bugs.
real 0m57.325s
user 0m44.903s
sys 0m13.200s
snucDom0 /etc/xen # |
Here's the pertinent part from the DomU boot:
| Code: | [ 2.552197] Run /init as init process
>> Genkernel 4.3.10 (2024-01-26 00:56:17 UTC). Linux kernel 6.6.13-gentoo
>> Activating udev ...
>> Scanning for volume groups ...
Reading all physical volumes. This may take a while...
>> Activating volume groups ...
>> Determining root device (trying /dev/xvda3) ........
!! Block device /dev/xvda3 is not a valid root device ...
!! Could not find the root block device in /dev/xvda3.
!! Please specify another value or:
!! - press Enter for the same
!! - type "shell" for a shell
!! - type "q" to skip ... |
Something lingers in my mind and introducing some time for lvm to catch up, but my searches for "delay" or "sleep" on command parameters is coming up empty.
I'm not sure where this should be posting, so I'm posting in this forum with the hope a moderator will re-assign as appropriate. Then I'm wondering if there is a bug afoot, or if there is something I can do to get around the problem.
[Edited: 1/26/24: corrected typo of "initramfs"]
Last edited by jlpoole on Mon Jan 29, 2024 6:45 pm; edited 2 times in total |
|
| Back to top |
|
 |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5118
Location: Bavaria
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5118
Location: Bavaria
|
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Fri Jan 26, 2024 6:30 pm Post subject: |
|
|
Thank you, pietinger. For your "see also" referencing Initramfs_kernel_command-line_parameters, yes, that is why in my initial posting I showed that I have specified "lvm" in the creation of the initramfs -- moreover, the initramfs works... with the 6.1 kernel and Dom0 with a 6.6 kernel.
My DomU configuration file does contain and has always contained the "dolvm" kernel parameter which remains static:
| Code: |
snucDom0 /etc/xen # date; head -n 37 ares.conf|nl|tail -n 2
Fri Jan 26 10:02:12 AM PST 2024
32 root = "/dev/xvda3 dolvm ro "
snucDom0 /etc/xen # |
Again, with the DomU configuration file specifying the 6.1 kernel, lvm works. But with the same DomU configuration file specifying the 6.6 kernel, lvm does not appear to be working. And, the same kernel and initramfs are used to successfully launch Dom0 where lvm is working. Maybe there is some sort of delay needed, perhaps to let lvm comple an inventory of all volumes? I cannot determine what package a Gentoo bug about this disparity might be filed under: 1) Xen, 2) LVM, or 3) Genkernel. My best guess is this might be an issue which should go to the Xen development community.
I thought the purpose of the initramfs was to ready things like hard drives and lvm volumes so when the kernel is loaded, they are found by the kernel referencing the local instances /etc/fstab file. It seems that when I specify the 6.6 kernel, that preparation, e.g. finding the lvm volume to expose as /dev/xvda3, is not working. I recall some sort of problem before with lvm and that before loading a kernel, some delay may be necessary to allow lvm to take inventory. But, again, the confounding part is simply switching kernels breaks the lvm reporting of what's available. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22673
|
| Posted: Fri Jan 26, 2024 7:12 pm Post subject: |
|
|
xvda3 does not appear to be an LVM device name, so it looks to me like failing to find /dev/xvda3 is not related to the success or failure of LVM discovery. xvda3 is a typical name for a Xen paravirtual block device.
Strictly speaking, the kernel must be loaded before the initramfs does anything, since the initramfs is run on the kernel. The purpose of an initramfs in typical context is to mount the root filesystem, then transfer control to the init system (systemd, openrc+sysvinit, etc.). Mounting the root filesystem could require discovering and activating LVM volumes, unlocking encrypted devices, assembling RAID devices, etc. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Fri Jan 26, 2024 7:19 pm Post subject: |
|
|
| Hu wrote: | xvda3 does not appear to be an LVM device name, so it looks to me like failing to find /dev/xvda3 is not related to the success or failure of LVM discovery. xvda3 is a typical name for a Xen paravirtual block device.
Strictly speaking, the kernel must be loaded before the initramfs does anything, since the initramfs is run on the kernel. The purpose of an initramfs in typical context is to mount the root filesystem, then transfer control to the init system (systemd, openrc+sysvinit, etc.). Mounting the root filesystem could require discovering and activating LVM volumes, unlocking encrypted devices, assembling RAID devices, etc. |
Thank you, Hu. Do you have thoughts as to which package I might log a bug under for this problem. Remember: the only difference between the what works vs. the inability to find /dev/xvda3 is the specification of the kernel/initramfs for 6.6 - 2 line modification to an otherwise working DomU configuration (which I have used for years). I'm happy to provide me detailed disclosures in the bug database issue rather than on a forum. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22673
|
| Posted: Fri Jan 26, 2024 7:45 pm Post subject: |
|
|
| I have no strong advice as to which package to pick. I would like to know, and expect the bug triage responder to also want, whether the problem is that (1) no xvd* devices are created ever, (2) the device is created with the wrong name, (3) the device is created too late. Dropping to an interactive shell after root fails to mount and inspecting /dev might address some of this. It may also be useful to know whether the initramfs used in the two kernels is the same, and if not, how it differs. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Fri Jan 26, 2024 11:50 pm Post subject: |
|
|
| Hu wrote: | | I have no strong advice as to which package to pick. I would like to know, and expect the bug triage responder to also want, whether the problem is that (1) no xvd* devices are created ever, (2) the device is created with the wrong name, (3) the device is created too late. Dropping to an interactive shell after root fails to mount and inspecting /dev might address some of this. It may also be useful to know whether the initramfs used in the two kernels is the same, and if not, how it differs. |
I, too, had the same question about what is appearing under /dev, so the first time I ran into this error, I dropped into the shell and saw no xvd*s. Unfortunately, I did not note the date and time, so I am re-ran it here with "-vvvv" on the xen create command.
| Code: | 1045 [ 2.557100] Run /init as init process
1046 >> Genkernel 4.3.10 (2024-01-26 00:56:17 UTC). Linux kernel 6.6.13-gentoo
1047 >> Activating udev ...
1048 >> Scanning for volume groups ...
1049 Reading all physical volumes. This may take a while...
1050 >> Activating volume groups ...
1051 >> Determining root device (trying /dev/xvda3) ........
1052 !! Block device /dev/xvda3 is not a valid root device ...
1053 !! Could not find the root block device in /dev/xvda3.
1054 !! Please specify another value or:
1055 !! - press Enter for the same
1056 !! - type "shell" for a shell
1057 !! - type "q" to skip ...
1058 root block device(/dev/xvda3) :: shell
1059 ** To leave and try again just press <Ctrl>+D
1060
1061 Generating "/run/initramfs/gksosreport.txt" ...
1062 >> You might want to save "/run/initramfs/gksosreport.txt" to a USB stick or /boot
1063 >> after mounting them and attach it to a bug report.
1064
1065 >> Welcome to Genkernel 4.3.10 (2024-01-26 00:56:17 UTC) rescue shell!
1066 >> ...running Linux kernel 6.6.13-gentoo
1067
1068 rescueshell ~ # ls /dev
1069 autofs tty11 tty44 ttyS19
1070 char tty12 tty45 ttyS2
1071 console tty13 tty46 ttyS20
1072 core tty14 tty47 ttyS21
1073 cpu_dma_latency tty15 tty48 ttyS22
1074 dma_heap tty16 tty49 ttyS23
1075 fd tty17 tty5 ttyS24
1076 full tty18 tty50 ttyS25
1077 hvc0 tty19 tty51 ttyS26
1078 hvc1 tty2 tty52 ttyS27
1079 hvc2 tty20 tty53 ttyS28
1080 hvc3 tty21 tty54 ttyS29
1081 hvc4 tty22 tty55 ttyS3
1082 hvc5 tty23 tty56 ttyS30
1083 hvc6 tty24 tty57 ttyS31
1084 hvc7 tty25 tty58 ttyS4
1085 hwrng tty26 tty59 ttyS5
1086 input tty27 tty6 ttyS6
1087 kmsg tty28 tty60 ttyS7
1088 mapper tty29 tty61 ttyS8
1089 mcelog tty3 tty62 ttyS9
1090 mem tty30 tty63 udmabuf
1091 null tty31 tty7 urandom
1092 port tty32 tty8 usbmon0
1093 ptmx tty33 tty9 userfaultfd
1094 pts tty34 ttyS0 vcs
1095 random tty35 ttyS1 vcs1
1096 shm tty36 ttyS10 vcsa
1097 snapshot tty37 ttyS11 vcsa1
1098 stderr tty38 ttyS12 vcsu
1099 stdin tty39 ttyS13 vcsu1
1100 stdout tty4 ttyS14 vga_arbiter
1101 tty tty40 ttyS15 xen
1102 tty0 tty41 ttyS16 zero
1103 tty1 tty42 ttyS17
1104 tty10 tty43 ttyS18
1105 rescueshell ~ # xencall:buffer: debug: total allocations:177 total releases:177 |
The more-detailed source of the above is at https://pastebin.com/kjSB94PV which will disappear in 1 month and is a private link. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22673
|
| Posted: Sat Jan 27, 2024 12:20 am Post subject: |
|
|
| That seems more like the 6.6 Xen guest kernel does not create Xen virtual block devices. Have you verified that the guest kernel is configured to support Xen virtual block devices? Please pastebin your kernel configuration for the Xen guest. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Sat Jan 27, 2024 2:21 am Post subject: |
|
|
| Hu wrote: | | That seems more like the 6.6 Xen guest kernel does not create Xen virtual block devices. Have you verified that the guest kernel is configured to support Xen virtual block devices? Please pastebin your kernel configuration for the Xen guest. |
All I am trying to do here is upgrade my kernel from 6.1.57 to 6.6.13 for this Gentoo Xen based server. I have three principal instances: a hypervisor, Dom0, and two guest VMs, aka DomUs. The DomUs rely solely on lvm.
Here is the 6.6.13 kernel .config file: https://pastebin.com/Sz0k1fyX . The kernel is used for both Dom0 and DomUs, it's a single-kernel-serves-all Gentoo instances set-up. The problem here is lvm is not working on the DomU startup.
For contrast, here is the latest version of the previous kernel, 6.1.57: https://pastebin.com/0cxNXTzt This 6.1.57 kernel, too, was used successfully for Dom0 [hypervisor] and Gentoo DomUs. LVM works for both Dom0 and the DomUs.
For this Gentoo Xen box the kernel version used previous to 6.1.57 was 5.4.92 and I think I had to go through kernel config process for Xen and/or possibly LVM in creating the 6.1.57 kernel since I did not expect using the 5.4.92 configuration file would work in a 6.1.57 build. For the 6.6.13, I relied on genkernel to reference the last 6.1.57 build. So, Hu, if your hunch is correct, then genkernel, or my reliance thereon in a build between 6.1 and 6.6, may be the culprit here. I am not aware of a different treatment of the Dom0 instance vs. DomU in terms of lvm. I have been working under the assumption that if Dom0 can utilize lvm, then a DomU running on the same kernel can, too. I have not undertaken a comparison between the 6.1.57 and 6.6.13, but I will do so and see if there are certain provisions for guest domain's ability to access lvm. Good idea! Thank you. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1921
|
| Posted: Sat Jan 27, 2024 2:34 am Post subject: |
|
|
| Code: | | CONFIG_XEN_BLKDEV_FRONTEND=m |
How have you configured genkernel's initramfs to include this module? It doesn't look like it will by default.
e.g. AMODULES_BLOCK="xen-blkfront" to genkernel.conf |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Sat Jan 27, 2024 2:37 am Post subject: Kernel Diffs |
|
|
I diff'd the two kernels: https://pastebin.com/P1UgEGfv
There are some noteworthy differences:
| Code: |
line 156
CONFIG_BLK_DEV_NBD=y | CONFIG_BLK_DEV_NBD=m
CONFIG_XEN_BLKDEV_FRONTEND=y | CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=y | CONFIG_XEN_BLKDEV_BACKEND=m
|
I think this may be the problem and i see that grnight has zeroed in on the difference, too. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Sat Jan 27, 2024 2:39 am Post subject: |
|
|
| grknight wrote: | | Code: | | CONFIG_XEN_BLKDEV_FRONTEND=m |
How have you configured genkernel's initramfs to include this module? It doesn't look like it will by default.
e.g. AMODULES_BLOCK="xen-blkfront" to genkernel.conf |
I did not do anything to configure initramfs other than specify "lvm" on the command line. We're getting close. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1921
|
| Posted: Sat Jan 27, 2024 2:41 am Post subject: |
|
|
FWIW, the kernel's scripts/diffconfig script (in any kernel source) is *very* nice to easily spot this kind of thing even if they appear on different lines as options can shift where diff cannot see |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Sat Jan 27, 2024 2:44 am Post subject: |
|
|
| grknight wrote: | | Code: | | CONFIG_XEN_BLKDEV_FRONTEND=m |
How have you configured genkernel's initramfs to include this module? It doesn't look like it will by default.
e.g. AMODULES_BLOCK="xen-blkfront" to genkernel.conf |
For posterity, here is the /etc/genkernel.conf I currently have and what the kernels are based on:
| Code: | snucDom0 /home/jlpoole/test/kernels # date; cat -n /etc/genkernel.conf
Fri Jan 26 06:42:33 PM PST 2024
1 # Configuration file for genkernel
2
3 # This file is sourced by genkernel at startup and determines which options
4 # we will be using to compile our kernel. The order of precidence is simple,
5 # with the internal settings being least important, configuration file
6 # settings next, and command line options being most important.
7
8 # =========COMMON COMMAND LINE OPTION DEFAULTS=========
9
10 # Install to $BOOTDIR
11 #INSTALL="yes"
12
13 # Run 'make oldconfig' before compiling this kernel
14 #OLDCONFIG="yes"
15
16 # Run 'make menuconfig' before compiling this kernel
17 #MENUCONFIG="no"
18
19 # Run 'make gconfig' before compiling this kernel
20 #GCONFIG="no"
21
22 # Run 'make nconfig' (ncurses 'menuconfig') before compiling this kernel
23 #NCONFIG="no"
24
25 # Run 'make xconfig' before compiling this kernel
26 #XCONFIG="no"
27
28 # Run 'make mrproper' before compiling this kernel
29 #MRPROPER="yes"
30
31 # Run 'make clean' before compiling this kernel
32 # Only needed if MRPROPER is set to NO because
33 # MRPROPER implies 'make clean'.
34 #CLEAN="yes"
35
36 # Mount BOOTDIR automatically if it isn't mounted
37 #MOUNTBOOT="yes"
38
39 # Make symlinks in BOOTDIR automatically
40 #SYMLINK="no"
41
42 # Save the new configuration in /etc/kernels upon
43 # successful compilation
44 #SAVE_CONFIG="yes"
45
46 # Enable color output in genkernel
47 NOCOLOR="false"
48
49 # Clear build cache dir on gernkernel start
50 #CLEAR_CACHEDIR="no"
51
52 # Clear all tmp files and caches after genkernel has run
53 #POSTCLEAR="no"
54
55 # Check for x MB free disk space in BOOTDIR
56 #CHECK_FREE_DISK_SPACE_BOOTDIR=0
57
58 # Check for x MB free disk space in kernel outputdir
59 #CHECK_FREE_DISK_SPACE_KERNELOUTPUTDIR=0
60
61 # Genkernel uses an independent configuration for MAKEOPTS, and does not source
62 # /etc/portage/make.conf . You can override the default setting by uncommenting
63 # and tweaking the following line. Default setting is set up by
64 # ${GK_SHARE}/${ARCH_OVERRIDE}/config.sh . The recommended value for -j
65 # argument is: <number of processors>*<number of cores per processor>+1
66 #MAKEOPTS="$(portageq envvar MAKEOPTS)"
67
68 # Run the kernel make at the following NICE level
69 #NICE=10
70
71 # Add bcache support
72 #BCACHE="no"
73
74 # Add LVM support
75 #LVM="no"
76 #
77 # 1/24/2024 jlpoole: Migration to kernel 6.6 caused xvga drive not to show
78 #
79 LVM="yes"
80
81 # Add LUKS support
82 #LUKS="no"
83
84 # Add GnuPG support
85 #GPG="no"
86
87 # Add keyctl support for loading LUKS passphrase into a keyring
88 #KEYCTL="no"
89
90 # Add in early microcode support: this sets the kernel options for early microcode loading
91 # Possible values: empty/"no", "all", "intel", "amd"
92 #MICROCODE="all"
93
94 # Include early microcode in generated initramfs.
95 # Only needed if system cannot load multiple initramfs.
96 # NOTE: >=sys-boot/grub-2 will detect and auto-load {amd,intel}-uc.img file
97 # provided by sys-firmware/intel-microcode[initramfs] or
98 # sys-kernel/linux-firmware[initramfs].
99 #MICROCODE_INITRAMFS="no"
100
101 # Add NFS support
102 #NFS="no"
103
104 # Add DMRAID support
105 #DMRAID="no"
106
107 # Add SSH support
108 #SSH="no"
109
110 # Add b2sum support
111 #B2SUM="no"
112
113 # Include busybox in the initramfs. If included, busybox is rebuilt
114 # if the cached copy is out of date.
115 #BUSYBOX="yes"
116
117 # Add MDRAID support
118 #MDADM="no"
119
120 # Specify a custom mdadm.conf.
121 # By default the initramfs will be built *without* an mdadm.conf and will auto-detect
122 # arrays during bootup. Usually, this should not be needed.
123 #MDADM_CONFIG="/etc/mdadm.conf"
124
125 # Add Multipath support
126 #MULTIPATH="no"
127
128 # Add iSCSI support
129 #ISCSI="no"
130
131 # Add e2fsprogs support
132 #E2FSPROGS="no"
133
134 # Include support for unionfs
135 #UNIONFS="no"
136
137 # Include support for zfs volume management. If unset, genkernel will attempt
138 # to autodetect and enable this when rootfs is on zfs.
139 #ZFS="no"
140
141 # Add BTRFS support
142 #BTRFS="no"
143
144 # Add xfsprogs support
145 #XFSPROGS="no"
146
147 # Install firmware onto root filesystem
148 # Will conflict with sys-kernel/linux-firmware package
149 #FIRMWARE_INSTALL="no"
150
151 # Include full contents of FIRMWARE_DIR
152 # (if FIRMWARE option below is set to YES).
153 #ALLFIRMWARE="no"
154
155 # Add firmware(s) to initramfs required by copied modules
156 #FIRMWARE="no"
157
158 # Specify directory to pull from
159 #FIRMWARE_DIR="/lib/firmware"
160
161 # Specify a comma-separated list of firmware files or directories to include,
162 # relative to FIRMWARE_DIR (if FIRMWARE option above is set to YES
163 # and ALLFIRMWARE is set to NO).
164 #FIRMWARE_FILES=""
165
166 # Add new kernel to grub
167 # Possible values: empty/"no", "grub", "grub2"
168 #BOOTLOADER="no"
169
170 # Use sandbox when building initramfs
171 #SANDBOX="yes"
172
173 # Embed and set font early on boot
174 # Possible values: empty/"none", "current", <PSF file>
175 #BOOTFONT="none"
176
177 # Add boot splash using splashutils
178 #SPLASH="no"
179
180 # Use this splash theme. If commented out - the "default" name theme is used.
181 # Also, SPLASH="yes" needs to be enabled for this one to work.
182 # This supersedes the "SPLASH_THEME" option in '/etc/conf.d/splash'.
183 #SPLASH_THEME="gentoo"
184
185 # Includes or excludes Plymouth from the initramfs. If "splash" is
186 # passed at boot, Plymouth will be activated.
187 #PLYMOUTH="no"
188
189 # Embeds the given plymouth theme in the initramfs.
190 #PLYMOUTH_THEME="text"
191
192 # Run "emerge @module-rebuild" automatically when possible and necessary
193 # after kernel and modules have been compiled
194 #MODULEREBUILD="yes"
195
196 # Run the specified command in the current environment after the kernel and
197 # modules have been compiled, useful to rebuild external kernel module
198 # (see MODULEREBUILD above) or installing additional
199 # files (use 'copy_image_with_preserve dtb path/to/dtb dtb <kernelname>')
200 #CMD_CALLBACK=""
201
202
203 # =========KEYMAP SETTINGS=========
204 #
205 # Force keymap selection at boot
206 #DOKEYMAPAUTO="no"
207
208 # Enables keymap selection support
209 #KEYMAP="yes"
210
211
212 # =========LOW LEVEL COMPILE SETTINGS=========
213 #
214 # Assembler to use for the kernel. See also the --kernel-as command line
215 # option.
216 #KERNEL_AS="as"
217
218 # Archiver to use for the kernel. See also the --kernel-ar command line
219 # option.
220 #KERNEL_AR="ar"
221
222 # Compiler to use for the kernel (e.g. distcc). See also the --kernel-cc
223 # command line option.
224 #KERNEL_CC="gcc"
225
226 # Linker to use for the kernel. See also the --kernel-ld command line option.
227 #KERNEL_LD="ld"
228
229 # NM utility to use for the kernel. See also the --kernel-nm command line option.
230 #KERNEL_NM="nm"
231
232 # GNU Make to use for kernel. See also the --kernel-make command line option.
233 #KERNEL_MAKE="make"
234
235 # objcopy utility to use for the kernel. See also the --kernel-objcopy command
236 # line option.
237 #KERNEL_OBJCOPY="objcopy"
238
239 # objdump utility to use for the kernel. See also the --kernel-objdump command
240 # line option.
241 #KERNEL_OBJDUMP="objdump"
242
243 # ranlib utility to use for the kernel. See also the --kernel-ranlib command
244 # line option.
245 #KERNEL_RANLIB="ranlib"
246
247 # readelf utility to use for the kernel. See also the --kernel-readelf command
248 # line option.
249 #KERNEL_READELF="readelf"
250
251 # strip utility to use for the kernel. See also the --kernel-strip command line
252 # option.
253 #KERNEL_STRIP="strip"
254
255 # Assembler to use for the utilities. See also the --utils-as command line
256 # option.
257 #UTILS_AS="as"
258
259 # Archiver to use for the utilities. See also the --utils-ar command line
260 # option.
261 #UTILS_AR="ar"
262
263 # C Compiler to use for the utilities (e.g. distcc). See also the --utils-cc
264 # command line option.
265 #UTILS_CC="gcc"
266
267 # C++ Compiler to use for the utilities (e.g. distcc). See also the --utils-cxx
268 # command line option.
269 #UTILS_CXX="g++"
270
271 # Linker to use for the utilities. See also the --utils-ld command line
272 # option.
273 #UTILS_LD="ld"
274
275 # NM utility to use for the utilities. See also the --utils-nm command line option.
276 #UTILS_NM="nm"
277
278 # GNU Make to use for the utilities. See also the --utils-make command line
279 # option.
280 #UTILS_MAKE="make"
281
282 # Target triple (i.e. aarch64-linux-gnu) to build for. If you do not
283 # cross-compile, leave blank for auto detection.
284 #CROSS_COMPILE=""
285
286 # Target triple (i.e. aarch64-linux-gnu) to build kernel for. Utilities will be
287 # built for the native target, not this target. If you do not cross-compile,
288 # leave blank.
289 #KERNEL_CROSS_COMPILE=""
290
291 # Override default make target (bzImage). See also the --kernel-target
292 # command line option. Useful to build a uImage on arm.
293 #KERNEL_MAKE_DIRECTIVE_OVERRIDE="fooImage"
294
295 # Override default kernel binary path. See also the --kernel-binary
296 # command line option. Useful to install a uImage on arm.
297 #KERNEL_BINARY_OVERRIDE="arch/foo/boot/bar"
298
299
300 # =========GENKERNEL LOCATION CONFIGURATION=========
301 #
302 # Variables:
303 # %%ARCH%% - Final determined architecture
304 # %%CACHE%% - Final determined cache location
305
306 # Set genkernel's temporary work directory
307 #TMPDIR="/var/tmp/genkernel"
308
309 # Set the boot directory, default is /boot
310 #BOOTDIR="/boot"
311
312 # Default share directory location
313 GK_SHARE="${GK_SHARE:-/usr/share/genkernel}"
314
315 # Location of the default cache
316 CACHE_DIR="/var/cache/genkernel"
317
318 # Location of DISTDIR, where our source tarballs are stored
319 DISTDIR="${GK_SHARE}/distfiles"
320
321 # Log output file
322 LOGFILE="/var/log/genkernel.log"
323
324 # Debug Level
325 LOGLEVEL=1
326
327
328 # =========COMPILED UTILS CONFIGURATION=========
329 #
330 # Default location of kernel source
331 DEFAULT_KERNEL_SOURCE="/usr/src/linux"
332
333 # Default kernel config (only use to override using
334 # arch/%%ARCH%%/kernel-config-${VER}.${PAT} !)
335 #DEFAULT_KERNEL_CONFIG="${GK_SHARE}/arch/%%ARCH%%/kernel-config"
336
337 # Specifies a user created busybox config
338 #BUSYBOX_CONFIG="/path/to/file"
339
340 # NOTE: Since genkernel 3.4.41 the version of
341 # busybox, lvm, mdadm, ... have been moved to
342 # /usr/share/genkernel/defaults/software.sh in order to
343 # reduce the merging you have to do during etc-update.
344 # You can still override these settings in here.
345
346
347 # =========MISC KERNEL CONFIGURATION=========
348 #
349 # Set kernel filename which will be used when kernel will be installed
350 # into BOOTDIR. See man page to learn more about available placeholders.
351 #KERNEL_FILENAME="vmlinuz-%%KV%%"
352
353 # Set kernel symlink name which will be used when kernel will be installed
354 # into BOOTDIR and SYMLINK option is enabled
355 #KERNEL_SYMLINK_NAME="kernel"
356
357 # This option will set kernel option CONFIG_LOCALVERSION.
358 # Use special value "UNSET" to unset already set CONFIG_LOCALVERSION.
359 #KERNEL_LOCALVERSION="-%%ARCH%%"
360
361 # This option is only valid if kerncache is
362 # defined. If there is a valid kerncache no checks
363 # will be made against a kernel source tree.
364 #KERNEL_SOURCES="yes"
365
366 # Build a static (monolithic kernel)
367 #BUILD_STATIC="no"
368
369 # Make and install kernelz image (PowerPC)
370 #GENZIMAGE="no"
371
372 # Archive file created using tar containing kernel binary, content
373 # of /lib/modules and the kernel config.
374 # NOTE: Archive is created before the callbacks are run!
375 #KERNCACHE="/path/to/file.tar.xz"
376
377 # Prefix to kernel module destination, modules
378 # will be installed in <prefix>/lib/modules
379 #KERNEL_MODULES_PREFIX=""
380
381
382 # =========MISC INITRAMFS CONFIGURATION=========
383 #
384 # Set initramfs filename which will be used when initramfs will be
385 # installed into BOOTDIR. See man page to learn more about available
386 # placeholders.
387 #INITRAMFS_FILENAME="initramfs-%%KV%%.img"
388
389 # Set initramfs symlink name which will be used when initramfs will be
390 # installed into BOOTDIR and SYMLINK option is enabled
391 #INITRAMFS_SYMLINK_NAME="initramfs"
392
393 # Copy all compiled kernel modules to the initramfs
394 #ALLRAMDISKMODULES="no"
395
396 # Copy selected modules to the initramfs based on arch-specific modules_load file
397 #RAMDISKMODULES="yes"
398
399 # Archive file created using tar containing kernel and initramfs.
400 # NOTE: No modules outside of the initramfs will be included!
401 #MINKERNPACKAGE="/path/to/file.tar.xz"
402
403 # Add additional modules to the initramfs using the module groups defined
404 # in /usr/share/genkernel/defaults/modules_load (see this file for
405 # more details). This would be used if, for example, you
406 # required an additional crypto module or network device at boot
407 # time and did not want to statically compile these in the kernel.
408 # Options take the form AMODULES_{group} where {group} is one of
409 # the groups in modules_load (which are in the form MODULES_{group}).
410 # Use this with caution.
411 #AMODULES_group="module-to-include another-module"
412
413 # Override the default modules in the initramfs, for a given group, as defined by
414 # /usr/share/genkernel/defaults/modules_load and the per-arch modules_load
415 # files. You PROBABLY want to use AMODULES_* above, and NOT MODULES_* here.
416 # If you use MODULES_* here, the default and per-arch modules will NOT be used.
417 #MODULES_group1="some-module"
418 #MODULES_group2="" # Load no modules for this group
419
420 # Override the default used linuxrc script.
421 #LINUXRC="/path/to/custom/linuxrc"
422
423 # Archive file created using tar containing modules after
424 # the callbacks have run
425 #MODULESPACKAGE="/path/to/file.tar.xz"
426
427 # Directory structure to include in the initramfs,
428 # only available on >=2.6 kernels
429 #INITRAMFS_OVERLAY=""
430
431 # Build the generated initramfs into the kernel instead of
432 # keeping it as a separate file
433 #INTEGRATED_INITRAMFS="no"
434
435 # Compress generated initramfs
436 #COMPRESS_INITRD="yes"
437
438 # Types of compression: best, xz, lzma, bzip2, gzip, lzop, lz4, zstd, fastest
439 # "best" selects the best available compression method
440 # "fastest" selects the fastest available compression method
441 #COMPRESS_INITRD_TYPE="best"
442
443 # wrap initramfs using mkimage for u-boot bootloader
444 # WRAP_INITRD=no
445
446 # Create a self-contained env in the initramfs
447 #NETBOOT="no"
448
449
450 # =========MISC BOOT CONFIGURATION=========
451 #
452 # Specify a default for real_root=
453 #REAL_ROOT="/dev/one/two/gentoo"
snucDom0 /home/jlpoole/test/kernels #
|
|
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Sat Jan 27, 2024 2:49 am Post subject: |
|
|
| grknight wrote: |
FWIW, the kernel's scripts/diffconfig script (in any kernel source) is *very* nice to easily spot this kind of thing even if they appear on different lines as options can shift where diff cannot see |
Thank you! I did not know of this more intelligent tool.
Here's my plan:
I'm going to reconfigure the 6.6 kernel to build in the LVM support on XEN. My goal will be to make the Diffs relating to xen and/or lvm disappear by making the 6.6 contain everything as the 6.1.57 did.
Lesson learned: migration of a Xen/LVM based kernel may not result in what was built-in on the former to be built-in on the latter. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22673
|
| Posted: Sat Jan 27, 2024 4:28 am Post subject: |
|
|
| You keep saying this is an LVM problem, but none of the output you've posted leads me to believe that. It looks to me like your DomU kernel wants to use a Xen paravirtual block device for its root device. The Dom0 might be using LVM to back that paravirtual block device, but from the DomU's perspective, it is a paravirtual block device, not an LVM device. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 489
Location: Salem, OR
|
| Posted: Sat Jan 27, 2024 5:26 am Post subject: |
|
|
| Hu wrote: | | You keep saying this is an LVM problem, but none of the output you've posted leads me to believe that. It looks to me like your DomU kernel wants to use a Xen paravirtual block device for its root device. The Dom0 might be using LVM to back that paravirtual block device, but from the DomU's perspective, it is a paravirtual block device, not an LVM device. |
Hu, you are correct. I have been thinking "lvm" when referencing the Xen virtual block devices. The issue was that the kernel when loaded for the DomU session was not finding the Xen blocks defined in the DomU configuration. Here's a partially redacted version of my disk specification for the DomU:
| Code: | root = "/dev/xvda3 dolvm ro "
...
disk = ['phy:/dev/sda4,xvda3,w',
'phy:/dev/vg0/[REDACTED],xvda4,w',
'phy:/dev/sda3,xvda2,w']
|
Couple the above configuration settings with the point of error:
| Code: | >> Activating volume groups ...
>> Determining root device (trying /dev/xvda3) ........
!! Block device /dev/xvda3 is not a valid root device ...
!! Could not find the root block device in /dev/xvda3.
|
and, yes, it boils down to "/dev/xvda3" and other "xvda##". I'm afraid I was focusing on lvm because the status message "Activating volume groups...." preceded the break point and I had to get lvm activated in the new kernel, as well, a couple of days ago.
Good call. Thank you.
CONCLUSION
I am pleased/relieved to advise that after making sure the values in the 6.6.13 kernel matched the 6.1.57 values, especially when the newer had the XEN related configurations set as modules rather than built-in, I was able to successfully launch my DomU using the regenerated 6.6.13 kernel. I'm pretty certain my problem has been solved. And the problem arose from my not making sure that the new 6.6.13 kernel had the Xen configuration set as included because I had hope genkernel would just pick them up. As we saw in the diffs, certain XEN configurations which were previously built-in were specified as modules (which I had not loaded).
I'll await a few days for further comments/replies and then marked "SOLVED". |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
