I want to install alpha2 inside Virtual Box 4.04 as guest and using Mandriva 2010.2 as host. Everything seems to be installing fine until I get to the installing bootloader screen, then it stops with the message below. Bootloader error: An error occurred mkinitrd failed: (mkinitrd -v -f /boot/initrd-2.6.37-desktop586-1.mga.img 2.6.37.3-desktop586-1.mga) If I click the OK button, it loops back to the bootloader screen, I have to stop the process completely to get out of the loop. I also had this same issue with alpha1. Not sure if this is a good idea at this stage for installing in VBbox. My hardware I'm currently using is a three year old Acer Aspire One netbook with 1gb ram, 160gb hd, intel video card. Thnx. Reproducible: Steps to Reproduce:
See https://bugs.mageia.org/show_bug.cgi?id=44 In alpha2, the problem is worse. The user never gets the option to select alt1 to use the sever kernel. I have not yet figured out why none of the server kernels will not work in VirtualBox on a single core host. All server kernels I've tried stop at "booting kernel" The current kernel used by the mageia install iso is not usable on a single core system, running under VirtualBox. I have not been able to get the install from iso working on real hardware, and at this point have had to give up on mageia, till this is fixed. I do still have a virtualbox version installed, which works ok using the custom kernel my system spent 10 days compiling, but see no further point in me trying to test mageia. My dvd drive can read, but anything it trys to write cannot be read. Until I replace the dvd burner, I cannot further test the mageia instlaller, except to say it doesn't work from an iso image on the hard drive, or booting from a usb flash drive created using unetbootin-linux-502. After I replace my dvd burner, I will try magiea again, but till then, there is no point in my testing it.
CC: (none) => davidwhodgins
Sorry for a late reply. Thanks for the info/tips. I guess I'll wait till the first beta comes out and try it again. I'm also looking to get a tower system, since I'm using my current netbook as a main system. Thnx.
Well, I did get another system, a HP DX5150 and installed Mageia to the hard drive without issues. I did use the Beta 1 iso instead of the Alpha. I haven't tried the beta in VirtualBox yet. Just a thought!
mkinitrd gets killed if it takes more than 10 minutes, we can probably increase the timeout
CC: (none) => pterjan
Beta, RC and final installed without any problem in VirtualBox 4.0.8. Maybe is the problem fixed now?
Created attachment 523 [details] Screenshot of log during install in VirtualBox showing mkinitrd failed. Still a problem with Mageia 1. The only way this can be fixed, is to provide (and have the installer use) a kernel with CONFIG_HZ_100=y that does not require PAE (as VirtualBox does not enable PAE by default. While increasing the timeout for mkinitrd from 10 minutes to say 20, might be enough to allow installation under VirtualBox, it still results in a system that is so slow, it gives a really bad impression. In my opinion, the best fix would be to add a kernel-lowend pacakage that is configured the same as kernel-desktop, except for the HZ setting, and have the installer use that kernel, during installation, and as the default when installed under VirtualBox.
I ran the mkinitrd after booting into rescue mode, and it took 12min, 4sec.
Source RPM: mkinitrd -v -f /boot/initrd-2.6.37-desktop586-1.mga.img 2.6.37.3-desktop586-1.mga => mkinitrd
While it is mkinitrd that is failing, mkinitrd is not the cause of the problem. The problem is that the kernel used while running the installer is using CONFIG_HZ_1000 instead of CONFIG_HZ_100. For background, see http://www.virtualbox.org/manual/ch12.html#idp12796768 The kernel used when running the installer shoud use CONFIG_HZ_100, but should not require PAE. The kernel that gets installed can still use CONFIG_HZ_1000, if appropriate (i.e. not running under VirtualBox and not on a slow cpu), but the installer itself must be able to run on slow systems, and under VirtualBox. A workaround would be to modify line 87 of /usr/lib/libDrakX/run_program.pm to increase the timeout from 10 minutes to 15 or 20, but taking 2 hours or more to do a minimal install (just selecting config and console tools), is not a pleasant experience.
CC: (none) => alda.cerny
CC: (none) => alien, tmb
Stephen, can you confirm that this is fixed by adding divider=10 as a kernel option for the installer solves this issue? If so, then this bug should be closed as a duplicate of bug 44.
Keywords: (none) => NEEDINFO
@ Stephen, Please reply to the question above within two weeks from now, to avoid this bug being closed as OLD.
CC: (none) => marja11
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD