Re: GEOM disklabel
On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: ... Don't use the '-r' option, it gets confused because geom::BSD does not lie to it. Yes, that seems to work... Time to say good bye for '-r' ? Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM disklabel
In message [EMAIL PROTECTED], Michael Reifenberger writes: On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: ... Don't use the '-r' option, it gets confused because geom::BSD does not lie to it. Yes, that seems to work... Time to say good bye for '-r' ? Well, we still need it for writing the first disklabel on an otherwise empty disk, but I think it could be implied in that case. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM disklabel
On Sat, Jan 25, 2003 at 10:17:39 +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Michael Reifenberger writes: On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: ... Don't use the '-r' option, it gets confused because geom::BSD does not lie to it. Yes, that seems to work... Time to say good bye for '-r' ? Well, we still need it for writing the first disklabel on an otherwise empty disk, but I think it could be implied in that case. -B implies -r too. Currenty this check prevents my bootblocks from writting. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM disklabel
In message [EMAIL PROTECTED], Michael Reifenberger w rites: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [EMAIL PROTECTED] for more info. --0-240786022-1043432225=:647 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, trying to disklabel new disks I get: (nihil)(root) # disklabel -w -B da0s1 auto (nihil)(root) # disklabel -r da0s1 Don't use the '-r' option, it gets confused because geom::BSD does not lie to it. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
In message [EMAIL PROTECTED], Ju lian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. Better plan: Abandon BSD labels before disks outgrow them. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
I agree with that too. On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. Better plan: Abandon BSD labels before disks outgrow them. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
[EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
On Mon, 13 Jan 2003, walt wrote: [EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? gpt I don't know where it comes from but I believe it's the native partition format for ia64 architecture machines. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
Julian Elischer wrote: On Mon, 13 Jan 2003, walt wrote: [EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? gpt I don't know where it comes from but I believe it's the native partition format for ia64 architecture machines. Pros: - fully 64 bit clean - maximum of 16384 partitions - unique id's for disks, partitions and OS types. - we already have the basic code support for it in the tree. - its on intel's roadmap for future i386 servers (for what thats worth) along with EFI. - it is possible to boot from, but needs new boot code written(*). Cons: - If you follow the spec strictly, it will not share disks with another fdisk-using OS. If strictly implemented according to the specs, it replaces the fdisk MBR and owns the entire disk. Our code however isn't that strict and will accept a GPT inside an MBR slice, meaning for i386 we can use GPT as a replacement for disklabel. - Booting is interesting(*). * - When GPT is used with EFI, the firmware has got a mini OS in rom which has native FAT32 file system support, which means we can just mount the boot partition and copy loader.efi in there and there are *no* bootblocks.. However, if we were to use it standalone we would not have this and would have to boot ourselves. The way this would be done is to put real boot code in the MBR, which would scan the gpt table to find a boot partition that contained the equivalent of what is now boot2. We could make this as big as we liked, but I'd imagine it would be 64K by default. That boot2 code would then be able to read UFS natively, just like now. In other words, it wouldn't be all that different to now except that somebody has to write it. Alternatively, we could deviate a bit from the strict specs and reserve the entire first track for boot code and avoid the problem that way. This would be easier and less likely to run into major code space pressure problems as it wouldn't have to parse GPT tables. Personally, unless EFI on i386 actually gets off the ground, if somebody is seriously considering this, I'd be inclined to suggest using a fairly loose gpt interpretation and using gpt as a replacement for disklabel inside a freebsd slice. That way it is easy to play nice with other OS's and less pain to deal with for booting. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
In message [EMAIL PROTECTED], walt writes: [EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? Probably EFI/GPT labels -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
