On Thu, Feb 01, 2024 at 03:13:42PM +, RVP wrote:
> This looks like a bug in NetBSD. Minimal reproducer:
>
> ```
> $ cat tit
> tit|TermInfo Test,
> # if the second number is >32767, it disappears!
> use=num, use=max,
> # putting the bigger one first makes "promotion" happen.
> # u
On Thu, Apr 25, 2024 at 10:43:43PM -, Christos Zoulas wrote:
> Thank you. I think there should be one compat set list, not one
> for each machine_arch, and only have a ad or md machine specific
> file for the parts that are different. I.e. there should be a
> base32/mi and a base32/shl.mi conta
On Sat, May 04, 2024 at 12:12:35AM +0300, Andrius V wrote:
> corrupted as well). After some actions crash is not reproducible
> anymore though. I guess issue can be considered as some kind of fluke.
Did you run a forced fsck on the file system?
I usually boot single user and then do something lik
On Tue, May 14, 2024 at 05:39:21PM +, nia wrote:
> > Which reminds me: whatever happened to the new wifi project?
[..]
> So, still ongoing, just slowly
Yes, sorry about that - it will get a lot more attention now that 10.0,
9.4 and 8.3 are out of the door.
Martin
On Sat, Jun 01, 2024 at 06:41:19PM +0100, Chavdar Ivanov wrote:
> ptyfsoldnodes fix:
> [1] Bad system call ${HOST_SH} "${MAKEDEV_DIR}/MAKEDEV" -s
You need to run a new kernel before you install new userland.
In this case you hit the new version of dup3(2) which crashes on the
old kernel.
On Wed, Jul 10, 2024 at 01:07:53PM +0200, Markus Kilbinger wrote:
> Is anybody else seeing this?
Yes, me: https://gnats.netbsd.org/58412
Martin
On Fri, Aug 30, 2024 at 08:30:23AM -0500, John D. Baker wrote:
> Followed the instructions in "UPDATING" about cleaning the tools objdir
> for 'gdb' (MKCROSSGDB=yes), but builds still fail attempting to build
> the "info" documentation (example for mips64el, but seen building sparc
> as well:
MKCR
On Sat, Sep 07, 2024 at 10:04:37AM +0200, Benny Siegert wrote:
> On Sat, Sep 7, 2024 at 10:01?AM Thomas Klausner wrote:
> > I think we should follow along and increase the default to 1MB too.
> >
> > Comments?
>
> I think this is a great idea. I know that my employer runs Linux
> kernels with spe
Since all the check would do (as all uid/gid checks) is to say "group _gpio
has changed; please fix manually", it should be absolutely trivial to
implement.
Martin
No, it is not normal, see:
http://releng.netbsd.org/b5reports/i386/commits-2013.06.html#end
Which qemu version do you use?
Martin
On Thu, Jun 20, 2013 at 04:09:07PM +, David Holland wrote:
> I wonder if there's a problem with make and stopping parallel jobs on
> error.
Don't think so - it is just a combination of the deep parallelization and
the truncated tail of the log files published (resp. bracket not finding
the rel
On Sun, Jun 23, 2013 at 02:38:00PM +0100, David Laight wrote:
> All of the makes should be using the same job token queue, so should stop
> as soon as the 'failed' token is inserted.
> So you should only see one non-make fail for each possible parralel task.
> (Of course, it could be buggy!)
And a
On Sun, Jun 23, 2013 at 10:32:46PM +0200, Stefan Hertenberger wrote:
> Jun 23 20:15:22 nbbook /netbsd: kern_assert() at netbsd:kern_assert+0x48
> Jun 23 20:15:22 nbbook /netbsd: kmem_free() at netbsd:kmem_free+0x82
> Jun 23 20:15:22 nbbook /netbsd: athn_pci_suspend() at
> netbsd:athn_pci_suspend+0x
On Mon, Jul 01, 2013 at 10:09:38AM +0200, Manuel Bouyer wrote:
> hello,
> recent test runs have been failing on UDF filesystem tests with:
> mount failed: Invalid argument
The tests have been added new and never worked so far.
See kern/47974.
Martin
On Tue, Jul 02, 2013 at 06:29:29PM +0300, Andreas Gustafsson wrote:
> FWIW, I already sent private mail to reinoud on Saturday asking him to
> do that, but I have not received a response.
There is a PR and most of the failures are expected to be solved RSN (or
maybe he already commited his fix, ha
On Fri, Aug 09, 2013 at 03:31:54PM -0700, Paul Goyette wrote:
> Yeah, sorry. I was having a senior moment, thinking back to the days
> before the vax, with the funky PDP11-endianness. :)
It is just the compiler being different. Sometimes it finds things newer
gcc doesn't, sometimes it has more
On Sat, Aug 24, 2013 at 06:43:19AM -0700, Paul Goyette wrote:
> /build/netbsd-local/dest/sparc/usr/lib/libc.a(gethnamaddr.o): In function
> `_gethostbyname':
> gethnamaddr.c:(.text+0x28c4): multiple definition of `_gethostbyname'
> libhack.o:(.text+0x2e4): first defined here
My libhack.o does not
On Sat, Aug 24, 2013 at 01:53:57PM -0700, Paul Goyette wrote:
> # find obj/sparc -name libhack.o | xargs stat -f "%SN%t%z"
> obj/sparc/distrib/miniroot/libhack.o 24575
> obj/sparc/distrib/sparc/ramdisk/libhack.o 27890
# Use stubs to eliminate some large stuff from libc
HACKSRC=${DISTR
On Sun, Aug 25, 2013 at 03:31:42PM +0200, Maxime Villard wrote:
> Ok/Comments?
Looks fine.
Martin
On Tue, Aug 27, 2013 at 08:28:04AM +0900, tsugutomo.en...@jp.sony.com wrote:
> Maxime Villard writes:
> - How often is_dyn is true?
Good point - I can't find any use for it. The code seems to agree:
/*
* XXX allow for executing shared objects. It seems silly
* but other
On Tue, Aug 27, 2013 at 07:59:44AM +, Christos Zoulas wrote:
> >Are there any ET_DYN that are not shared libs? Maybe we should remove
> >the is_dyn exec support completely.
>
> Why, have you tried running libc.so on linux? :-)
Yes, but I do not consider that a usefull feature unless someone c
On Tue, Aug 27, 2013 at 04:37:30AM -0400, Christos Zoulas wrote:
> Useful or not, it currently works :-)
Yes, and if we need it for compat: fine. Out of curiosity: why does linux
produce some binaries with ET_DYN and other with ET_EXEC? We only seem
to do ET_EXEC for native binaries.
Anyway: I wo
On Tue, Aug 27, 2013 at 10:56:04AM +0200, Maxime Villard wrote:
> ET_DYN can be either a shared library or a position-independent executable
> (PIE). There's no way to distinguish between them, except that a PIE must
> have a PT_INTERP segment.
Ok, I'm on an arch w/o sane PLT format for ASLR, so n
On Sat, Sep 28, 2013 at 03:08:33PM +0200, Riccardo Mottola wrote:
> >20130605:
> > Previous freetype installations eroneously installed private
> > header files. If you are building against a non-empty $DESTDIR,
> > please remove ${DESTDIR}//usr/X11R7/include/freetype2/freet
On Mon, Sep 30, 2013 at 07:50:50AM +0200, Riccardo Mottola wrote:
> To be extra-sure, I removed the externa/mit and the x11 in my src tree
> and -rechecked it out.
Did you realy "cvs co" or just remove them and "cvs up"?
If you use "cvs up", please try something like:
cd /usr/src; cvs up -dP
On Mon, Sep 30, 2013 at 11:35:14AM +0200, Riccardo Mottola wrote:
> I actually did a rm -rf && cvs -q update -dPA
Hmm, then there should be no old files (at least in the parts you rm'd)
> I have never heard/used the -I \! option, but I will try this evening
> and let you know! Thanks.
You can d
On Wed, Oct 02, 2013 at 02:45:43AM +, Thomas Mueller wrote:
> Running "mount" by itself shows
>
> tmpfs on /dev type tmpfs (union, local)
You have two choices: add your dk additions to /etc/MAKEDEV.local or fix
the /dev/console device in the lower layer of your union mount.
Martin
On Wed, Oct 02, 2013 at 10:31:25AM +0200, Riccardo Mottola wrote:
> I noticed that build.sh with X takes quite a long time (long parts are
> surely the compiler and the X distirbution) and if I restart it, it will
> essentially restart. Is there no way to restart? or to build in pieces?
Try the
On Thu, Oct 03, 2013 at 01:10:13PM +0200, Riccardo Mottola wrote:
> Hi,
>
> after updating to current, I can't compile gnustep anymore!
Gnustep was updated?
(Just guessing, I can't find objc/runtime.h in any NetBSD version I have
installed)
Martin
On Mon, Oct 07, 2013 at 05:15:46PM -0700, Paul Goyette wrote:
> When booting either my custom/minimalistic kernel or a GENERIC kernel,
> it gets as far as printing the sizes of the various sections, and then
> gives the message
>
> head full (0x6cd08+16384)
Did the size of modules change
On Tue, Oct 08, 2013 at 05:00:27AM -0700, Paul Goyette wrote:
> So, the newer ffs module is actually _smaller_ than the old one?
A tiny bit, but there goes this straw.
Martin
On Tue, Oct 08, 2013 at 04:21:16PM -0400, Dennis Ferguson wrote:
> While looking for something to compile a tree with some m68k bits
> added I found that a successful build of evbcf needs the changes
> below. The problems seem related to the binutils changes.
Can you please provide a bit more det
On Wed, Oct 09, 2013 at 10:04:13AM -0400, Dennis Ferguson wrote:
> I did notice that removal of -fomit-frame-pointer for those architectures
> was a recent change, however, and the build errors for evbcf looked like
> this:
>
> # compile ld.elf_so/mdreloc.o
> /build/evbcf/obj/tooldir.NetBSD-6.9
On Thu, Oct 10, 2013 at 11:49:08AM +0200, Joerg Sonnenberger wrote:
> By fixing the ld default.
Is this (untested) enough? Do we need add_DT_NEEDED_for_regular to be 0 too?
Martin
Index: ldlang.h
===
RCS file: /cvsroot/src/external/
On Thu, Oct 10, 2013 at 06:40:51PM +0400, Valery Ushakov wrote:
> > >> /build/test/tools/x86_64/amd64/bin/x86_64--netbsd-gcc\
> > >> --sysroot=/build/test/dest/amd64 -o npfctl \
>
> Go to the objdir and run that command (without -lcrypt) with
> -Wl,--verbose - you should see something li
On Thu, Oct 10, 2013 at 04:43:12PM +0200, Martin Husemann wrote:
> Wasn't there a bug to this effect in the toolchain with --sysroot= that
> was later fixed in -current?
PR 47922.
Martin
On Thu, Oct 10, 2013 at 06:39:27PM +0200, Rhialto wrote:
> On Thu 10 Oct 2013 at 12:19:50 +0200, Martin Husemann wrote:
> > - unsigned int add_DT_NEEDED_for_dynamic : 1;
> > + unsigned int add_DT_NEEDED_for_dynamic : 0;
>
> From the limited context it seems that that is a s
On Thu, Oct 10, 2013 at 06:42:54PM +0200, Martin Husemann wrote:
> You are right, but I can't find the initialization ;-)
It is a bit hidden, but I think the patch below should do it - modulo
the open question what defaults exactly we want changed.
Joerg, do you mean t
On Fri, Oct 11, 2013 at 10:14:55AM +0200, Martin Husemann wrote:
> Do we have some simple test case for the whole issue?
Here is a simple test case, based on the curses abuse Roy complained about:
--8<--
#include
#include
int main(int argc, char **argv)
{
int e
On Fri, Oct 11, 2013 at 10:50:06AM +0200, Martin Husemann wrote:
> On Fri, Oct 11, 2013 at 10:14:55AM +0200, Martin Husemann wrote:
> > Do we have some simple test case for the whole issue?
>
> Here is a simple test case, based on the curses abuse Roy complained about:
And wi
On Fri, Oct 11, 2013 at 10:02:11PM +0100, David Laight wrote:
> What does that change do?
>
> If you link a program with -lcurses you don't want a DT_NEEDED entry
> for libtemcap.so whether or not the program directly references
> anything in libtermcap.so.
You tell it to link against libcurses.s
On Sat, Oct 12, 2013 at 11:59:46AM +0200, Martin Husemann wrote:
> However, I have been unable to make ld not emit a DT_NEEDED for
> libterminfo, no matter what options I tried, so the test program ends
> up with:
>
> Dynamic Section:
> NEEDED libcurs
On Sun, Oct 13, 2013 at 01:30:35AM +0400, Valery Ushakov wrote:
> This (quoted earlier) looks highly suspicious:
>
> /usr/lib/libpthread.so.1: could not read symbols: Invalid operation
ld(1) does that in netbsd-current whenever the no-copy-dt-needed thing hits
and it ends up with an unresolved
You could uncomment the following lines in the src/libexec/ld.elf_so/Makefile
#CPPFLAGS+= -DDEBUG
#CPPFLAGS+= -DRTLD_DEBUG
(re-)build and install ld.elf_so, and set LD_DEBUG=1 when starting the program.
But better keep a copy of old ld.elf_so around and a root shell open
so you can resto
On Wed, Nov 27, 2013 at 06:11:39AM -0800, Paul Goyette wrote:
> vax--netbsdelf-mdsetimage: fs image (2097152 bytes) too big for buffer
> (2048000 bytes)
This has been broken for quite some time (but we had no buildable tree).
I'm working on tracking it down.
Martin
Since -current had some "hard times" in the last few weeks, and maybe
not everyone is aware of this site:
http://releng.netbsd.org/cgi-bin/builds.cgi
shows the status of the last autobuilds. We already had one working
-current (HEAD) build this week, yay!
As you can see there, the stable branc
This same step also crashes on vax and evbarm (with eabi) - seems like the
stack gets mangled or something.
Martin
On Sun, Jan 26, 2014 at 09:30:14PM +0100, Martin Husemann wrote:
> This same step also crashes on vax and evbarm (with eabi) - seems like the
> stack gets mangled or something.
And on arm it works when ntpd is compiled with -O1.
Martin
On Thu, Jun 11, 2015 at 11:39:33AM +0200, Kurt Schreiner wrote:
> _and_ my setting of MKCOMPAT to "no" in /etc/mk.conf
>
> If MKCOMPAT=yes, build.sh ... distribution completes w/o hickups.
Should be fixed now.
Martin
On Sun, Jun 21, 2015 at 01:32:41PM +0200, carsten.ku...@arcor.de wrote:
> Hi,
>
> amd64 port is missing in latest snapshots on
> ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/
> Is this due to a bug in the snaphost build?
It failed to build - you can see the logs and error messages here:
On Thu, Jun 25, 2015 at 02:15:44PM -0400, Christos Zoulas wrote:
> On Jun 25, 12:06pm, br...@nmsu.edu (Brook Milligan) wrote:
> -- Subject: Re: dynamically created /dev/null is a regular file
>
> | On Jun 25, 2015, at 11:15 AM, Christos Zoulas wrote:
> | > Why isn't MAKEDEV invoked with -f?
> |
>
On Thu, Jul 02, 2015 at 09:06:21AM +0200, Manuel Bouyer wrote:
> is this already fixed ?
Yes.
Martin
On Thu, Jul 02, 2015 at 04:03:19AM +0900, Ryo ONODERA wrote:
> Hi,
>
> I have gotten the following error.
> I did something wrong?
Can you try removing $OBJDIR/compat/arm/oabi and then retry the build.sh?
Martin
On Sun, Jul 05, 2015 at 09:04:47PM -0600, Brook Milligan wrote:
> Does this mean that something is writing to the DOMU /dev/null after
> the tmpfs is unmounted? What could that be?
Yes - and good question (but now probably easier to spot).
However (and this maybe a stupid question): why are you
On Mon, Jul 06, 2015 at 06:32:59AM -0600, Brook Milligan wrote:
> I was hoping to run a read-only root. In that case, isn't tmpfs /dev
> the right solution?
I don't think it is needed, but of course it also should work.
But this is the easy way to track it down: remove the bogus /dev/null,
turn
On Fri, Jul 17, 2015 at 12:55:39AM +0200, Michael van Elst wrote:
> Maybe this emulation can be turned off in the BIOS. Otherwise,
> it's probably necessary to just remove the pckbd driver from
> the kernel config.
On all machines I had trouble like this turning the (often quite hidden)
option in
On Mon, Jul 20, 2015 at 09:57:26AM +0100, Patrick Welche wrote:
> # mount /home
> mount_ffs: /dev/raid2a on /home: incorrect super block
No kernel error message here? Is it FFSv1 or FFSv2?
I'd expect something like:
http://www.netbsd.org/docs/ffsv1badsuperblock.html
or the "not off by o
On Mon, Jul 20, 2015 at 08:12:44AM -0400, Greg Troxel wrote:
> Arguably enough should be pulled up so that fsck in netbsd-7 will catch
> if not fix everything that current kernel objects to, so that fsck
> before update is sound.
Nothing of this is in -7 yet - and fsck has not been updated in -cur
On Mon, Jul 20, 2015 at 08:36:27AM -0400, Greg Troxel wrote:
> I would argue that it's a serious bug in current to have the kernel
> reject filesystems that fsck is ok with, especially since they seem to
> be somewhat common and otherwise work ok.
Yes, totally agreed. I mailed Patrick a debug patc
On Mon, Jul 20, 2015 at 12:20:32PM -0400, MLH wrote:
> This is the same problem I discussed back on Apr 27. The answer
> then was there was no problem an I had to reformat the drive(s).
> Problem is that all of my external drives have this same problem
> so I can't mount them without losing possibl
On Mon, Aug 17, 2015 at 09:23:58PM -0500, John D. Baker wrote:
> This works quite well. In fact,
>
> !sleep 1
>
> is sufficient to let 'named' successfully bind to the IP address of the
> "bge1" interface.
Sounds like a named bug to me then.
Martin
On Tue, Aug 25, 2015 at 07:45:15AM +0800, Paul Goyette wrote:
> Upgrading from a recent 7.99.20 to yesterday's 7.99.21 (on amd64)
>
> # /bin/sh /build/netbsd-local/src/usr.sbin/postinstall/postinstall \
> -s /build/netbsd-local/src -d // fix rc
> rc fix:
> cp: /build/netbsd-local/src/etc/rc.
On Mon, Sep 14, 2015 at 10:23:29PM +, John Klos wrote:
> Kernel and userland compiled from today's current sources from about six
> hours ago on an evbmips-eb system:
Just to make sure: evbmips-eb or evbmips64-eb ?
(i.e.: native or compat_netbsd32 issue?)
Martin
On Tue, Sep 15, 2015 at 03:45:13PM +, John Klos wrote:
> Oh - sorry - evbmips64-eb. But on a much more common Raspberry Pi 2
> running -current, things work :P
The ioctl translation for IPF is missing in netbsd32.
Easiest work around: use NPF ;-)
Martin
On Mon, Sep 21, 2015 at 12:47:49AM -0400, Thor Lancelot Simon wrote:
> And failing that, you can grep around until you find the superblock.
We even have scan_ffs(8) for that.
Martin
On Sun, Oct 25, 2015 at 06:05:23PM +0100, Jørn de Jong wrote:
> Since i?m new to NetBSD, i?m not really sure how to continue from this point
> on out.
> I?m not able to try other boot settings, as my USB keyboard doesn?t work in
> the bootmanager.
Can you access the root file system on the USB s
On Sun, Nov 01, 2015 at 03:27:01PM +, Michael van Elst wrote:
> w...@netbsd.org (Thomas Klausner) writes:
>
> >/usr/pkg/go/pkg/tool/netbsd_amd64/vet: Unknown elf note type 4 (unknown
> >tag): [namesz=4, descsz=40 name=Go ]
>
> >Ideas how to fix this?
Change the message to only happen #ifde
On Sat, Nov 21, 2015 at 12:16:33PM +0800, Paul Goyette wrote:
> While trying to test some recent changes to filemon(4), I discovered
> that not only does a default system installation not create a
> /dev/filemon but the supplied /dev/MAKEDEV script doesn't even know
> how to create it!
>
> It shou
On Wed, Dec 23, 2015 at 03:30:54PM +1100, Geoff Wing wrote:
> Hi,
> for a long time, the parser reading /etc/exports would treat the following
> example from exports(5):
>
> /u -maproot=bin: -network 131.104.48 -mask 255.255.255.0
>
> as 131.104.48/24
>
> Currently it's being treated as 13
On Thu, Dec 31, 2015 at 07:32:52PM +0800, Paul Goyette wrote:
> Now, when I press Control/T I frequently see something like one of the
> following, with a hex number instead of a wchan.
>
> load: 3.16 cmd: guile 23408 [0x7f7ff4c3cd4a/3] 0.56u 2.17s 10% 47440k
This cmd is active, on cpu 3, with
See PR kern/50601 - and yes, Michael's changes fix this issue, but trigger
another we are still investigating.
The patch from the PR works fine for me as a temporary workaround.
Martin
On Fri, Jan 15, 2016 at 11:56:11PM +0100, Riccardo Mottola wrote:
> Apart the inconvenience that my favourite operating system fails to
> install straight away, when I go back to the install menu and I try to
> execute /bin/sh, I get a segmentation fault and get back to the
> beginning I tried s
On Wed, Jan 27, 2016 at 09:08:51AM +0100, Manuel Bouyer wrote:
> fs/psshfs/t_psshfs (493/641): 3 test cases
> inode_nos: atf-run: ERROR: tools::fs::file_info: Cannot get information
> of /
> tmp/atf-run.mCXF4l/mnt; lstat(2) failed: Device not configured
> [2.017885s] Passed.
> atf-report: ERRO
On Wed, Jan 27, 2016 at 09:51:47AM +0100, Manuel Bouyer wrote:
> it also pass when atf-run is started from /usr/tests/fs
> Trying again to run from /usr/tests/ ...
Is /tmp on a tmpfs?
Martin
On Tue, Feb 02, 2016 at 12:48:07PM +0200, Andreas Gustafsson wrote:
> Presumably this is because of src/share/mk/bsd.kmodule.mk 1.56,
> "If we are building CTF, keep debugging symbols."
We need to send a HEADS UP to current users about this, especially on
evbarm it may be a bad suprise.
What are
In case anyone wondered how much space the recently on x86 + earm
enabled by default MKCTF + MKDTRACE needs:
I took an arbitrary example arm arch (evbearmv7hf-eb), and did a clean
build (no release, no sets, just the build including X) to get an idea
of $DESTDIR size differences (and, for fun, $OB
On Fri, Feb 05, 2016 at 05:25:43PM +0700, Robert Elz wrote:
> If it is limited like that, why does it get installed in /usr/sbin ?
> Why not only have it on install media, and not actually installed itself?
Parts of it are very usefull on an installed system already, but the main
issue is that we
On Fri, Feb 12, 2016 at 09:21:22AM +0100, Manuel Bouyer wrote:
> It's strange, I'm running HEAD on a olimex lime2 (which has A20+axp20x too)
> and never seen this. I also occasionally run on a cubieboard, but
> it's usually not powered on for more than a few hours.
I run a cubietruck with -current
On Sun, Feb 14, 2016 at 01:22:32AM -0500, Michael wrote:
> I have seen it with -current from a month ago, and only after the
> machine's been up for ca. 2 weeks. It's been updated 10 days ago and no
> errors since.
Ah, that would explain why I haven't - I update that board once a week
to run ATF t
On Tue, Mar 01, 2016 at 05:42:51PM -0600, John D. Baker wrote:
> I have so-far observed this only on i386 and not any of the other
> architectures I build.
This is probably caused by ld.elf_so bugs. There is a pullup request
pending to (hopefully) fix this.
A simple test (and easy workaround) is
On Thu, Mar 10, 2016 at 03:05:36PM +0900, Ryota Ozaki wrote:
> We're seeing many test failures (> 1000) on
> amd64 and i386, and installation failures on
> sparc.
We should back out the gcc change that causes the x86 failures.
Sparc bootblocks are broken, everything else works fine - I am looking
Beware when updating -current - the ssh version now on HEAD once again
deliberately breaks connectivity to some machines, especially some Sun
ALOM console processors.
The cryptic message they throw is:
ssh_dispatch_run_fatal: Connection to 192.168.150.113 port 22: DH GEX group out
of range
whic
On Fri, Mar 11, 2016 at 10:08:59PM +0100, Martin Husemann wrote:
> The other current issue is that both sshd and ssh are completely
> non-operational on sparc64, we will need to test other architectures too.
A clean rebuild fixed that issue.
Martin
On Sun, Mar 13, 2016 at 09:19:14PM +0100, Ian D. Leroux wrote:
> maintains the current behaviour. Those who run /dev-on-tmpfs can
> instead set it to something like "/var/shm /tmp", or set it to the
> empty string, to avoid the untimely disappearence of /dev.
This is all good for "planned" instan
On Sun, Mar 13, 2016 at 10:40:04PM +0100, Ian D. Leroux wrote:
> If /dev/console can just go missing however (does that happen?)
No, it *should* never happen unintendedly (besides catastrophic file
system corruption, mount failures for other similar reasons, ...).
The init reaction is an emergenc
On Fri, Mar 18, 2016 at 09:04:32PM +, Dave Tyson wrote:
> I am of the same opinion as the PR originator that it is easier to control
> access permissions with a uscanner device rather than having to open up a
> whole raft of ugen devices, but I guess the sane developers feel that using
> lib
On Sat, Mar 19, 2016 at 08:45:59AM +, Michael van Elst wrote:
> That's a can of worms. You don't even know what a particular ugen*
> device is until you opened and queried it.
Here is my original suggestion:
http://mail-index.netbsd.org/tech-userlevel/2015/10/25/msg009389.html
Martin
On Sat, Mar 19, 2016 at 10:49:51AM +0100, Ian D. Leroux wrote:
> If we want to avoid magic values completely, we can split the
> configuration into two settings:
> swapoff_umount (auto, manual, no)
> swapoff_umount_list (only used if $swapoff_umount=manual)
> Perhaps that would be better (more
On Sat, Mar 19, 2016 at 03:12:08PM +0100, Michael van Elst wrote:
> Changing ownerships of the filesystem entries isn't sufficient.
> After all some ugen* can be changed quickly.
I expected devpubd to deal with that for us - not sure what you mean
here.
> I'd prefer either some separate ACLs spec
On Sat, Mar 19, 2016 at 07:17:50PM +0200, Andreas Gustafsson wrote:
> I think we should disable uscanner in GENERIC now. I have been doing
> that on my own systems for years, as uscanner has never worked for me.
> The permissions issues can be fixed later.
I agree.
Martin
On Sat, Mar 19, 2016 at 09:37:03PM +0100, Ian D. Leroux wrote:
> an ed script to munge the output of mount(1) with regexps. Surely there
> has to be a better, less brittle way of getting the required
> information. Can anyone give me a hint as to what it might be?
Maybe add a -p option so you onl
On Sun, Mar 27, 2016 at 08:42:22PM +, co...@sdf.org wrote:
> Has anyone successfully used this driver, with Xorg?
Yes, it works fine on my GTX 460.
Martin
On Mon, Mar 28, 2016 at 01:42:23AM +0200, Johnny Billquist wrote:
> The error is:
> Configuring CCD devices.
> ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Invalid argument
> /etc/rc.d/ccd exited with code 1
>
> Did we do some incompatible change recently? Not too happy with this one.
Nothing obviou
On Tue, Apr 05, 2016 at 07:14:48PM +0800, Paul Goyette wrote:
> panic: init died (signal 0, exit 11)
It does not do that for me, but:
swapctl: setting dump device to /dev/sd0b
/etc/rc: WARNING: No swap space configured!
and swapctl -l says:
Device 1K-blocks UsedAvail Capacity Prio
On Tue, Apr 05, 2016 at 12:25:23PM -0700, bch wrote:
> With very latest src:
With the compiler change it is important to not do an update build and
clean all of obj (and maybe even $DESTDIR) before building with the
new compiler.
Not sure if that is what happened to your system, but I managed to
On Sat, Apr 09, 2016 at 08:20:27AM +0200, Thomas Klausner wrote:
> rt_msg1: type=0x7 len=152
Debug output leftovers, Christos already removed the printf.
Martin
On Sun, Apr 10, 2016 at 04:42:45PM +, Christos Zoulas wrote:
> security.pax.aslr.global: Enable/disable ASLR default (you can
> override this on individual binaries
> via ELF notes)
Hint: see paxctl(8).
Other architectures will f
On Mon, Apr 11, 2016 at 09:34:15AM +0300, Andreas Gustafsson wrote:
> Christos Zoulas wrote:
> > Please repoort any issues!
>
> The install media are failing to boot on the testbed:
Should be fixed!
Martin
On Mon, Apr 11, 2016 at 10:23:11AM -0400, Christos Zoulas wrote:
> I still don't understand why the else part is needed.
I assumed it had never been tested on anything but amd64 (and your commit
log and the comments only talked about defaulting amd64 to on).
But indeed, w/o aslr turned on for eve
On Tue, Apr 12, 2016 at 07:59:49PM -0700, Matt Thomas wrote:
> The install media don't include ld.elf_so so that's probably the problem
> there.
> We would need crt0 support for static pie to do the rel/rela relocations
> intrinsic to those images.
Indeed. Bringing over "-static -pie" support
1 - 100 of 740 matches
Mail list logo
