Felix Miata writes:

On 2007/09/20 00:44 (GMT-0600) bugzilla_noreply@novell.com apparently typed:

...

https://bugzilla.novell.com/show_bug.cgi?id=218122

...

--- Comment #25 from Andreas Jaeger 2007-09-20 00:44:01 MST --- See the release notes

They don't say what one should find in /dev as a result of running activate_dm_linear or what if anything people running >15 on SATA can do or expect.

Ignore activate_dm_linear, it's really not working. Btw. you even get a popup which advises to use "hwprobe=-modules.pata".

Tentative release notes for 10.3 seem to be nicely hidden, not yet on http://en.opensuse.org/Release_Notes. It would be nice to see http://www.suse.com/relnotes/i386/openSUSE/10.2/RELEASE-NOTES.en on http://en.opensuse.org/Factory and/or http://en.opensuse.org/Development_Version

...

(and bug # 305095)-

I've been following that and every other related bug (keyword >15). Most of what's in them seems pretty cryptic. I would expect running activate_dm_linear /dev/sda at the start of an RC1 install should produce some evidence that anything happened in /dev, but I don't see it.

As I've said: It misses some files in the inst.sys and therefore just does not work in RC1.

...

and use "hwprobe=-modules.pata" to not use libata at all.

I don't see how that could be of any help on SATA systems with >15 partitions. I already use it on PATA.

A SATA system with > 15 partitions was never ever supported! If you want that, then use LVM. the activate_dm_linear solution would only help with updating existing PATA systems.

...

The workaround from Hannes needs some more work we will do for RC2 - but even then it will not be nicely integrated and only something for a real hacker.

From what I can tell in the relevant bugs, activate_dm_linear seems simple enough for an unreal hacker to manage. I've been ready for quite some time if only I could find functional guidance on what to do or evidence that anything resulted from what I did.

...

This needs more work for 11.0.

Obviously. :-p I feel like the progress so far is behind a locked door to which the public key is hidden by secret code, or doesn't exist.

...

The general advise really is to use hwprobe=-modules.pata - this works just fine.

On SATA?

What is FATE?

FATE is our FeAture Tracking Tool Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On 2007/09/20 21:00 (GMT+0200) Andreas Jaeger apparently typed:

Felix Miata wr0te:

...

On 2007/09/20 00:44 (GMT-0600) bugzilla_noreply@novell.com apparently typed:

...

...

https://bugzilla.novell.com/show_bug.cgi?id=218122

...

...

--- Comment #25 from Andreas Jaeger 2007-09-20 00:44:01 MST --- See the release notes

...

They don't say what one should find in /dev as a result of running activate_dm_linear or what if anything people running >15 on SATA can do or expect.

Ignore activate_dm_linear, it's really not working.

Btw. you even get a popup which advises to use "hwprobe=-modules.pata".

I haven't seen that yet, but I haven't been past the first YaST screen in over a month.

...

Tentative release notes for 10.3 seem to be nicely hidden, not yet on http://en.opensuse.org/Release_Notes. It would be nice to see http://www.suse.com/relnotes/i386/openSUSE/10.2/RELEASE-NOTES.en on http://en.opensuse.org/Factory and/or http://en.opensuse.org/Development_Version

...

...

(and bug # 305095)-

...

I've been following that and every other related bug (keyword >15). Most of what's in them seems pretty cryptic. I would expect running activate_dm_linear /dev/sda at the start of an RC1 install should produce some evidence that anything happened in /dev, but I don't see it.

As I've said: It misses some files in the inst.sys and therefore just does not work in RC1.

If that's referring to https://bugzilla.novell.com/show_bug.cgi?id=326692 I'd like some notification when it hits the factory mirrors instead of waiting over a week for RC2.

...

...

and use "hwprobe=-modules.pata" to not use libata at all.

...

I don't see how that could be of any help on SATA systems with >15 partitions. I already use it on PATA.

A SATA system with > 15 partitions was never ever supported!

I well understand that. However https://bugzilla.novell.com/show_bug.cgi?id=218122 summary says "Support more than 15 partitions on libata", not "Support more than 15 partitions on PATA on libata". Unless I grossly misunderstand the nature of libata, I expect libata to mean libata HD support regardless whether used for PATA or SATA. If I'm not wrong in my understanding, and yet >15 on SATA is unlikely to be supported now or within next year or so, then the summary of that bug seems to be wrong, and should be changed to remove any implication of applicability to SATA either now or in the future.

If you want that, then use LVM.

That may be fine for most people, as that's apparently what the kernel developers expect, as well as the only offering for Fedora users. It's not so good for people with a tried and true multiboot creation, maintenance, backup and restore strategy based upon cloning/copying partitions and a minimal number of physical hard disks per system. LVM is no solution to many of us with true multiboot of multiple versions of Linux and other operating systems (more than ~3 total). LVM is not OS agnostic. On systems that use it, systems that don't understand it have to work around it, which to my knowledge as a user of >15 on multiple systems for many years is simply not practical. IOW, if >15 is never to be supported on SATA, those of us committed to >15 are committed to having to buy converter gadgets to use SATA drives as PATA drives as the old PATA drives need replacement[1], and to keeping legacy systems operational well beyond expected lifetimes, since new motherboards omit PATA controllers, and PATA add-in cards are treated as SCSI cards not under boot order control of the PC system BIOS. It's really absurd that as HD sizes continue to escalate that users should be forced to using ever stupidly larger partitions due to the kernels arbitrary limitation of 14 replacing the traditional 62. A limit of 14 on a 500GiB drive means either average partition size over 10 times the size of my current average partition size, or wasting 80% or more of the disk to keep partitions to a manageable size for backup and pruning purposes. [1] Seagate, world's largest HD supplier, has already announced imminent cessation of PATA drive production.

the activate_dm_linear solution would only help with updating existing PATA systems.

Does this mean it could not be applied to SATA, or merely that was not the intent of creating a solution for upgrading systems with >15 on PATA?

...

...

The workaround from Hannes needs some more work we will do for RC2 - but even then it will not be nicely integrated and only something for a real hacker.

...

From what I can tell in the relevant bugs, activate_dm_linear seems simple enough for an unreal hacker to manage. I've been ready for quite some time if only I could find functional guidance on what to do or evidence that anything resulted from what I did.

...

...

This needs more work for 11.0.

...

Obviously. :-p I feel like the progress so far is behind a locked door to which the public key is hidden by secret code, or doesn't exist.

...

...

The general advise really is to use hwprobe=-modules.pata - this works just fine.

On Mandriva Cooker 2008 it's conceptually simpler, even though it requires an extra step, because it's easier to remember. On the kernel line one appends the six letters "noauto", after which the installer allows explicit selection of the driver to be used for PATA.

...

On SATA?

...

What is FATE?

FATE is our FeAture Tracking Tool

Is it, as it applies to OpenSUSE, Novell internal access only? If not, an URL to it's OpenSUSE-applicable home would be nice. On 2007/09/20 21:01 (GMT+0200) Andreas Jaeger apparently typed:

Carlos E. R. wrote:

...

The Thursday 2007-09-20 at 09:19 -0400, Felix Miata wrote:

...

...

They don't say what one should find in /dev as a result of running activate_dm_linear or what if anything people running >15 on SATA can do or expect.

...

I think they would appear under /dev/mapper/. I have used the device mapper thing previously (for encrypted filesystems in old twofishSL92 format), but I know pretty little about it, close to nothing. I believe it can be a very interesting piece of gadgetry, but I haven't seen any user documentation. A howto.

Hannes promised me to write a howto in the openSUSE wiki.

Excellent. Thanks in advance.

But with RC1 it just does not work because two binaries are missing in the inst.sys,

I'm anxiously awaiting a factory mirror sync that includes this. Lack of ability to test this has previously just missed beta/rc release cuts a few times already. It seems Hannes has been the only one in a position to even try out his work. -- "It yet remains a problem to be solved in human affairs, whether any free government can be permanent, where the public worship of God, and the support of religion, constitute no part of the policy or duty of the state in any assignable shape." Chief Justice Joseph Story Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2007/09/20 19:34 (GMT-0300) Juan Erbes apparently typed:

2007/9/20, Felix Miata wrote:

...

Andreas Jaeger wrote:

...

...

If you want that, then use LVM.

...

That may be fine for most people, as that's apparently what the kernel developers expect, as well as the only offering for Fedora users. It's not so good for people with a tried and true multiboot creation, maintenance, backup and restore strategy based upon cloning/copying partitions and a minimal number of physical hard disks per system.

From the backup point of view, is more secure to use 2 HD, rather than only one. Because if You has only one HD, and it got mechanicals or controller (internal) problems, the backup of one partition in other of the same disk, goes useless.

Additional safety of more disks unless using RAID is an illusion, and then with RAID you're right back to the limit of 14. To get 28 and safety means you need 4 disks: 2 for each set of 14 partitions, and matching devices for the RAID1. Now with 4 disks you have 4 times the opportunity for hardware failure, and 4 times the cost.

If You use 2 Hard Disks, then the problem of the 15 partitions is resolved, because You can obtain 30 partitions from the 2 HDs.

30 takes 3 devices, because 15 is only the name of the last device, not the count, which is 14, because on sd[1-4] only 3 can have filesystems. What makes you think 30 is enough? I have 42+, and don't want to buy 3 times as many disks and the larger power supplies to feed them, and the extra electricity/pollution to run them full time. My backups involve (small) part time usage disks, typically shared among multiple systems. There are many ways to skin the backup cat, and multiple partitions is a choice of no small number, including myself. -- "It yet remains a problem to be solved in human affairs, whether any free government can be permanent, where the public worship of God, and the support of religion, constitute no part of the policy or duty of the state in any assignable shape." Chief Justice Joseph Story Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-09-20 at 19:37 -0400, Felix Miata wrote:

Additional safety of more disks unless using RAID is an illusion, and then with RAID you're right back to the limit of 14. To get 28 and safety means you need 4 disks: 2 for each set of 14 partitions, and matching devices for the RAID1. Now with 4 disks you have 4 times the opportunity for hardware failure, and 4 times the cost.

I think we might do something: use two disks in software raid configuration. Perhaps some non raid partitions (/boot?), then a big raid partition having the rest of the disk. This would appear as /dev/md0. Now, md0 can be partitioned. From /usr/src/linux/Documentation/devices.txt: 9 block Metadisk (RAID) devices 0 = /dev/md0 First metadisk group 1 = /dev/md1 Second metadisk group ... Here, the minor represents the device. I'm not sure how would partitions inside appear. I know it can be partitioned because fdisk says so: ] nimrodel:~ # fdisk /dev/md0 ] Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel ] Building a new DOS disklabel. Changes will remain in memory only, ] until you decide to write them. After that, of course, the previous ] content won't be recoverable. ] ] ] The number of cylinders for this disk is set to 781136. ] There is nothing wrong with that, but this is larger than 1024, ] and could in certain setups cause problems with: ] 1) software that runs at boot time (e.g., old versions of LILO) ] 2) booting and partitioning software from other OSs ] (e.g., DOS FDISK, OS/2 FDISK) ] Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) I haven't tried it, not further that point. It is not ideal, of course, but... :-? might work? Of course, you can use a degraded raid of only one side, ie, one disk.

