On 2007/08/24 20:46 (GMT+0200) Carlos E. R. apparently typed:
Friday 2007-08-24 at 13:51 -0400, Felix Miata wrote:
On 2007/08/24 15:18 (GMT0200) Andreas Jaeger apparently typed:
"Carlos E. R." <robin.listas@telefonica.net> writes:
Question: Can 10.2 coexist in the same PC with 10.3 beta? Regarding this problem, I mean.
It should - Hannes, can you comment?
Dunno why Carlos should ask. I have 4-5 systems with both Factory and 10.2, 10.1 and/or 10.0, along with several other distros, and windoz, and OS/2, and DOS, and more than 15 partitions per PATA HD, each. As long as partition tables remain standard, no OS depends on how any other is configured.
I ask because I don't know and I'm afraid to try. I have no idea what will happen to a disk with 18 partitions when the system does not see the last two. Will it think that is empty space?
Using brokenmodules=ata_piix to install causes traditional drivers to be used instead of libata, which means everything works as before. If Andreas is referring to some other kind of workaround, then I don't know. Compare to Fedora 7, where its installer is incapable of proceeding beyond the partitioning phase on a system with a disk having more than 15 partitions, unless it is allowed to erase all current partitioning.
Are scsi partitions defined differently, assigning a nibble (4 bits) to the partition number, and so when it finds a partition table needing a byte will everything in the table be pushed over another 4 bits? Because the only reason I can think of limiting to 16 items is because a record somewhere is limited to 4 bits.
IIUI, the SCSI major of 8 uses too many bits, such that insufficent bits remain to count past 15, a combined record limit of one byte.
Will it overwrite the grub code with references to sda somehow, so that later my main system wanting to use hda will fail?
AFAIK, Grub's only installation facility limitation here is the existence of a device. If the system can't provide one for a partition >15, Grub can't install to it. As long as you have something booted that can provide access to the device (pre-libata, a pre-10.2 live CD, Knoppix, etc.), then you can use that to install Grub, presuming there's any reason to install it again on a system that already has it installed somewhere. I keep generic MBR code installed, and only put Grub on partitions. I have one partition per system I use as /boot for one distro, either as an active primary partition, or as the first logical, to which I chainload from another boot loader. I avoid letting any installer or installed OS mess with the grub directory on that partition. Additional installations get their boot loader installed to their /, and I either chainload from my primary loader, or use my /boot partition's Grub installation to load its kernel and initrd directly. IOW, there's no good reason to have an additional installation write to the MBR, or to any existing partition that it isn't told to use.
Notice that the same grub instance will have to boot both 10.2 and 10.3 (or rather, the grub in the mbr will have to start another mbr for the other system). Ie, a 10.2 grub in the mbr will start one of two other grubs in different boot partitions, each starting 10.2 (main) or 10.3 (beta).
Use 10.2 as your primary boot loader. Install 10.3's Grub on its own /, and use 10.2 to chainload to 10.3. Optionally, have 10.3 install no boot loader at all, and just load the 10.3 kernel and initrd directly from 10.2's Grub.
You see, I'm completely ignorant on this issue, and because I'm ignorant I'm afraid. Just the same as a village in my country have rejected the installation of a new cellular phone aerial because they think it is dangerous and "radioactive" (and thus, they have no phone service at all). Ignorance breeds fear. and I'm afraid about this new scsi issue.
It's easier with spare systems and/or spare HDs to experiment on. I have many, and do a lot of experimenting. -- " It is impossible to rightly govern the world without God and the Bible." George Washington Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org