| View previous topic :: View next topic |
| Author |
Message |
papu
l33t
Joined: 25 Jan 2008
Posts: 709
Location: Sota algun pi o alzina...
|
 Posted: Thu Jan 18, 2024 5:01 pm Post subject: |
 |
|
| GDH-gentoo wrote: | It's not hardcoded in the kernel. It should give different pathnames for different computers.
"ioctls" are interfaces that the kernel exposes to userspace programs through one system call (see man 2 ioctl if you are curious). grub-probe makes use of some of the Btrfs-specific ones if it finds out (by reading /proc/self/mountinfo) that the pathname it is given is the mountpoint of a device with such a filesystem.
One of these ioctls, BTRFS_IOC_DEV_INFO, seems to have changed behaviour and affect grub-probe. Seemingly for one specific corner case:
- Kernels are on the rootfs.
- The rootfs is Btrfs.
- The rootfs is mounted without an initramfs.
I want to post a small C program based on GRUB's code that readers can build and run to test their kernels. I'll try to do that when I come home after work. |
i made a initr just for 6.7.0 until i see what happens with this
you are very kind 
_________________
"~amd64" --cpu 7700 non-x --DDR5 2x16GB 6000MHz --gpu RX 470
Last edited by papu on Fri Jan 19, 2024 12:57 am; edited 1 time in total |
|
| Back to top |
|
 |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Thu Jan 18, 2024 11:39 pm Post subject: |
