Re: Re: bsdlabel blues again
Michel, On 12/23/-58 20:59, Michel Talon wrote: > Volker said: > >> As I've done this procedure twice yesterday and once more today, >> I've double and triple checked everything but I'm running into one >> single problem: >> >> partition c extends past end of unit and doesn't start at 0. > > I think you should run bsdlabel on the mirror, not on the > raw partitions or disks. Then you will have no more problem > of the above type, only the innocuous following one: Thanks for your answer but I should have stated in my first message I'm not a totally stupid bloody newby. I do know the difference between raw disk slices and mirrored slices. I've also done this procedure a lot times before with less trouble. I was talking about something what I would like to name a bug or call it strange behavior. Just for the archives, I've got it working now. As I've converted from one (working) mirror to another, gmirror seemed to cache slice / partition infos. To work around that kind of trouble, one needs to create the slices, label the mirror, reboot (!) and then continue with partioning. Otherwise gmirror is working on old, cached values which will give out of bound partitioning values. Creating the slices, label the mirror and create the partitions in one go will most likely get you to bad partition values. This extra step of rebooting should most likely not be needed if one is able to `gmirror load' after labeling the mirror but in my case I've been unable to unload gmirror because I've already been working on a live mirror. So the reboot was needed as there's no command to re-sync geom values. My description does not mean to be technically correct but this is what I've experienced and the only thing I can imagine what's going on in the background. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsdlabel blues again
Volker said: > As I've done this procedure twice yesterday and once more today, > I've double and triple checked everything but I'm running into one > single problem: > > partition c extends past end of unit and doesn't start at 0. I think you should run bsdlabel on the mirror, not on the raw partitions or disks. Then you will have no more problem of the above type, only the innocuous following one: gms1 is a mirror of ad0s1 and ad4s1: asmodee% bsdlabel mirror/gms1 # /dev/mirror/gms1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 2097152 524288 swap c: 327669920unused0 0 # "raw" part, d: 524288 26214404.2BSD 2048 16384 32776 e: 524288 31457284.2BSD 2048 16384 32776 f: 29096970 36700164.2BSD 2048 16384 28552 asmodee% bsdlabel ad0s1 # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 2097152 524288 swap c: 327669920unused0 0 # "raw" part, d: 524288 26214404.2BSD 2048 16384 32776 e: 524288 31457284.2BSD 2048 16384 32776 f: 29096970 36700164.2BSD 2048 16384 28552 bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities asmodee% bsdlabel ad4s1 # /dev/ad4s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 2097152 524288 swap c: 327669920unused0 0 # "raw" part, d: 524288 26214404.2BSD 2048 16384 32776 e: 524288 31457284.2BSD 2048 16384 32776 f: 29096970 36700164.2BSD 2048 16384 28552 bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities I think the difference is the last sector of the partition on which geom writes its configuration. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
