Description of problem: With Cauldtron RC I have the same problem like the Beta 3. When I start the live CD and install from the running live version the first time it fails to install the boot loader correct. At this step I start with the install DVD for Mageia 1 and go to the repair section. Here I install the Windows bootloader. Now I start again the live CD, install Mageia and all is OK. I have three HDs: first and second is Windows, third is for testing new versions of Mageia. This is the install-order, but the boot HD (entrie in the BIOS) ist the third HD and on this I install the boot-loader Version-Release number of selected component (if applicable): Mageia 2 RC How reproducible: Steps to Reproduce: 1. 2. 3.
CC: (none) => norbert.marchl
can you add the output of fdisk -l ?
CC: (none) => thierry.vignaudSource RPM: (none) => draktools
from the reporter in private: Here the text with fdisk -l Disk /dev/sda: 41.1 GB, 41110142976 bytes 255 Köpfe, 63 Sektoren/Spur, 4998 Zylinder, zusammen 80293248 Sektoren Einheiten = sectors von 1 x 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xd63e96e5 Gerät boot. Anfang Ende Blöcke Id System /dev/sda1 * 63 80276804 40138371 7 HPFS/NTFS/exFAT Disk /dev/sdb: 80.1 GB, 80060424192 bytes 255 Köpfe, 63 Sektoren/Spur, 9733 Zylinder, zusammen 156368016 Sektoren Einheiten = sectors von 1 x 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x9bb99bb9 Gerät boot. Anfang Ende Blöcke Id System /dev/sdb1 * 2048 156364799 78181376 7 HPFS/NTFS/exFAT Disk /dev/sdc: 15.4 GB, 15377080320 bytes 255 Köpfe, 63 Sektoren/Spur, 1869 Zylinder, zusammen 30033360 Sektoren Einheiten = sectors von 1 x 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xecece1ff Gerät boot. Anfang Ende Blöcke Id System /dev/sdc1 * 63 15711569 7855753+ 83 Linux /dev/sdc2 15714279 30025484 7155603 5 Erweiterte /dev/sdc5 15714304 29222234 6753965+ 83 Linux /dev/sdc6 29224960 30025484 400262+ 82 Linux Swap / Solaris I hope this help you. But now is a second miracle: I install "synergy" and set in the Host-Definitions as second name another name then "localhost" reboot and now I have lost the Boot-Entry for Windows. Maybe I can't send a email with attachement? I try it, but the mail comes back.
(In reply to comment #0) > Description of problem: With Cauldtron RC I have the same problem like the Beta > 3. > When I start the live CD and install from the running live version the first > time it fails to install the boot loader correct. What do you mead by it fails to install the boot loader? Does that step fail with an error message, or is it installing the boot loader, but the boot loader isn't working?
CC: (none) => davidwhodgins
(In reply to comment #3) > (In reply to comment #0) > > Description of problem: With Cauldtron RC I have the same problem like the Beta > > 3. > > When I start the live CD and install from the running live version the first > > time it fails to install the boot loader correct. > > What do you mead by it fails to install the boot loader? > > Does that step fail with an error message, or is it installing > the boot loader, but the boot loader isn't working? It will install the bootloader without any error-message, but when I reboot I have an ASCII bootloader and can't boot nothing. So I install with the Install-DVD for Mageia 1 the Windows only Bootloader, start Windows to see it works, shutdown Winwdows ans with the Install-DVD for Mageia 1 I Re-install the Bootloader. One hour later, I install the Program synergy and the entry for Winwows isn't there. Here I Install the Bootloader from Mageia 2 RC. Now seems all OK.
If I understand correctly, with the live cd, grub gets installed, but can't find /boot/grub, while with the Mageia 1 dvd it works. My best guess, is that the drives are being seen in a different order, depending on how you're booting. Can you run "fdisk -l >fdisk.txt", and then attach the file to this bug report, twice. Once when booted from the live cd, once when booted from the working system? Also run "dmesg > dmesg.txt" from both, and attach those here as well.
(In reply to comment #5) > If I understand correctly, with the live cd, grub gets > installed, but can't find /boot/grub, while with the > Mageia 1 dvd it works. > > My best guess, is that the drives are being seen in a > different order, depending on how you're booting. > > Can you run "fdisk -l >fdisk.txt", and then attach the > file to this bug report, twice. Once when booted > from the live cd, once when booted from the working > system? > > Also run "dmesg > dmesg.txt" from both, and attach > those here as well. Here a littel bit more, at first what is in BIOS: Advanced IDE Configuration: Primary Master = Maxtor 6E040L0 (Windows System) Primary Slave = Samsung SP0802M (Windows Daten) Second Master = CD-ROM Secondary Slave = IBM-DJNA- 351520 (Linux Testen) Boot: 1st Boot Device = CD-ROM 2nd Boot Device = IBM-DNA-351520 3rd Boot Device = 1st Floppy Device Hard Disk Drives 1st Drive = IBM-DJNA-351520 2nd Drive = Maxtor 6E04020 3rd Drive = Samsung Sp0802M Now fdisk -l > fdisk.txt (on the live system): Disk /dev/hda: 41.1 GB, 41110142976 bytes 255 Köpfe, 63 Sektoren/Spur, 4998 Zylinder, zusammen 80293248 Sektoren Einheiten = sectors von 1 à 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xd63e96e5 Gerät boot. Anfang Ende Blöcke Id System /dev/hda1 * 63 80276804 40138371 7 HPFS/NTFS/exFAT Disk /dev/hdb: 80.1 GB, 80060424192 bytes 255 Köpfe, 63 Sektoren/Spur, 9733 Zylinder, zusammen 156368016 Sektoren Einheiten = sectors von 1 à 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x9bb99bb9 Gerät boot. Anfang Ende Blöcke Id System /dev/hdb1 * 2048 156364799 78181376 7 HPFS/NTFS/exFAT Disk /dev/hdd: 15.4 GB, 15377080320 bytes 255 Köpfe, 63 Sektoren/Spur, 1869 Zylinder, zusammen 30033360 Sektoren Einheiten = sectors von 1 à 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xecece1ff Gerät boot. Anfang Ende Blöcke Id System /dev/hdd1 * 63 15711569 7855753+ 83 Linux /dev/hdd2 15714279 30025484 7155603 5 Erweiterte /dev/hdd5 15714304 29222234 6753965+ 83 Linux /dev/hdd6 29224960 30025484 400262+ 82 Linux Swap / Solaris Here ist fdisk -l fdisk.tex (on the installed/running system) Disk /dev/sda: 41.1 GB, 41110142976 bytes 255 Köpfe, 63 Sektoren/Spur, 4998 Zylinder, zusammen 80293248 Sektoren Einheiten = sectors von 1 à 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xd63e96e5 Gerät boot. Anfang Ende Blöcke Id System /dev/sda1 * 63 80276804 40138371 7 HPFS/NTFS/exFAT Disk /dev/sdb: 80.1 GB, 80060424192 bytes 255 Köpfe, 63 Sektoren/Spur, 9733 Zylinder, zusammen 156368016 Sektoren Einheiten = sectors von 1 à 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x9bb99bb9 Gerät boot. Anfang Ende Blöcke Id System /dev/sdb1 * 2048 156364799 78181376 7 HPFS/NTFS/exFAT Disk /dev/sdc: 15.4 GB, 15377080320 bytes 255 Köpfe, 63 Sektoren/Spur, 1869 Zylinder, zusammen 30033360 Sektoren Einheiten = sectors von 1 à 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xecece1ff Gerät boot. Anfang Ende Blöcke Id System /dev/sdc1 * 63 15711569 7855753+ 83 Linux /dev/sdc2 15714279 30025484 7155603 5 Erweiterte /dev/sdc5 15714304 29222234 6753965+ 83 Linux /dev/sdc6 29224960 30025484 400262+ 82 Linux Swap / Solaris
(In reply to comment #6) > Here a littel bit more, at first what is in BIOS: Whenever adding information like this where the output is more than a dozen lines or so, please put the information into a file, and then attach it to the bug report, as a plain/text file. > Now fdisk -l > fdisk.txt (on the live system): > Disk /dev/hda: 41.1 GB, 41110142976 bytes > Here ist fdisk -l fdisk.tex (on the installed/running system) > Disk /dev/sda: 41.1 GB, 41110142976 bytes That makes the problem clear. It's the problem with pata/acpi module loading order. On the installed / running system, run (as root) "lspcidrake|grep IDE" and post the output.
Created attachment 2290 [details] output from lspcidrake|grep IDE>lspci.txt
Here the output. Sorry, when I was to blind to see at the botton "Attachments"
Please try booting the live cd with the kernel option rdloaddriver=pata_amd to confirm the drives change from /dev/hd? to /dev/sd* If it does, this bug can be closed as a duplicate of bug 4997.
CC: (none) => tmb
Created attachment 2298 [details] Machine drive related hardware information Output from lspcidrake, fdisk -l from liveCD, rescue and running system and information from DVD hardware detection tool.
The attachment didn't work like I expected. Was going to say I've also had problems booting after installing the latest Mageia2 RC x86_64 DVD. Right after a fresh install, the machine was not bootable. Also, if I use mcc to alter the boot menu, it becomes unbootable again. I have to edit the device.map and related files by hand to get a working system. Posting comment now so the attachment makes more sense. Will give more details in next comment.
CC: (none) => fcs
Sorry, new at this and making lot's of mistakes. I've had problems getting grub to work right for the last 3 installs on this machine. Grub sees the drives in a different order than BIOS. The machine had different hard drives installed for the previous 2 installs (sata only), but there were problems with the drive order during boot and could not find /boot/grub because of it. There were both IDE and sata drive present during this install. BIOS saw the first IDE drive (/dev/sdc) as 0x80, but the created device.map had the first sata drive listed as hd0 instead. Installing grub onto /dev/sda failed with error 17. After editing the device.map and related files to match the order shown by the hardware detection tool (DVD), reinstalling grub onto /dev/sda failed with error 15. Finally, installing grub onto /dev/sdc (hd0), after hand editing the device.map and related files to reflect how BIOS saw the drives, the boot menu loaded and the system booted correctly.
Created attachment 2299 [details] Machine drive related hardware information Updated output from lspcidrake, fdisk -l from liveCD, rescue and running system and information from DVD hardware detection tool.
Attachment 2298 is obsolete: 0 => 1
Created attachment 2300 [details] dmesg output from running system, rescue and KDE liveCD The system was installed from the x86_64 RC DVD. The output of dmesg from the liveCD was just for reference.
There are two separate problems here. The first, is the ide drive showing as /dev/hda, which indicates the module order is still wrong. The second is getting a consistent drive order. When you boot the live cd, press f6 to alter the kernel options. Due to a known bug, that can't get fixed in time for Mageia 2, the selection will jump down to install. Press the escape key, then the up arror, to get back to the boot option. Then press f6 again. Press enter, to see the default options. Add the kernel option "rdloaddriver=pata_amd" without the quotes, then press enter to boot the live cd. Confirm that fdisk -l now shows all of the hard drives as /dev/sd?. If that works, you should then be able to install from the running live cd. Ensure the boot loader gets installed to /dev/sda, and that that drive is the drive selected to boot from when you reboot. Getting the drives to be seen in a consistent order, varies depending on the bios. Most bios setup programs will allow you to specify the boot order. Ensure the order in that list, is the same as the order seen when running fdisk -l from the live cd. If that works for getting grub to find the initrd, but dracut fails to find the drive, you'll have to add the "rdloaddriver=pata_amd" to the kernel options in the grub menu.lst file, until we can figure out how to enusure the pata_amd module gets loaded before the sd module.
(In reply to comment #15) > Created attachment 2300 [details] > dmesg output from running system, rescue and KDE liveCD > > The system was installed from the x86_64 RC DVD. The output of dmesg from the > liveCD was just for reference. Missed this part when posting the latest reply. If booting from the dvd, use the same procedure for adding the kernel option, but you only have to press f6 once, with the dvd, and then enter, to get the default options before adding the rdloaddriver option.
Following these steps, press F6, adding reloaddriver=pata_amd, installing grub to sda and booting to it, failed with grub error 17. The DVD hardware detection tool shows 0x80 as the drive that becomes sdc, even when sda is the first in the BIOS boot order. I'm thinking it's a buggy BIOS, part of the Murphy curse. I formatted one of the, otherwise useless, fat partitions for this install, leaving the working system intact. Just had to set BIOS to boot sdc and I have a working system again. Altering the boot menu with mcc sets hd0 back to sda in all the config files, so all changes need to be done via text editor. I can live with that. This was previously my primary machine and only had (3) sata drives installed. Both Mageia1 and Mageia2's grub got the BIOS drive id order of those drives wrong as well. Trying to chainload between the different bootloaders was near catastrophic.
Adding Colin to the cc list. Whatever fix was done to get pata_via to load before pata_acpi also needs to be done to ensure pata_amd gets loaded before the module sd.
CC: (none) => mageia
Created attachment 2302 [details] Adventures in chainloading. reloaddriver=pata_amd in the previous comment it a typo. Adding this as an attachment, since it's about a chainloading problem. Same machine, different drives.
Hmm, I can't actually remember what was done before here before. I don't actually remember changing anything specifically.
Installing from any of the final LiveCD's and adding the kernel parameter rdloaddriver=pata_amd, diskdrake shows all the drives in the correct BIOS id order. The installs were quick and the grub menu boots into the newly installed system. Once the new system loads, diskdrake shows them in the wrong order again, e.g: 0x80 = sdc, 0x81 = sdd, 0x82 = sda and 0x83 = sdb. Both the i586 and 64 bit dvd's had the drive order wrong from the start and neither were bootable after install. I was testing out final UE1 iso installs and didn't stop to collect dmesg and fdisk information from each of them. I expect they're the same as what I supplied in previous attachments. Let me know if there's any information needed and I'll gladly supply it.
(In reply to comment #22) > Installing from any of the final LiveCD's and adding the kernel parameter > rdloaddriver=pata_amd, diskdrake shows all the drives in the correct BIOS id > order. The installs were quick and the grub menu boots into the newly installed > system. Once the new system loads, diskdrake shows them in the wrong order > again, e.g: 0x80 = sdc, 0x81 = sdd, 0x82 = sda and 0x83 = sdb. > > Both the i586 and 64 bit dvd's had the drive order wrong from the start and > neither were bootable after install. > > I was testing out final UE1 iso installs and didn't stop to collect dmesg and > fdisk information from each of them. I expect they're the same as what I > supplied in previous attachments. Let me know if there's any information needed > and I'll gladly supply it. Can you modify the grub entry on the installed system to include the rdloaddriver option, and see if that changes the order?
That didn't work either. Everything is fine until the system boots from the hard drive, then the drives show up out of order again. I'd tried adding the same kernel parameter with the DVD install and rescue and that failed as well. The liveCD gave a false sense of hope since it booted up cleanly after install. The DVD install didn't get that far. Using mcc to reinstall grub, without any changes and rebooting the liveCD install fails. Looking in the wrong places. I noticed pata_amd loaded before dracut started loading it's drivers on the liveCD install. I'll attach the dmesg output from that (after I save this comment).
Created attachment 2323 [details] Installing from KDE liveCD with added kernel parameter rdloaddriver=pata_amd This is the dmesg output taking during the Mageia2 pre-final KDE liveCD install with rdloaddriver=pata_amd added to the kernel parameters.
I'm not sure if this is the sam problem I've got, but having Mageia installed next to Windows makes Windows bootloader MBR crash & I can't repair it without reinstalling.
CC: (none) => kristoffer.grundstrom1983
I'm replicating this on the Mageia-2-LiveCD-KDE4-Europe2-x86_64-CD. but its not a Mageia or mdv bug, i have had this for a few years on this m/board with various distros. The board has ide and sata hard drives which do seem to get switch between grub install and first reboot. It catches me every time, a quick hack is to hit the F11 key in the bios screen (different key combo for different bios versions) and choose the ide drive to boot from. Looking at the live and installed from live hardware info in controll centre the live cd system see the drives as hda for the ide hard drive and sda for the sata, while the installed from running cd sees both hard drives as sda, sdb and swaps the physical drive Dave Hodgins your comment 16 fix did not work even though the live version and installed version sees all the hd's as sd?. I could go into the "set up boot system in control centre and change grub to boot the correct drive
CC: (none) => led43john
I have just had another look at this with md5sum: 720d93a589120abc27a9ec80a54c04f4 Mageia-2-LiveCD-KDE4-Europe2-x86_64-CD.iso. I hit the same problem HD's being seen as sd? / hd? when live booted. rebooting with the loaddriver=pata_amd sets the HD's to sd? and as this m/board will only boot from ide, not ide or sata i told drakx to install grub on the ide drive and the system rebooted ok.
Adding the "rdloaddriver=pata_amd" kernel option worked for me!
Status: NEW => RESOLVEDCC: (none) => joedeso.heatonResolution: (none) => FIXED
(In reply to comment #29) > Adding the "rdloaddriver=pata_amd" kernel option worked for me! you are not the reporter
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Having to add the rdloaddriver=pata_amd kernel parameter, both when installing and in the grub menu.lst on the installed system makes this a Mageia 2 bug, that will apply to cauldron as well, once it's opened. Norbert, In order to get a consistent drive order, here are the steps I use. When booted from a live cd (not a usb stick), first ensure all ide drives show up as sd? not hd?. If they do show up as hd?, you need to reboot and add the kernel option, as above. Make a list of which drive is sda, sdb, etc. Reboot, and go into the bios setup, and check the order of the drives in the boot priority list. Modify the order, if needed, so that it is the same as the order seen when booted from a live cd. Never use the bios option to select which drive to boot from, as that will alter the drive order before the os gets control, which will confuse things. I find it best to always install grub to the root filesystem of each linux installation, and use the gag bootloader on the mbr of sda, to select which install to boot. When installing the boot manager, specify that you are booting from sda, so that it will build the device map properly.
Keywords: NEEDINFO => (none)Version: Cauldron => 2
1. Changing version to cauldron since we can't fix installer for released versions (that's what alphas and betas are for) 2. Is this bug still valid with latest installer? (Mageia 4 alpha 1 as of today)
Version: 2 => Cauldron
Please reply to comment #33 or close as old.
Closing as old and the machine that displayed the problem has been retired.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED