ow much automation can be used for bisecting a problem on grub?
My rx2660 is considerably up to date and still booting.
What do you recommend for best bisecting the offending step?
On Aug 6, 2023, at 10:13, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
Hi!
On Sun, 2023-08-06 at 15:08 +0000, Pedro Miguel Justo wrote:
ow much automation can be used for bisecting a problem on grub?
My rx2660 is considerably up to date and still booting.
What do you recommend for best bisecting the offending step?
You cannot automate this as the machine needs to be rebooted all the time.
That is what I was expecting.
Basically, you need to do the following:
# apt build-dep grub2
Sourt of embarrassing question but… what is the deb-src right entry for debian ports?
# git clone git://git.savannah.gnu.org/grub.git
This leads me to another question: Has anyone been able to install git these days?
On Aug 7, 2023, at 01:03, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
# wget http://snapshot.debian.org/archive/debian/20220510T034305Z/pool/main/g/git/git-man_2.36.1-1_all.deb
# dpkg -i git-man_2.36.1-1_all.deb
Then install git normally with apt-get.
Thanks Adrian.
From there, all good till the grub-install step, which failed:
pmsjt@itanium:~/grub$ sudo /usr/local/sbin/grub-install /dev/sda
Installing for ia64-efi platform.
/usr/local/sbin/grub-install: warning: cannot open directory `/usr/local/share/locale': No such file or directory.
/usr/local/sbin/grub-install: error: efibootmgr: not found.
Well, you need to install efibootmgr. Not sure why it isn't installed on your
machine in the first place since it's needed for grub-install to update the boot manager settings in firmware and create the "grub" entry.
Just install it with:
# apt install efibootmgr
Adrian
Thanks Adrian. It is a mystery why it was previously installed. After that I was able to go through 3 or 4 bisections with successful boots. Then, finally, I hit the problem. The trouble is that it seems to have also affected my “debian” entry, sono safe boot:
Loading.: debian
Starting: debian
Welcome to GRUB!
7 0 0x00006B 0x000000000000001E unexpected trap
7 0 0x000066 0x000000000000001E trap taken, number in ext PE
7 0 0x00003C 0x0000000000005A00 trap taken, offset in ext PE
Thanks Adrian. It is a mystery why it was previously installed. After that
I was able to go through 3 or 4 bisections with successful boots. Then, finally, I hit the problem. The trouble is that it seems to have also affected
my “debian” entry, so no safe boot:
Here it is:
06edd40db76bb78457ac26156ed5f7b62381bbe8 is the first bad commit
commit 06edd40db76bb78457ac26156ed5f7b62381bbe8
Author: Oliver Steffen <osteffen@redhat.com>
Date: Fri May 26 13:35:43 2023 +0200
guid: Unify GUID types
There are 3 implementations of a GUID in GRUB. Replace them with
a common one, placed in types.h.
It uses the "packed" flavor of the GUID structs, the alignment attribute
is dropped, since it is not required.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Here it is:
06edd40db76bb78457ac26156ed5f7b62381bbe8 is the first bad commit
commit 06edd40db76bb78457ac26156ed5f7b62381bbe8
Author: Oliver Steffen <osteffen@redhat.com>
Date: Fri May 26 13:35:43 2023 +0200
guid: Unify GUID types
There are 3 implementations of a GUID in GRUB. Replace them with
a common one, placed in types.h.
It uses the "packed" flavor of the GUID structs, the alignment attribute
is dropped, since it is not required.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Hello!
The following important packages are broken on ia64:
- grub (git master) does not boot on ia64, crashes when loading stage2 (https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00106.html)
- kernel FTBFS with gcc-13 (https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ia64&ver=6.4.4-2&stamp=1690708282&raw=0)
Hi Adrian,
On 06.08.23 10:44, John Paul Adrian Glaubitz wrote:
Hello!
The following important packages are broken on ia64:
- grub (git master) does not boot on ia64, crashes when loading stage2
(https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00106.html)
- kernel FTBFS with gcc-13
(https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ia64&ver=6.4.4-2&stamp=1690708282&raw=0)
I created a bug report for this, see [1]. In short this happens (1) also
for cross-compilation on amd64 (most likely also for other
cross-compilation host arches), (2) for me always for the same file (`net/ipv4/fib_semantics.c`) and function ("fib_create_info()"), but
there are others, too, see buildd link, (3) for different kernel
versions and (3) is gone when providing `-fsanitize=undefined` during compilation.
Details in [1].
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425
I hope someone picks that up.
The resulting kernel and modules aren't yet tested, though. I plan that
for today and tomorrow.
Richard Biener suggested `-fno-var-tracking` or `-g0` as workaround and
both indeed workaround the problem (see [2]). I don't yet know how to
limit the addition of `-fno-var-tracking` to KBUILD_CFLAGS to `net/ipv4/fib_semantics.c` [...]
Worked for me, MR is here:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/852
Looking forward to new ia64 kernels for Sid.
I don't think this patch is acceptable in its current form as it
modifies the Makefile globally so that the flag is passed on to
the host compiler for all architectures.
Yes, thought about that, too. Know a better solution? Is there a way to
make this only affecting compilations for ia64?
On Mon, 2023-09-18 at 22:36 +0200, Frank Scheiner wrote:
I don't think this patch is acceptable in its current form as it
modifies the Makefile globally so that the flag is passed on to
the host compiler for all architectures.
Yes, thought about that, too. Know a better solution? Is there a way to
make this only affecting compilations for ia64?
You could modify CFLAGS globally in debian/rules specifically for ia64:
ifneq (,$(filter $(DEB_HOST_ARCH),ia64))
export DEB_CFLAGS_MAINT_APPEND += -fno-var-tracking
endif
That's the other extreme then, everything for ia64 gets compiled with `-fno-var-tracking`, or? Is that more acceptable?
Maybe the per-file CFLAGS are also effective when included in the architecture Makefile in `arch/ia64/`?
Or maybe we could query the arch from within the two Makefiles and only
apply `-fno-var-tracking` when we compile for ia64.
I'll have a look into that tomorrow.
On 18.09.23 22:42, John Paul Adrian Glaubitz wrote:
On Mon, 2023-09-18 at 22:36 +0200, Frank Scheiner wrote:
I don't think this patch is acceptable in its current form as it
modifies the Makefile globally so that the flag is passed on to
the host compiler for all architectures.
Yes, thought about that, too. Know a better solution? Is there a way to
make this only affecting compilations for ia64?
You could modify CFLAGS globally in debian/rules specifically for ia64:
ifneq (,$(filter $(DEB_HOST_ARCH),ia64))
export DEB_CFLAGS_MAINT_APPEND += -fno-var-tracking
endif
That's the other extreme then, everything for ia64 gets compiled with `-fno-var-tracking`, or? Is that more acceptable?
Maybe the per-file CFLAGS are also effective when included in the architecture Makefile in `arch/ia64/`?
Or maybe we could query the arch from within the two Makefiles and only
apply `-fno-var-tracking` when we compile for ia64.
I'll have a look into that tomorrow.
On Tue, 2023-09-19 at 20:26 +0200, Frank Scheiner wrote:
The MR ([1]) was updated and now uses `-fno-var-tracking` for the
respective files only when the target architecture is ia64. This works
like so for example:
```
ifeq ($(ARCH),ia64)
CFLAGS_bnx2x_sp.o += -fno-var-tracking
endif
```
Tested via a local kernel build where one case was using a wrong target
architecture (i386) at first to see it failing and then working after
changing that back to the correct target architecture (ia64).
[1]: https://salsa.debian.org/kernel-team/linux/-/merge_requests/852
This looks reasonable to me and I think we can have this merged as a temporary
workaround so that we can get 6.5 and 6.6 kernels built for ia64 on the buildds.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 74:35:03 |
| Calls: | 6,694 |
| Calls today: | 4 |
| Files: | 12,228 |
| Messages: | 5,347,067 |
| Posted today: | 1 |