30 takes 3 devices, because 15 is only the name of the last device, not the count, which is 14, because on sd[1-4] only 3 can have filesystems.

Ouch. I hadn't noticed that "detail". We usually don't count the extended partition. Of course, we can only use partition 1..15, of which one of them is not writeable. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG8w58tTMYHG2NR9URAj9AAKCAMDcF4F9h1rv2nzfz8tFbEXGdpACbBZzh +6JLKaa26Xl+NS/mTcusVQQ= =WYf0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-09-21 at 10:02 +0200, Andreas Jaeger wrote: ...

More than 15 are supported with LVM since ages. The problem we're talking about is migration - and therefore the bug is called on libata. Seeing your confusion, I guess it should have been stated "libata for PATA devices".

Unfortunately, LVM means repartitioning every thing, and it opens another can of worms, I'm afraid.

Hannes has to answer the rest of the email - and I guess you should start this discussion on the Linux kernel mailing list or on the libata development list. We're speaking about a limitation of the upstream kernel,

I know. A very unfortunate limitation. A bad decission, IMHO. But I'm not knowledgeable enough to participate in those lists. I'm just a... let's say, a power user. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG85/CtTMYHG2NR9URArocAJ0dZ2cogrk3ZQRjmDQJlwpP2frxKQCfTCkP YMdV43kd4rmavPFFCzMgMhE= =WBNi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2007/9/21, Felix Miata :

