From owner-freebsd-current Wed Aug 23 05:01:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id FAA29551 for current-outgoing; Wed, 23 Aug 1995 05:01:16 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id FAA29528 for ; Wed, 23 Aug 1995 05:00:34 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA18265; Wed, 23 Aug 1995 21:37:59 +1000 Date: Wed, 23 Aug 1995 21:37:59 +1000 From: Bruce Evans Message-Id: <199508231137.VAA18265@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@time.cdrom.com Subject: Re: Of slices and boot code.. Cc: alain@Wit401402.student.utwente.nl, current@freefall.FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Well, you must admit that this example is a little contrived and if >such insane nesting were required because the user was trying to >shoe-horn FreeBSD into a system already so dedicated to DOS and Linux, >well, then so be it. I'm trying to keep the most common scenarios as >simple and clean as possible and, truth be told, if someone REALLY >wanted to install FreeBSD in such a convoluted environment then I'd >say that the naming would be the least of their worries! Another try. The following naming schemes for slices exist or are being considered: DOS FreeBSD Linux what you asked for -- ------ ---- ----- C: sd0s1 sda1 sd0s1 ### assume there is only one drive so that some DOS drive letters ### aren't for other drives D: sd0s2 sda2 sd0s2 E: sd0s3 sda3 sd0s3 F: sd0s4 sda4 sd0s4 ### end of slices on MBR ### assume sd0s4 is an extended slice and the only extended slice G: sd0s5 sda5 sd0s4e0 H: sd0s6 sda6 sd0s4e1 I: sd0s7 sda7 sd0s4e2 J: sd0s8 sda8 sd0s4e3 K: sd0s9 sda9 sd0s4e4 L: sd0s10 sda10 sd0s4e5 M: sd0s11 sda11 sd0s4e6 N: sd0s12 sda12 sd0s4e7 O: sd0s13 sda13 sd0s4e8 P: sd0s14 sda14 sd0s4e9 Q: sd0s15 sda15 sd0s4e10 R: sd0s16 can't handle sd0s4e11 S: sd0s17 " sd0s4e12 T: sd0s18 " sd0s4e13 U: sd0s19 " sd0s4e14 V: sd0s20 " sd0s4e15 W: sd0s21 " sd0s4e16 X: sd0s22 " sd0s4e17 Y: sd0s23 " sd0s4e18 Z: sd0s24 " sd0s4e19 can't handle sd0s25 " sd0s4e20 " sd0s26 " sd0s4e21 " sd0s27 " sd0s4e22 " sd0s28 " sd0s4e23 " sd0s29 " sd0s4e24 " sd0s30 " sd0s4e25 Which do you prefer? :-) Which is the least consistent? >More to the point, I have yet to get a single tech-support query from >someone with all 4 MBR slots filled. It just doesn't seem to happen >that way. I think that my proposal still has merit. This is probably because people with 4 MBR slots filled have probably practiced running fdisk at least 3 times more than people with 1 MBR slot filled. >> >I'm still not clear on whether or not those last patches of yours will >> >enable me to yank the "compatibility hacks" out of sysinstall. I >> >surely would like to as it would actually simplify the code >> >considerably! >> >> It would also simplify the kernel code considerably. >So. Um. You're saying that this is planned/done/on the way? I'm >still a little unclear on that.. :-) I didn't have the compatibility hacks originally, but it became obvious that there would be too many problems getting everyone converted without them. Bruce