You are not logged in.
I thought it would be useful to post a link to a problem that some people may hit when trying to boot kernel 4.9 since it may get pushed to core before long. It seems that for some hardware the 4.9 and 4.10-rcX kernels won't boot, when using efi with both grub and refind:
https://bugzilla.kernel.org/show_bug.cgi?id=191121
https://bugzilla.kernel.org/show_bug.cgi?id=191801
I know of at least one other arch user affected by this issue, and thought it was worth posting so that anyone else affected by this issue may see this and have it flagged up, and keep a fallback kernel available so that their machine can be booted if this happens.
Last edited by mcloaked (2017-01-27 07:46:07)
Mike C
Offline
+1 It was a bit too late until i have to revert back to 4.8.15
Offline
Looks like a patch is now available to try that might resolve this - see: https://bugzilla.kernel.org/show_bug.cgi?id=191121
Mike C
Offline
Looks like arch kernel 4.9.4-1 was pushed to testing today - though that does not I believe contain the crucial patches that fix this issue - I understand that 4.9.5 has the required patches upstream so anybody who has the problem should wait for 4.9.5
Mike C
Offline
@mcloaked - FYI you can look in the stable queue to see which patches are queued for the next RC: https://git.kernel.org/cgit/linux/kerne … /queue-4.9
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Thanks, Graysky.
Mike C
Offline
Well shit, that's why my system no-longer works. I was using EFI via SystemD's own bootloader. System no-longer boots with "efi: Error ident-mapping new memmap".
Offline
Well shit, that's why my system no-longer works. I was using EFI via SystemD's own bootloader. System no-longer boots with "efi: Error ident-mapping new memmap".
I know of one arch user who was using refind who hit this problem, and tried to boot using grub with the same original 4.9.x series kernels and it didn't change the failed boot. So it is not the bootloader that is affected but the kernel files irrespective of the bootloader. Once the patched kernels are available then boot should not fail if it is this particular issue impacting your machine (mainly Lenovo machines as far as I can tell from the reports where this has happened).
Mike C
Offline
Yeah, I noticed a lot of mention of Lenovos and that it's specifically a kernel issue rather than an init issue.
This machine is actually a desktop (Asrock Z97E ITX motherboard) oddly enough so it's not just laptops affected.
Offline
Yeah, I noticed a lot of mention of Lenovos and that it's specifically a kernel issue rather than an init issue.
This machine is actually a desktop (Asrock Z97E ITX motherboard) oddly enough so it's not just laptops affected.
Yes the affected code is specifically an efi related memory issue - if you go to the linked git queue you can find the patch and look at the code if you want to see the fine details!
Mike C
Offline
Looks like 4.9.5 won't fix this bug which makes linux 4.9 not working on lots of CPUs...
https://bugzilla.kernel.org/show_bug.cgi?id=192111 and commit fixing this PITA bug :
http://git.kernel.org/cgit/linux/kernel … 37993c481d
Well, looks like 4.9.6 will be the first one to be a candidate for core update. Well, nearly a month since last kernel update on core... It hurts!
Offline
Looks like 4.9.5 won't fix this bug which makes linux 4.9 not working on lots of CPUs...
https://bugzilla.kernel.org/show_bug.cgi?id=192111 and commit fixing this PITA bug :
http://git.kernel.org/cgit/linux/kernel … 37993c481d
Well, looks like 4.9.6 will be the first one to be a candidate for core update. Well, nearly a month since last kernel update on core... It hurts!
The second of your links is a separate issue to that referenced in the first?
Mike C
Offline
Yes the 4.9.5rc was released before https://git.kernel.org/cgit/linux/kerne … 5d7ec63000
The second of your links is a separate issue to that referenced in the first?
Offline
Yes the 4.9.5rc was released before https://git.kernel.org/cgit/linux/kerne … 5d7ec63000
mcloaked wrote:The second of your links is a separate issue to that referenced in the first?
Too bad this PITA bug will have to wait at least until 4.9.6 to be closed... 4.9 LTS kernel is having a bad start. Maybe one of the worst I've seen since using linux distributions as only OS booted by my computers, starting back in 2006...
Offline
I am not familiar with the Arch Linux kernel update process. Just wondering that while 4.9.x is stuck in limbo, can we not get a push of 4.8.17? Or is it against Arch kernel policy?
Thanks,
Sachin
Offline
I am not familiar with the Arch Linux kernel update process. Just wondering that while 4.9.x is stuck in limbo, can we not get a push of 4.8.17? Or is it against Arch kernel policy?
Thanks,
Sachin
The arch kernel maintainer is usually very well aware of current issues concerning new kernel versions, and will make decisions about releasing new versions for very clearly thought out reasons. When the next version of the kernel can sensibly be released I am confident that it will be, but if there is a good reason not to do so then it is important to trust the judgement on that.
Mike C
Offline
I am not familiar with the Arch Linux kernel update process. Just wondering that while 4.9.x is stuck in limbo, can we not get a push of 4.8.17? Or is it against Arch kernel policy?
Probably best to raise this as a separate issue on the Arch Discussion sub forum. Just from my knowledge I do not think there is a specific policy for the kernel / kernels.
Technically however with 4.9 now being in the testing repository replacing it with a 4.8 based release would need to use the epoch feature to override the default expectation release numbers always increase.
Without placing it in the testing repository there would be the issue of how to test it. Whatever reason caused arch not to use 4.8.14-4.8.17 may still apply. Also 4.8.17 is now marked EOL by upstream.
@fredbezies as 4.9.5 is delayed by https://www.spinics.net/lists/stable/msg156518.html you could try replying to https://www.spinics.net/lists/stable/msg156525.html ( I mean the message on the list if that is possible or just to the list )
asking for a backport of https://git.kernel.org/cgit/linux/kerne … 5d7ec63000
I suggest this because https://git.kernel.org/cgit/linux/kerne … -for-linus contains Cc: <stable@vger.kernel.org> # v4.9+ as do many of the other commits marked for linus in the tip repository but the rcu one did not but I am just speculating from that stable may not be aware of the patch being relevant to 4.9.
Edit:
https://git.kernel.org/cgit/linux/kerne … rcu/urgent contains Cc: <stable@vger.kernel.org> # 4.9.0-
Last edited by loqs (2017-01-20 08:57:18)
Offline
Too late for 4.9.5. I can only hope for 4.9.6. Such a regression can't stay any longer in a future LTS release. I think I'm not that powerful to imply such a patch. Commit coder can.
Offline
https://git.kernel.org/cgit/linux/kerne … d28745e03e so 4.9.6 should contain the fix for 192111.
With 191121 already fixed in 4.9.5 both bugs covered by 52246 should then be fixed.
Offline
https://git.kernel.org/cgit/linux/kerne … d28745e03e so 4.9.6 should contain the fix for 192111.
With 191121 already fixed in 4.9.5 both bugs covered by 52246 should then be fixed.
I'm following git page for stable queue commit. I was happy to see it added... At least
Offline
Resolved in kernel 4.9.6-1-ARCH
Mike C
Offline
I just updated to 4.9.6-1 and still unable to boot with "efi: Error ident-mapping new memmap (0x226914000)" which then immediately leads to "No working init found".
Last edited by Enverex (2017-01-28 12:27:12)
Offline
I just updated to 4.9.6-1 and still unable to boot with "efi: Error ident-mapping new memmap (0x226914000)" which then immediately leads to "No working init found".
Would suggest you bisect the issue then report it upstream. If you need help with the bisection would suggest you start a fresh topic as this one is marked as solved and covers multiple issues.
Offline
Looks like my issue was actually that the /usr/lib64 symlink didn't exist, not sure where that went or how.
Offline