Is it a new or old system?
What's the last working kernel version for you?
Have you considered going back to the official kernel version for your
Ubuntu (if it works?)?
Another option you may have would be to try disabling that
"...SANITZE_ALL" config and rebuild the kernel from kernel.org using
1) Do an $ ls -lah /boot
2) look for config-5.15.6 file and nano into it. That's the
config for the kernel that Ubuntu used for building it.
3) ctrl+w and type or paste "CONFIG_UBSAN_TRAP" and hit enter. (paste
is ctrl+shift+v)
If it doesn't find it, then it is odd that it doesn't work for
Does it have "CONFIG_UBSAN_TRAP" set in the config?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1942684
Title:
Kernel 5.14.X / 5.13.14 fails to boot
Status in linux package in
Kernel works ok.
So as it stands, new 5.15.3 has no "CONFIG_UBSAN_TRAP" in config.
So for new kernels you can probably close this bug off as long as they
don't reintroduce it.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
Looks like they may have removed "CONFIG_UBSAN_TRAP" from the kernel
config of 5.15.3!
Only this is in the config...
```
# CONFIG_UBSAN is not set
```
I'm building it now to see if it is ok and works.
--
You received this bug notification because you are a member of Kernel
Packages, which is
Fails for me too 5.15.1 on Penryn, Ivybridge, Haswell and guest VMs on
Zen3.
I had to rebuild the kernel from kernel.org using the config from Ubuntu
Mainline but disabling the debian pem certs and "CONFIG_UBSAN_TRAP".
After that it worked on all the above architectures.
--
You received this
On another test, using vanilla Ubuntu mainline 5.14.14 on a guest VBOX
VM runs ok for about half a day then crashes to black screen. This has
happened 4x!
Replacing the vanilla Ubuntu mainline 5.14.14 with a custom build of
5.14.14 using point 1 above (see comment 43) has so far worked for 3
Done
Point 1) above WORKS on zen3, haswell, and ivybridge.
That means disabled 'CONFIG_UBSAN_TRAP' in the kernel config prior to building.
Just nano or vim into the ".config" and put a '#' in front of the line to
disable it. before running "$ make olddefconfig"
I built the kernel using LLVM-13
Tried building 5.14.14 from vanilla upstream
https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.14.14.tar.xz
using the config from ubuntu mainline config-5.14.14-051414-generic
but removing the debian "pem" for a custom kernel build; and...
It fails to boot after grub for ivybridge and haswell
@Jens Glathe - Good stuff!
I wrote down some high-level steps in #32.
the mainline kernels from kernel.org have a lot of stuff disabled which
will make things "fiddly". Easiest way to enable them for all the new
hardware is to download the same mainline ubuntu kernel version even if
it is
For penryn the -march option is "core2" in that GCC options link.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1926938
Title:
Recent mainline packages are built with Hirsuite 21.04,
@tlk,- Ignorance doesn't mean knowledge, it is quite the opposite...
DKMS doesn't break because of headers when using clang with lto. The
headers are there and complete! Everything complete with well produced
binaries from LLVM/Clang.
The problem is because programs (not the headers and not
configuration (GCC)...
$ time KCFLAGS="-march=native -msse2avx -pipe -O3" KCPPFLAGS="-march=native
-msse2avx -pipe -O3" make -j$(( $(nproc) + 1 )) deb-pkg
LOCALVERSION=-danglingpointer-zen3-optimised
This is my build command post CLANG configuration with LTO...
time KCFLAGS=&quo
You guys mocking around trying to hack headers and wotnot, just build
the bloody kernel and you'll have a full kernel without wondering if you
broke something by hacking stuff! You could have built the kernel a
100x by now!
1) Just build dwarves from hirsute
2) build libbpf from hirsute
3)
Awesome.
I've been building dwarves and libbpf using the c library from 20.04. I
believe you are too Tuxinvader.
But yes, there are extra hoops to jump over having to do those! If they
get it in then that would be a couple less things to boilerplate.
Would be good if they fixed DKMS as well
If you want to stay with Ubuntu 20.04 LTS with latest stable mainline, you'll
need to build it.
Otherwise, try openSuse-Tumbleweed or Fedora.
I'm sticking with ubuntu so just building my own kernels. Runs faster
now as well since it is optimised for my rig specifically now.
--
You received
Thanks to this "bug", yes it IS a"bug"; thousands of ubuntu users have
learnt to compile mainline kernels!
I never had to compile a linux kernel until this happened to 5.11.17+!
I've always just installed whatever the mainline kernel team built.
The silver lining here is that my ivy-bridge
What a joke! So how is the community going to contribute, help, and
support the mainline kernels for "debug purposes" now?
Everyone on LTS that wants mainline will now be forced to compile their
own kernels or arbitrarily trust PPAs of unofficial 3rd parties if
choosing to stay with Ubuntu.
@eitch
Try Dougss steps without the aggressive optimisations first so you get
the hang of it. Make sure it works and your hardware all works.
My steps are a little different to Doug's and perhaps a little more
complicated. But once you get the hang of it, it is repeatable and can be
PPAs are a mechanism for "moving around raw debs"... ;-)
But you have a point, however if all systems are in the same network, it
is far much more easier to copy all debs to all servers and sudo dpkg
-i./*.deb in automation.
If systems are geographically not in the same network and crossing
All you guys mocking around with ppas could have compiled 5.12.5 by now
20x!
The last working mainline kernel is 5.11.16. Nothing later works when
installing into 18.04 LTS.
I've been forced to compile each latest kernel since. But because of
that predicament, I've now got it down to a fixed
21 matches
Mail list logo
