[SOLVED] Slackware Current - LILO VESA Warnings after recent updates
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just ran the updates here from 5.10.10 -> 5.10.12, etc, mkinitrd then lilo with no issues, reboot and startx into Xfce. All's well.
Although the issue came in with 5.10.11 kernel, most people would not have seen the warning as they ran lilo under the existing 5.10.10 kernel when doing the upgrade.
It was only after people started upgrading from 5.10.11 to 5.10.12 that the warnings were noted.
A bit further information.
Lilo saves a copy of the disk boot sector into memory starting at 0x00000600 during the boot process and expects to be able to access that. With the change in the kernel, that memory location is now nulled out when the kernel starts.
> Hi Mike,
>
> This probably wont make it through your spam filters but I will try anyway.
Actually it did ;-)
> I am investigating a problem with the venerable lilo boot loader that has
> occurred subsequent to kernel 5.10.10 in Slackware64-current. that has been
> discussed here. https://www.linuxquestions.org/questions/slackware-14/
> slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#
> post6214439
>
> The lilo boot loader saves a copy of the boot sector at 0x00000600, but this
> area appears to be nulled out with kernel 5.10.11.
>
> I note that on a system running the 5.10.10 kernel
> root@Magpie:~# dmesg | grep 'mem.*reserved'
> [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000003fe57c00-0x000000003fffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fed003ff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed20000-0x00000000fed9ffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000feefffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved
> [ 0.001982] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> [ 0.003211] e820: update [mem 0x3ff00000-0xffffffff] usable ==> reserved
> [ 0.281844] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
> [ 0.948843] system 00:02: [mem 0x00000000-0x0009ffff] could not be reserved
> [ 0.948850] system 00:02: [mem 0x00100000-0x00ffffff] could not be reserved
> [ 0.948855] system 00:02: [mem 0x01000000-0x3fe51bff] could not be reserved
> [ 0.948860] system 00:02: [mem 0x000f0000-0x000fffff] could not be reserved
> [ 0.948865] system 00:02: [mem 0x000c0000-0x000d7fff] could not be reserved
> [ 0.948870] system 00:02: [mem 0xfec00000-0xfecfffff] could not be reserved
> [ 0.948875] system 00:02: [mem 0xfee00000-0xfeefffff] has been reserved
> [ 0.948879] system 00:02: [mem 0xffb00000-0xffbfffff] has been reserved
> [ 0.948884] system 00:02: [mem 0xffc00000-0xffffffff] has been reserved
> [ 0.952813] system 00:03: [mem 0xe0000000-0xefffffff] has been reserved
> [ 0.952818] system 00:03: [mem 0xfeda0000-0xfedacfff] has been reserved
>
> but on system running the 5.10.11 kernel
> lroot@Eagle:/# dmesg | grep 'mem.*reserved'
> [ 0.000000] BIOS-e820: [mem 0x000000000009d000-0x000000000009ffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000bb681000-0x00000000bb6befff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000bb800000-0x00000000bfffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000feb00000-0x00000000feb03fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed1b000-0x00000000fed1ffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000ffe80000-0x00000000ffffffff] reserved
> [ 0.205580] PCI: MMCONFIG at [mem 0xf0000000-0xf3ffffff] reserved in E820
> [ 0.539441] system 00:04: [mem 0xfed1c000-0xfed1ffff] has been reserved
> [ 0.539446] system 00:04: [mem 0xfed10000-0xfed13fff] has been reserved
> [ 0.539450] system 00:04: [mem 0xfed18000-0xfed18fff] has been reserved
> [ 0.539454] system 00:04: [mem 0xfed19000-0xfed19fff] has been reserved
> [ 0.539458] system 00:04: [mem 0xf0000000-0xf3ffffff] has been reserved
> [ 0.539462] system 00:04: [mem 0xfed20000-0xfed3ffff] has been reserved
> [ 0.539466] system 00:04: [mem 0xfed45000-0xfed8ffff] has been reserved
> [ 0.539470] system 00:04: [mem 0xff000000-0xffffffff] could not be reserved
> [ 0.539474] system 00:04: [mem 0xfee00000-0xfeefffff] could not be reserved
> [ 0.539478] system 00:04: [mem 0xd6500000-0xd6500fff] has been reserved
> [ 0.539482] system 00:04: [mem 0xff800000-0xffffffff] could not be reserved
> I see no such reservation.
>
> This is getting way out of my league but I would be pleased if you could
> provide me some insight.
I suspect that the problem is that I didn't take into account the way
kernel allows /dev/mem access to certain BIOS areas in RAM.
Can you please sent me the output of 'sudo head /proc/iomem' from both of
your systems?
If it is possible to run kernel 5.10.10 on Eagle as well, the same output
there will be also helpful.
> Best regards,
>
> David Allen
--
Sincerely yours,
Mike.
Quote:
Hi Mike,
Thanking you so much for your kind reply and your interest.
Please find attached the results of running 'cat /proc/iomem' on Eagle and Magpie when running the 5.10.10 kernel and 5.10.11 kernels.
I know these are elderly machines. If you want more recent samples I am happy to make a call out to the Slackware forum.
I understand that the commit is the way of the future. If lilo needs to go the way way of the dodo then so be it'
Re: Linux 5.11-rc5
From: Mike Rapoport
Date: Thu Feb 04 2021 - 13:22:10 EST
On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
>
> Mike: should we perhaps revert the first patch too (commit
> bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?
Unfortunately, I was too optimistic and didn't take into account that this
commit changes the way /dev/mem sees the first page of memory.
There were reports of slackware users about issues with lilo after upgrade
from 5.10.11 to 5.10.12
The root cause is that lilo is no longer able to access the first memory
page via /dev/mem because its type was changed from E820_TYPE_RESERVED to
E820_TYPE_RAM, so this became a part of the "System RAM" resource and
devmem_is_allowed() considers it disallowed area.
Re: Linux 5.11-rc5
From: Linus Torvalds
Date: Thu Feb 04 2021 - 13:35:24 EST
On Thu, Feb 4, 2021 at 10:19 AM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote:
>
> On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> >
> > Mike: should we perhaps revert the first patch too (commit
> > bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?
>
> Unfortunately, I was too optimistic and didn't take into account that this
> commit changes the way /dev/mem sees the first page of memory.
>
> There were reports of slackware users about issues with lilo after upgrade
> from 5.10.11 to 5.10.12
Ok, applied to mainline.
Greg & stable people - this is now commit 5c279c4cf206 ("Revert
"x86/setup: don't remove E820_TYPE_RAM for pfn 0"") in my tree.
Although maybe you just want to revert the commit in stable, rather
than take it from upstream? Same difference.
Linus
Last edited by cwizardone; 02-04-2021 at 04:25 PM.
Sorry, I was sleeping.
Just found this in my inbox.
Quote:
On Fri, Feb 05, 2021 at 01:46:20AM +1100, david.a58@optusnet.com.au wrote:
> Hi Mike,
>
> Thanking you so much for your kind reply and your interest.
>
> Please find attached the results of running 'cat /proc/iomem' on Eagle and
> Magpie when running the 5.10.10 kernel and 5.10.11 kernels.
>
> I know these are elderly machines. If you want more recent samples I am happy
> to make a call out to the Slackware forum.
No need for more samples, those you've sent confirm my hypothesis.
> I understand that the commit is the way of the future. If lilo needs to go the
> way way of the dodo then so be it'
I think the most important rule in the kernel community is "we don't break
userspace", so even breaking lilo alone is bad, but there are other
applications that may rely on /dev/mem access of the first memory page.
So we will fix this in the kernel, probably by simply reverting the commit.
rherbert@starbug.org:~/src/linux-5.10.14$ sudo make install
sh ./arch/x86/boot/install.sh 5.10.14 arch/x86/boot/bzImage \
System.map "/boot"
Warning: /dev/sdb is not on the first disk
Added Linux + *
One warning was issued.
This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe.
Changing the first memory page type from E820_TYPE_RESERVED to
E820_TYPE_RAM makes it a part of "System RAM" resource rather than a
reserved resource and this in turn causes devmem_is_allowed() to treat
is as area that can be accessed but it is filled with zeroes instead of
the actual data as previously.
The change in /dev/mem output causes lilo to fail as was reported at
slakware users forum, and probably other legacy applications will
experience similar problems.
I see no one mentioned: this thread was referred to in a commit that made it into 5.10.14, so if you upgrade to it I assume all problems should disappear. Commit says:
Code:
[…]
Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"
commit 5c279c4cf206e03995e04fd3404fa95ffd243a97 upstream.
This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe.
Changing the first memory page type from E820_TYPE_RESERVED to
E820_TYPE_RAM makes it a part of "System RAM" resource rather than a
reserved resource and this in turn causes devmem_is_allowed() to treat
is as area that can be accessed but it is filled with zeroes instead of
the actual data as previously.
The change in /dev/mem output causes lilo to fail as was reported at
slakware users forum, and probably other legacy applications will
experience similar problems.
Link: https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439
[…]
Did you read post #25, just before your post (#26)?
Haha, lol, I didn't realize the content I saw was only the first page, and then there are more pages. Well, what can I say. The links to other pages don't really stand out.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
).
