Date: Wed, 23 Aug 1995 21:37:59 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, jkh@time.cdrom.com Cc: alain@Wit401402.student.utwente.nl, current@freefall.FreeBSD.org Subject: Re: Of slices and boot code.. Message-ID: <199508231137.VAA18265@godzilla.zeta.org.au>
index | next in thread | raw e-mail
>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. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508231137.VAA18265>