Re: partman problems (sparc and elsewhere)
When trying to create a logical volume, I get the error: Striped: Required device-mapper target(s) not in your kernel -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Choosing another menu item that fails totaly can get it back to a consistant state. Choosing a menu item that partly succeds (such as lvm) can make things even crazier. Can you give more details about this? I was able to create a volume group, but not logical volumes. When I deleted the physical volumes and created ext3 partitions, I wound up with what was showing as a bunch of physical volumes. (Maybe part of the problem was I was trying to use the entire disk as a physical volume, which overwrote the disk label.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 10:51:42PM +0100, Sven Luther wrote: I still don't get why the kernel should complain though ? Because it can not reread the partition table if it uses some of the partitions for something - swap (partman automaticaly activates any existing swap to allow small memory installs), LVM or RAID phisical volume or mounted partition (used as installation medium). Consider this: 1. The user creates the necessary partitions and goes to configure LVM 2. Partman writes the partition table to the disks and invokes the LVM configurator 3. The configurator creates logical volumes. At that stage the kernel is no more able to reread the partition table 4. The user specifies file systems and mount points for the logical volumes but decides / to be in a regular partition rather than in a logical volume 5. Partman sets_system_type for the partition for / 6. When the user finishes partman writes the partition tables to the disks. The kernel complains. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 03:36:14PM +0100, Sven Luther wrote: Or partition we are mounting without formating if its type doesn't correspond to the file system it contains. Well, i don't think so, not automatically at least. Partman has to do something with the partition type of such partitions. Consider this: 1. The user specifies some partition to be new-world boot partition. 2. Partman sets the flags and file system apropriately 3. Parted changes the partition type in its internal structures 4. The user changes his mind and decides to use the existing file system in this partition. It was ext3 and the partititon type needs to be restored. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Thu, Dec 02, 2004 at 12:55:18PM +0100, Sven Luther wrote: You are meaning that if the kernel uses one of the partitions of the partition table, it can then not modify the other ones ? Yes. 6. When the user finishes partman writes the partition tables to the disks. The kernel complains. Mmm. Then the kernel is buggy. :-) This bug is probably not going to be fixed. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Mon, Nov 29, 2004 at 11:40:37PM +0100, Sven Luther wrote: BTW, i also believe that this is a problem on pegasos. Doing a ped_partition_set_system each time we put a filesystem on a partition may be the thing to do, do you do this ? Yes. Example, on pegasos, i was going to install an ext3 filesystem in the old swap partition. The old partition was marked as type swap, and this was not changed, and thus the ext3 filesystem was not readable from the firmware, which thought it contained swap, and since there are no driver for this, it failed. The following happens: 1. The partition type is swap, but it contains ext3 2. parted reports the partition as ext3 partition 3. you tell partman to use this partition as ext3 partition 4. partman does ped_partition_set_system(ext3) for it 5. however partman sees that the partition was ext3 previously and concludes that the partition table is unchanged. Thats why partman doesn't write it to the disk The API of parted doesn't provide functions to access the partition type and thats why partman has no way to find out whether your assignment of the partition as ext3 requires changes in the partition table or not. The solution (not nice) would be to write the partition tables unconditionaly. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 04:20:17PM +0200, Anton Zinoviev wrote: On Mon, Nov 29, 2004 at 11:40:37PM +0100, Sven Luther wrote: BTW, i also believe that this is a problem on pegasos. Doing a ped_partition_set_system each time we put a filesystem on a partition may be the thing to do, do you do this ? Yes. Example, on pegasos, i was going to install an ext3 filesystem in the old swap partition. The old partition was marked as type swap, and this was not changed, and thus the ext3 filesystem was not readable from the firmware, which thought it contained swap, and since there are no driver for this, it failed. The following happens: 1. The partition type is swap, but it contains ext3 2. parted reports the partition as ext3 partition 3. you tell partman to use this partition as ext3 partition 4. partman does ped_partition_set_system(ext3) for it 5. however partman sees that the partition was ext3 previously and concludes that the partition table is unchanged. Thats why partman doesn't write it to the disk Ah, no, it was a swap paritition previously, not an ext3. The API of parted doesn't provide functions to access the partition type and thats why partman has no way to find out whether your assignment of the partition as ext3 requires changes in the partition table or not. Yeah, this may change in the future though, but well. The solution (not nice) would be to write the partition tables unconditionaly. Why is it not-nice ? It is a good solution, either that or have some way to set it by hand. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 02:25:02PM +0100, Sven Luther wrote: Ah, no, it was a swap paritition previously, not an ext3. Are you sure that it didn't contain ext3 signatures already? If it contained swap but partman didn't update the partition type then this must be some unknown bug. (Well, it must be unknown for the present version of partman. In the past partman would not update the partition type in this case.) The solution (not nice) would be to write the partition tables unconditionaly. Why is it not-nice ? It is a good solution, either that or have some way to set it by hand. Because: 1. Partman may not write all partition tables - some of them may be for example USB disk we are installing from 2. Consequently partman may try to write only the partition tables that contain partitions that will be used somehow by the new Debian (partitions with some file system, with swap or booting partition) 3. But if the user uses LVM or RAID partman has to write the partition tables before it knows which of them will be used. Latter they are already in use and the kernel complains about changes in them Yes, these problems probably can be got round but not in a clear way. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 04:48:32PM +0200, Anton Zinoviev wrote: On Wed, Dec 01, 2004 at 02:25:02PM +0100, Sven Luther wrote: Ah, no, it was a swap paritition previously, not an ext3. Are you sure that it didn't contain ext3 signatures already? If it contained swap but partman didn't update the partition type then this must be some unknown bug. (Well, it must be unknown for the present version of partman. In the past partman would not update the partition type in this case.) Mmm. Need to investigate, but anyway, the below should solve this reasonably. The solution (not nice) would be to write the partition tables unconditionaly. Why is it not-nice ? It is a good solution, either that or have some way to set it by hand. Because: 1. Partman may not write all partition tables - some of them may be for example USB disk we are installing from So what ? 2. Consequently partman may try to write only the partition tables that contain partitions that will be used somehow by the new Debian (partitions with some file system, with swap or booting partition) Well, the idea is to write the system type only for the partition we are formating, not ? 3. But if the user uses LVM or RAID partman has to write the partition tables before it knows which of them will be used. Latter they are already in use and the kernel complains about changes in them And ? You simply do the system flag writing at the same time you format the partitions, provided they are not on a LVM or RAID device ? Yes, these problems probably can be got round but not in a clear way. Is the above not a clear way ? What would you find cleaner ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 03:07:54PM +0100, Sven Luther wrote: 1. Partman may not write all partition tables - some of them may be for example USB disk we are installing from So what ? The following is a quote from http://lists.debian.org/debian-boot/2004/debian-boot-200402/msg01788.html * When it writes the partition data, I always get this error from partman: The kernel was unable to re-read the partition table on /dev/scsi/host1/bus0/target0/lun0/disk (Device or resource busy). That is the usb device I booted the installer from, and I did not tell partman to do anything with it (nor does it), so I do not know why it displays this message. 2. Consequently partman may try to write only the partition tables that contain partitions that will be used somehow by the new Debian (partitions with some file system, with swap or booting partition) Well, the idea is to write the system type only for the partition we are formating, not ? Or partition we are mounting without formating if its type doesn't correspond to the file system it contains. 3. But if the user uses LVM or RAID partman has to write the partition tables before it knows which of them will be used. Latter they are already in use and the kernel complains about changes in them And ? You simply do the system flag writing at the same time you format the partitions, provided they are not on a LVM or RAID device ? At the time when some partition is being formatted (or simply sceduled for mounting) the partition table may already contain physical volumes of activated volume groups. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 05:31:15PM +0200, Anton Zinoviev wrote: On Wed, Dec 01, 2004 at 03:07:54PM +0100, Sven Luther wrote: 1. Partman may not write all partition tables - some of them may be for example USB disk we are installing from So what ? The following is a quote from http://lists.debian.org/debian-boot/2004/debian-boot-200402/msg01788.html * When it writes the partition data, I always get this error from partman: The kernel was unable to re-read the partition table on /dev/scsi/host1/bus0/target0/lun0/disk (Device or resource busy). That is the usb device I booted the installer from, and I did not tell partman to do anything with it (nor does it), so I do not know why it displays this message. So what ? you only change the type of the partitions you format. Since you don't touch the usb device, it should be no problem, and if you can't change the partition type of a partition you are formating, you have worse problems, i believe. 2. Consequently partman may try to write only the partition tables that contain partitions that will be used somehow by the new Debian (partitions with some file system, with swap or booting partition) Well, the idea is to write the system type only for the partition we are formating, not ? Or partition we are mounting without formating if its type doesn't correspond to the file system it contains. Well, i don't think so, not automatically at least. 3. But if the user uses LVM or RAID partman has to write the partition tables before it knows which of them will be used. Latter they are already in use and the kernel complains about changes in them And ? You simply do the system flag writing at the same time you format the partitions, provided they are not on a LVM or RAID device ? At the time when some partition is being formatted (or simply sceduled for mounting) the partition table may already contain physical volumes of activated volume groups. So what ? a raid or LVM partition is simply a partition with a given flag. The fact that you modify the other partition on the partition table should in no way affect any raid or lvm partitions you have, and you should also in no way try to put a partition table on a raid or lvm partition. It is currently possible in partman, but it is a bug, since the kernel will then not be able to boot the given system, nor mount them. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 03:36:14PM +0100, Sven Luther wrote: Or partition we are mounting without formating if its type doesn't correspond to the file system it contains. Well, i don't think so, not automatically at least. (Lib)parted repairs the wrong partition types in all cases. In some cases partman will not write the partition table but if it has to for some reason then the partition type will be changed. At the time when some partition is being formatted (or simply sceduled for mounting) the partition table may already contain physical volumes of activated volume groups. So what ? a raid or LVM partition is simply a partition with a given flag. The fact that you modify the other partition on the partition table should in no way affect any raid or lvm partitions you have, The kernel will complain that it can not reread the partition table. This complain is not dangerous and partman can probably safely hide it from the user but this already is not nice. Moreover the confirmation dialog contains a list of the changed partition tables. If we decide to write all partition tables to the disk just because they contain some formatted partition this means that they have to be included in this list. In most cases this list will contain all partition tables and because of that it will be less informative. I think I can take the partition type from the structures of parted but I wonder the format of these structures can change in future versions of parted. and you should also in no way try to put a partition table on a raid or lvm partition. It is currently possible in partman, but it is a bug, since the kernel will then not be able to boot the given system, nor mount them. Yes, of course. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 09:13:47PM +0200, Anton Zinoviev wrote: On Wed, Dec 01, 2004 at 03:36:14PM +0100, Sven Luther wrote: Or partition we are mounting without formating if its type doesn't correspond to the file system it contains. Well, i don't think so, not automatically at least. (Lib)parted repairs the wrong partition types in all cases. In some cases partman will not write the partition table but if it has to for some reason then the partition type will be changed. At the time when some partition is being formatted (or simply sceduled for mounting) the partition table may already contain physical volumes of activated volume groups. So what ? a raid or LVM partition is simply a partition with a given flag. The fact that you modify the other partition on the partition table should in no way affect any raid or lvm partitions you have, The kernel will complain that it can not reread the partition table. This complain is not dangerous and partman can probably safely hide it from the user but this already is not nice. Moreover the confirmation dialog contains a list of the changed partition tables. If we decide to write all partition tables to the disk just because they contain some formatted partition this means that they have to be included in this list. In most cases this list will contain all partition tables and because of that it will be less informative. I don't follow this. You read the partition table, modify the type for one partition type, write it back. This should not change the rest of the partitions, or it is a RC parted bug, and your duty is to fill a bug report about this. I think I can take the partition type from the structures of parted but I wonder the format of these structures can change in future versions of parted. not withtout an api change. And anyway, we don't care, just automatically do a set_system_type when formatting, and everything should be fine. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 07:21:04PM +0100, Sven Luther wrote: On Wed, Dec 01, 2004 at 09:13:47PM +0200, Anton Zinoviev wrote: On Wed, Dec 01, 2004 at 03:36:14PM +0100, Sven Luther wrote: Or partition we are mounting without formating if its type doesn't correspond to the file system it contains. Well, i don't think so, not automatically at least. (Lib)parted repairs the wrong partition types in all cases. In some cases partman will not write the partition table but if it has to for some reason then the partition type will be changed. At the time when some partition is being formatted (or simply sceduled for mounting) the partition table may already contain physical volumes of activated volume groups. So what ? a raid or LVM partition is simply a partition with a given flag. The fact that you modify the other partition on the partition table should in no way affect any raid or lvm partitions you have, The kernel will complain that it can not reread the partition table. This complain is not dangerous and partman can probably safely hide it from the user but this already is not nice. Moreover the confirmation dialog contains a list of the changed partition tables. If we decide to write all partition tables to the disk just because they contain some formatted partition this means that they have to be included in this list. In most cases this list will contain all partition tables and because of that it will be less informative. I don't follow this. You read the partition table, modify the type for one partition type, write it back. If the file system type is unchanged partman can not know whether the partition type is modified or not. Thats why you proposed that partman writes the partition table if it contains formatted partition (or partition with phisical volume for RAID or LVM). In many cases this means that partman will have to write unchanged partition tables. In order to fix #238388 (i.e. partman allows user to make changes in partition tables that are used by the kernel) partman has to know which operations change the partition table and disallow them. However even in this case it will have to write the unchanged partition tables because some some partition type may have changed without its knowledge. :( This should not change the rest of the partitions, or it is a RC parted bug, and your duty is to fill a bug report about this. Ah, I see. It changes only the type of the partitions that have set_system_type. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 10:26:01PM +0200, Anton Zinoviev wrote: I don't follow this. You read the partition table, modify the type for one partition type, write it back. If the file system type is unchanged partman can not know whether the partition type is modified or not. Thats why you proposed that partman Well, if you look at the current process : 1) you do all the partition table stuff in memory. 2) once you hit finished (or you go into the raid or lvm menu), the partition table is written to disk. 3) the partitions who are formated are actually formatted. The only addition would be to do, in addition to 3), a writing of the partition type to the partition entry in the partition table, and everything would be fine. We do know that the partition is changed, we don't care about what parted things about the partition, since parted ignores the partition table contained type, and does physical probing, which may or may not be correct. the firmware does need to know about the partition type though, so we make sure it is always correct for all partitions that *WE* do write. writes the partition table if it contains formatted partition (or partition with phisical volume for RAID or LVM). In many cases this means that partman will have to write unchanged partition tables. So what ? At worst we allow it only for partition tables we know are not broken ? (which probably include MBRs and amiga partitions tables, unsure about the rest of them). In order to fix #238388 (i.e. partman allows user to make changes in partition tables that are used by the kernel) partman has to know which operations change the partition table and disallow them. However even in this case it will have to write the unchanged partition tables because some some partition type may have changed without its knowledge. :( So what ? This should not change the rest of the partitions, or it is a RC parted bug, and your duty is to fill a bug report about this. Ah, I see. It changes only the type of the partitions that have set_system_type. Exact. Friendly, Sven LUther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 08:47:57PM +0100, Sven Luther wrote: In many cases this means that partman will have to write unchanged partition tables. So what ? At least the kernel will complain. But yes - this is a solution, although not nice in my opinion. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Wed, Dec 01, 2004 at 11:10:01PM +0200, Anton Zinoviev wrote: On Wed, Dec 01, 2004 at 08:47:57PM +0100, Sven Luther wrote: In many cases this means that partman will have to write unchanged partition tables. So what ? At least the kernel will complain. But yes - this is a solution, although not nice in my opinion. I still don't get why the kernel should complain though ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Thu, Nov 25, 2004 at 01:00:51PM -0800, Blars Blarson wrote: Looking into the partman bugs reports, I think all of these bugs are symptoms of the same partman bug: In my opinion most of these bugs are different. My summery is that partman has information in memory on what the desired partitioning is, and information on disk. It can write information to the disk without updating all of its in memory information to match, and gets itself into an inconsistant state. It is possible that libparted does this when it uses sun disk labels (but I don't know the internals of libparted). Partman doesn't have its information on the disk. However there is the following bug in partman: sometimes it considers the partition tables in its own data structures unchanged and misses to write them to the disk. The result is that when the type of some partition doesn't correspond to the file system in it partman may miss to correct the partition type and latter grub fails. Choosing another menu item that fails totaly can get it back to a consistant state. Choosing a menu item that partly succeds (such as lvm) can make things even crazier. Can you give more details about this? Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Mon, Nov 29, 2004 at 07:22:09PM +0200, Anton Zinoviev wrote: On Thu, Nov 25, 2004 at 01:00:51PM -0800, Blars Blarson wrote: Looking into the partman bugs reports, I think all of these bugs are symptoms of the same partman bug: In my opinion most of these bugs are different. My summery is that partman has information in memory on what the desired partitioning is, and information on disk. It can write information to the disk without updating all of its in memory information to match, and gets itself into an inconsistant state. It is possible that libparted does this when it uses sun disk labels (but I don't know the internals of libparted). Partman doesn't have its information on the disk. However there is the following bug in partman: sometimes it considers the partition tables in its own data structures unchanged and misses to write them to the disk. The result is that when the type of some partition doesn't correspond to the file system in it partman may miss to correct the partition type and latter grub fails. BTW, i also believe that this is a problem on pegasos. Doing a ped_partition_set_system each time we put a filesystem on a partition may be the thing to do, do you do this ? Example, on pegasos, i was going to install an ext3 filesystem in the old swap partition. The old partition was marked as type swap, and this was not changed, and thus the ext3 filesystem was not readable from the firmware, which thought it contained swap, and since there are no driver for this, it failed. Not sure if it is a general failure to do a ped_partition_set_system, or a instance of the bug you mention above ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Blars Blarson wrote: | lvm was what failed on missing modules. I was able to mark partitions | as physical volumes and create the volume group using the choose an | option that fails to convince it to accept the current configuration | trick, but creating a logical volume failed with a complaint about | missing the stripeing module. (Sorry I don't remember the exact | name.) Interesting. I was able to create my volume group, logical volumes, etc., with no hassle on 2.4.27, but some partitioning issues prevented second stage from booting. My point is that LVM seems to be fully functional here in the aspects that you pointed out; what steps did you take to get it to trip on missing a 'striping' module? (Which doesn't even exist on i386, AFAICS.) | The raid problem was trying to figure out how to set partitions as | part of a md set, not missing modules. OK. - -- Joshua Kwan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQalRx6OILr94RG8mAQJMlRAA2URS8MoreEViMRSia7NYcLddci85P+gu DuTIczuijH5lg2jng6Pum/WwgKX8HziTxRKGy0gV9UXtCShKbuxPa9R39eeP0fWX 3GZv3Nqg8AdEUO964iQC2e8883UqgO35arqh0gFzgneBOb3HLfEX5hBJMK5G+bjg aNslugf6uwKg3TnMm3ByN5vxPfb3P77BuMvS2+U4NbTOGz7srp/IvwqdS/45xtup EMrxnjKGBDkENf2axzaOCOD8hEZUIRKmMyDHWjCHE+llqaVdwAJFNVmO0W2RjGUk oQJX47LQpCALSXE/Gp2B4ncPkXd/jikvr0fDJ5cjxwy6jx+gAkcT/bwf7ALHZxVl dNNZK3wvkUp/oOgqXsC3gvz/3at8vaZ7lG0/3BTepGkeN9P3NLBjzQkN0txrtXXa 9O4k2kDmjbInuEKz5qnPepKKk8L67BpFyp61ll0JFijrLjbYACyTiyJYP3A2DpQi qoyZlH1BQkxYWp8VMRt3M1KpNXWvoTUyoKKUgW8Nc1NwUyDmpxiT+wLr3GwR+xCT 8W/4V5eWlh0euViOhOQDPmnJ05UgSvcLpW5vza503Kqbp+cq758ib5KVrs2p1JMN L347Ytm306wyiqR+rzcndGFuBd2Uox4FZS++gZkFnIGXz472ciIk3RROPoc/qevx K1xCXQ4zN9k= =U1+B -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
On Thu, Nov 25, 2004 at 06:04:28PM -0800, Joshua Kwan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Blars Blarson wrote: | After doing successful installs using rc2 on a stack of sparc systems | (ultra1, ultra1e, ultra2, ultra2) I started playing with raid and lvm | installs. Unfortunatly, the raid and lvm stuff failed due to bugs in | partman and missing modules. What missing modules? lvm was what failed on missing modules. I was able to mark partitions as physical volumes and create the volume group using the choose an option that fails to convince it to accept the current configuration trick, but creating a logical volume failed with a complaint about missing the stripeing module. (Sorry I don't remember the exact name.) The raid problem was trying to figure out how to set partitions as part of a md set, not missing modules. I've got plans for the weekend so probably won't have time until monday to play with this any more. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman problems (sparc and elsewhere)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Blars Blarson wrote: | After doing successful installs using rc2 on a stack of sparc systems | (ultra1, ultra1e, ultra2, ultra2) I started playing with raid and lvm | installs. Unfortunatly, the raid and lvm stuff failed due to bugs in | partman and missing modules. What missing modules? md-modules-2.4.27-1-sparc32-di | 0.61 | testing | sparc md-modules-2.4.27-1-sparc32-di | 0.61 | unstable | sparc md-modules-2.4.27-1-sparc64-di | 0.61 | testing | sparc md-modules-2.4.27-1-sparc64-di | 0.61 | unstable | sparc md-modules-2.6.8-1-sparc32-di | 0.02 | testing | sparc md-modules-2.6.8-1-sparc32-di | 0.02 | unstable | sparc md-modules-2.6.8-1-sparc64-di | 0.02 | testing | sparc md-modules-2.6.8-1-sparc64-di | 0.02 | unstable | sparc And they're all full of the right stuff, or so it seems. If whatever you need requires kernel config changes, speak NOW, because I'm already rebuilding new sparc images to add dmfe.ko for Netras and Fires and if possible I want to get them out before next dinstall. - -- Joshua Kwan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQaaPLKOILr94RG8mAQI9QxAA0sB82ImV5Z7XXDm1jXzQYe2B+cYAMMt3 +GORYL+yMOKISMd7hhUxO6x/DhvaHbzG7GpeFYeVPJYp7o0ojzVrmiQzEOs0kwfb d2FlH408VqxFaczK9BOEXwuk6yA4+SZ6ShIvED7kIQXHDorn9VcW/ypL0RLebwdl 5uGPpvG91rNSxPElbc0Qrr7/5jU0MVbDVudV5PjP493FTAmXwnSTIbRVS7NrUHqp gglbyAJ7JVchzDFaAv4ihRWzNQIW4Vfuo4NmSJgvGGS6bCLtk6sBAfh42GWUUlgt I59Eq4Cy8NrpeKwlGfU0pkcALaGXQwaHSlC2CI1DwoJIR1jxRNCwAEnY9J65TuMj jm5ZjP2tkWLa7g/C8pQfS2VN93oFgD6nnKXqgvoDSy8+xvqsQUZVmPGSysuJl07t te9LvtL+ijcgelqo9GcOvLL+w4KMeHUlk7/QLnu19n/dTEiVSrS/6arasPfAlwUs trKS6/UOIbf0A4euREZW7xKtq01+wuUATczEzCxbYtgGrr/QVz4XQn+ep/0XyTQp pbnMRm11w9FHRWPTJCM/gtQtv5NwlRimR8xO+LOSw/c9fmpP5lQEPZns98Pc52GO xGbGs4I7l6l8ILYT4t4GO138EywwcrTqlA9YYOxRSVi5fN+IfaYBCcEliGy0WK3k HT6xeOmFRbY= =91g0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
