On Thu, 3 Dec 2020 11:45+0100, Mateusz Guzik wrote:
> This should be fixed by r368271
Thank you, guys. I'll upgrade my laptop when I get home.
--
Trond.
___
freebsd-current@freebsd.org mailing list
Fam,
After close(2) got fixed in r368006 last week, my laptop at home has
been acting up.
It currently runs:
FreeBSD E590T.ufp 13.0-CURRENT FreeBSD 13.0-CURRENT #870 r368192: Mon Nov 30
20:29:15 CET 2020 r...@e590t.ufp:/usr/obj/usr/src/amd64.amd64/sys/E590T
amd64 1300130 1300130
It would seem
options dtrace
options dtraceall
are incompatible with
options zfs
This is on base/head, r365358, amd64.
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x7fff8
fault code = supervisor write data, page not present
On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> OK, I figured it out.
>
> I used to have MK_CTF=no in src.conf, but I recently changed it to
> WITH_CTF=no.
It's either WITH_xxx=yes or WITHOUT_xxx=yes.
> /sys/conf/kern.post.mk checks whether MK_CTF is no and apparently
> does not invoke
On Tue, 10 Mar 2020 06:37-0600, The Doctor wrote:
> On Mon, Mar 09, 2020 at 09:12:49PM -0400, AN wrote:
> >
> > After an update today to world, kernel, and ports my mouse no longer works.
> > Mouse works on console. I use startx, mouse seems to break after startx is
> > issued.
> >
> > Is any
On Tue, 3 Mar 2020 15:31+0300, Yuri Pankov wrote:
> On 03.03.2020 15:27, Trond Endrestøl wrote:
> > On Tue, 3 Mar 2020 12:56+0300, Yuri Pankov wrote:
> >
> > > On 03.03.2020 12:44, Trond Endrestøl wrote:
> > > > On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wro
On Tue, 3 Mar 2020 12:56+0300, Yuri Pankov wrote:
> On 03.03.2020 12:44, Trond Endrestøl wrote:
> > On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wrote:
> >
> > > On 03.03.2020 11:49, Yuri Pankov wrote:
> > > > With recent pkg fallout, I'm trying
On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wrote:
> On 03.03.2020 11:49, Yuri Pankov wrote:
> > With recent pkg fallout, I'm trying to build rust myself first time ever (as
> > far as I can remember), and it's failing running out of swap on the
> > following step:
> >
> > Building stage0 std
On Tue, 3 Mar 2020 11:49+0300, Yuri Pankov wrote:
> With recent pkg fallout, I'm trying to build rust myself first time ever (as
> far as I can remember), and it's failing running out of swap on the following
> step:
>
> Building stage0 std artifacts (x86_64-unknown-freebsd ->
>
On Tue, 18 Feb 2020 11:03+0100, Jochen Neumeister wrote:
> Anyone got a tip to solve this problem?
> Otherwise I would unfortunately have to reinstall the server. My Poudriere Box
> runs on this server
>
> Am 17.02.20 um 18:14 schrieb Kyle Evans:
> > On Mon, Feb 17, 2020 at 11:13 AM Jochen
On Mon, 16 Dec 2019 10:27+0200, Toomas Soome wrote:
> Also make sure you do have updated firmware.
1.22 is the latest one.
> r355347 by itself does not really look like it should cause infinite loop on
> normal input, but there we would need to check what we do get from keypress
> and then we
On Sun, 15 Dec 2019 20:41+0100, Trond Endrestøl wrote:
> I updated the loader.efi stored in the ESP of my laptop, Lenovo
> ThinkPad E590T (20NB), running boot firmware 1.22, as I wanted to try
> out base/head r355441.
>
> As soon as I press a button, say 2 or 3, the loader freez
I updated the loeader.efi stored in the ESP of my laptop, Lenovo
ThinkPad E590T (20NB), running boot firmware 1.22, as I wanted to try
out base/head r355441.
As soon as I press a button, say 2 or 3, the loader freezes.
Ctrl+Alt+Delete is being recognized.
I have tried loader.efi from the
On Sat, 7 Dec 2019 20:05-, Graham Perrin wrote:
> --- lib/libprocstat__L ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named 'next'
> in 'struct vm_map_entry'
> for (entryp = map->header.next;
> ~~~ ^
>
On Sat, 7 Dec 2019 20:25+0100, Trond Endrestøl wrote:
> On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
>
> > This member removal has other consequences. As follows ..
> >
> > --- lib/libprocstat__L ---
> > Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat
On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
> This member removal has other consequences. As follows ..
>
> --- lib/libprocstat__L ---
> Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
> --- libprocstat.o ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no
On Mon, 16 Sep 2019 20:09+0900, Masachika ISHIZUKA wrote:
> My machine (with core i5-7500) is hangup when loading i915kms.ko
> on r352239 and r352386 (1300047).
> This machine was working good with r351728 (1300044).
>
> /etc/rc.conf has the following line.
> kld_list="i915kms.ko"
Pardon
On Mon, 5 Aug 2019 22:32+0200, Trond Endrestøl wrote:
> On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote:
>
> > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> >
> > > I'm going home and see if VBox 6.0.10 exhibits the same beha
On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote:
> On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
>
> > I'm going home and see if VBox 6.0.10 exhibits the same behaviour.
>
> Try r350608. There was a mis-merge in the committed patch (more serious
On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > Hi,
> >
> > Has anyone else noticed the kernel being unable to spawn init lately?
> >
> > All I get is:
> >
> > init die
Hi,
Has anyone else noticed the kernel being unable to spawn init lately?
All I get is:
init died (signal 6, exit 0)
panic: Going nowhere without my init!
/sbin/init hasn't had any changes in 4 months, and is present in /sbin
in the new BE.
I've tried and failed in VBox at home this weekend,
On Sun, 21 Jul 2019 15:07-0400, AN wrote:
> I don't understand why the /tmp is being mounted. It is causing problems
> because when I try to run portupgrade it fails for lack of space. If I
> forcibly unmount it everything breaks.
tmpmfs is set to "AUTO" in /etc/defaults/rc.conf.
Try setting
On Sun, 16 Jun 2019 17:49+0200, Rainer Hurling wrote:
> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
> II X6 1090T).
>
> Am I the only one, who observes this breakage? Thanks for any hint.
No. This also happens on Intel Core i7 960.
I will retry buildworld using -D
On Thu, 9 May 2019 17:23-0500, Larry Rosenman wrote:
> On 05/09/2019 5:19 pm, Trond Endrestøl wrote:
> > Host is Windows 7 x64 SP1.
> > CPU is Core i7 960.
> > Hypervisor is VirtualBox 6.0.6.
> > VM is using UEFI.
> > Kernel config is
> > https://ximalas.in
Host is Windows 7 x64 SP1.
CPU is Core i7 960.
Hypervisor is VirtualBox 6.0.6.
VM is using UEFI.
Kernel config is
https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head
Crash happens early during boot, right after launching the APs.
fault virtual address = 0x0
[...]
KDB
On Tue, 9 Apr 2019 10:06+0200, Trond Endrestøl wrote:
> On Mon, 8 Apr 2019 19:58+0200, O. Hartmann wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hello,
> >
> > after a bunch of updates this weekend, mounting ZFS filesystem
On Mon, 8 Apr 2019 19:58+0200, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> after a bunch of updates this weekend, mounting ZFS filesystems on CURRENT
> r346025 doesn't
> work anymore at boot time when ZFS is built-in-kernel. zfs_enable="YES" is
> set
On Tue, 19 Mar 2019 16:02+0300, Slawa Olhovchenkov wrote:
> On Mon, Mar 18, 2019 at 11:00:10PM +0200, Andriy Gapon wrote:
>
> > On 18/03/2019 20:01, Andrey Fesenko wrote:
> > > Not this? ZFS use wired and not clean only reboot?
> > > https://reviews.freebsd.org/D7538?id=25108
> >
> > Wired
On Tue, 12 Mar 2019 13:27+0200, Andriy Gapon wrote:
> On 12/03/2019 11:37, Trond Endrestøl wrote:
> > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > # mounted filesystems when viewed by df(1).
>
> df reports filesystems in the order they were moun
On Tue, 12 Mar 2019 12:14+0100, Trond Endrestøl wrote:
> On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
>
> > > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > > wrote:
> > > I concocted a shell script, it looks promising:
> > >
> >
On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
> > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > wrote:
> > I concocted a shell script, it looks promising:
> >
> > #!/bin/sh
> > #-
> > # Parallel mounting of ZFS filesystems leaves a ch
On Tue, 12 Mar 2019 08:54+0200, Andriy Gapon wrote:
> On 12/03/2019 02:12, Rodney W. Grimes wrote:
> >> On 11/03/2019 23:03, Freddie Cash wrote:
> >>> Wouldn't it make more sense to teach df, du, "zfs list", and other things
> >>> that list the mounted filesystems to use sorted output?
> >>
> >>
On Mon, 11 Mar 2019 14:03-0700, Freddie Cash wrote:
> On Mon, Mar 11, 2019 at 1:59 PM Trond Endrestøl <
> trond.endres...@fagskolen.gjovik.no> wrote:
>
> > On Mon, 11 Mar 2019 13:47-0700, Matthew Ahrens wrote:
> >
> > > On Mon, Mar 11, 2019 at 11:33 AM
On Mon, 11 Mar 2019 13:47-0700, Matthew Ahrens wrote:
> On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl <
> trond.endres...@fagskolen.gjovik.no> wrote:
>
> > Has anyone else noticed ZFS datasets are no longer mounted in
> > alphanumerical order in CURRENT? It looks
Has anyone else noticed ZFS datasets are no longer mounted in
alphanumerical order in CURRENT? It looks more like they are mounted
in the order in which they are encountered.
Are there any chance of reverting to the old behaviour?
Here's an example:
Filesystem SizeUsed
On Sun, 20 Jan 2019 13:09-0500, David Boyd wrote:
> 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled.
>
> Running in VirtualBox 6.0.2.
>
> The identical configuration running 12.0-RELEASE-p2, 12.0-STABLE, 11.2-
> RELEASE-p8 and 11.2-STABLE do not exhibit this behavior.
>
> This
On Thu, 17 Jan 2019 15:53+0100, Trond Endrestøl wrote:
> Try the attached patch, [...]
I fail to see how r343113 actually fixes r343111.
Attached patch augments and corrects the changes done in r343113.
--
Trond.Index: contrib/libc++/include/errn
On Thu, 17 Jan 2019 04:49-0800, David Wolfskill wrote:
> On Thu, Jan 17, 2019 at 03:37:16PM +0300, Lev Serebryakov wrote:
> >
> > I can not build CURRENT r343111 on r343022 world. Looks like r343111
> > itself cause problems (r343110 builds):
> >
> > In file included from
On Fri, 12 Oct 2018 09:59+0200, Raúl wrote:
> (also deleted obj)
I do that whenever sys/sys/param.h changes. My builder wipes obj
unconditionally every Monday in addition to the above.
--
Trond.
___
freebsd-current@freebsd.org mailing list
On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> Sorry guys, last time I touched ZFS I tried to push to make it an option to
> statically link and was actually told that it wasn't something anyone else
> wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
If consensus
On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:
> On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
>
> > Is anyone else seeing this when building a new kernel with ZFS compiled in?
> >
> > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
> > B
On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
> Is anyone else seeing this when building a new kernel with ZFS compiled in?
>
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
> --- kernel ---
> linking kernel
> ld: error:
On Fri, 8 Jun 2018 02:51+0200, Mateusz Guzik wrote:
> Thanks for the report. Next time if you identify the culprit please cc:
> the committer - not everyone watches mailing lists too closely.
Wilco.
> I set it up on FreeBSD as dom0 and verified the problem exists.
> I fixed it with the
After trial and error, I found r334533 to be responsible for rendering
head unbootable on XenServer 7.4. Neither of the two available
XenServer patches has been applied on the host server.
Normal and verbose boot messages stops non-deterministically at:
hpet0: iomem 0xfed0-0xfed003ff on
On Tue, 20 Mar 2018 08:00+0900, KIRIYAMA Kazuhiko wrote:
> Hi,
>
> I've been encountered suddenly death in ZFS full volume
> machine(r330434) about 10 days after installation[1]:
>
> ZFS: i/o error - all block copies unavailable
> ZFS: can't read MOS of pool zroot
> gptzfsboot: failed to mount
On Tue, 6 Mar 2018 08:40-0800, Rodney W. Grimes wrote:
> > On Mon, 5 Mar 2018 14:39-0600, Larry Rosenman wrote:
> >
> > > Upgraded to:
> > >
> > > FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r330385:
> > > Sun Mar 4 12:48:52 CST 2018
> > >
On Mon, 5 Mar 2018 14:39-0600, Larry Rosenman wrote:
> Upgraded to:
>
> FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r330385: Sun
> Mar 4 12:48:52 CST 2018
> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER amd64
> +1200060 1200060
>
> Yesterday, and I'm
On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote:
> On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl
> <trond.endres...@fagskolen.gjovik.no> wrote:
>
> > On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote:
> >
> > > Does this mean I always have to
On Wed, 21 Feb 2018 20:49+0100, Andreas Nilsson wrote:
> As of pkg-1.10.5 it will ask if you wish to proceed which makes this much
> easier to deal with.
That's an huge improvement. sys/sys/param.h and base are in agreement
on the systems I manage, so I won't see the improvement in action for
On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote:
> Does this mean I always have to do a *clean* buildworld after every version
> bump? This takes ages.
Yes, I've come to the conclusion that whenever __FreeBSD_version in
sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote:
> On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl <
> trond.endres...@fagskolen.gjovik.no> wrote:
>
> > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote:
> >
> > > Note: -r329448 was reverted in -r329461
On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote:
> Note: -r329448 was reverted in -r329461 : racy.
True. I got a crash when compiling r329451 while running r329449.
I've now booted the r329422 ZFS BE and I'm attempting to build
r329529.
--
Trond.
On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote:
> Can you please bisect this? There is another report stating that r329418
> works fine.
My problems started yesterday with r329464. I decided to go back to
r329101 (ZFS BE), update the source tree, move forward to the latest
revision, and
On Sat, 17 Feb 2018 17:39-0800, Mark Millard wrote:
> This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine.
> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files.
> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen
> Threadripper 1950X). No other
On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote:
> I run a small appliance on an APU from PCengines. This box is bootet via SD
> card, the
> image is created by a modified NanoBSD, which creates GPT/UEFI partitioning
> and booting
> images.
>
> That worked until two days ago (I do not track
On Mon, 7 Aug 2017 09:51+0300, Boris Samorodov wrote:
> So my question is: how to set up local time zone if CMOS is set to UTC?
My timezone is Europe/Oslo, adjust to fit your timezone:
rm -f /etc/wall_cmos_clock
cp -p /usr/share/zoneinfo/Europe/Oslo /etc/localtime
echo Europe/Oslo >
On Sun, 16 Jul 2017 10:43+0200, Trond Endrestøl wrote:
> At boot time /etc/rc display this message:
>
> /etc/rc: WARNING: $ipfw_netflow_enable is not set properly - see rc.conf(5).
>
> This was introduced in r320944 and corrected to some extent in
> r321008.
>
> Never
uot;# rules definition file for pf
pf_program="/sbin/pfctl" # where the pfctl program lives
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl,
On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote:
> On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:
>
> > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > > > https://people.freebsd.org/~kib/misc/vm2.2.patch
> > >
> > &
On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:
> On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > > https://people.freebsd.org/~kib/misc/vm2.2.patch
> >
> > This patch made ruby23 happy on my end. Can't say the same for
> > emacs-nox11 or temacs while building
Try running make installworld without -j N.
Serial installworld was successful at my end.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl
On Mon, 26 Jun 2017 12:22+0100, Steven Hartland wrote:
> Is this related to kib's additional fix over the weekend?
>
> https://svnweb.freebsd.org/changeset/base/320344
Attempting to run r320348 with no patches applied proved unfruitful earlier
today.
I had partial success the weekend building
On Sun, 25 Jun 2017 14:07-0500, Benjamin Kaduk wrote:
> On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestøl wrote:
>
> > Ah, they wound up in /usr/libexec. Still, that's an odd place for user
On Sun, 25 Jun 2017 20:55+0200, Trond Endrestøl wrote:
> I was at bit surprised to see gdb missing from /usr/bin this evening.
> The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb.
>
> This is on base/head r320329.
>
> Do we need to add WITH_GDB=yes to
?
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf
size. This size caused the stack gap to be correctly calculated
> as having zero size, because the whole stack is allocated by initial grow.
> But then there is no space for the guard page, which caused mapping failure
> for it, and overall stack mapping failure.
>
> Try this.
> https://peo
On Sun, 25 Jun 2017 18:08+0200, Trond Endrestøl wrote:
> On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote:
>
> > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:
> >
> > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> > >
> &
On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote:
> On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:
>
> > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> >
> > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > > &
On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:
> On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
>
> > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > >
> > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov <
25 16:39 /usr/lib/libthr.so ->
../../lib/libthr.so.3
-r--r--r-- 1 root wheel 270362 May 28 21:41 /usr/lib/libthr_p.a
-r--r--r-- 1 root wheel 45376 Apr 22 10:39 /usr/lib/libthread_db.a
lrwxr-xr-x 1 root wheel 17 Jun 25 16:39 /usr/lib/libthread_db.so ->
libthread_db.so.3
-r--r--
On Wed, 21 Jun 2017 11:18+0300, Andriy Gapon wrote:
> On 21/06/2017 00:45, Trond Endrestøl wrote:
> > On Tue, 20 Jun 2017 17:31-0400, Allan Jude wrote:
> >
> >> On 2017-06-20 17:27, Trond Endrestøl wrote:
> >>> Has anyone else seen a crash in base/head in abd_
On Tue, 20 Jun 2017 17:31-0400, Allan Jude wrote:
> On 2017-06-20 17:27, Trond Endrestøl wrote:
> > Has anyone else seen a crash in base/head in abd_put() after r320156?
> >
> > One of my experimental VMs at home crashed spectacularly after
> > upgrading to r32015
() at 0x8096915e = fork_trampoline+0xe/frame
0xfe01b0231bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 4s
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond
tems were transferred to the new systems
using tar and nc. That way the old systems kept humming while I
recompiled base, ports, etc, on their replacements.
Here are three things I didn't do/tried before "going live" last year:
recursively copying /usr/local/lib to /usr/local/lib/compat/lib32,
cr
ich I build on my own, not pre-compiled packages.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlan
.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway
rip)
> db> reboot
>
> I will add that after this, every boot hits this problem. (same stack trace).
> the box is effectively bricked
> (or would be if it weren't just a bhyve image)
--
+---++
| Vennlig hilsen, | Best regards,
On Wed, 5 Oct 2016 19:50+0200, Trond Endrestøl wrote:
> Oct 4 13:23:24 [WITHHELD] kernel: add net default: gateway
> 2001:x:y:z::1 fib 0: Network is unreachable
This problem was due to a typo, sorry for the noise.
> Also, why do the startup scripts attempt to add addition
for
127.0.0.1 and ::1? I see that behaviour on both head and stable/11.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig,
affected.
--
+---+----+
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innland
in /usr/share/vt/keymaps/ and
update the keymap line in /etc/rc.conf.
Here's the Norwegian keyboard layout as an example:
keymap="norwegian.iso" # Old Norwegian keymap for the sc console
keymap="no"# New Norwegian keymap for the vt console
--
+--
nks Mark, that looks like the right fix. I’ll put it in today.
>
> Scott
A few of my stable/10 systems simple froze due to this bug. Would it
be possible for the kernel to detect when it's running low on (kernel)
memory, or when it's completely out of (kernel) memory, and call on
panic() only to limp away for a day or so before
pment, but would like to see where the full instructions
> on its implementation / restrictions, at least as early as has been
> described https://wiki.freebsd.org/RootOnZFS
If you keep /boot as a separate dataset/filesystem, with
efiwpool/ROOT/init0/boot as the given bootfs, then boot1.efi will not
see a /boot directory inside that datas
On Thu, 17 Dec 2015 12:51+0100, Claude Buisson wrote:
> On 12/17/2015 12:21, Trond Endrestøl wrote:
> > On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> >
> > > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> > >
> > > > On Wed, Dec 1
On Thu, 17 Dec 2015 13:56+0100, Trond Endrestøl wrote:
> On Thu, 17 Dec 2015 12:51+0100, Claude Buisson wrote:
>
> > On 12/17/2015 12:21, Trond Endrestøl wrote:
> > > On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> > >
> > > > On Wed, 1
g to commit it? Ed Maste is assigned, so unless you're too
busy, Ed, would you commit this patch to CURRENT and MFC/MFH as
appropriate?
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endre
On Thu, 17 Dec 2015 12:21+0100, Trond Endrestøl wrote:
> On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
>
> > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> >
> > > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze <carsten.ku...@arcor.de>
On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze <carsten.ku...@arcor.de>
> wrote:
>
> > Trond Endrestøl <trond.endres...@fagskolen.gjovik.no> wrote:
> >
> > > I guess we who live outsid
On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
>
> > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze <carsten.ku...@arcor.de>
> > wrote:
> >
> > > Trond Endrestøl <trond.endres...@fagskolen.
=> /lib/libc.so.7 (0x800827000)
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College
On Tue, 7 Jul 2015 19:37+0200, Trond Endrestøl wrote:
Hi,
I guess both the instructions for enabling DTrace,
https://wiki.freebsd.org/DTrace/KernelSupport and r284356 are to
blame.
I suggest the wiki be amended with:
STRIP=:
or some other innocuous command like 'echo
regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952
On Mon, 22 Jun 2015 09:41-0700, Jason Evans wrote:
On Jun 21, 2015, at 1:05 PM, Garrett Cooper yaneurab...@gmail.com wrote:
On Jun 21, 2015, at 3:16, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
Am I the only one who fails to build recent base/head (r284673) on
pretty
On Mon, 22 Jun 2015 18:14-, Mark Johnston wrote:
On Mon, Jun 22, 2015 at 08:00:13PM +0200, Trond Endrestøl wrote:
I concur. DTrace support is b0rken.
I installed a fresh VM at work using Glen's recent base/head snapshot,
20150618 r284544. I created an /etc/src.conf file
probably
leftovers from when we could choose between gcc and clang. I'll remove
those lines and see what happens. Thanks.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl
.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob
/lib/clang/3.6.0
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator
to be the case. Correct me if I'm wrong.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System
make delete-old can't finish off the /usr/lib/private directory due to
the presence of libssh_p.a. Manual intervention is required UFN.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
?
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway
1 - 100 of 138 matches
Mail list logo
