You are not logged in.
Hi all,
I'm running Arch on a C720 chromebook, using Syslinux as the bootloader. When I upgrade the kernel from 4.8.7 to 4.8.8, on reboot the laptop gets as far as "Probing EDD (edd=off to disable)... ok" before immediately rebooting with no further output. I have tried enabling extra kernel output according to the wiki, but this is so early in the boot process that I get nothing on-screen or in journalctl.
I have tried running mkinitcpio from a live disk, as well as reinstalling linux, syslinux and even the base system. Rolling back to 4.8.7 fixes the problem and the machine boots normally. I've not found any results on Google of other people with the same problem, so I'm not sure if it is a problem with my machine specifically or not. Does anyone else have a C720 successfully running this kernel? Any ideas as to what I can do to get it working on my machine?
Thanks.
Last edited by smudge145 (2017-03-25 15:19:15)
Offline
I had the exact same problem as you (C720 chrome book, syslinux as the bootloader). Was running linux-4.8.6-1. I upgraded to linux-4.8.8-2 and on reboot I got to the same spot as you where it immediately rebooted again (and again, and again). Downgrading back to linux-4.8.6-1 works for me. Unfortunately I do not have a fix, but I can confirm you're not crazy
Offline
Thanks for the reply! At least this means its not my machine that is broken. Is there somewhere that this problem should be reported so that it gets fixed?
Offline
Bisect linux-git between 4.8.7 and 4.8.8? That should give you the first bad commit if it is a kernel issue.
$ git clone https://aur.archlinux.org/linux-git.git
$ cd linux-git
$ rm config config.x86_64
$ curl -o config 'https://git.archlinux.org/svntogit/packages.git/plain/trunk/config?h=packages/linux&id=de73c61b6f3c2f2a150e4ca455c8cc78760c9b5a'
$ curl -o config.x86_64 'https://git.archlinux.org/svntogit/packages.git/plain/trunk/config.x86_64?h=packages/linux&id=de73c61b6f3c2f2a150e4ca455c8cc78760c9b5a'
$ sed -i 's/_srcname=linux/_srcname=linux-stable/' PKGBUILD
$ sed -i 's/torvalds\/linux.git/stable\/linux-stable.git#tag=v4.8.7/' PKGBUILD
$ sed -i 's/becc0c98cff692dee9500f19d38882636caf4c58d5086c7725690a245532f5dc/2ac8818414beb7dbacbd3ad450c516e6ada804827132a7132f63b8189e5f5151/' PKGBUILD
$ sed -i 's/3f26b7a3262ef8a5883da7d9761871d2c8208406d7cd5b8b0adc073bcddd4b52/93a4ad4f6c7bb9296fddec436ed7477a5a5c11cf4d6e68482fa6610442cbcb1f/' PKGBUILD
$ makepkg -os
$ cd src/linux-stable/
$ git bisect start
$ git bisect bad v4.8.8
$ git bisect good v4.8.7
Bisecting: 18 revisions left to test after this (roughly 4 steps)
[d3bbd04b92fddeb25a798d44b0fb9c903b6038e8] net: core: Correctly iterate over lower adjacency list
$ cd ../..
$ makepkg -ef
Install linux-git along side the existing kernel package(s) add bootloader entry if needed
$ cd linux-git/src/linux-stable/
$ git bisect result
Where result is good or bad. Repeat from ../.. until git bisect reaches conclusion
Offline
Just wanted to say that I also ran into this, c720, 2gb ram model. Booting from a live USB drive and installing/switching to linux-lts worked for me. If I can find the time, I'll try to narrow down the commit that broke this.
Offline
Thanks loqs for the recipe. The results of the bisect are below. I looked at the offending commit but quickly realized I lacked the context to make any judgement. Any advice on what to do next?
git bisect log:
git bisect start
# bad: [61385cc1db42b163c664429ab87d6399ea043c0d] Linux 4.8.8
git bisect bad 61385cc1db42b163c664429ab87d6399ea043c0d
# good: [567aeca9fbb7f1f00fc6bbdd6861010ce7ddaf22] Linux 4.8.7
git bisect good 567aeca9fbb7f1f00fc6bbdd6861010ce7ddaf22
# good: [d3bbd04b92fddeb25a798d44b0fb9c903b6038e8] net: core: Correctly iterate over lower adjacency list
git bisect good d3bbd04b92fddeb25a798d44b0fb9c903b6038e8
# bad: [eb77db88ea11e334816ceb5a537d775c1fc3fb72] macsec: Fix header length if SCI is added if explicitly disabled
git bisect bad eb77db88ea11e334816ceb5a537d775c1fc3fb72
# bad: [64774617da37025abe8ccdbb1ad09425c37586ff] net: fec: Call swap_buffer() prior to IP header alignment
git bisect bad 64774617da37025abe8ccdbb1ad09425c37586ff
# bad: [8418193f705251d9903b8b0b9760e769b3f32efd] ipv4: disable BH in set_ping_group_range()
git bisect bad 8418193f705251d9903b8b0b9760e769b3f32efd
# bad: [23c110c4cdbce17b6c5df90298168fc4b990ecc1] net: add recursion limit to GRO
git bisect bad 23c110c4cdbce17b6c5df90298168fc4b990ecc1
# first bad commit: [23c110c4cdbce17b6c5df90298168fc4b990ecc1] net: add recursion limit to GRO
Details on bad commit:
23c110c4cdbce17b6c5df90298168fc4b990ecc1 is the first bad commit
commit 23c110c4cdbce17b6c5df90298168fc4b990ecc1
Author: Sabrina Dubroca <sd@queasysnail.net>
Date: Thu Oct 20 15:58:02 2016 +0200
net: add recursion limit to GRO
[ Upstream commit fcd91dd449867c6bfe56a81cabba76b829fd05cd ]
Currently, GRO can do unlimited recursion through the gro_receive
handlers. This was fixed for tunneling protocols by limiting tunnel GRO
to one level with encap_mark, but both VLAN and TEB still have this
problem. Thus, the kernel is vulnerable to a stack overflow, if we
receive a packet composed entirely of VLAN headers.
This patch adds a recursion counter to the GRO layer to prevent stack
overflow. When a gro_receive function hits the recursion limit, GRO is
aborted for this skb and it is processed normally. This recursion
counter is put in the GRO CB, but could be turned into a percpu counter
if we run out of space in the CB.
Thanks to Vladimír Beneš <vbenes@redhat.com> for the initial bug report.
Fixes: CVE-2016-7039
Fixes: 9b174d88c257 ("net: Add Transparent Ethernet Bridging GRO support.")
Fixes: 66e5133f19e9 ("vlan: Add GRO support for non hardware accelerated vlan")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
:040000 040000 a955f75cf3ef14e806c48f59d0f8843e0693fd3d 1d922be3e6e6f9117d8d675f5afad5d60e826de4 M drivers
:040000 040000 fcec339ef1af0c3330fd6a7b728f3438cd39c2bc e89ff89b2c726333e6a385bc0bfb2f7902b24c98 M include
:040000 040000 58b021fa053c943da425e893884b6350b02170f2 a40bcb7b8c5638648f7969eb57dd4d3b517b90a0 M net
Last edited by jkramer (2016-11-20 21:24:28)
Offline
Thank you for doing the bisect I agree it does not seem an obvious candidate to cause failure to boot but the bisect contained both working and failing kernels so the process seemed to be working correctly.
Perhaps ask on IRC for others to review it before submitting a bug report upstream.
My only other suggestion would be you could try building the 4.8.9 which would expect to fail then revert that one commit.
In the PKGBUILD change tag#4.8.7 to 4.8.9 then makepkg -f this kernel should fail as it has the bad commit.
Then the following should revert that one commit.
$ cd linux-git/src/linux-stable/
$ git revert -n 23c110c4cdbce17b6c5df90298168fc4b990ecc1
$ cd ../..
$ makepkg -ef
Also please use code tags around the outputs of commands.
Offline
I added code tags above, sorry about that.
I tried your suggestion. As expected, unadulterated 4.8.9 will not boot. 4.8.9 with 23c110c reverted boots fine.
I don't have IRC, so I'll have to get that set up tomorrow sometime. I'll ask around there for folks' opinions.
Offline
I just reported https://bugzilla.kernel.org/show_bug.cgi?id=188391
Offline
panpog1 thank you for reporting it upstream also welcome to the arch linux forums.
Your report is against Tree: Mainline should it not be Tree: Stable?
Also the commit which seems to cause the issue is not klibc/kinit but modules or other.
Does the error still occur with 4.8.11 and does reverting just 3c110c4cdbce17b6c5df90298168fc4b990ecc1 fix the issue?
Offline
This issue still occurs for me with 4.8.11 and 4.8.12.
Reverting 23c110c4cdbce17 does not fix the issue for either of those versions.
Offline
I also had the same issue with the kernel version 4.8.11, after a downgraded to 4.8.7 everything worked again.
For downgrading I used the wiki: https://wiki.archlinux.org/index.php/Ke … all_kernel
Offline
As there seems to be not activity on the bug report upstream perhaps ask on IRC for suggestions if there is anything more you can do such as would it be appropriate to email the author the author of the bad commit found by the git bisection or the linux-stable mailing list.
You could also test if the issue is present on the newly released 4.9 kernel.
Offline
Hi all. I found some time to look at this some more. I'm not sure what broke what, but it appears that there are some commits in the Syslinux git repo that fix this issue. Indeed, these patches are now in the Debian package for Syslinux.
I updated a local copy of the Arch Linux Syslinux PKGBUILD to include these patches, and sure enough, I am now running Linux 4.9.11-1 on my Acer C720 Chromebook.
loqs, do you think I should contact the maintainer of Syslinux for Arch Linux and ask him to include these patches and bump his package to a new release?
Here is my diff to his PKGBUILD
diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 48ec7d30928..1b3f03e15db 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -6,7 +6,7 @@
pkgname=syslinux
pkgver=6.03
_tag=syslinux-$pkgver
-pkgrel=6
+pkgrel=7
pkgdesc='Collection of boot loaders that boot from FAT, ext2/3/4 and btrfs filesystems, from CDs and via PXE'
url='http://www.syslinux.org/'
arch=(i686 x86_64)
@@ -34,6 +34,8 @@ optdepends=('perl-crypt-passwdmd5: For md5pass'
source=(git://git.kernel.org/pub/scm/boot/syslinux/syslinux.git#tag=$_tag
syslinux.cfg
syslinux-install_update
+ load-linux-correct-a-type.patch::http://repo.or.cz/syslinux.git/patch/83aad4f69065509ba5b1c080edccfed316a4cff0
+ update-prot-mode-base.patch::http://repo.or.cz/syslinux.git/patch/0a2dbb3392ee710838bea6bda80d4daad6b54780
btrfs-fix.patch::http://repo.or.cz/syslinux.git/patch/548386049cd41e887079cdb904d3954365eb28f3?hp=721a0af2f0ba111c31685c5f6c5481eb25346971
gcc-fix-alignment.patch::http://repo.or.cz/syslinux.git/patch/e5f2b577ded109291c9632dacb6eaa621d8a59fe?hp=8dc6d758b564a1ccc44c3ae11f265d43628219ce
dont-guess-alignment.patch::http://repo.or.cz/syslinux.git/patch/0cc9a99e560a2f52bcf052fd85b1efae35ee812f?hp=e5f2b577ded109291c9632dacb6eaa621d8a59fe
@@ -41,7 +43,9 @@ source=(git://git.kernel.org/pub/scm/boot/syslinux/syslinux.git#tag=$_tag
)
sha1sums=('SKIP'
'1145f454bd297d373ad123425f93620c3e92f585'
- '29d7c28639e57cdaefc8ef2447e8412a7b59709d'
+ '2cf5a0eccfb0bf4196b8aea4add1002be948332d'
+ '6fdd0ebd6c34e4a424982e29beacff0a16e50c02'
+ 'd3551c17674ea51f3457a05ec1136604349fb89e'
'3e7d6e399c25fb7f5d31cc8e580d01163695e351'
'74b976dd3ce28a619c2e9ef69a33fd455dc4bd4c'
'b6ef5a7cdd4b7c714fd78c174e93ae6e854ae1ee'
@@ -55,6 +59,9 @@ esac
prepare() {
cd syslinux
+ patch -p1 < ../load-linux-correct-a-type.patch
+ patch -p1 < ../update-prot-mode-base.patch
+
# FS#48253
patch -p1 < ../gcc-fix-alignment.patch
patch -p1 < ../dont-guess-alignment.patch
Offline
loqs, do you think I should contact the maintainer of Syslinux for Arch Linux and ask him to include these patches and bump his package to a new release?
Yes please file a bug report. (Reporting_bug_guidelines)
Nice work on determining the issue is syslinux and finding the patches.
Offline
Bug report here: https://bugs.archlinux.org/task/53083
Offline
syslinux-6.03-7 with these 2 patches has been pushed to [testing]. Please verify that it works for you.
Last edited by anatolik (2017-02-28 14:13:52)
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
syslinux-6.03-7 with these 2 patches has been pushed to [testing]. Please verify that it works for you.
Today I updated my syslinux to syslinux-6.03-7 from stable onto my Acer C720 and it worked for me. I'm now able to boot 4.9.11-1 without a problem (previously I used 4.8.7).
Thank you!
Offline
Upgraded to 4.10.5-1 today, with syslinux-6.03-7 my Acer C720 now seems to be working fine so I'll mark the topic as solved. Thanks all for the replies!
Offline