Booting from GPT on i386 [Re: Hardcoding gmirror provider]
Am Mittwoch, 23. Februar 2005 11:24 schrieb Poul-Henning Kamp: + The c partition is a problem you have to address anyway (and it is + best addressed by removing the magicness of the c partition + altogether). [...] It is not going to be removed. We're going to wait for MBR to die. s/MBR/BSDlabel/ My servers boot from CF-Card so all my hard disks are GPT sliced only. Will it be possible to boot from GPT disks on i386(amd64)? Is anyone currently working on that?. That's what I'm really missing. Thanks, -Harry pgpJ2MtMetZEE.pgp Description: PGP signature
Re: Hardcoding gmirror provider
Pawel Jakub Dawidek [EMAIL PROTECTED] writes: On Tue, Feb 22, 2005 at 09:29:38PM +0100, Dag-Erling Sm?rgrav wrote: George Hartzell [EMAIL PROTECTED] writes: I just skimmed through your comment about hardcoding the provider name if ad0 and ad0s1 have the same length. This wouldn't be a problem if gmirror, gstripe etc. placed metadata at the start of the provider, like God intended, instead of at the end. You won't be able to boot from the mirror then. That's a special case, and it could have been solved differently (e.g. by teaching the boot loader to recognize gmirror metadata). It does not justify the similar breakage in gstripe and graid3. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider
Pawel Jakub Dawidek [EMAIL PROTECTED] writes: ...and metadata at the begining of the provider still doesn't fix 'c' partition problem and 'a' partition which starts at sector 0, which is the default start offset in sysinstall. The c partition is a problem you have to address anyway (and it is best addressed by removing the magicness of the c partition altogether). As for the a partition, I don't see the problem. It is not at the start of the slice, since the label comes first. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider
On Wed, Feb 23, 2005 at 10:32:01AM +0100, Dag-Erling Sm?rgrav wrote: + Pawel Jakub Dawidek [EMAIL PROTECTED] writes: + ...and metadata at the begining of the provider still doesn't fix 'c' + partition problem and 'a' partition which starts at sector 0, which is + the default start offset in sysinstall. + + The c partition is a problem you have to address anyway (and it is + best addressed by removing the magicness of the c partition + altogether). [...] It is not going to be removed. We're going to wait for MBR to die. + [...] As for the a partition, I don't see the problem. It is + not at the start of the slice, since the label comes first. It comes first, yes, but it is visible inside 'a' partition when it starts at sector 0. UFS has a workaround to skip first 16 sectors. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpmCynBprOtU.pgp Description: PGP signature
Re: Hardcoding gmirror provider
In message [EMAIL PROTECTED], Pawel Jakub Dawidek wr ites: --2VOk7s3pVsDYAazo Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 23, 2005 at 10:32:01AM +0100, Dag-Erling Sm?rgrav wrote: + Pawel Jakub Dawidek [EMAIL PROTECTED] writes: + ...and metadata at the begining of the provider still doesn't fix 'c' + partition problem and 'a' partition which starts at sector 0, which is + the default start offset in sysinstall. +=20 + The c partition is a problem you have to address anyway (and it is + best addressed by removing the magicness of the c partition + altogether). [...] It is not going to be removed. We're going to wait for MBR to die. s/MBR/BSDlabel/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider
On Wed, Feb 23, 2005 at 10:27:09AM +0100, Dag-Erling Sm?rgrav wrote: + Pawel Jakub Dawidek [EMAIL PROTECTED] writes: + On Tue, Feb 22, 2005 at 09:29:38PM +0100, Dag-Erling Sm?rgrav wrote: + George Hartzell [EMAIL PROTECTED] writes: +I just skimmed through your comment about hardcoding the provider name +if ad0 and ad0s1 have the same length. + This wouldn't be a problem if gmirror, gstripe etc. placed metadata at + the start of the provider, like God intended, instead of at the end. + You won't be able to boot from the mirror then. + + That's a special case, and it could have been solved differently (e.g. + by teaching the boot loader to recognize gmirror metadata). It does + not justify the similar breakage in gstripe and graid3. It was done for consistency, so I can centralize metadata handling in the future. I also don't think that teaching boot loader about gmirror is reasonable solution... The additional thing which can be stored in metadata in provider's size. This should fix discussed problems (except 'c' partition and 'a' at sector 0). -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpMe4QYY5hgd.pgp Description: PGP signature
Re: Hardcoding gmirror provider [was Re: Problem with migrating...]
I just skimmed through your comment about hardcoding the provider name if ad0 and ad0s1 have the same length. I think that you need to mention that you need to add the -h flag to both the gmirror label command and the final gmirror insert command when you add in the second disk. g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider
George Hartzell [EMAIL PROTECTED] writes: I just skimmed through your comment about hardcoding the provider name if ad0 and ad0s1 have the same length. This wouldn't be a problem if gmirror, gstripe etc. placed metadata at the start of the provider, like God intended, instead of at the end. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider
On Tue, Feb 22, 2005 at 09:29:38PM +0100, Dag-Erling Sm?rgrav wrote: + George Hartzell [EMAIL PROTECTED] writes: + I just skimmed through your comment about hardcoding the provider name + if ad0 and ad0s1 have the same length. + + This wouldn't be a problem if gmirror, gstripe etc. placed metadata at + the start of the provider, like God intended, instead of at the end. You won't be able to boot from the mirror then. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp7vo2mr7CW0.pgp Description: PGP signature
Re: Hardcoding gmirror provider
On Wed, Feb 23, 2005 at 12:47:28AM +0100, Pawel Jakub Dawidek wrote: + On Tue, Feb 22, 2005 at 09:29:38PM +0100, Dag-Erling Sm?rgrav wrote: + + George Hartzell [EMAIL PROTECTED] writes: + + I just skimmed through your comment about hardcoding the provider name + + if ad0 and ad0s1 have the same length. + + + + This wouldn't be a problem if gmirror, gstripe etc. placed metadata at + + the start of the provider, like God intended, instead of at the end. + + You won't be able to boot from the mirror then. ...and metadata at the begining of the provider still doesn't fix 'c' partition problem and 'a' partition which starts at sector 0, which is the default start offset in sysinstall. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpShBczDCbWs.pgp Description: PGP signature
Re: Hardcoding gmirror provider
On Wed, Feb 23, 2005 at 12:58:52AM +0100, Pawel Jakub Dawidek wrote: ...and metadata at the begining of the provider still doesn't fix 'c' partition problem and 'a' partition which starts at sector 0, which is the default start offset in sysinstall. Is this the C partition problem you refer to? bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities Could this possibly be at the root of my boot problem: disk1s1: FFS bad disklabel disk2s1: FFS bad disklabel It only seems to be a problem if I try to use slices as gmirror providers and shrink them to avoid the last sector collision with the whole disk. -Snow ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider
On Tue, Feb 22, 2005 at 09:48:37PM -0500, James Snow wrote: On Wed, Feb 23, 2005 at 12:58:52AM +0100, Pawel Jakub Dawidek wrote: ...and metadata at the begining of the provider still doesn't fix 'c' partition problem and 'a' partition which starts at sector 0, which is the default start offset in sysinstall. Is this the C partition problem you refer to? bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities Could this possibly be at the root of my boot problem: disk1s1: FFS bad disklabel disk2s1: FFS bad disklabel It only seems to be a problem if I try to use slices as gmirror providers and shrink them to avoid the last sector collision with the whole disk. The c partition doesn't need to be shrunk by a sector since it's not used as a gmirror provider, and only the slices that end at the end of the disk/provider their slicing. So a disk with two consecutive slices, say a and d, only d needs to be reduced by 1 sector since a doesn't end at the end of the disk anyways. -Snow ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to [EMAIL PROTECTED] -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider [was Re: Problem with migrating...]
On Sun, Feb 06, 2005, George Hartzell wrote: Pawel Jakub Dawidek writes: [...] It happens because ad0 and ad0s1 share the same last sector. To fix this you should use '-h' option as you did or you should recreate ad0s1 slice one sector smaller. Thanks for the help! That makes sense, which is always a nice feeling. Does that mean that the instructions at: http://people.freebsd.org/~rse/mirror/ in the section labeled: GEOM mirror Approach 2: Single Slice, Preferred, More Flexible are incorrect and will result in the same kind of slice-table breakage that I was seeing or is there something going on that I'm not getting? Would it be more correct for Ralf to update the instructions to include a -h arg on his gmirror label step? I've added a comment to the slice creation command that one just substract one block or alternatively use the -h option on the gmirror label command for hard-coding the provider. Thanks for catching this subtle problem. -- [EMAIL PROTECTED]Ralf S. Engelschall FreeBSD.org/~rse [EMAIL PROTECTED] FreeBSD committer www.engelschall.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardcoding gmirror provider [was Re: Problem with migrating...]
On Sun, Feb 06, 2005 at 11:05:08AM -0800, George Hartzell wrote: + I've figured out that if I hardcode the provider when I label my + mirror everything seems to work out, which leaves me confused. + + Here's the label command I was using (modified for my situation): + + gmirror label -v -n -b round-robin disk0 /dev/ad0s1 + + After running that command, gmirror list tells me that the consumer + for disk0 is Name: ad0, even though I've specified ad0s1 above and + when I bsdlabel the disk the slice table gets clobbered. + + If I do this instead: + + gmirror label -v -n -h -b round-robin disk0 /dev/ad0s1 + + then gmirror list tells me that the consumer is Name: ad0s1 and + bsdlabel doesn't stomp on the slice table. + + Am I [just] confused, and I tripping over a sharp piece of exposed + code, or is this a bug. + + FWIW, I get the same behaviour on: + + FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sat Dec 18 12:38:37 PST 2004 + [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MERLIN i386 + + and + + Freesbie 1.1 It happens because ad0 and ad0s1 share the same last sector. To fix this you should use '-h' option as you did or you should recreate ad0s1 slice one sector smaller. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp63lUNPVv7b.pgp Description: PGP signature
Re: Hardcoding gmirror provider [was Re: Problem with migrating...]
Pawel Jakub Dawidek writes: [...] It happens because ad0 and ad0s1 share the same last sector. To fix this you should use '-h' option as you did or you should recreate ad0s1 slice one sector smaller. Thanks for the help! That makes sense, which is always a nice feeling. Does that mean that the instructions at: http://people.freebsd.org/~rse/mirror/ in the section labeled: GEOM mirror Approach 2: Single Slice, Preferred, More Flexible are incorrect and will result in the same kind of slice-table breakage that I was seeing or is there something going on that I'm not getting? Would it be more correct for Ralf to update the instructions to include a -h arg on his gmirror label step? g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
