Re: Do you need/prefer the non-DUID option in the installer?
On 15 March 2015 at 23:38, Theo de Raadt wrote: >> The only thing I'd like to have is a command or easy way >> to convert a duid to a /dev/sd0a name to use current - or future - >> utilities that don't support DUID like badblocks from e2fsprogs >> in ports... > > In disklabel, you can see the duid for a drive; > >disklabel sd0 | grep duid > > Alternatively, sysctl knows them too > >sysctl hw.disknames > > There are circumstances where a disk can lack a duid, because > they have no way to store the information. But these are rare, > and not typical storage. For those faced with onerous task of manually changing a duid infested fstab to the equivalent non-DUID one I present the (not quite complete, but it's off the top of my head) script. Sorry 'bout the gmail de-indentation. Needs some more sed magic to put /dev/sdNn rather than sdN.n in the fstab lines generated. I'm sure true script mages (I name no names) could make it much more elegant. Perhaps this will alleviate some of the panic engendered by suddenly facing a duid fstab. :-) I leave the changes to do the reverse process as an exercise for the reader. No fair looking at the install script source. Ken #!/bin/ksh # De-DUID an fstab. OIFS=$IFS IFS=, set -- $(sysctl -n hw.disknames) IFS=$OIFS cp /etc/fstab /tmp/fstab entries=$* for _entry in $entries; do OIFS=$IFS IFS=":" set -- $_entry if [[ -n $2 ]]; then echo "$1 has a DUID of $2" sed -e "/$2/s//$1/p" /tmp/fstab >/tmp/fstab.new cp /tmp/fstab.new /tmp/fstab fi IFS=$OIFS done #cp /tmp/fstab /etc/fstab
Re: Do you need/prefer the non-DUID option in the installer?
> The only thing I'd like to have is a command or easy way > to convert a duid to a /dev/sd0a name to use current - or future - > utilities that don't support DUID like badblocks from e2fsprogs > in ports... In disklabel, you can see the duid for a drive; disklabel sd0 | grep duid Alternatively, sysctl knows them too sysctl hw.disknames There are circumstances where a disk can lack a duid, because they have no way to store the information. But these are rare, and not typical storage.
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 5:45 PM, Theo de Raadt wrote: > DUID support was written so that we could solve a problem, without > a question. This is a mop-up operation. The question being posed > is not "shall we leave the non-DUID question", but "what DUID support > gaps still remain, so that we can finish those". > The only thing I'd like to have is a command or easy way to convert a duid to a /dev/sd0a name to use current - or future - utilities that don't support DUID like badblocks from e2fsprogs in ports... I know it can be done via the C api (opendev(3)?), and using a program to get the name first is subject to some races... $ badblocks `duid2dev 9d45a80cb6151768.c` but obviously this has nothing to do with the options in the installer...
Re: Do you need/prefer the non-DUID option in the installer?
On 03/15/15 14:59, Jiri B wrote: > On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: >> Using DUIDs in the installed /etc/fstab has been the default for some time >> now. >> >> We'd like to eliminate the question in the installer and just use >> DUIDs unconditionally. >> >> But first we need to know you are aware of any circumstances where >> people need or prefer to use the non-DUID option when installing? > > iirc nick@ once said he uses /altroot and thus doesn't > use duids. but event it is still the truth it is unusual > setup. thanks, I can get myself in trouble without your help. ;) (tl;dr version: I'm fine with the installer becoming DUID-only) There are some cases where I like to use non-DUID labels. However, these are all non-standard cases where one has to do manual editing ANYWAY, and thus, switching over to non-DUIDs is a non-issue (and even there, it's usually just a few lines, the rest stay -- and need to stay -- DUID!) Unix-Philosophically speaking, I like non-DUIDs. They are simple things in the /dev directory. One doesn't really have to understand much about OpenBSD to see /dev/sd0h and have some idea what it means. e4fc87e6abfa5e45.h is not so obvious, 'specially to those who have seen Solaris and their c1t2d0s3 style notation which might look superficially similar. One really still needs to understand the non-DUID notation, too, so DUID is One More Thing to learn. It's a step away from the simplicity that has been an OpenBSD trait, and I can't type or remember sixteen characters in a row accurately. BUT as anyone who fiddled with USB disks or softraid has seen, there are issues with non-DUIDs. DUIDs are very important to have, modern systems without it would be ... difficult. And learning them takes about 60 seconds, no big deal. You must be this --> <--- smart to ride this ride. Score, at least to me: Problems solved by DUIDs: lots Problems CREATED by DUIDs: none (that I have found) Lots to zero. I'm more than happy to flip the switch to DUID only in the installer. Nick.
Re: mg(1): refactor sysdef.h?
On 03/15/15 21:01, Kamil Rytarowski wrote: > Brian Callahan wrote: >> On 03/15/15 19:24, Kamil Rytarowski wrote: >>> Hello, Currently sysdef.h includes C headers for little purpose, as >>> the same headers are already pulled in appropriate .c files. In the >>> result the headers listed in sysdef.h are pulled in twice. I propose >>> to move the remaining content (literally 11 lines-of-code) to def.h or >>> a better place. I think that back in time all system includes were >>> pulled in from sysdef.h, today I see no need for it any more. >> I'm not sure you've tried doing that. There's a warning to include those >> files in order for a reason. >> >> However, there are some files that have redundant includes. Below is a >> diff to remove those. >> >> OK? >> > Thank you, this is another approach. OK from me! No no. When I say "OK?" I'm asking another developer to look at it and say whether or not I can commit it. Anyhow I've talked to Theo about this and I will be bringing mg in line with the rest of how OpenBSD handles includes. ~Brian
Re: mg(1): refactor sysdef.h?
Brian Callahan wrote: > On 03/15/15 19:24, Kamil Rytarowski wrote: > > Hello, Currently sysdef.h includes C headers for little purpose, as > > the same headers are already pulled in appropriate .c files. In the > > result the headers listed in sysdef.h are pulled in twice. I propose > > to move the remaining content (literally 11 lines-of-code) to def.h or > > a better place. I think that back in time all system includes were > > pulled in from sysdef.h, today I see no need for it any more. > > I'm not sure you've tried doing that. There's a warning to include those > files in order for a reason. > > However, there are some files that have redundant includes. Below is a > diff to remove those. > > OK? > Thank you, this is another approach. OK from me!
Re: mg(1): refactor sysdef.h?
On 03/15/15 19:24, Kamil Rytarowski wrote: > Hello, Currently sysdef.h includes C headers for little purpose, as > the same headers are already pulled in appropriate .c files. In the > result the headers listed in sysdef.h are pulled in twice. I propose > to move the remaining content (literally 11 lines-of-code) to def.h or > a better place. I think that back in time all system includes were > pulled in from sysdef.h, today I see no need for it any more. I'm not sure you've tried doing that. There's a warning to include those files in order for a reason. However, there are some files that have redundant includes. Below is a diff to remove those. OK? ~Brian Index: dired.c === RCS file: /cvs/src/usr.bin/mg/dired.c,v retrieving revision 1.69 diff -u -p -r1.69 dired.c --- dired.c30 Dec 2014 22:05:32 -1.69 +++ dired.c15 Mar 2015 23:44:45 - @@ -10,7 +10,6 @@ #include "funmap.h" #include "kbd.h" -#include #include #include #include Index: extend.c === RCS file: /cvs/src/usr.bin/mg/extend.c,v retrieving revision 1.58 diff -u -p -r1.58 extend.c --- extend.c6 Dec 2014 23:20:17 -1.58 +++ extend.c15 Mar 2015 23:44:45 - @@ -10,7 +10,6 @@ #include "kbd.h" #include "funmap.h" -#include #include #include Index: fileio.c === RCS file: /cvs/src/usr.bin/mg/fileio.c,v retrieving revision 1.98 diff -u -p -r1.98 fileio.c --- fileio.c16 Nov 2014 04:16:41 -1.98 +++ fileio.c15 Mar 2015 23:44:45 - @@ -7,7 +7,6 @@ */ #include "def.h" -#include #include #include #include Index: grep.c === RCS file: /cvs/src/usr.bin/mg/grep.c,v retrieving revision 1.42 diff -u -p -r1.42 grep.c --- grep.c16 Nov 2014 04:16:41 -1.42 +++ grep.c15 Mar 2015 23:44:45 - @@ -6,11 +6,9 @@ #include "kbd.h" #include "funmap.h" -#include #include #include #include -#include int globalwd = FALSE; static int compile_goto_error(int, int); Index: line.c === RCS file: /cvs/src/usr.bin/mg/line.c,v retrieving revision 1.54 diff -u -p -r1.54 line.c --- line.c16 Nov 2014 04:16:41 -1.54 +++ line.c15 Mar 2015 23:44:45 - @@ -20,8 +20,6 @@ #include "def.h" #include -#include -#include /* * Allocate a new line of size `used'. lrealloc() can be called if the line Index: re_search.c === RCS file: /cvs/src/usr.bin/mg/re_search.c,v retrieving revision 1.30 diff -u -p -r1.30 re_search.c --- re_search.c20 Mar 2014 07:47:29 -1.30 +++ re_search.c15 Mar 2015 23:44:45 - @@ -16,7 +16,6 @@ #ifdef REGEX #include "def.h" -#include #include #include "macro.h" Index: region.c === RCS file: /cvs/src/usr.bin/mg/region.c,v retrieving revision 1.34 diff -u -p -r1.34 region.c --- region.c20 Mar 2014 07:47:29 -1.34 +++ region.c15 Mar 2015 23:44:45 - @@ -9,12 +9,10 @@ * internal use. */ -#include #include #include #include -#include #include #include "def.h" Index: tags.c === RCS file: /cvs/src/usr.bin/mg/tags.c,v retrieving revision 1.10 diff -u -p -r1.10 tags.c --- tags.c16 Nov 2014 00:59:25 -1.10 +++ tags.c15 Mar 2015 23:44:45 - @@ -6,16 +6,11 @@ * Author: Sunil Nimmagadda */ -#include #include #include -#include #include #include -#include -#include -#include #include #include "def.h" Index: tty.c === RCS file: /cvs/src/usr.bin/mg/tty.c,v retrieving revision 1.32 diff -u -p -r1.32 tty.c --- tty.c16 Nov 2014 00:50:00 -1.32 +++ tty.c15 Mar 2015 23:44:45 - @@ -29,7 +29,6 @@ #include "def.h" -#include #include #include Index: ttyio.c === RCS file: /cvs/src/usr.bin/mg/ttyio.c,v retrieving revision 1.35 diff -u -p -r1.35 ttyio.c --- ttyio.c20 Mar 2014 07:47:29 -1.35 +++ ttyio.c15 Mar 2015 23:44:45 - @@ -11,7 +11,6 @@ */ #include "def.h" -#include #include #include #include Index: yank.c === RCS file: /cvs/src/usr.bin/mg/yank.c,v retrieving revision 1.11 diff -u -p -r1.11 yank.c --- yank.c20 Mar 2014 07:47:29 -1.11 +++ yank.c15 Mar 2015 23:44:45 - @@ -8,8 +8,6 @@ #include "def.h" -#include - #ifndef KBLOCK #define KBLOCK256/* Kill buffer block size. */ #endif
Re: Do you need/prefer the non-DUID option in the installer?
> I guess as long as /etc/fstab continues to support non-DUID device > names, it can be manually edited after the initial system build. Of course the non-DUID device names will continue working. OK, this seems like a conversation with people who never read the code to see how DUID works. What a waste of words.
Re: Do you need/prefer the non-DUID option in the installer?
> On 3/15/15, Michael W. Lucas wrote: > > On Sun, Mar 15, 2015 at 01:06:37PM -0600, Theo de Raadt wrote: > >> Look, if people keep being unspecific on how DUIDs interfere with > >> their usage patterns, then the non-DUID configuration mode is going > >> to go away. > >> > >> WHY must be use the non-DUID option in the installer??!?!?! > > > > As someone who recently had several OpenBSD boxes in production, in a > > variety of roles: > > > > I can't imagine why DUIDs wouldn't work. > > > > We defaulted to DUIDs the moment they became available. They worked > > fine. Even for the Linux guys. > > > > If someone has a particular dislike of DUIDs, they can easily change > > them back. Anyone who has a whole bunch of OpenBSD boxes probably has > > uses a post-install script, and a couple lines of > > sed/awk/perl/whatever will make them happy. > > The ridiculousness of this point is beyond ... beyond ... well, > it is silly. > > The installation script right now, as everyone is used to, asks > a simple question. With a "yes" (the default) or a "no" answer > everyone's preference and need are met. > > You are arguing to make more work -- which certainly means > more time, more effort and less convenience, with potential > introduction of errors -- for a single group of people, just so > the other group isn't bothered to press the enter key to accept > the default "yes" answer during installation? > > Is this the problem you are trying to solve? One less press > of the enter key for you? > > Are you serious?! Hmm. I find this interesting. Once in a while a user goes off their rocker and thinks they are in control of the decisions the developers put into the source tree... Get back onto your meds. DUID support was written so that we could solve a problem, without a question. This is a mop-up operation. The question being posed is not "shall we leave the non-DUID question", but "what DUID support gaps still remain, so that we can finish those".
Re: Do you need/prefer the non-DUID option in the installer?
> Do all arches work with DUIDs now? I have a recollection of problems > somewhere not all that long ago. Might have been sparc or vax or something. DUID support is unconditional in the installer. It is possible to have some disks that have non-OpenBSD labels, in which case the DUID might not be stored. But that won't be a boot disk... > I don't care whether the installer uses DUIDs or not, as long as 1) they > work and 2) the option to use /dev/sd0a etc remains in fstab. Naturally.
Re: Do you need/prefer the non-DUID option in the installer?
On 3/15/15, Michael W. Lucas wrote: > On Sun, Mar 15, 2015 at 01:06:37PM -0600, Theo de Raadt wrote: >> Look, if people keep being unspecific on how DUIDs interfere with >> their usage patterns, then the non-DUID configuration mode is going >> to go away. >> >> WHY must be use the non-DUID option in the installer??!?!?! > > As someone who recently had several OpenBSD boxes in production, in a > variety of roles: > > I can't imagine why DUIDs wouldn't work. > > We defaulted to DUIDs the moment they became available. They worked > fine. Even for the Linux guys. > > If someone has a particular dislike of DUIDs, they can easily change > them back. Anyone who has a whole bunch of OpenBSD boxes probably has > uses a post-install script, and a couple lines of > sed/awk/perl/whatever will make them happy. The ridiculousness of this point is beyond ... beyond ... well, it is silly. The installation script right now, as everyone is used to, asks a simple question. With a "yes" (the default) or a "no" answer everyone's preference and need are met. You are arguing to make more work -- which certainly means more time, more effort and less convenience, with potential introduction of errors -- for a single group of people, just so the other group isn't bothered to press the enter key to accept the default "yes" answer during installation? Is this the problem you are trying to solve? One less press of the enter key for you? Are you serious?! --patrick > If you have one OpenBSD box, and you just don't like DUIDs, again, > it's really easy to revert. > > ==ml > > PS: Yes, I still have OpenBSD hosts. But I'm no longer a pro sysadmin, > so I can't claim to be running a server farm or anything like that. > > -- > Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor > http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ > >
mg(1): refactor sysdef.h?
Hello, Currently sysdef.h includes C headers for little purpose, as the same headers are already pulled in appropriate .c files. In the result the headers listed in sysdef.h are pulled in twice. I propose to move the remaining content (literally 11 lines-of-code) to def.h or a better place. I think that back in time all system includes were pulled in from sysdef.h, today I see no need for it any more.
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 01:06:37PM -0600, Theo de Raadt wrote: > Look, if people keep being unspecific on how DUIDs interfere with > their usage patterns, then the non-DUID configuration mode is going > to go away. > > WHY must be use the non-DUID option in the installer??!?!?! As someone who recently had several OpenBSD boxes in production, in a variety of roles: I can't imagine why DUIDs wouldn't work. We defaulted to DUIDs the moment they became available. They worked fine. Even for the Linux guys. If someone has a particular dislike of DUIDs, they can easily change them back. Anyone who has a whole bunch of OpenBSD boxes probably has uses a post-install script, and a couple lines of sed/awk/perl/whatever will make them happy. If you have one OpenBSD box, and you just don't like DUIDs, again, it's really easy to revert. ==ml PS: Yes, I still have OpenBSD hosts. But I'm no longer a pro sysadmin, so I can't claim to be running a server farm or anything like that. -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: Do you need/prefer the non-DUID option in the installer?
On 2015/03/15 17:37, System Administrator wrote: > I guess as long as /etc/fstab continues to support non-DUID device > names, it can be manually edited after the initial system build. > However, that also opens the window to transcription errors which can > easily render the system non-operational, requiring recovery from > external media, thus substantially complicating the deployment step. It can be automatically edited, too, avoiding transcription errors.
Re: Do you need/prefer the non-DUID option in the installer?
Do all arches work with DUIDs now? I have a recollection of problems somewhere not all that long ago. Might have been sparc or vax or something. I don't care whether the installer uses DUIDs or not, as long as 1) they work and 2) the option to use /dev/sd0a etc remains in fstab.
Re: Do you need/prefer the non-DUID option in the installer?
Here is a similar use-case: I maintain a number of HA clusters with fully automatic bi-directional synchronization using rdist. To achieve this I have as few file differences as possible and those that must differ (mostly hostname.$if) being entirely scriptable -- the sole noteable exception is /etc/myname that drives the reconciliation script. Obviously, the logs and temporary files are excluded, but every file necessary to configure and operate the system must be included. Now for the tricky part relevant to the title subject -- most of the clusters are not created by cloning, so their DUIDs are independent. Most of my clients are SMBs and do not realize to what extent they rely on the infrastructure "appliances" as the commercial appliances these servers replace do not generally support HA-clustering (that feature being marketed to "Enterprises" not SMBs). Once the client is educated and discovers that the incremental cost to add HA is relatively low, they go for it; however now that the primary server is busy under load, the additional cluster member(s) are built using installation image rather than direct cloning. I guess as long as /etc/fstab continues to support non-DUID device names, it can be manually edited after the initial system build. However, that also opens the window to transcription errors which can easily render the system non-operational, requiring recovery from external media, thus substantially complicating the deployment step. -Jacob. On 15 Mar 2015 at 12:12, Bob Beck wrote: > Yes I do. when I install machines that I dump/restore clone, I do not > use DUID's. it's very nice to make a system > without DUID's in that case. > > I think you could eliminate the DUID question for laptops. it's always > right there. I'd like to keep it for "server's" but don't > know if that's reasonably possible in the installer > > > > > On Sun, Mar 15, 2015 at 11:49 AM, Theo de Raadt > wrote: > >> On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > >> > Using DUIDs in the installed /etc/fstab has been the default for some > >> > time now. > >> > > >> > We'd like to eliminate the question in the installer and just use > >> > DUIDs unconditionally. > >> > > >> > But first we need to know you are aware of any circumstances where > >> > people need or prefer to use the non-DUID option when installing? > >> > >> I prefer not using DUIDs. > > > > OK, I think Ken made a mistake mentioning preferences. The real > > question is if anyone has a use-case where DUIDs do not work. > > > > Preference has nothing to do with it. If DUIDs have no downsides, > > and only the upsides that they were designed to support, then it is > > time to remove the installation question. > > > > The non-DUID access patterns continue to work, of course. That is > > also not part of the question. > > > >
Re: Do you need/prefer the non-DUID option in the installer?
On March 15, 2015 8:18:59 PM GMT+01:00, Vadim Zhukov wrote: >15 марта 2015 г. 21:26 пользователь "Robert Peichaer" > >написал: >> >> On Sun, Mar 15, 2015 at 09:03:45PM +0300, Vadim Zhukov wrote: >> > 15 ?? 2015 ??. 20:50 "Theo de >Raadt" < >dera...@cvs.openbsd.org> >> > ??: >> > > >> > > > On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback >wrote: >> > > > > Using DUIDs in the installed /etc/fstab has been the default >for >some >> > time now. >> > > > > >> > > > > We'd like to eliminate the question in the installer and just >use >> > > > > DUIDs unconditionally. >> > > > > >> > > > > But first we need to know you are aware of any circumstances >where >> > > > > people need or prefer to use the non-DUID option when >installing? >> > > > >> > > > I prefer not using DUIDs. >> > > >> > > OK, I think Ken made a mistake mentioning preferences. The real >> > > question is if anyone has a use-case where DUIDs do not work. >> > > >> > > Preference has nothing to do with it. If DUIDs have no >downsides, >> > > and only the upsides that they were designed to support, then it >is >> > > time to remove the installation question. >> > > >> > > The non-DUID access patterns continue to work, of course. That >is >> > > also not part of the question. >> > >> > Virtualization appliances: after cloning you could get a different >drive >> > ID, right? - and thus get a non-bootable system. That's the only >real >issue >> > I know. Hope to be wrong. :) >> > >> > -- >> > Vadim Zhukov >> >> At least on VMware, the DUID does not change after cloning. > >Nice to know, thanks. I'll recheck tomorrow (at $mainjob) how it goes >with >KVM. It surely shouldn't, as the DUID is part of the disklabel, which is none of VMware's business. /Alexander > >-- >Vadim Zhukov
Re: Do you need/prefer the non-DUID option in the installer?
15 марта 2015 г. 21:26 пользователь "Robert Peichaer" написал: > > On Sun, Mar 15, 2015 at 09:03:45PM +0300, Vadim Zhukov wrote: > > 15 ?? 2015 ??. 20:50 "Theo de Raadt" < dera...@cvs.openbsd.org> > > ??: > > > > > > > On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > > > > > Using DUIDs in the installed /etc/fstab has been the default for some > > time now. > > > > > > > > > > We'd like to eliminate the question in the installer and just use > > > > > DUIDs unconditionally. > > > > > > > > > > But first we need to know you are aware of any circumstances where > > > > > people need or prefer to use the non-DUID option when installing? > > > > > > > > I prefer not using DUIDs. > > > > > > OK, I think Ken made a mistake mentioning preferences. The real > > > question is if anyone has a use-case where DUIDs do not work. > > > > > > Preference has nothing to do with it. If DUIDs have no downsides, > > > and only the upsides that they were designed to support, then it is > > > time to remove the installation question. > > > > > > The non-DUID access patterns continue to work, of course. That is > > > also not part of the question. > > > > Virtualization appliances: after cloning you could get a different drive > > ID, right? - and thus get a non-bootable system. That's the only real issue > > I know. Hope to be wrong. :) > > > > -- > > Vadim Zhukov > > At least on VMware, the DUID does not change after cloning. Nice to know, thanks. I'll recheck tomorrow (at $mainjob) how it goes with KVM. -- Vadim Zhukov
Re: Do you need/prefer the non-DUID option in the installer?
> On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > > Using DUIDs in the installed /etc/fstab has been the default for some time > > now. > > > > We'd like to eliminate the question in the installer and just use > > DUIDs unconditionally. > > > > But first we need to know you are aware of any circumstances where > > people need or prefer to use the non-DUID option when installing? > > iirc nick@ once said he uses /altroot and thus doesn't > use duids. but event it is still the truth it is unusual > setup. Look, if people keep being unspecific on how DUIDs interfere with their usage patterns, then the non-DUID configuration mode is going to go away. WHY must be use the non-DUID option in the installer??!?!?!
Re: tiny tetris patch
> On Sun, Mar 15, 2015 at 1:21 PM, Theo de Raadt > wrote: > > > One day, it would be nice if /var cannot be filled up in a hostile > > fashion... > > > > slightly off-topic, but I routinely make /var and /var/log separate > filesystems (especially on Internet-facing hosts). this might be worth > considering as a default behavior for the installer. it doesn't > completely fix the problem but it at least mitigates one of the more > frequent causes. With only 14 partitions available, that is a bit of a loss. And unfortunately /var/log is not the only attack surface.
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > Using DUIDs in the installed /etc/fstab has been the default for some time > now. > > We'd like to eliminate the question in the installer and just use > DUIDs unconditionally. > > But first we need to know you are aware of any circumstances where > people need or prefer to use the non-DUID option when installing? iirc nick@ once said he uses /altroot and thus doesn't use duids. but event it is still the truth it is unusual setup. j.
Re: tiny tetris patch
On Sun, Mar 15, 2015 at 1:21 PM, Theo de Raadt wrote: > One day, it would be nice if /var cannot be filled up in a hostile > fashion... > slightly off-topic, but I routinely make /var and /var/log separate filesystems (especially on Internet-facing hosts). this might be worth considering as a default behavior for the installer. it doesn't completely fix the problem but it at least mitigates one of the more frequent causes. -ken
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 09:03:45PM +0300, Vadim Zhukov wrote: > 15 ?? 2015 ??. 20:50 "Theo de Raadt" > > ??: > > > > > On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > > > > Using DUIDs in the installed /etc/fstab has been the default for some > time now. > > > > > > > > We'd like to eliminate the question in the installer and just use > > > > DUIDs unconditionally. > > > > > > > > But first we need to know you are aware of any circumstances where > > > > people need or prefer to use the non-DUID option when installing? > > > > > > I prefer not using DUIDs. > > > > OK, I think Ken made a mistake mentioning preferences. The real > > question is if anyone has a use-case where DUIDs do not work. > > > > Preference has nothing to do with it. If DUIDs have no downsides, > > and only the upsides that they were designed to support, then it is > > time to remove the installation question. > > > > The non-DUID access patterns continue to work, of course. That is > > also not part of the question. > > Virtualization appliances: after cloning you could get a different drive > ID, right? - and thus get a non-bootable system. That's the only real issue > I know. Hope to be wrong. :) > > -- > Vadim Zhukov At least on VMware, the DUID does not change after cloning. -- -=[rpe]=-
Re: Do you need/prefer the non-DUID option in the installer?
> It's very nice to make a system without DUID's in that case. Better question is: Why? The only visible effect from the admin perspective is the first column in /etc/fstab, which now contains an unambigious tag. All the sysadm tools can the DUID names.
Re: Do you need/prefer the non-DUID option in the installer?
> Yes I do. when I install machines that I dump/restore clone, I do > not use DUID's. it's very nice to make a system without DUID's in > that case. I'm sorry, but I don't understand the usage case here which blocks DUIDS, so let's see a better explanation or demonstration. When you have DUIDs in /etc/fstab, you can still use the disk partitions using the raw disk names. The partitions are obvious. Figuring out which disk it is, is really easy, lots of options to provide the translation. And as far as I know, all the tools have been adapted to accept DUID. > I think you could eliminate the DUID question for laptops. it's always > right there. I'd like to keep it for "server's" but don't > know if that's reasonably possible in the installer The installer makes no differentiation between laptops and servers.
Re: Do you need/prefer the non-DUID option in the installer?
Yes I do. when I install machines that I dump/restore clone, I do not use DUID's. it's very nice to make a system without DUID's in that case. I think you could eliminate the DUID question for laptops. it's always right there. I'd like to keep it for "server's" but don't know if that's reasonably possible in the installer On Sun, Mar 15, 2015 at 11:49 AM, Theo de Raadt wrote: >> On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: >> > Using DUIDs in the installed /etc/fstab has been the default for some time >> > now. >> > >> > We'd like to eliminate the question in the installer and just use >> > DUIDs unconditionally. >> > >> > But first we need to know you are aware of any circumstances where >> > people need or prefer to use the non-DUID option when installing? >> >> I prefer not using DUIDs. > > OK, I think Ken made a mistake mentioning preferences. The real > question is if anyone has a use-case where DUIDs do not work. > > Preference has nothing to do with it. If DUIDs have no downsides, > and only the upsides that they were designed to support, then it is > time to remove the installation question. > > The non-DUID access patterns continue to work, of course. That is > also not part of the question. >
Re: Do you need/prefer the non-DUID option in the installer?
15 марта 2015 г. 20:50 пользователь "Theo de Raadt" написал: > > > On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > > > Using DUIDs in the installed /etc/fstab has been the default for some time now. > > > > > > We'd like to eliminate the question in the installer and just use > > > DUIDs unconditionally. > > > > > > But first we need to know you are aware of any circumstances where > > > people need or prefer to use the non-DUID option when installing? > > > > I prefer not using DUIDs. > > OK, I think Ken made a mistake mentioning preferences. The real > question is if anyone has a use-case where DUIDs do not work. > > Preference has nothing to do with it. If DUIDs have no downsides, > and only the upsides that they were designed to support, then it is > time to remove the installation question. > > The non-DUID access patterns continue to work, of course. That is > also not part of the question. Virtualization appliances: after cloning you could get a different drive ID, right? - and thus get a non-bootable system. That's the only real issue I know. Hope to be wrong. :) -- Vadim Zhukov
Re: Do you need/prefer the non-DUID option in the installer?
> On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > > Using DUIDs in the installed /etc/fstab has been the default for some time > > now. > > > > We'd like to eliminate the question in the installer and just use > > DUIDs unconditionally. > > > > But first we need to know you are aware of any circumstances where > > people need or prefer to use the non-DUID option when installing? > > I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question.
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > Using DUIDs in the installed /etc/fstab has been the default for some time > now. > > We'd like to eliminate the question in the installer and just use > DUIDs unconditionally. > > But first we need to know you are aware of any circumstances where > people need or prefer to use the non-DUID option when installing? I prefer not using DUIDs. --patrick
Re: tiny tetris patch
> The global variables gid and egid are only set at one place; > actually, it's visible in your patch itself in tetris.c. > So we know both are always the process's real, effective, or saved GID. > Consequently, setegid() cannot fail, and there is no need to check. Yes. Long term, I would like to see the games stop being setgid as a way to write to /var. One day, it would be nice if /var cannot be filled up in a hostile fashion...
Re: tiny tetris patch
Hi David,
David CARLIER wrote on Sun, Mar 15, 2015 at 09:09:25AM +:
> As tetris is one of my preferred game :-) ... just did wrapper around
> setegid in same manner than xmalloc and such. If it can find any use ...
This doesn't make sense to me.
The global variables gid and egid are only set at one place;
actually, it's visible in your patch itself in tetris.c.
So we know both are always the process's real, effective, or saved GID.
Consequently, setegid() cannot fail, and there is no need to check.
Even if it could fail, error handling is already in place:
err(1, "cannot open %s for %s", _PATH_SCOREFILE, human);
err(1, "cannot fdopen %s for %s", _PATH_SCOREFILE, human);
That's also visible in your patch.
To summarize, there is no need to change anything.
Yours,
Ingo
> Index: scores.c
> ===
> RCS file: /cvs/src/games/tetris/scores.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 scores.c
> --- scores.c 16 Nov 2014 04:49:49 - 1.12
> +++ scores.c 15 Mar 2015 09:08:46 -
> @@ -111,11 +111,11 @@ getscores(FILE **fpp)
> human = "reading";
> lck = LOCK_SH;
> }
> - setegid(egid);
> + xsetegid(egid);
> mask = umask(S_IWOTH);
> sd = open(_PATH_SCOREFILE, mint, 0666);
> (void)umask(mask);
> - setegid(gid);
> + xsetegid(gid);
> if (sd < 0) {
> if (fpp == NULL) {
> nscores = 0;
> @@ -123,10 +123,10 @@ getscores(FILE **fpp)
> }
> err(1, "cannot open %s for %s", _PATH_SCOREFILE, human);
> }
> - setegid(egid);
> + xsetegid(egid);
> if ((sf = fdopen(sd, mstr)) == NULL)
> err(1, "cannot fdopen %s for %s", _PATH_SCOREFILE, human);
> - setegid(gid);
> + xsetegid(gid);
>
> /*
>* Grab a lock.
> Index: tetris.c
> ===
> RCS file: /cvs/src/games/tetris/tetris.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 tetris.c
> --- tetris.c 16 Nov 2014 04:49:49 - 1.25
> +++ tetris.c 15 Mar 2015 09:08:46 -
> @@ -161,7 +161,7 @@ main(int argc, char *argv[])
>
> gid = getgid();
> egid = getegid();
> - setegid(gid);
> + xsetegid(gid);
>
> classic = showpreview = 0;
> while ((ch = getopt(argc, argv, "ck:l:ps")) != -1)
> @@ -363,4 +363,11 @@ usage(void)
> {
> (void)fprintf(stderr, "usage: tetris [-cps] [-k keys] [-l level]\n");
> exit(1);
> +}
> +
> +void
> +xsetegid(gid_t gid)
> +{
> +if (setegid(gid) == -1)
> +err(1, "setegid() failed");
> }
> Index: tetris.h
> ===
> RCS file: /cvs/src/games/tetris/tetris.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 tetris.h
> --- tetris.h 10 Aug 2008 12:23:25 - 1.10
> +++ tetris.h 15 Mar 2015 09:08:46 -
> @@ -176,3 +176,4 @@ extern intclassic;
> int fits_in(const struct shape *, int);
> void place(const struct shape *, int, int);
> void stop(char *);
> +void xsetegid(gid_t);
Re: Do you need/prefer the non-DUID option in the installer?
> On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > > Using DUIDs in the installed /etc/fstab has been the default for some time > > now. > > > > We'd like to eliminate the question in the installer and just use > > DUIDs unconditionally. > > > > But first we need to know you are aware of any circumstances where > > people need or prefer to use the non-DUID option when installing? > > > > Ken > > I think there were issues on Octeon when using DUIDs by default. > Did anyone else run into this too? No description of the issue. Please...
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: > Using DUIDs in the installed /etc/fstab has been the default for some time > now. > > We'd like to eliminate the question in the installer and just use > DUIDs unconditionally. > > But first we need to know you are aware of any circumstances where > people need or prefer to use the non-DUID option when installing? > > Ken I think there were issues on Octeon when using DUIDs by default. Did anyone else run into this too? -- jasper
Do you need/prefer the non-DUID option in the installer?
Using DUIDs in the installed /etc/fstab has been the default for some time now. We'd like to eliminate the question in the installer and just use DUIDs unconditionally. But first we need to know you are aware of any circumstances where people need or prefer to use the non-DUID option when installing? Ken
[PATCH] dependency tree bug in ramdisk Makefile
Hi there,
i think i found a bug in the build process, im not able to build miniroot
with multiple processes through - for example - 'make -j4'
$ pwd
/usr/src/distrib/amd64/ramdisk_cd
$ sudo make -j 4
awk -f /usr/src/distrib/amd64/ramdisk_cd/../../miniroot/makeconf.awk
CBIN=instbin /usr/src/distrib/amd64/ramdisk_cd/../common/list
/usr/src/distrib/amd64/ramdisk_cd/list.local > instbin.conf
mtree -def /usr/src/distrib/amd64/ramdisk_cd/../../miniroot/mtree.conf -p /mnt/
-u
cd /usr/src/distrib/amd64/ramdisk_cd/../../../sys/arch/amd64/conf && config
RAMDISK_CD
Filesystem 512-blocks Used Avail Capacity iused ifree %iused
Mounted on
/dev/sd0a 2057756448656 150621623%6151 149751 4% /
umount /mnt
umount: /mnt: not currently mounted
*** Error 1 in target 'rd_teardown' (ignored)
vnconfig -u vnd0
vnconfig: VNDIOCCLR: Device not configured
*** Error 1 in target 'rd_teardown' (ignored)
cp /var/tmp/image.31801 mr.fs
cp: /var/tmp/image.31801: No such file or directory
*** Error 1 in target 'rd_teardown'
TOPDIR=/usr/src/distrib/amd64/ramdisk_cd/..
CURDIR=/usr/src/distrib/amd64/ramdisk_cd
OBJDIR=/usr/src/distrib/amd64/ramdisk_cd REV=56 TARGDIR=/mnt
UTILS=/usr/src/distrib/amd64/ramdisk_cd/../../miniroot RELEASEDIR= sh
/usr/src/distrib/amd64/ramdisk_cd/../../miniroot/runlist.sh
/usr/src/distrib/amd64/ramdisk_cd/../common/list
/usr/src/distrib/amd64/ramdisk_cd/list.local
COPY${OBJDIR}/instbin
instbin
cp: /usr/src/distrib/amd64/ramdisk_cd/instbin: No such file or directory
*** Error 1 in target 'do_files'
cd /usr/src/distrib/amd64/ramdisk_cd/../../../sys/arch/amd64/compile/RAMDISK_CD
&& make clean && COPTS=-Os exec make
rm -f eddep *bsd *bsd.gdb tags *.[dio] [a-z]*.s [Ee]rrs linterrs assym.h
cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main
-Wno-uninitialized -Wstack-larger-than-2047 -mcmodel=kernel -mno-red-zone
-mno-sse2 -mno-sse -mno-3dnow -mno-mmx -msoft-float -fno-omit-frame-pointer
-fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf
-fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -fno-pie
-fno-stack-protector -Wa,-n -Os -pipe -nostdinc -I../../../.. -I.
-I../../../../arch -DSCSITERSE -DSMALL_KERNEL -DNO_PROPOLICE -DTIMEZONE="0"
-DDST="0" -DFFS -DFFS2 -DEXT2FS -DNFSCLIENT -DCD9660 -DUDF -DMSDOSFS -DINET
-DINET6 -DBOOT_CONFIG -DCRYPTO -DRAMDISK_HOOKS -DMINIROOTSIZE="0x1180"
-DPCIVERBOSE -DMAXUSERS=4 -D_KERNEL -MD -MP -c swapbsd.c
I think this is a bug in the dependency tree of
src/distrib/amd64/ramdisk_cd/Makefile.inc
This Patch would fix it:
Index: distrib/amd64/common/Makefile.inc
===
RCS file: /home/cvs/src/distrib/amd64/common/Makefile.inc,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile.inc
--- distrib/amd64/common/Makefile.inc 29 Mar 2014 17:31:40 - 1.26
+++ distrib/amd64/common/Makefile.inc 13 Mar 2015 14:28:53 -
@@ -71,7 +71,7 @@ bsd:
${MAKE} clean && COPTS=-Os exec ${MAKE}
cp ${.CURDIR}/../../../sys/arch/amd64/compile/${RAMDISK}/bsd bsd
-${IMAGE}: ${CBIN} rd_setup do_files rd_teardown
+${IMAGE}: rd_teardown
rd_setup: ${CBIN}
dd if=/dev/zero of=${REALIMAGE} bs=512 count=${NBLKS}
@@ -81,7 +81,7 @@ rd_setup: ${CBIN}
fsck ${VND_RDEV}
mount ${VND_DEV} ${MOUNT_POINT}
-rd_teardown:
+rd_teardown: do_files
@df -i ${MOUNT_POINT}
-umount ${MOUNT_POINT}
-vnconfig -u ${VND}
@@ -120,7 +120,7 @@ ${CBIN}: ${CBIN}.mk ${CBIN}.cache ${CBIN
${CRUNCHCONF}: ${LISTS}
awk -f ${UTILS}/makeconf.awk CBIN=${CBIN} ${LISTS} > ${CRUNCHCONF}
-do_files:
+do_files: rd_setup
mtree -def ${MTREE} -p ${MOUNT_POINT}/ -u
TOPDIR=${TOP} CURDIR=${.CURDIR} OBJDIR=${.OBJDIR} \
REV=${REV} TARGDIR=${MOUNT_POINT} UTILS=${UTILS} \
Re: libssl: signal races in capability checks
> grep'ed the tree for siglongjmp calls, and spotted possible offenders in > libssl's code. The code in question checks hardware capabilities for > ARM, S390x, and SPARCv9. > > The code will call some routines that could trigger SIGILL (or SIGBUS), > which is caught with an own signal handler. This signal handler will > perform the previously mentioned siglongjmp and jumps out of the > capability testing. For the record, none of this code is enabled under OpenBSD. I will spare you my opinion of libraries registering signal handlers, because the amount of profanity I'd use is beyond the tolerance level of this list. All the information about the processor we run, and obtained by attempting to execute code and catch signals, has to be obtained from the kernel in a safe way (such as sysctl). Only the kernel will know that all the processors the library may run on, when running on a multiprocessor system, support the various instruction flavours. For a good example of this, see for example ppccap.c, although it is currently unused either. > It's difficult to write proper signal handlers, and even worse, I lack > machines of these types. "gcc -c" compiles the S390x and SPARCv9 files > for me, so there shouldn't be syntax errors. Yet I really need peer > reviews. If somebody dares to look at signals: Now is the time! :) I think now is the time to remove the S390x code, and work on documenting what the signal-based code attempts to know so that this code can be removed completely. (and this reminds me to add a few machdep sysctls to sparc64 so that I can tinker with the VIS Montgomery code...) Miod
Re: keyboard and mouse problems
On 03/14/15 21:48, Theo de Raadt wrote:
yes, can you try the next snapshot?
we are muddling our way through trying to find a series of fixes for
a problem :)
Laptop keyboard now working again, as expected with:
OpenBSD 5.7-current (RAMDISK_CD) #723: Sat Mar 14 14:51:43 MDT 2015
bsd.rd dmesg below.
Thanks
Fred
Script started on Sun Mar 15 10:53:03 2015
port:fred ~> cu -l /dev/cuaU0 -s115200
Connected to /dev/cuaU0 (speed 115200)
bsd.rd
/-\|/-\booting hd0a:bsd.rd:
|/-\|6494084/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+423044
[72+243584-\|/-\|/-\|/-\|+233906/-\|/-\|/-\|/-]=0x70d720
entry point at 0x200120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.
http://www.OpenBSD.org
OpenBSD 5.7-current (RAMDISK_CD) #723: Sat Mar 14 14:51:43 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel(R) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class)
1.60 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,EST,TM2,PERF
real mem = 1600516096 (1526MB)
avail mem = 1566670848 (1494MB)
mainbus0 at root
bios0 at mainbus0: date 03/14/06, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev.
2.33 @ 0xe0010 (59 entries)
bios0: vendor IBM version "74ET61WW (2.06 )" date 03/14/2006
bios0: IBM 2525FAG
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG BOOT
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (EXP0)
acpiprt2 at acpi0: bus -1 (EXP1)
acpiprt3 at acpi0: bus -1 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 4 (PCI1)
acpiprt6 at acpi0: bus -1 (DOCK)
bios0: ROM list: 0xc/0xe800! 0xce800/0x1600 0xd/0x1000
0xdc000/0x4000! 0xe/0x1
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
vga1 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03: apic 1 int 20
pci1 at ppb0 bus 2
bge0 at pci1 dev 0 function 0 "Broadcom BCM5751M" rev 0x11, BCM5750 B1
(0x4101): apic 1 int 16, address 00:16:d3:2f:63:7c
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
pci2 at ppb1 bus 4
cbb0 at pci2 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0x8d: apic 1 int 16
sdhc0 at pci2 dev 0 function 1 "Ricoh 5C822 SD/MMC" rev 0x13: apic 1 int 17
sdmmc0 at sdhc0
iwi0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2915ABG" rev 0x05:
apic 1 int 21, address 00:16:6f:c1:16:40
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 5 device 0 cacheline 0x0, lattimer 0xb0
pcmcia0 at cardslot0
"Intel 82801FB AC97" rev 0x03 at pci0 dev 30 function 2 not configured
"Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured
pcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03
pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 57231MB, 117210240 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
"Intel 82801FB SMBus" rev 0x03 at pci0 dev 31 function 3 not configured
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
u
tiny tetris patch
Hi all,
As tetris is one of my preferred game :-) ... just did wrapper around
setegid in same manner than xmalloc and such. If it can find any use ...
Thanks.
Index: scores.c
===
RCS file: /cvs/src/games/tetris/scores.c,v
retrieving revision 1.12
diff -u -p -r1.12 scores.c
--- scores.c16 Nov 2014 04:49:49 - 1.12
+++ scores.c15 Mar 2015 09:08:46 -
@@ -111,11 +111,11 @@ getscores(FILE **fpp)
human = "reading";
lck = LOCK_SH;
}
- setegid(egid);
+ xsetegid(egid);
mask = umask(S_IWOTH);
sd = open(_PATH_SCOREFILE, mint, 0666);
(void)umask(mask);
- setegid(gid);
+ xsetegid(gid);
if (sd < 0) {
if (fpp == NULL) {
nscores = 0;
@@ -123,10 +123,10 @@ getscores(FILE **fpp)
}
err(1, "cannot open %s for %s", _PATH_SCOREFILE, human);
}
- setegid(egid);
+ xsetegid(egid);
if ((sf = fdopen(sd, mstr)) == NULL)
err(1, "cannot fdopen %s for %s", _PATH_SCOREFILE, human);
- setegid(gid);
+ xsetegid(gid);
/*
* Grab a lock.
Index: tetris.c
===
RCS file: /cvs/src/games/tetris/tetris.c,v
retrieving revision 1.25
diff -u -p -r1.25 tetris.c
--- tetris.c16 Nov 2014 04:49:49 - 1.25
+++ tetris.c15 Mar 2015 09:08:46 -
@@ -161,7 +161,7 @@ main(int argc, char *argv[])
gid = getgid();
egid = getegid();
- setegid(gid);
+ xsetegid(gid);
classic = showpreview = 0;
while ((ch = getopt(argc, argv, "ck:l:ps")) != -1)
@@ -363,4 +363,11 @@ usage(void)
{
(void)fprintf(stderr, "usage: tetris [-cps] [-k keys] [-l level]\n");
exit(1);
+}
+
+void
+xsetegid(gid_t gid)
+{
+if (setegid(gid) == -1)
+err(1, "setegid() failed");
}
Index: tetris.h
===
RCS file: /cvs/src/games/tetris/tetris.h,v
retrieving revision 1.10
diff -u -p -r1.10 tetris.h
--- tetris.h10 Aug 2008 12:23:25 - 1.10
+++ tetris.h15 Mar 2015 09:08:46 -
@@ -176,3 +176,4 @@ extern int classic;
intfits_in(const struct shape *, int);
void place(const struct shape *, int, int);
void stop(char *);
+void xsetegid(gid_t);
Re: keyboard and mouse problems
On 03/11/15 16:11, Theo de Raadt wrote:
Two related problems regarding mice and keyboards came to my attention
during s2k15 in Brisbane and I worked with jcs@ on solutions.
The first problem is some newer machines (such as the thinkpad x1)
have keyboard repeat or stuttering during install -- this issue only
happes on the RAMDISK kernel. Eventually we figured out that this is
due to the large touchpad! Even a light brush against it would mess
up the pckbc driver subtly, causing 10 second pauses. This happens
because the RAMDISK media lacks the pms driver.
The solution is to forcibly reset the mouse port at attach. We
initially thought this change would only be needed for RAMDISK, but
it looks like this sequence was always missing in the past, and we
need it.
I also noticed the keyboard stutters on my Thinkpad Edge E130, but
didn't make the connection to the touchpad. Great detective work!
The stutters are gone after upgrading to the snapshot from 14-Mar-2015
and I don't notice any other issues with the keyboard.
Thank you!
Frederic
The second related issue is that boot -c on some machines has never
worked. The keyboard would be unresponsive. It turns out this is
also related to mouse ports which have not been reset.
These changes did not make the cut for 5.7, because there are a
plethora of keyboard contoller models, on PCs and non-PCs. We need
lots of testing before it goes in.
Index: dev/ic/pckbc.c
===
RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
retrieving revision 1.43
diff -u -r1.43 pckbc.c
--- dev/ic/pckbc.c 19 Dec 2014 07:23:57 - 1.43
+++ dev/ic/pckbc.c 11 Feb 2015 03:52:01 -
@@ -41,6 +41,7 @@
#include
#include
+#include
#include "pckbd.h"
@@ -277,6 +278,12 @@
if (t->t_slotdata[slot] == NULL)
return 0;
pckbc_init_slotdata(t->t_slotdata[slot]);
+ } else if (!found && slot == PCKBC_AUX_SLOT) {
+ u_char cmd[1] = { PMS_RESET };
+
+ (void) pckbc_poll_cmd(t, PCKBC_AUX_SLOT, cmd, sizeof cmd,
+ 0, NULL, 1);
+ pckbc_slot_enable(t, PCKBC_AUX_SLOT, 0);
}
return (found);
}
Index: pckbd.c
===
RCS file: /cvs/src/sys/dev/pckbc/pckbd.c,v
retrieving revision 1.38
diff -u -p -u -r1.38 pckbd.c
--- pckbd.c 24 Jul 2014 22:38:19 - 1.38
+++ pckbd.c 11 Feb 2015 04:57:35 -
@@ -79,6 +79,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1033,6 +1034,8 @@ pckbd_cnpollc(void *v, int on)
/* Just to be sure. */
cmd[0] = KBC_ENABLE;
pckbc_poll_cmd(t->t_kbctag, PCKBC_KBD_SLOT, cmd, 1, 0, NULL, 0);
+ cmd[0] = PMS_RESET;
+ pckbc_poll_cmd(t->t_kbctag, PCKBC_AUX_SLOT, cmd, 1, 0, NULL, 0);
}
}
Re: ksh version lies
On Sat, Mar 14, 2015 at 07:29:30PM +, Christian Weisgerber wrote: > > KSH_VERSION shouldn't be removed and if we want to tweak the value, > we need to leave the leading "@(#)PD KSH" alone, which is what > people will most likely match on. This is essentially the "Mozilla/5.0" > user agent issue... > Thank you for this information, a pull request against the ansible script is available here: https://github.com/ansible/ansible/pull/10466 -- Patrik Lundin
