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
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...
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
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
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
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
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
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
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 --
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
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
15 марта 2015 г. 21:26 пользователь Robert Peichaer rob...@peichaer.org
написал:
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
On March 15, 2015 8:18:59 PM GMT+01:00, Vadim Zhukov persg...@gmail.com wrote:
15 марта 2015 г. 21:26 пользователь Robert Peichaer
rob...@peichaer.org
написал:
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
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
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.
On Sun, Mar 15, 2015 at 1:21 PM, Theo de Raadt dera...@cvs.openbsd.org
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
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
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
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
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
On Sun, Mar 15, 2015 at 1:21 PM, Theo de Raadt dera...@cvs.openbsd.org
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
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
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
On 3/15/15, Michael W. Lucas mwlu...@michaelwlucas.com 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
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
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
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
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
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
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
On 3/15/15, Michael W. Lucas mwlu...@michaelwlucas.com 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
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
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.
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
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
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,
On 15 March 2015 at 23:38, Theo de Raadt dera...@cvs.openbsd.org 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
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
On Sun, Mar 15, 2015 at 5:45 PM, Theo de Raadt dera...@cvs.openbsd.org 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
40 matches
Mail list logo