|
|
| GDH-gentoo wrote: | | I want to post a small C program based on GRUB's code that readers can build and run to test their kernels. I'll try to do that when I come home after work. |
Here it is:
test.c
| Code: | #include <errno.h>
#include <inttypes.h>
#include <fcntl.h>
#include <linux/btrfs.h>
#include <stdio.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
if (argc < 2) {
fprintf(stderr, "Usage: test <rootfs-device>\n");
return 1;
}
int rootdir_fd = open("/", O_RDONLY);
if (rootdir_fd < 0) {
fprintf(stderr, "Error: cannot open \"/\": %s\n", strerror(errno));
return 1;
}
struct btrfs_ioctl_fs_info_args fsinfo;
if (ioctl(rootdir_fd, BTRFS_IOC_FS_INFO, &fsinfo) < 0)
printf("Error: BTRFS_IOC_FS_INFO ioctl failed: %s\n", strerror(errno));
else for (int i = 1, j = 0; i <= fsinfo.max_id && j < fsinfo.num_devices; i++, j++) {
struct btrfs_ioctl_dev_info_args devinfo;
memset(&devinfo, 0, sizeof devinfo);
devinfo.devid = i;
if (ioctl(rootdir_fd, BTRFS_IOC_DEV_INFO, &devinfo) < 0)
printf("Error: BTRFS_IOC_DEV_INFO ioctl failed: %s\n", strerror(errno));
else
printf("path for devid == %d: %s\ngrub-probe %s find this pathname usable\n", i,
devinfo.path, strcmp("/dev/root", devinfo.path)? "WILL": "MIGHT NOT");
}
close(rootdir_fd);
struct stat rootdir_st;
if (stat("/", &rootdir_st) < 0) {
fprintf(stderr, "Error: cannot use stat() with \"/\": %s\n", strerror(errno));
return 1;
}
struct stat rootdev_st;
if (stat(argv[1], &rootdev_st) < 0) {
fprintf(stderr, "Error: cannot use stat() with \"%s\": %s\n", argv[1], strerror(errno));
return 1;
}
if (!S_ISBLK(rootdev_st.st_mode)) {
fprintf(stderr, "Error: \"%s\" is not a block special file\n", argv[1]);
return 1;
}
printf("st_dev for \"/\": %" PRIXMAX "\nst_rdev for \"%s\": %" PRIXMAX "\n"
"grub-probe %s succeed traversing /dev and comparing dev_t values\n",
(uintmax_t)rootdir_st.st_dev, argv[1], (uintmax_t)rootdev_st.st_rdev,
rootdir_st.st_dev == rootdev_st.st_rdev? "WILL": "WILL NOT");
return 0;
} |
Well, error checking made it not that small after all.
Requirements: None. Well, a C compiler, the libc and kernel headers, which every Gentoo system should have 
Building: gcc -o test test.c
Running: ./test rootfs_device, where the argument is the pathname that you know corresponds to the device that contains your rootfs, e. g. ./test /dev/nvme0n1p3
It makes the system calls that IIUC grub-probe makes, which I believe are not privileged, so it should be able to run with a normal unprivileged user.
| GDH-gentoo wrote: | | The same BTRFS_IOC_DEV_INFO ioctl is returning a different string as the value of the path member of the struct btrfs_ioctl_dev_info_args object passed to the ioctl() system call. It's /dev/nvme0n1p3 for the older kernel, which is directly usable by grub-probe, and /dev/root for the newer one. Or at least it is if the rootfs was mounted directly by the kernel instead of by an initramfs, it seems. That might be causing the breakage. |
The tests it prints should help narrow the problem an corroborate the hypothesis.
For me, the output is:
| Code: | $ ./test /dev/sda3
Error: BTRFS_IOC_FS_INFO ioctl failed: Inappropriate ioctl for device
st_dev for "/": 803
st_rdev for "/dev/sda3": 803
grub-probe WILL succeed traversing /dev and comparing dev_t values |
Which is expected, since my rootfs is ext4, not Btrfs 
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
Last edited by GDH-gentoo on Fri Jan 19, 2024 1:58 am; edited 1 time in total |
|
| Back to top |
|
|
papu
l33t
Joined: 25 Jan 2008
Posts: 709
Location: Sota algun pi o alzina...
|
| Posted: Fri Jan 19, 2024 12:34 am Post subject: |
|
|
initr
~/src $ uname -a
Linux .... 6.7.0-gentoo
| Code: | ~/src $ ./test /dev/nvme0n1p3
path for devid == 1: /dev/nvme0n1p3
grub-probe WILL find this pathname usable
st_dev for "/": 19
st_rdev for "/dev/nvme0n1p3": 10303
grub-probe WILL NOT succeed traversing /dev and comparing dev_t values |
no initr
~/src $ uname -a
Linux ... 6.7.0-gentoo
| Code: | ~/src $ ./test /dev/nvme0n1p3
path for devid == 1: /dev/root
grub-probe MIGHT NOT find this pathname usable
st_dev for "/": 14
st_rdev for "/dev/nvme0n1p3": 10303
grub-probe WILL NOT succeed traversing /dev and comparing dev_t values |
kernel 6.6.12
~/src $ uname -a
Linux ... 6.6.12-gentoo
| Code: | ~/src $ ./test /dev/nvme0n1p3
path for devid == 1: /dev/nvme0n1p3
grub-probe WILL find this pathname usable
st_dev for "/": 14
st_rdev for "/dev/nvme0n1p3": 10303
grub-probe WILL NOT succeed traversing /dev and comparing dev_t values |
_________________
"~amd64" --cpu 7700 non-x --DDR5 2x16GB 6000MHz --gpu RX 470
Last edited by papu on Fri Jan 19, 2024 12:53 am; edited 7 times in total |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Fri Jan 19, 2024 12:37 am Post subject: |
|
|
| papu wrote: | | Code: | path for devid == 1: /dev/nvme0n1p3
grub-probe WILL find this pathname usable |
|
And without the initramfs?
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
papu
l33t
Joined: 25 Jan 2008
Posts: 709
Location: Sota algun pi o alzina...
|
| Posted: Fri Jan 19, 2024 12:56 am Post subject: |
|
|
| GDH-gentoo wrote: | | papu wrote: | | Code: | path for devid == 1: /dev/nvme0n1p3
grub-probe WILL find this pathname usable |
|
And without the initramfs? |
now i edited it
_________________
"~amd64" --cpu 7700 non-x --DDR5 2x16GB 6000MHz --gpu RX 470 |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Fri Jan 19, 2024 1:47 am Post subject: |
|
|
Thanks for the testing.
| papu wrote: | no initr
~/src $ uname -a
Linux ... 6.7.0-gentoo
| Code: | ~/src $ ./test /dev/nvme0n1p3
path for devid == 1: /dev/root
grub-probe MIGHT NOT find this pathname usable
st_dev for "/": 14
st_rdev for "/dev/nvme0n1p3": 10303
grub-probe WILL NOT succeed traversing /dev and comparing dev_t values |
|
Yeah. Not only is the BTRFS_IOC_DEV_INFO ioctl giving a different result with the same input (not sure if this qualifies as a kernel regression), but both tests 'fail' (I didn't say much about the second one yet).
Late again in my timezone, I'll continue tomorrow.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Fri Jan 19, 2024 12:16 pm Post subject: |
|
|
| Code: | | newfstatat(AT_FDCWD, "/dev/root", 0x7ffc5006a920, 0) = -1 ENOENT (No such file or directory) |
Could you try booting with kernel 6.7.0 and no initramfs, creating /dev/root as a symlink to the appropriate special file (nvme0n1p3 in this case), and running grub-mkconfig -o test-grub.cfg? And if it works, compare test-grub.cfg with /boot/grub/grub.cfg using diff?
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Sat Jan 20, 2024 3:37 pm Post subject: |
|
|
For what is worth, here's my analysis.
1) grub-mkconfig calls grub-probe --target=device / to construct the root= parameter of the kernel command line in menu entries, and that fails.
2) grub-probe fails when function grub_guess_root_devices() is called.
util/grub-probe.c
| Code: | static void
probe (const char *path, char **device_names, char delim)
{
char **drives_names = NULL;
char **curdev, **curdrive;
char *grub_path = NULL;
int ndev = 0;
if (path != NULL)
{
grub_path = grub_canonicalize_file_name (path);
if (! grub_path)
grub_util_error (_("failed to get canonical path of `%s'"), path);
device_names = grub_guess_root_devices (grub_path);
free (grub_path);
}
if (! device_names)
grub_util_error (_("cannot find a device for %s (is /dev mounted?)"), path);
// ...
} |
3) grub_guess_root_devices() on Linux first calls grub_find_root_devices_from_mountinfo().
grub-core/osdep/unix/getroot.c
| Code: | char **
grub_guess_root_devices (const char *dir_in)
{
char **os_dev = NULL;
// ...
char *dir = grub_canonicalize_file_name (dir_in);
if (!dir)
grub_util_error (_("failed to get canonical path of `%s'"), dir_in);
#ifdef __linux__
if (!os_dev)
os_dev = grub_find_root_devices_from_mountinfo (dir, NULL);
#endif /* __linux__ */
// ...
} |
4) grub_find_root_devices_from_mountinfo() usually returns information retrieved from /proc/self/mountinfo.
grub-core/osdep/linux/getroot.c
| Code: | char **
grub_find_root_devices_from_mountinfo (const char *dir, char **relroot)
{
FILE *fp = NULL;
char *buf = NULL;
size_t len = 0;
grub_size_t entry_len, entry_max = 4;
struct mountinfo_entry *entries;
struct mountinfo_entry parent_entry = { 0, 0, 0, "", "", "", "" };
int i;
int retry = 0;
// ...
char **ret = NULL;
// ...
entries = xcalloc (entry_max, sizeof (*entries));
again:
fp = grub_util_fopen ("/proc/self/mountinfo", "r");
// ...
/* First, build a list of relevant visible mounts. */
while (getline (&buf, &len, fp) > 0)
{
struct mountinfo_entry entry;
int count;
// ...
if (sscanf (buf, "%d %d %u:%u %s %s%n",
&entry.id, &parent_entry.id, &entry.major, &entry.minor,
entry.enc_root, entry.enc_path, &count) < 6)
continue;
// ...
}
/* Now scan visible mounts for the ones we're interested in. */
for (i = entry_len - 1; i >= 0; i--)
{
char *fs_prefix = NULL;
if (!*entries[i].device)
continue;
if (grub_strcmp (entries[i].fstype, "fuse.zfs") == 0
|| grub_strcmp (entries[i].fstype, "zfs") == 0)
{
// ...
}
else if (grub_strcmp (entries[i].fstype, "btrfs") == 0)
{
// ...
}
else if (!retry && grub_strcmp (entries[i].fstype, "autofs") == 0)
{
// ...
}
if (!ret)
{
ret = xmalloc (2 * sizeof (ret[0]));
ret[0] = strdup (entries[i].device);
ret[1] = 0;
}
// ...
}
// ...
return ret;
} |
But Btrfs must have some peculiarity, and gets special treatment.
| Code: | if (grub_strcmp (entries[i].fstype, "fuse.zfs") == 0
|| grub_strcmp (entries[i].fstype, "zfs") == 0)
{
// ...
}
else if (grub_strcmp (entries[i].fstype, "btrfs") == 0)
{
ret = grub_find_root_devices_from_btrfs (dir);
// ...
}
else if (!retry && grub_strcmp (entries[i].fstype, "autofs") == 0)
{
// ...
} |
5) grub_find_root_devices_from_btrfs() tries to get information using the BTRFS_IOC_DEV_INFO ioctl:
| Code: | static char **
grub_find_root_devices_from_btrfs (const char *dir)
{
int fd;
struct btrfs_ioctl_fs_info_args fsi;
int i, j = 0;
char **ret;
fd = open (dir, 0);
// ...
if (ioctl (fd, BTRFS_IOC_FS_INFO, &fsi) < 0)
{
close (fd);
return NULL;
}
ret = xcalloc (fsi.num_devices + 1, sizeof (ret[0]));
for (i = 1; i <= fsi.max_id && j < fsi.num_devices; i++)
{
struct btrfs_ioctl_dev_info_args devi;
memset (&devi, 0, sizeof (devi));
devi.devid = i;
if (ioctl (fd, BTRFS_IOC_DEV_INFO, &devi) < 0)
{
// ...
return NULL;
}
ret[j++] = xstrdup ((char *) devi.path);
if (j >= fsi.num_devices)
break;
}
close (fd);
ret[j] = 0;
return ret;
} |
And here comes the first problem: the ioctl returns a different result for 6.7 kernels, /dev/root, if the rootfs has been mounted without an initramfs.
6) Now, back to grub_guess_root_devices(). If grub_find_root_devices_from_mountinfo() returns a /dev/root entry, it is further processed, since it doesn't convey much information by itself.
| Code: | char **
grub_guess_root_devices (const char *dir_in)
{
char **os_dev = NULL;
// ...
if (os_dev)
{
char **cur;
for (cur = os_dev; *cur; cur++)
{
char *tmp = *cur;
int root, dm;
if (strcmp (*cur, "/dev/root") == 0
|| strncmp (*cur, "/dev/dm-", sizeof ("/dev/dm-") - 1) == 0)
*cur = tmp;
else
{
*cur = grub_canonicalize_file_name (tmp);
// ...
}
root = (strcmp (*cur, "/dev/root") == 0);
dm = (strncmp (*cur, "/dev/dm-", sizeof ("/dev/dm-") - 1) == 0);
if (!dm && !root)
continue;
// ...
}
if (!*cur)
return os_dev;
// ...
}
// ...
} |
7) So what's tried next? If there's really a /dev/root file, using stat() on it, and comparing the returned st_rdev to that of all relevant /dev files, until a match is found.
| Code: | char **
grub_guess_root_devices (const char *dir_in)
{
char **os_dev = NULL;
struct stat st;
dev_t dev;
// ...
if (os_dev)
{
char **cur;
for (cur = os_dev; *cur; cur++)
{
char *tmp = *cur;
int root, dm;
// ...
if (!dm && !root)
continue;
if (stat (*cur, &st) < 0)
break;
free (*cur);
dev = st.st_rdev;
*cur = grub_find_device (dm ? "/dev/mapper" : "/dev", dev);
}
if (!*cur)
return os_dev;
// ...
}
// ...
} |
8 ) But of course, it /dev/root does not exist, stat() fails with ENOENT, so then on to the last fallback: using stat() on "/", and comparing the returned st_dev to the st_rdev of all relevant /dev files, until a match is found. That's all the newfstatat() calls in the straces.
| Code: | char **
grub_guess_root_devices (const char *dir_in)
{
char **os_dev = NULL;
struct stat st;
dev_t dev;
char *dir = grub_canonicalize_file_name (dir_in);
// ...
if (os_dev)
{
char **cur;
for (cur = os_dev; *cur; cur++)
for (cur = os_dev; *cur; cur++)
{
// ...
}
if (!*cur)
return os_dev;
for (cur = os_dev; *cur; cur++)
free (*cur);
free (os_dev);
os_dev = 0;
}
if (stat (dir, &st) < 0)
grub_util_error (_("cannot stat `%s': %s"), dir, strerror (errno));
free (dir);
dev = st.st_dev;
os_dev = xmalloc (2 * sizeof (os_dev[0]));
/* This might be truly slow, but is there any better way? */
os_dev[0] = grub_find_device ("/dev", dev);
// ...
os_dev[1] = 0;
return os_dev;
} |
9) And here comes the last problem: Internet searches show that, apparently, it is known that the st_dev value returned by stat() when the filesystem is Btrfs cannot be used for that comparison. Here's one link. Test results in this thread seem to confirm. So... grub_guess_root_devices() ends up with nothing and gives up:
| Code: | char **
grub_guess_root_devices (const char *dir_in)
{
char **os_dev = NULL;
struct stat st;
dev_t dev;
char *dir = grub_canonicalize_file_name (dir_in);
// ...
if (stat (dir, &st) < 0)
grub_util_error (_("cannot stat `%s': %s"), dir, strerror (errno));
free (dir);
dev = st.st_dev;
os_dev = xmalloc (2 * sizeof (os_dev[0]));
/* This might be truly slow, but is there any better way? */
os_dev[0] = grub_find_device ("/dev", dev);
if (!os_dev[0])
{
free (os_dev);
return 0;
}
// ...
} |
Conclusion: A real fix probably requires filing a bug report somewhere. Probably at least in Gentoo's bug tracker so that this problem is known.
Workarounds: Using an initramfs is seemingly enough (the mount() system call from the /init script probably makes the difference) to have the BTRFS_IOC_DEV_INFO ioctl return something useful. Or... trying to make step 7 succeed by creating a suitable /dev/root symlink, as proposed in previous post. stat() follows symlinks. A workaround, because on most systems /dev is a devtmpfs, so the symlink vanishes on every reboot. This last workaround is currently untested.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
Last edited by GDH-gentoo on Sat Jan 27, 2024 5:35 pm; edited 1 time in total |
|
| Back to top |
|
|
tka
n00b
Joined: 20 Jan 2024
Posts: 1
|
| Posted: Sat Jan 20, 2024 3:48 pm Post subject: |
|
|
| GDH-gentoo wrote: | | Or... trying to make step 7 succeed by creating a suitable /dev/root symlink, as proposed in previous post. stat() follows symlinks. A workaround, because on most systems /dev is a devtmpfs, so the symlink vanishes on every reboot. This last workaround is currently untested. |
Creating the /dev/root symlink works, and the resulting grub.cfg file is equal to the grub.cfg created under a kernel version 6.6.x:
| Code: | # diff -s /boot/grub/grub.cfg test-grub.cfg
Files /boot/grub/grub.cfg and test-grub.cfg are identical
|
|
|
| Back to top |
|
|
papu
l33t
Joined: 25 Jan 2008
Posts: 709
Location: Sota algun pi o alzina...
|
| Posted: Sat Jan 20, 2024 5:11 pm Post subject: |
|
|
i just updated to 6.7.1 today and same thing,
the files are equal
| Code: | ~ $ LC_MESSAGES=C.utf8 diff -s /boot/grub/grub.cfg /boot/grub/test-grub.cfg
Files /boot/grub/grub.cfg and /boot/grub/test-grub.cfg are identical |
i don't know where and to whom to send this bug because my engilsh is not enoght good to explain technical stuff 
_________________
"~amd64" --cpu 7700 non-x --DDR5 2x16GB 6000MHz --gpu RX 470
Last edited by papu on Sat Jan 20, 2024 8:30 pm; edited 1 time in total |
|
| Back to top |
|
|
leyvi
n00b
Joined: 08 Sep 2023
Posts: 65
Location: Israel
|
| Posted: Sat Jan 20, 2024 7:21 pm Post subject: |
|
|
Hello,
I'm having the exact same issue, although I have GRUB on a separate
partition from /boot (mounted at /efi, the ESP). Obviously the ESP is
vFAT, but /boot is btrfs. I'm willing to do some experimentation to help
solve the problem. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Sun Jan 21, 2024 12:15 am Post subject: |
|
|
| leyvi wrote: | I'm having the exact same issue, although I have GRUB on a separate
partition from /boot (mounted at /efi, the ESP). Obviously the ESP is
vFAT, but /boot is btrfs. |
I looked again at grub-mkconfig and /etc/grub.d/10_linux (both are shell scripts). grub-probe --target=device / is run unconditionally, its result is used for composing the root= parameter of the kernel command line. So if you are getting the "error: cannot find a device for / (is /dev mounted?)" message with a >= 6.7 kernel, your rootfs is Btrfs, and it's mounted by the kernel (i.e. no initramfs), then yes, you are likely on the same boat unfortunately...
If you want more confirmation, you can run strace or the test program posted earlier.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
leyvi
n00b
Joined: 08 Sep 2023
Posts: 65
Location: Israel
|
| Posted: Mon Jan 22, 2024 7:39 pm Post subject: |
|
|
I tried running `grub-mkconfig` and setting the `-o` argument to both `/boot/grub/grub.cfg` and `/efi/EFI/grub/grub.cfg`.
Both times, I made sure that there was a symlink to the device file of my root partition in `/dev` (that being `/dev/root` -> `/dev/nvme0n1p2`).
However, while `grub-mkconfig` didn't show any of the errors from before, the new `grub.cfg` file was not detected in
either of the two scenarios. I'm wondering if this is a different problem entirely, or did the developers who updated
GRUB not drink enough coffee when working on btrfs support? |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Mon Jan 22, 2024 8:24 pm Post subject: |
|
|
| leyvi wrote: | I tried running `grub-mkconfig` and setting the `-o` argument to both `/boot/grub/grub.cfg` and `/efi/EFI/grub/grub.cfg`.
[...]
However, while `grub-mkconfig` didn't show any of the errors from before, the new `grub.cfg` file was not detected in either of the two scenarios. |
Sorry, I don't follow. GRUB expects its configuration file to be in /boot/grub, so running grub-mkconfig -o /efi/EFI/grub/grub.cfg would be useless. In a setup where the EFI System Partition is mounted at /efi, and /boot is just a directory in the Btrfs root filesystem, the only part of GRUB that ends up in the ESP is its EFI PE32+ executable, grubx64.efi. Kernels and the rest of GRUB would be on the Btrfs filesystem. And that's OK, GRUB can read from filesystems other than FAT.
I don't know what you mean by "not detected".
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
leyvi
n00b
Joined: 08 Sep 2023
Posts: 65
Location: Israel
|
| Posted: Mon Jan 22, 2024 9:05 pm Post subject: |
|
|
| When I wrote "not detected", I meant to say that GRUB loaded the old `grub.cfg`. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Mon Jan 22, 2024 9:13 pm Post subject: |
|
|
And what do you mean now by "old grub.cfg". Command grub-mkconfig -o /boot/grub/grub.cfg will overwrite the file each time, which "old one" are you referring to?
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
leyvi
n00b
Joined: 08 Sep 2023
Posts: 65
Location: Israel
|
| Posted: Mon Jan 22, 2024 9:33 pm Post subject: |
|
|
As in, despite running `grub-mkconfig` again, with a different (installed) theme selected in `/etc/default/grub`,
the old configuration was loaded, with the old themes, and the new kernel version didn't show up. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Mon Jan 22, 2024 9:37 pm Post subject: |
|
|
| leyvi wrote: | As in, despite running `grub-mkconfig` again, with a different (installed) theme selected in `/etc/default/grub`,
the old configuration was loaded, with the old themes, and the new kernel version didn't show up. |
Ah. Is /boot on yet another partition? Could you post the output of the mount and ls -1 /boot commands?
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
leyvi
n00b
Joined: 08 Sep 2023
Posts: 65
Location: Israel
|
| Posted: Tue Jan 23, 2024 6:36 am Post subject: |
|
|
I’m in school right now, I’ll run the command and post the output when I get home.
For clarification:
My root partition is /dev/nvme0n1p2, Btrfs, mounted at /.
My ESP is /dev/nvme0n1p4, vFAT, mounted at /efi. (GRUB is installed here)
My boot partition is /dev/nvme0n1p5, Btrfs, mounted at /boot.
My old boot partition is /dev/nvme0n1p1. I have not deleted it yet, but I plan to once I get this worked out.
My old GRUB configuration was stock, with a custom background.
My new GRUB configuration should use the MineGRUB theme, and should have a newer version of Linux. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Tue Jan 23, 2024 12:16 pm Post subject: |
|
|
| leyvi wrote: | My boot partition is /dev/nvme0n1p5, Btrfs, mounted at /boot.
My old boot partition is /dev/nvme0n1p1. I have not deleted it yet, but I plan to once I get this worked out. |
I see. This migration from /dev/nvme0n1p1 to /dev/nvme0n1p5 needs running grub-install again at some point, or else grubx64.efi will continue using /dev/nvme0n1p1, which you no longer update.
Note that you don't need a partition for /boot with this setup if you use GRUB. If you want that partition, these should be the steps for the migration.
1) Make sure that /dev/nvme0n1p5 is mounted at /boot.
2) Make sure that /boot contains all your kernels. If it doesn't, mount /dev/nvme0n1p1 elsewhere (e. g. at /mnt) and copy the missing kernels to /boot.
3) Make sure that /dev/nvme0n1p4 is mounted at /efi. Optionally, you can get rid of /efi/EFI/grub to only leave in the ESP what should actually be there.
4) Run grub-install --efi-directory=/efi. This is necessary for reinstalling GRUB modules, themes, etc. in /dev/nvme0n1p5, and for making a new grubx64.efi that looks for them (and its configuration file) in that partition.
5) Make sure that all files that make up the GRUB theme you want are in appropriate subdirectories of /boot/grub.
6) Now you can run grub-mkconfig -o /boot/grub/grub.cfg. With the /dev/root -> nvme0n1p2 symlink if necessary to work around the problem reported in this thread.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
leyvi
n00b
Joined: 08 Sep 2023
Posts: 65
Location: Israel
|
| Posted: Tue Jan 23, 2024 5:44 pm Post subject: |
|
|
| Ah, forgot to mention; I already installed GRUB on the new ESP. |
|
| Back to top |
|
|
leyvi
n00b
Joined: 08 Sep 2023
Posts: 65
Location: Israel
|
| Posted: Tue Jan 23, 2024 5:51 pm Post subject: |
|
|
Also, here's the output of ls -1 /boot:
| Code: | [leyvi@fast-penguin] {~}
$ ls -1 /boot
amd-uc.img
config-6.7.1-gentoo
config-6.7.1-gentoo.old
config-6.7.1-gentoo-r1
grub
initramfs-6.7.1-gentoo.img
initramfs-6.7.1-gentoo.img.old
initramfs-6.7.1-gentoo-r1.img
System.map-6.7.1-gentoo
System.map-6.7.1-gentoo.old
System.map-6.7.1-gentoo-r1
vmlinuz-6.7.1-gentoo
vmlinuz-6.7.1-gentoo.old
vmlinuz-6.7.1-gentoo-r1
|
GRUB keeps loading 6.7.0, which is not on this partition (it's on the old /boot partition). |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1532
Location: South America
|
| Posted: Tue Jan 23, 2024 9:45 pm Post subject: |
|
|
| leyvi wrote: | | GRUB keeps loading 6.7.0, which is not on this partition (it's on the old /boot partition). |
I'd say do run again the grub-install --efi-directory=/efi and grub-mkconfig -o /boot/grub/grub.cfg commands, and then post the output of the mount command, and the contents of the generated /boot/grub/grub.cfg and /boot/grub/x64_64-efi/load.cfg files.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
papu
l33t
Joined: 25 Jan 2008
Posts: 709
Location: Sota algun pi o alzina...
|
| Posted: Fri Jan 26, 2024 10:24 am Post subject: |
|
|
I have compiled 6.8.0-rc1 and the problem persist 
_________________
"~amd64" --cpu 7700 non-x --DDR5 2x16GB 6000MHz --gpu RX 470 |
|
| Back to top |
|
|
cc68
n00b
Joined: 21 Jul 2008
Posts: 6
|
| Posted: Sat Jan 27, 2024 4:22 pm Post subject: |
|
|
| GDH-gentoo wrote: |
| Code: | | newfstatat(AT_FDCWD, "/dev/root", 0x7ffc5006a920, 0) = -1 ENOENT (No such file or directory) |
Could you try booting with kernel 6.7.0 and no initramfs, creating /dev/root as a symlink to the appropriate special file (nvme0n1p3 in this case), and running grub-mkconfig -o test-grub.cfg? And if it works, compare test-grub.cfg with /boot/grub/grub.cfg using diff? |
I tried with 2 systems, one is efi one without. On both adding an appropriate symlink solved the issue. Thanks very much, this is a great temporary fix! |
|
| 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
|
|
Kernel & Hardware
