Date: Wed, 27 Jun 2012 13:14:08 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: Doug Rabson <dfr@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, Andriy Gapon <avg@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: [CFC/CFT] large changes in the loader(8) code Message-ID: <AFD7FE25-F536-4594-81E4-5E6F54207C11@xcllnt.net> In-Reply-To: <4FEB5EA1.7060903@yandex.ru> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote: > On 27.06.2012 21:55, Marcel Moolenaar wrote: >> You can't just re-interpret standards to match a context you know = very well >> isn't applicable and consequently redefine what the word "device" = means. >> You're on a slippery slope and while you may not see it as a problem, = you >> do make it a problem for FreeBSD users. It's our users we should be = keeping >> in mind when we solve problems. >>=20 >>> If a user wants modify GPT in the disk editor from the another OS, >>> he can do it, and it should work. The result depends only from the = partition editor, >>> it might overwrite the last sector and might don't. >>=20 >> Right. Another happy user that sees his/her FreeBSD installation = destroyed >> or degraded (no mirroring, warning messages about corrupted GPT, etc) = for >> no apparent reason and without any kind of warning that what he/she = is doing >> is potentially harmful... That's the spirit! >=20 > Ok. Let's return back to my patches. They don't add any new methods to > shoot in the foot. We are talking about the *FreeBSD loader*. > This is the program that starts FreeBSD kernel. It doesn't start other > OS. We already have many users who uses FreeBSD as a single system on > the machine. Many of them use GPT inside of some GEOM provider. Your patches are a continuation on a path that we're discussing isn't necessarily the path we should be on. While you don't make things worse from a compliance perspective, you make it worse by adding the non-compliant behaviour to more components. > As i understand there two parts where we haven't a consensus: >=20 > 1. You are against from: > Our loader detects that primary GPT header is damaged. It tries to = read > backup GPT header from the last LBA and it detects that there is > "GEOM::" signature. It tries to read one previous sector and there is > *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. > 2. You are against from having one fake PMBR entry by default in the > /boot/pmbr image. I don't understand what you're saying or what I'm being accused to be against. --=20 Marcel Moolenaar marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFD7FE25-F536-4594-81E4-5E6F54207C11>