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
> 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
Alternative
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 c
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
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
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
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 1
> 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
> 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 no
> 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 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
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 th
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 rec
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-operatio
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
i
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.or
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
> 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
> 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
>
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 an
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
de
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 defa
> 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.
> 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 i
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
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
> 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
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 an
> 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
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 se
> 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
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 an
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 install
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/distr
> 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. Thi
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
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 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 -- thi
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 iss
40 matches
Mail list logo