On 2007/09/21 10:02 (GMT+0200) Andreas Jaeger apparently typed:

...

I guess you should start this discussion on the ... libata development list.

I don't see any such list on http://vger.kernel.org/vger-lists and Google doesn't seem to be able to find one for me elsewhere. Do you have subscription instructions or a link thereto?

You can search with "libata lkml", and then appear for example: http://lkml.org/lkml/2007/7/3/255 You can see that one of the involved developers are Tejun Heo, from Novell. You can register the bug in the bugzilla from the kernel: http://bugzilla.kernel.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2007/09/21 04:02 (GMT-0400) Andreas Jaeger apparently typed:

* Use some hacks with devicemapper to support more than 15 partitions. Bug 218122 is one such hack. We wanted to use it for the migration issue. It was not intented for new installations - for those, please use LVM!

I tried again according to https://bugzilla.novell.com/show_bug.cgi?id=218122#c18 'activate_dm_linear /dev/sda' as soon as GUI YaST installer gave me the language selection screen. I still don't see any mapper devices added to /dev, and it isn't possible to return to YaST to test. Alt-F7 just gives a black screen. :-( -- "It yet remains a problem to be solved in human affairs, whether any free government can be permanent, where the public worship of God, and the support of religion, constitute no part of the policy or duty of the state in any assignable shape." Chief Justice Joseph Story Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org