Bug 5809

can you add the output of fdisk -l ?

CC: (none) => thierry.vignaud
Source 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 => RESOLVED
CC: (none) => joedeso.heaton
Resolution: (none) => FIXED

(In reply to comment #29)
> Adding the "rdloaddriver=pata_amd" kernel option worked for me!

you are not the reporter

Status: RESOLVED => REOPENED
Resolution: 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.

Keywords: (none) => NEEDINFO

Closing as old and the machine that displayed the problem has been retired.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED