sparc64 kernel bug
Time for a better subject line. Therefore here we are.
------------------------ original message ------------------------
Message-ID: <[🔎] e28d33c4-6fae-3432-2e2b-9624b25c9708@physik.fu-berlin.de>
Date: Mon, 4 Apr 2022 00:00:41 +0200
Subject: Re: nasty bug in /usr/sbin/grub-probe
In-Reply-To: <[🔎] eb5411f8-ec5b-913a-38eb-3b82928c51c6@blastwave.org>
Resent-Date: Sun, 3 Apr 2022 22:01:00 +0000 (UTC)
On 4/3/22 23:54, Dennis Clarke wrote:
> No, I am not. I am going with whatever is in the Makefile.
>
>
https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3
>
> So this was seen before regardless.
Please just follow my advise and use Linus' tree and don't use any LTS
kernels
which may have some changes from the latest kernels backported.
I know that cross-compiling and bisecting works 100%, so we really don't
need to
argue about this. You didn't find some hidden bug that the daily CI
hasn't caught.
The kernel developers are regularly rebuilding the kernel for most
targets with
all the various standard kernel configuration presets, so it's extremely
unlikely
that you run a kernel that won't compile due to a bug.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--------------------- end of original message ---------------------
I don't see any reasonable way to do this other than using a cross build
on some reasonably fast AMD64 boxen. That means I will need the sparc64
binutils as well as who knows what else. Certainly a GCC cross compiler
and maybe other tools. This is not exactly something I do on any given
Sunday. However I am game to try.
I can checkout the Linux ( Linus ) tree well enough but picking a tag
where things worked? That is a blind guess at best. I would need to
compile the kernel with a limited set of modules selected and then
create the initrd and vmlinuz files to drop into /boot on the target
machine. So that means digging into initramfs-tools as well as the
snazzy usr/gen_init_cpio tool[1] with its file format goodness. None
of this stuff is well documented ( at least not at kernel.org ) where
I see pages of stuff from twenty years ago or more.
I am even wondering if I can netboot the target machine? That would
save me the hassle of creating initrd/vmlinuz files over and over with
a hacked /boot/grub/grub.cfg file. Given that I can not run update-grub
there is no other way than to manually edit the file. I may do a netboot
test just to see what happens with the netinst file from 28th March.
Dennis Clarke
[1] The cpio created and then compressed initramfs/initrd file seems
to have documentation from twenty years ago or more :
https://www.kernel.org/doc/html/latest/driver-api/early-userspace/buffer-format.html
https://www.kernel.org/doc/html/latest/driver-api/early-userspace/early_userspace_support.html
Within the Linux 5.17.1 stable tree I see this :
hades# file usr/gen_init_cpio
usr/gen_init_cpio: ELF 64-bit MSB pie executable, SPARC V9, relaxed
memory ordering, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux.so.2,
BuildID[sha1]=2279f500e2a81d6211820c85283ce73ed44471ab, for GNU/Linux
3.2.0, not stripped
hades#
hades# usr/gen_init_cpio
Usage:
usr/gen_init_cpio [-t <timestamp>] <cpio_list>
<cpio_list> is a file containing newline separated entries that
describe the files to be included in the initramfs archive:
# a comment
file <name> <location> <mode> <uid> <gid> [<hard links>]
dir <name> <mode> <uid> <gid>
nod <name> <mode> <uid> <gid> <dev_type> <maj> <min>
slink <name> <target> <mode> <uid> <gid>
pipe <name> <mode> <uid> <gid>
sock <name> <mode> <uid> <gid>
<name> name of the file/dir/nod/etc in the archive
<location> location of the file in the current filesystem
expands shell variables quoted with ${}
<target> link target
<mode> mode/permissions of the file
<uid> user id (0=root)
<gid> group id (0=root)
<dev_type> device type (b=block, c=character)
<maj> major number of nod
<min> minor number of nod
<hard links> space separated list of other links to file
example:
# A simple initramfs
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
dir /sbin 0755 0 0
file /sbin/kinit /usr/src/klibc/kinit/kinit 0755 0 0
<timestamp> is time in seconds since Epoch that will be used
as mtime for symlinks, special files and directories. The default
is to use the current time for these entries.
hades#
Reply to: