Description of problem: I have described my issue in length in this forum post: https://forums.mageia.org/en/viewtopic.php?f=8&t=4451 Briefly, when a PATA disk gets added to a setup with two existing SATA disks, it is correctly identified (using fdisk -l or MCC-Local Disks) as /dev/sdc in Mageia2 but incorrectly identified as /dev/sda in a Cauldron installation, which causes problems with kernel updates. Also the grub identification is different, in M2 it's: (hd0) and (hd1), in Cauldron it's: (hd1) and (hd2) [Note:I have omitted the partition references here for clarity. The PATA disk is only being used for data.] I have indicated that I think it might be due to the new grub package in Cauldron compared to the package in Mageia2, but this purely because I get boot issues and I don't have the knowledge to correctly identify what is happening. How reproducible: Every time Steps to Reproduce: 1.Set up installations of Mageia2 and Cauldron on SATA disks 2.Confirm correct identification, for both installations, of the two disks, i.e. /dev/sda and /dev/sdb 3.Add a PATA disk to this setup 4.Confirm correct identification, for both installations, of the three disks, i.e./dev/sda, /dev/sdb and /dev/sdc Reproducible: Steps to Reproduce:
I added Thomas Backlund in CC list I give you my hypothesis : No it's probably not a grub problem ! It perhaps may be related to the : ata-prefer-ata-drivers-over-ide-drivers-when-both-are-built.patch that is added in Cauldron kernels and last updated Mageia2 Kernels If you use the first kernel provided with Mageia2 your PATA disk is /dev/sdc , unless you add the kernel option "rdloaddriver=pata_xxx" (xxx being via or amd or jmicron or piix depending of the mainboard you have) : in this case it will appear as /dev/sda If you use an updated kernel of Mageia2 (built with this patch) it will appear as /dev/sda !!! In Cauldron it will appear as /dev/sda The patch was needed to allow IDE CDdrives to appear correctly in /dev/ as sr0 and eventually sr1 instead of wrongly hdc or hdd To confirm this hypothesis, 1) Maybe you may try to use an updated kernel in your Mageia2 and observe that your Pata disk changes from /dev/sdc to /dev/sda... 2) You may use the original kernel of Mageia2 and add the boot option rdloaddriver=pata_xxx" (xxx being via or amd or jmicron or piix depending of the mainboard you have) : to know which module you have run "lspcidrake|grep IDE"
CC: (none) => philippedidier, tmb
Hi Philippe, I did update my kernel to the newest version this morning: [root@localhost ~]# uname -a Linux localhost 3.4.32-desktop-2.mga2 #1 SMP Mon Feb 18 21:13:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux but my PATA drive is still /dev/sdc, which is good for me. My PATA is using module: [root@localhost ~]# lspcidrake|grep IDE pata_jmicron : JMicron Technology Corp.|JMB368 IDE controller [STORAGE_IDE] Here is fdisk -l, my PATA disk is 82GB: [root@localhost ~]# fdisk -l Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000efc87 Device Boot Start End Blocks Id System /dev/sda1 * 63 59842124 29921031 7 HPFS/NTFS/exFAT /dev/sda2 59842560 100791809 20474625 83 Linux /dev/sda3 100792320 104872319 2040000 82 Linux swap / Solaris /dev/sda4 104873984 156296384 25711200+ 83 Linux Disk /dev/sdb: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000bf4c4 Device Boot Start End Blocks Id System /dev/sdb1 63 82092149 41046043+ 7 HPFS/NTFS/exFAT /dev/sdb2 * 82094080 105529343 11717632 83 Linux /dev/sdb3 105529344 135813509 15142083 83 Linux /dev/sdb4 135815168 156296384 10240608+ 83 Linux Disk /dev/sdc: 82.0 GB, 81964302336 bytes 255 heads, 63 sectors/track, 9964 cylinders, total 160086528 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xad551bd9 Device Boot Start End Blocks Id System /dev/sdc1 * 63 82638359 41319148+ 7 HPFS/NTFS/exFAT
To answer you point 2), I booted from the original kernel, adding rdloaddriver=pata_jmicron and my PATA disk is still /dev/sdc
So my hypothesis is wrong. Sorry to make you spend time to refute it ... Nevertheless it will lead to find other explanations
No problem. Every investigation is a process of elimination.
Hi Steve, I have read your forum posts and can understand the mess you are in :\ Grub legacy relies on device assignments. (/dev/sda etc) Unfortunately it derives these in part from the bios. All bioses are not equal, hence the device assignments are no better than guesses by grub, based on unreliable information. What a system finally decides about device assignments is "correct" for that system. So, you have added an extra drive. This has thrown the whole mix of device identifiers into confusion. It would probably be possible to eventually untangle the mess, but really not worthwhile, as this is really not the best way to handle multi-booting. Also problems are only likely to get worse. It would be better to use a small (50MB) grub (preferably grub2) partition (which is not related to any of your systems) which has a hand made menu capable of booting any of your systems. No system's own menu would need to boot a different system - therefore no conflicts or confusion. The major advantage of using grub2 for this, is that grub2 does not need any reference to device assignments, it can search out either uuid's or labels from all your drives/partitions and boot the correct one. How you boot each system is up to you, chainloading would be the way to go for linux systems with grub legacy, multiboot is the way to go for grub2 systems. This way kernel updates only affect the system in question - the "master" bootloader partition is never mounted by ANY system. (unless you need to edit it) If you decide to change to this approach and have any questions then please ask them in that forum topic and I will try to help. I will comment there now so that I get notifications. Barry
CC: (none) => zen25000
Sorry, but this bug saw no action since over 2 yrs ago. No cauldron package has stayed the same since then. Closing as OLD Please reopen if this report is still valid for _current_ cauldron and/or fully updated Mageia 4
Status: NEW => RESOLVEDResolution: (none) => OLD