Description of problem: Version-Release number of selected component (if applicable): Kernel 3.18.3-server How reproducible: Installation of kernel and all related RPMS and lilo Steps to Reproduce: 1. Install kernel and all related RPMS to it on machine 2. Let lilo configure itself for newest kernel 3. Reboot machine and choose that kernel 4. You will get (at least I got) error message: "Kernel and initrd memory conflict" Reproducible: Steps to Reproduce:
CC: (none) => mageia, pterjan, tmb
Is it the same as bug 9848 Vuk?
hmm perhaps not
(In reply to claire robinson from comment #2) > hmm perhaps not I have this reports. Installed all files from repo as update to Cauldron and received 3.18.3-server-2 kernel. Kernel installed in Lilo and still getting the same error on boot (Kernel and Initrd memory conflict). However 3.18.3-desktop-2 kernel booted ok (not including shutdown of machine during boot which is I think my hardware failure). So 3.18.3-server-2 can not boot because initrd is somewhere wrong and 3.18.3-desktop-2 boots without problem and I'm now using it. I noticed that machine is slightly faster or faster when using desktop kernel instead of server. Vuk Vujovic
Source RPM: kernel-server-3.18.3 => kernel-server-3.18.3 liloWhiteboard: (none) => MGA5TOO
I have been trying to upgrade/update from mga4 to 5 the last week and get the same error listed above. Also using lilo. It seems mga5 is installed, but I have to manually select one of the older mga4 kernels to boot. It was suggested to me to post this here. Hopefully this is OK. Thanks duder
CC: (none) => 1alan.headrick, sysadmin-bugsComponent: RPM Packages => Release (media or process)Version: Cauldron => 5Source RPM: kernel-server-3.18.3 lilo => desktop-4.1.13-2.mga5
Has anyone tried with grub2 installed? Would like to rule out the boot loader. Of note about lilo, it's last code commit was well over 2 years ago and many distributions are now dropping support for it. Also, grub (not grub2) is no longer in active development due to grub2 being the replacement. I may file a report about these.
CC: (none) => luke.nukem.jones
Also reported via https://forums.mageia.org/en/viewtopic.php?f=7&t=10498 although I don't understand the actual issue, kernel and initrd images look just fine.
CC: (none) => doktor5000
Its not the kernel or initrd as such that is the problem, it's when lilo tries to map kernel and initrd to memory it gets in trouble... probably because kernel size has grown... I havent looked at lilo lately to see if it can be fixed for mga5... for mga6 we should simply drop lilo... as for grub legacy I guess it will live for a long time as it is a small nice loader with simple clean configs, and does not have any of the useless bloat that grub2 comes whit and its uggly configs. The only thing we wont patch grub legacy for is efi support, so as times goes by... Then again we could look at other clean efi loaders, such as gummiboot as default...
(In reply to Thomas Backlund from comment #7) > Its not the kernel or initrd as such that is the problem, it's when lilo > tries to map kernel and initrd to memory it gets in trouble... > probably because kernel size has grown... Yeah also read similar things after posting here. From what I found, in theory there should be no size limit to either kernel or initrd that lilo handles. But this only seems to happen on upgrades, found the same issue "Kernel and initrd memory conflict" reported for lilo for a MDK 9.0 > 9.2 upgrade. This seems to be the problem code: https://github.com/a2o/lilo/blob/master/src/second.S#L1862 I've also asked the guy in the forum to try to switch to grub/grub2 just to see if that fixes this issue.
Assigning to all packagers collectively since lilo has no registered maintainer for now. But also CCing kernel maintainers.
CC: (none) => kernelAssignee: bugsquad => pkg-bugsSource RPM: desktop-4.1.13-2.mga5 => lilo
I've seen such similar behaviour in the past (it was reboot not poweroff), around a year ago but I don't remember what was the exact issue.
CC: (none) => thierry.vignaud
Hi Vuk, Thank you for having taken the needed time to report this issue! We regret if this issue didn't get fixed in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, but non-security bugs have no chance of still getting fixed. I haven't seen anyone report this issue in Mageia 6 or later (and even this bug report for Mageia 5 had no action in a very long time. Closing as OLD. Please reopen this report and change its "Version:" at the top left to "6", if the same bug still exists in Mageia 6. Cheers, Marja
Resolution: (none) => OLDStatus: NEW => RESOLVEDCC: (none) => marja11