Re: aliasing (or renaming) kern.geom.debugflags
In message alpine.gso.1.10.1110242118020@multics.mit.edu, Benjamin Kaduk writes: On Mon, 24 Oct 2011, Andrey V. Elsukov wrote: This is stale message. boot0cfg might work without this. On a *mounted* disk? Surely that qualifies as an open for the purposes of the check. The way this used to work before gpart, is that boot0cfg would send a GEOM ctl-message to the MBR-geom asking Would you please write this boot code ? Since the MBR-geom was the owner of the whole disk, and the one who had it open for writing, it could obviously do so, if it saw fit, and after it had edited its idea about the mbr-partition table into that boot-code. Gpart appearantly does not implement such a ctl message. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On 25.10.2011 10:08, Poul-Henning Kamp wrote: The way this used to work before gpart, is that boot0cfg would send a GEOM ctl-message to the MBR-geom asking Would you please write this boot code ? Since the MBR-geom was the owner of the whole disk, and the one who had it open for writing, it could obviously do so, if it saw fit, and after it had edited its idea about the mbr-partition table into that boot-code. Gpart appearantly does not implement such a ctl message. gpart does it in the same way. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
In message 4ea654f6.1060...@yandex.ru, Andrey V. Elsukov writes: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig1B092FDF9A756BE78BC74C01 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 25.10.2011 10:08, Poul-Henning Kamp wrote: The way this used to work before gpart, is that boot0cfg would send a GEOM ctl-message to the MBR-geom asking Would you please write this boot code ? =20 Since the MBR-geom was the owner of the whole disk, and the one who had it open for writing, it could obviously do so, if it saw fit, and after it had edited its idea about the mbr-partition table into that boot-code. =20 Gpart appearantly does not implement such a ctl message. gpart does it in the same way. So why doesn't boot0cfg work ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Mon, 24 Oct 2011, Andrey V. Elsukov wrote: On 24.10.2011 1:54, Arnaud Lacombe wrote: NOTE Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. This is stale message. boot0cfg might work without this. On a *mounted* disk? Surely that qualifies as an open for the purposes of the check. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On 25.10.2011 5:18, Benjamin Kaduk wrote: to allow writing to the MBR, and restore it to 0 afterwards. This is stale message. boot0cfg might work without this. On a *mounted* disk? Surely that qualifies as an open for the purposes of the check. Yes. boot0cfg uses GEOM_PART' control interface and it may write bootcode to the open disk. Actually i found bug here and now it is fixed in r226714. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
Hi, 2011/10/7 Andrey V. Elsukov bu7c...@yandex.ru: On 07.10.2011 23:41, Glen Barber wrote: In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. The problem is that this bad suggestion is everywhere in the Internet. And users use it always even when it not needed. I think it is bad idea add it in the our official documentation. FWIW, boot0cfg(8) also mentions it: NOTE Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. - Arnaud When you doing all in the right way using debugflags=16 is not needed. And it is really dangerous when you doing something what you do not know exactly. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On 24.10.2011 1:54, Arnaud Lacombe wrote: NOTE Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. This is stale message. boot0cfg might work without this. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
In message 1644928028.20111008143...@serebryakov.spb.ru, Lev Serebryakov writ es: Hello, Poul-Henning. You wrote 8 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 14:07:29: It seems, that GPT will be incompatible with any pure-software mirror or mirror-like RAID. Unless you do what other implementations have done: Play nice with GPT and store your metadata in a GPT partition. So, every other GEOM class should have special knowledge about GPT? It doesn't look like topology-agnostic GEOM way :) That's mostly because GPT by design does not try to play nice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hello, Poul-Henning. You wrote 9 октября 2011 г., 11:37:21: So, every other GEOM class should have special knowledge about GPT? It doesn't look like topology-agnostic GEOM way :) That's mostly because GPT by design does not try to play nice. I understand that... See my proposal in other thread (renamed to MBR, GPT and their co-existence with other GEOM classes). -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message CACqU3MVgVUxe+Mtaf9wq6oz5=PZAq=sx-ihyqh1gyjd3pxm...@mail.gmail.com , Arnaud Lacombe writes: If you expose a setting, you cannot rely on a user not to use it even if you told him not to. As long as this is exposed and usable, it will be used, even more when it was documented. This is clearly marked as a debug tool, the only bug here, is that people tell users to abuse it in the documentation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message alpine.bsf.2.00.1110071734140.4...@wonkity.com, Warren Block write s: Since we're talking about this, could you review the usage in the gmirror section of the Handbook GEOM chapter: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html Seems like that is a valid non-debugging use, to allow the last block to be written. gmirror and this procedure has several problems: 1. It steals the last sector on the disk. If that sector contained data you lost them, with no notice. Most often it will not, particularly on a freshly installed system, but it is still a bad thing. 2. The paritioning is not fixed up to record the stealing of this sector. I wouldn't be surprised if this could cause confusion down the road. 3. In this case, writing only happens to a single sector, which we assume is not going to be written by anybody else, so apart from #1 and #2 debugflags=16 does not cause any additional damage. This is the kind of usage that makes me sad I ever added that option. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hello, Poul-Henning. You wrote 8 октября 2011 г., 12:18:54: gmirror and this procedure has several problems: 1. It steals the last sector on the disk. If that sector contained data you lost them, with no notice. Most often it will not, particularly on a freshly installed system, but it is still a bad thing. 2. The paritioning is not fixed up to record the stealing of this sector. I wouldn't be surprised if this could cause confusion down the road. Yes, see discussion about GPT and MBR problems in thread, which is named (and should be re-named already, really) RFC: Project geom-events This is the kind of usage that makes me sad I ever added that option. Storing metadata of GEOM in last (or first) sector plays bad with MBR and, especially, GPT :( And I cannot see good solution for this. It seems, that GPT will be incompatible with any pure-software mirror or mirror-like RAID. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message 338510238.20111008140...@serebryakov.spb.ru, Lev Serebryakov write s: It seems, that GPT will be incompatible with any pure-software mirror or mirror-like RAID. Unless you do what other implementations have done: Play nice with GPT and store your metadata in a GPT partition. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hello, Poul-Henning. You wrote 8 октября 2011 г., 14:07:29: It seems, that GPT will be incompatible with any pure-software mirror or mirror-like RAID. Unless you do what other implementations have done: Play nice with GPT and store your metadata in a GPT partition. So, every other GEOM class should have special knowledge about GPT? It doesn't look like topology-agnostic GEOM way :) Now it is possible to make gmirror inside GPT partition by hands, of course. but if here is multiple partitions it will lead to multiple instances of gmirror, and, in case of synchronization, it will thrash disk, as all instances will try to read and write from different areas of disks (partiitons) in same time... I don't see good universal solution for this, unfortunately :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 4:11 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message CACqU3MVgVUxe+Mtaf9wq6oz5=PZAq=sx-ihyqh1gyjd3pxm...@mail.gmail.com , Arnaud Lacombe writes: If you expose a setting, you cannot rely on a user not to use it even if you told him not to. As long as this is exposed and usable, it will be used, even more when it was documented. This is clearly marked as a debug tool, the only bug here, is that people tell users to abuse it in the documentation. User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... This should never have been present in a release kernel. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. debugflags16 has legitimate uses if you know exactly what kind of shitty situation you are in, and it should absolutely be in the release kernel for that reason. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. I will certainly never ask you to draw blueprints for a shooting range. There is NO legitimacy whatsoever for an emergency hatch to pass though the firing line. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Sat, Oct 8, 2011 at 11:08 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. I will certainly never ask you to draw blueprints for a shooting range. There is NO legitimacy whatsoever for an emergency hatch to pass though the firing line. Certain groups do use this emergency hatch in production to get past safeguards and purposely zero out disks. Granted, it's an ill-advised procedure for most end-users. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 2:11 PM, Garrett Cooper yaneg...@gmail.com wrote: On Sat, Oct 8, 2011 at 11:08 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. I will certainly never ask you to draw blueprints for a shooting range. There is NO legitimacy whatsoever for an emergency hatch to pass though the firing line. Certain groups do use this emergency hatch in production to get past safeguards and purposely zero out disks. Granted, it's an ill-advised procedure for most end-users. Then it is not an emergency hatch. Using an emergency hatch in non emergency, or emergency-drill, situation is in most case strictly forbidden. It would rather be a service hatch. In which case, that part of geom is just badly designed. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message CACqU3MUT36PVxP2hMuizTxYLcuTkBQ_fOfrELit=7ueq-hv...@mail.gmail.com , Arnaud Lacombe writes: Arnaud, Are we done here ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 3:10 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message CACqU3MUT36PVxP2hMuizTxYLcuTkBQ_fOfrELit=7ueq-hv...@mail.gmail.com , Arnaud Lacombe writes: Arnaud, Are we done here ? 'your call. A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, Oct 7, 2011 at 10:42 AM, Benjamin Kaduk ka...@mit.edu wrote: Dear all, I feel like this has come up before, but a quick search didn't reveal anything terribly recent, at least. The new installation chapter of the handbook for 9.0 (that Warren and Glen and Garrett and Gavin and more people I am probably missing have sunk huge amounts of time into) has instructions on (e.g.) preparing a USB stick install image: http://www.glenbarber.us/FreeBSD9/doc/en_US.ISO8859-1/books/handbook/install-pre.html (scroll down most of the way). But in order to do so, the instructions include 'sysctl kern.geom.debugflags=16'! Now, an ordinary user who is doing this for the first time might ask, why do I need to do something with 'debugflags' in order to make a USB stick? I'm not debugging anything, this is a standard operation!. I can't really advocate for changing the geom logic at this point in the release cycle (though it's not really clear why rank 1 geom providers need to be so special), but I think it would be nice to have a user-visible interface to it that does not have debug in the name, since the actual flags are apparently here for the long haul. I could certainly imagine aliasing the debugflags to just flags, which seems more innocuous-sounding. Does this sound crazy? Yes. From geom(4): DIAGNOSTICS Several flags are provided for tracing GEOM operations and unlocking pro- tection mechanisms via the kern.geom.debugflags sysctl. All of these flags are off by default, and great care should be taken in turning them on. geom(4) has more details about what they do. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, 7 Oct 2011, Garrett Cooper wrote: On Fri, Oct 7, 2011 at 10:42 AM, Benjamin Kaduk ka...@mit.edu wrote: Dear all, I feel like this has come up before, but a quick search didn't reveal anything terribly recent, at least. The new installation chapter of the handbook for 9.0 (that Warren and Glen and Garrett and Gavin and more people I am probably missing have sunk huge amounts of time into) has instructions on (e.g.) preparing a USB stick install image: http://www.glenbarber.us/FreeBSD9/doc/en_US.ISO8859-1/books/handbook/install-pre.html (scroll down most of the way). But in order to do so, the instructions include 'sysctl kern.geom.debugflags=16'! Now, an ordinary user who is doing this for the first time might ask, why do I need to do something with 'debugflags' in order to make a USB stick? I'm not debugging anything, this is a standard operation!. I can't really advocate for changing the geom logic at this point in the release cycle (though it's not really clear why rank 1 geom providers need to be so special), but I think it would be nice to have a user-visible interface to it that does not have debug in the name, since the actual flags are apparently here for the long haul. I could certainly imagine aliasing the debugflags to just flags, which seems more innocuous-sounding. Does this sound crazy? Yes. From geom(4): DIAGNOSTICS Several flags are provided for tracing GEOM operations and unlocking pro- tection mechanisms via the kern.geom.debugflags sysctl. All of these flags are off by default, and great care should be taken in turning them on. geom(4) has more details about what they do. I'm not sure I follow your point. Yes, geom(4) describes what they do; my objection is to the use of debug to describe the one in particular that we tell new users to blindly set. A hypothetical kern.geom.flags need not allow setting (e.g.) 0x01 (G_T_TOPOLOGY) Provide tracing of topology change events if we don't want it to. -Ben___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin Kaduk writes: Now, an ordinary user who is doing this for the first time might ask, why do I need to do something with 'debugflags' in order to make a USB stick? Which is the exactly right question to ask. The procedure documented is clearly flawed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote: In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin Kaduk writes: Now, an ordinary user who is doing this for the first time might ask, why do I need to do something with 'debugflags' in order to make a USB stick? Which is the exactly right question to ask. The procedure documented is clearly flawed. Probably a misunderstanding on my part, since I suggested it to Glen. Can't recall the circumstances exactly. The next question would be: what is the correct procedure? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wbl...@wonkity.com wrote: On Fri, 7 Oct 2011, Poul-Henning Kamp wrote: In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin Kaduk writes: Now, an ordinary user who is doing this for the first time might ask, why do I need to do something with 'debugflags' in order to make a USB stick? Which is the exactly right question to ask. The procedure documented is clearly flawed. Probably a misunderstanding on my part, since I suggested it to Glen. Can't recall the circumstances exactly. The next question would be: what is the correct procedure? I'd guess the procedure involves shooting your feet: from `sys/geom/geom_subr.c': /* If foot-shooting is enabled, any open on rank#1 is OK */ if ((g_debugflags 16) pp-geom-rank == 1) ; this was introduced by phk@ himself in: commit 641a10a0cb4ca86785ef13fce9343bc34c30f326 Author: phk p...@freebsd.org Date: Wed Feb 12 09:48:27 2003 + Implement a handle for efficient implementation of perforations in lower extremities. Setting bit 4 in debugflags (sysctl kern.geom.debugflags=16) will allow any open to succeed on rank#1 providers. This will generally correspond to the physical disk devices: ad0, da0, md0 etc. This fundamentally violates the mechanics of GEOMs autoconfiguration, and is only provided as a debugging facility, so obviously error reports on GEOM where this bit is or has been set will not be accepted. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, 7 Oct 2011, Arnaud Lacombe wrote: Hi, On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wbl...@wonkity.com wrote: On Fri, 7 Oct 2011, Poul-Henning Kamp wrote: In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin Kaduk writes: Now, an ordinary user who is doing this for the first time might ask, why do I need to do something with 'debugflags' in order to make a USB stick? Which is the exactly right question to ask. The procedure documented is clearly flawed. Probably a misunderstanding on my part, since I suggested it to Glen. Can't recall the circumstances exactly. The next question would be: what is the correct procedure? I'd guess the procedure involves shooting your feet: from `sys/geom/geom_subr.c': /* If foot-shooting is enabled, any open on rank#1 is OK */ if ((g_debugflags 16) pp-geom-rank == 1) ; Well, yes. The goal is to unprotect the device, regardless of what may already be on it. Then the user can overwrite it with the memory stick image. The current documentation is sysctl kern.geom.debugflags=16 dd if=memstick.img of=/dev/whatever0 bs=64k ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, 7 Oct 2011, Warren Block wrote: On Fri, 7 Oct 2011, Arnaud Lacombe wrote: Hi, On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wbl...@wonkity.com wrote: On Fri, 7 Oct 2011, Poul-Henning Kamp wrote: In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin Kaduk writes: Now, an ordinary user who is doing this for the first time might ask, why do I need to do something with 'debugflags' in order to make a USB stick? Which is the exactly right question to ask. The procedure documented is clearly flawed. Probably a misunderstanding on my part, since I suggested it to Glen. Can't recall the circumstances exactly. The next question would be: what is the correct procedure? I'd guess the procedure involves shooting your feet: from `sys/geom/geom_subr.c': /* If foot-shooting is enabled, any open on rank#1 is OK */ if ((g_debugflags 16) pp-geom-rank == 1) ; Well, yes. The goal is to unprotect the device, regardless of what may already be on it. Then the user can overwrite it with the memory stick image. The current documentation is sysctl kern.geom.debugflags=16 dd if=memstick.img of=/dev/whatever0 bs=64k I presume that Poul-Henning was not claiming that the documentation did not match the functional procedure, but rather that the procedure needed to achieve the goal (of a functional USB stick) is flawed. (Even if it is correctly documented.) -Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message alpine.bsf.2.00.1110071236270.2...@wonkity.com, Warren Block write
s:
Which is the exactly right question to ask.
The procedure documented is clearly flawed.
Well, yes. The goal is to unprotect the device, regardless of what may
already be on it. Then the user can overwrite it with the memory stick
image.
Unprotect from what ? from being already mounted ?
If you cannot open a geom provider for writing, then it is because
some piece of code in the kernel thinks it already owns the device
and don't want you to muck about with it.
Overriding this check is just asking for panics...
What I usually do in cases like this is:
(umount /dev/${whatever} || true) /dev/null 21
And if that isn't enough, or not possible, then the user needs
to undo whatever he did to the device...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, Oct 7, 2011 at 12:03 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message alpine.bsf.2.00.1110071236270.2...@wonkity.com, Warren Block
write
s:
Which is the exactly right question to ask.
The procedure documented is clearly flawed.
Well, yes. The goal is to unprotect the device, regardless of what may
already be on it. Then the user can overwrite it with the memory stick
image.
Unprotect from what ? from being already mounted ?
If you cannot open a geom provider for writing, then it is because
some piece of code in the kernel thinks it already owns the device
and don't want you to muck about with it.
Overriding this check is just asking for panics...
What I usually do in cases like this is:
(umount /dev/${whatever} || true) /dev/null 21
And if that isn't enough, or not possible, then the user needs
to undo whatever he did to the device...
My guess is that GEOM isn't letting go of the GPT table and you have
multiple partitions in the GPT table and you're not destroying them
hierarchically in a proper manner.. but again, that's just a guess
based on hazy recollection.
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message CAGH67wQk0jR+uk0oFO7Ye001vd-0UgcY-bf+84a8=9wtlhg...@mail.gmail.com , Garrett Cooper writes: My guess is that GEOM isn't letting go of the GPT table and you have multiple partitions in the GPT table and you're not destroying them hierarchically in a proper manner.. but again, that's just a guess based on hazy recollection. If none of the GPT partitions are open, you should be able to open /dev/da0. If not, the GPT geom class is buggy. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On 07.10.2011 22:53, Warren Block wrote: The current documentation is sysctl kern.geom.debugflags=16 dd if=memstick.img of=/dev/whatever0 bs=64k Did you try just write your image without debugflags settings? When /dev/whatever0 is not used nothing should prevent you write your image. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On 10/7/11 3:18 PM, Poul-Henning Kamp wrote: My guess is that GEOM isn't letting go of the GPT table and you have multiple partitions in the GPT table and you're not destroying them hierarchically in a proper manner.. but again, that's just a guess based on hazy recollection. If none of the GPT partitions are open, you should be able to open /dev/da0. If not, the GPT geom class is buggy. In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On 07.10.2011 23:41, Glen Barber wrote: In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. The problem is that this bad suggestion is everywhere in the Internet. And users use it always even when it not needed. I think it is bad idea add it in the our official documentation. When you doing all in the right way using debugflags=16 is not needed. And it is really dangerous when you doing something what you do not know exactly. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, 7 Oct 2011, Glen Barber wrote: Hi, On 10/7/11 3:18 PM, Poul-Henning Kamp wrote: My guess is that GEOM isn't letting go of the GPT table and you have multiple partitions in the GPT table and you're not destroying them hierarchically in a proper manner.. but again, that's just a guess based on hazy recollection. If none of the GPT partitions are open, you should be able to open /dev/da0. If not, the GPT geom class is buggy. In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. Tried it just now with the 9.0-BETA3 memstick image. # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.614157 secs (13033219 bytes/sec) # mount /dev/da0p2 /mnt # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k dd: /dev/da0: Operation not permitted # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 - 16 # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.915362 secs (12959031 bytes/sec) Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking automounter here.) We could make the normal procedure just the dd, followed by a note: If this gives an 'Operation not permitted' error, make sure that the target device is not in use or being automounted by some helpful utility program. And maybe If the error still appears and no other options are available, sysctl kern.geomflags.debug=16 will override the system safety and allow writes to the device. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On 10/7/11 4:27 PM, Warren Block wrote: In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. Tried it just now with the 9.0-BETA3 memstick image. [...] Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking automounter here.) Me not being one that uses hald or devd for USB, I'm certain the device was not mounted when writing the memstick image. In the former case of your test, is the USB stick bootable? -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Fri, Oct 7, 2011 at 4:27 PM, Warren Block wbl...@wonkity.com wrote: On Fri, 7 Oct 2011, Glen Barber wrote: Hi, On 10/7/11 3:18 PM, Poul-Henning Kamp wrote: My guess is that GEOM isn't letting go of the GPT table and you have multiple partitions in the GPT table and you're not destroying them hierarchically in a proper manner.. but again, that's just a guess based on hazy recollection. If none of the GPT partitions are open, you should be able to open /dev/da0. If not, the GPT geom class is buggy. In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. Tried it just now with the 9.0-BETA3 memstick image. # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.614157 secs (13033219 bytes/sec) # mount /dev/da0p2 /mnt # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k dd: /dev/da0: Operation not permitted # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 - 16 # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.915362 secs (12959031 bytes/sec) in the mean time, some background application issued a sync(2), corrupting part of what you just wrote, if not crashing the kernel. Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking automounter here.) We could make the normal procedure just the dd, followed by a note: If this gives an 'Operation not permitted' error, make sure that the target device is not in use or being automounted by some helpful utility program. And maybe If the error still appears and no other options are available, sysctl kern.geomflags.debug=16 will override the system safety and allow writes to the device. Then you can start to introduce backdoor for every single kernel-enforced policy. `kern.geomflags.debug=16' should not be used by the lambda user. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, 7 Oct 2011, Glen Barber wrote: On 10/7/11 4:27 PM, Warren Block wrote: In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. Tried it just now with the 9.0-BETA3 memstick image. [...] Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking automounter here.) Me not being one that uses hald or devd for USB, I'm certain the device was not mounted when writing the memstick image. In the former case of your test, is the USB stick bootable? I cleared the first 34 blocks and wrote it again to make sure, but yes. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message alpine.bsf.2.00.1110071352210.2...@wonkity.com, Warren Block write s: # mount /dev/da0p2 /mnt # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k dd: /dev/da0: Operation not permitted # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 - 16 # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.915362 secs (12959031 bytes/sec) Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking automounter here.) And you are sure the stick now contains what you expect ? If the dirty filesystem had blocks to write, it might have done so... debugflags are called debugflags for a reason: You should never need them, unless you are debugging a problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Fri, Oct 7, 2011 at 5:10 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message alpine.bsf.2.00.1110071352210.2...@wonkity.com, Warren Block write s: # mount /dev/da0p2 /mnt # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k dd: /dev/da0: Operation not permitted # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 - 16 # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.915362 secs (12959031 bytes/sec) Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking automounter here.) And you are sure the stick now contains what you expect ? If the dirty filesystem had blocks to write, it might have done so... debugflags are called debugflags for a reason: You should never need them, unless you are debugging a problem. How about disabling debugflags=16's action unless for DIAGNOSTICS kernel ? If you expose a setting, you cannot rely on a user not to use it even if you told him not to. As long as this is exposed and usable, it will be used, even more when it was documented. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On 10/7/11 5:10 PM, Warren Block wrote: Me not being one that uses hald or devd for USB, I'm certain the device was not mounted when writing the memstick image. In the former case of your test, is the USB stick bootable? I cleared the first 34 blocks and wrote it again to make sure, but yes. Ok, this should be updated in the Handbook then. -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1110071352210.2...@wonkity.com, Warren Block writes: Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking automounter here.) And you are sure the stick now contains what you expect ? If the dirty filesystem had blocks to write, it might have done so... debugflags are called debugflags for a reason: You should never need them, unless you are debugging a problem. Testing with md5 showed it was okay, but point taken. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
On Sat, 8 Oct 2011, Andrey V. Elsukov wrote: On 07.10.2011 23:41, Glen Barber wrote: In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. The problem is that this bad suggestion is everywhere in the Internet. And users use it always even when it not needed. I think it is bad idea add it in the our official documentation. When you doing all in the right way using debugflags=16 is not needed. And it is really dangerous when you doing something what you do not know exactly. Since we're talking about this, could you review the usage in the gmirror section of the Handbook GEOM chapter: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html Seems like that is a valid non-debugging use, to allow the last block to be written. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
