Re: HOWTO donate CPU to the fight against the Corona-virus
Hi all, Running this on a 12.1-STABLE system, I see a whole lot of this in /var/log/messages: fahclient[53019]: ^[[91m12:15:25:ERROR:WU00:FS00:Exception: Could not get an assignment^[[0m Is this because there temporarily isn't enough work to go around, or because more FreeBSD support is required on the work distribution end as well? Jon On Fri, 20 Mar 2020 at 08:37, Bob Bishop wrote: > Hi, > > Just a note that the client can grow its logfile at the rate of ~1GB a > day. You’ll probably want to take avoiding action. > > > On 19 Mar 2020, at 07:57, Alexander Leidinger via freebsd-stable < > freebsd-sta...@freebsd.org> wrote: > > > > Hi, > > > > if someone wants to donate some FreeBSD based CPU resources to the fight > against the Corona-virus, here is a quick HOWTO in terms of installing the > Folding@Home client on FreeBSD: > > > > > https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ > > > > I tested this on a recent -current. > > > > If you are interested in how this helps in the fight against the virus, > please refer to the https://foldingathome.org/ website. In short and > over-simplified: they search for vaccines. > > > > Bye, > > Alexander. > > > > -- > > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF > > -- > Bob Bishop > r...@gid.co.uk > > > > > -- jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
Hi Ed, I think that sounds great. In the future, could we go even further and, by default, only emit date/user/path if the source tree is “dirty” with respect to SVN? If the build really is reproducible, that data should only be informative when building something that doesn’t match a FreeBSD SVN revision (e.g., a Git commit in a local repo or a tree with local changes). Cheers, Jon -- jonat...@freebsd.org On 10 Sep 2018, at 12:26, Ed Maste wrote: The FreeBSD base system is a reproducible build[1] with a minor exception: the build metadata (timestamps, user, hostname, etc.) included in the kernel and loader. With the default, non-reproducible build the kernel ident looks like: FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 user@hostname:/path/to/freebsd/src and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 (Mon Jan 1 10:11:12 EDT 2018 user@hostname) With reproducible builds enabled the kernel ident looks like: FreeBSD 12.0-ALPHA5 r338195 and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 I would like to enable the REPRODUCIBLE_BUILD knob by default for the 12.0 release, and propose we do this by adding a step to switch the default to the list of changes[2] that re@ commits to the branch as part of the release process. [1] https://reproducible-builds.org [2] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: extending the maximum filename length (pointer to patch)[request for input]
On 12 Sep 2017, at 14:38, Julian Elischer wrote: “这是一个测试多字符文件名长度的文件目的是命名一个文件用中文或者日文或者韩文字符并且要求字符长度超过八十五个字符然后拷贝该文件到我们的共享文件夹看看是否能够拷贝该文件到我.txt” (I have no idea what that says but apparently it's a real filename from a windows machine that blew up when written via samba.) Google Translate says, amusingly: "This is a test file for the length of the file name. The purpose is to name a file in Chinese or Japanese or Korean characters and require the character to be longer than 85 characters and then copy the file into our shared folder to see if it can copy the file To me" (.txt, I guess) No matter what number you choose for a path length, you're never going to win against that specific user. :) Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: EVDEV support in psm(4) driver
Hi Vladimir, On 04/16/17 15:18, Vladimir Kondratyev wrote: Following patch [1] bring in multitouch EVDEV support for Synaptics and Elan PS/2 touchpads found in many laptops. (And for generic relative PS/2 mices as well). This allows to replace our limited in-kernel gesture processor with full-blown one from xf86-input-synaptics or xf86-input-libinput driver and makes Synaptics and Elan PS/2 touchpad support to be mostly on par with Linux Thanks very much... I've been using your patch for awhile with my Synaptics touchpad and it's lovely to have two-finger scrolling that works properly! I did need to massage the patch to make it apply on drm-next: https://github.com/trombonehero/freebsd/commit/3d74a33a1bc709d289216cb946744afecb70f6b5 Sometimes I experience dropped touchpad events, particularly when the system is busy and my wi-fi is being reconfigured. Is there anything I can do to help debug this? Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: regression suspend/resume on Lenovo T420
On 15 May 2017, at 14:57, Konstantin Belousov wrote: On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote: Running drm-next (which has -CURRENT last merged somewhere around r317651), this patch fixes one of the two problems I've been experiencing with suspend/resume. Definite progress. :) Could you, please, clarify. Does the resume work after this ? If not, how did you diagnosed that 'one of two problems' is solved with the change ? Sorry, I'll try to clarify. My problems were: 1. since at least late March, I've had visual artifacts on resume that make the screen unusable; 2. more recently, the machine didn't resume at all. Applying your patch, I can successfully suspend to S3 and resume again, so problem #2 is resolved. This leaves me in a better position to try and test solutions for problem #1 (which might be an issue related to the Mar 13 firmware update on drm-next rather than a -CURRENT problem). Thanks, Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: regression suspend/resume on Lenovo T420
On 15 May 2017, at 7:26, Konstantin Belousov wrote: Try this. If it works, I will write a proper patch. diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S index 33437ad16e6..9c0cd05ebea 100644 --- a/sys/amd64/amd64/cpu_switch.S +++ b/sys/amd64/amd64/cpu_switch.S @@ -369,6 +369,11 @@ END(savectx) * Resuming processor state from pcb. */ ENTRY(resumectx) + movl$MSR_EFER,%ecx + rdmsr + orl $EFER_NXE,%eax + wrmsr + /* Switch to KPML4phys. */ movqKPML4phys,%rax movq%rax,%cr3 Running drm-next (which has -CURRENT last merged somewhere around r317651), this patch fixes one of the two problems I've been experiencing with suspend/resume. Definite progress. :) Thanks! Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot failure - svn up from this morning
On 7 Mar 2017, at 16:50, Chris H wrote: On Tue, 07 Mar 2017 16:27:59 -0330 "Jonathan Anderson" <jonat...@freebsd.org> wrote Hi, On 5 Mar 2017, at 20:31, Chris H wrote: OK copying the boot.efi from the install DVD will only hose the system (EFI). Before I attempt to do the same thing... what do you mean by "hose the system"? Is the correct recovery path to build a new USB image with "make release" post-r314828? That was *my* bad. I inadvertently copied the *wrong* file (I was in a hurry). So. That said; if you move loader.efi aside -- say; to _loader.efi. Then copy loader.efi from the install DVD, or any other system that's not too much older, and is good. You should be fine. :-) Make sure the permissions are correct, after the copy. Sorry for the misinformation. Thanks for the clarification! I am back up and running now. Cheers, Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot failure - svn up from this morning
Hi, On 5 Mar 2017, at 20:31, Chris H wrote: OK copying the boot.efi from the install DVD will only hose the system (EFI). Before I attempt to do the same thing... what do you mean by "hose the system"? Is the correct recovery path to build a new USB image with "make release" post-r314828? Thanks, Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 14:26, Matthew Macy wrote: Thanks. Pete already filed that as part of #108. With luck markj@ will have that fixed this weekend. -M Fantastic, I'll subscribe to that issue. Cheers, Jon -- jonathan.ander...@ieee.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 14:06, Matthew Macy wrote: kernel cores tend to be large (all of wired memory after all) and unless I have exactly the same kernel as you with the same sources at the same changeset, not useful. A backtrace is a good place to start. kgdb /boot/kernel/kernel /var/crash/vmcore.last % bt -M Ok, here we are: #0 doadump (textdump=0) at pcpu.h:222 #1 0x82a445e7 in vt_kms_postswitch (arg=) at /usr/home/jon/freebsd/graphics/sys/modules/drm/drm/../../../dev/drm/linux_fb.c:82 #2 0x808de76b in vt_window_switch (vw=0x81760ea8) at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:540 #3 0x808dc280 in vtterm_cngrab (tm=) at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:1465 #4 0x809f3e02 in cngrab () at /usr/home/jon/freebsd/graphics/sys/kern/kern_cons.c:368 #5 0x80a4d27a in vpanic (fmt=0x80ff218f "Assertion %s failed at %s:%d", ap=0xfe0233e6f5f0) at /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:765 #6 0x80a4d166 in kassert_panic (fmt=) at /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:669 #7 0x80d2b93c in vm_fault_hold (map=0xf8010c9aa000, vaddr=34369822720, fault_type=, fault_flags=0, m_hold=0x0) at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:389 #8 0x80d2a1b8 in vm_fault (map=0xf8010c9aa000, vaddr=optimized out>, fault_type=2 '\002', fault_flags=) at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:474 #9 0x80ebb412 in trap_pfault (frame=0xfe0233e6f9c0, usermode=1) at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:708 #10 0x80ebaba2 in trap (frame=0xfe0233e6f9c0) at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:326 #11 0x80e9b181 in calltrap () at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/exception.S:236 #12 0x0008022a3876 in ?? () It looks like the other core files have the same backtrace. Please let me know if any other details would help... Jon -- jonathan.ander...@ieee.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 12:48, Pete Wright wrote: On 1/6/17 9:14 AM, Matthew Macy wrote: I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core. I have found the following has enabled me to catch kernel panic's pretty reliably on the drm-next branch when i have the i915kms module loaded: dev.drm.skip_ddb=1 Excellent: I turned that on and got a core, then got another core while tar'ing up the first core. :) The machine in question is currently not connected to any network (iwm is being a bit unhappy), but once it is, where can I put the tarball? Jon -- jonathan.ander...@ieee.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 13:53, Pete Wright wrote: i've been having the same problems with iwm too (failing to load firmware on boot). my trick has been to either boot into an old kernel where iwm was mostly usable. also i've commented out the line enabling wlan0 in my rc.conf then uncommented it after boot and manually running "service netif start" to bring up iwm. that method works most of the time... -pete I am able to load iwm (iwm7265fw), but there are some networks that I just can't connect to (INIT -> INIT, swscan_cancel_scan, repeat). Attaching to an iPhone hotspot is one example of a not-entirely-helpful network, but there is other, more typical infrastructure that gives trouble too. There is an iwm8xxx in the room that seems to work fine, however... I do not meddle in the affairs of wi-fi, for it is subtle and quick to anger. :) Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 5 Jan 2017, at 0:17, Matthew Macy wrote: On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson <jonat...@freebsd.org> wrote Hi all, I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of not-quite-CURRENT, it's also very possible that I don't understand how the laundry queue is supposed to work. Nonetheless, I thought I'd check whether there is a tunable I should change, an issue with the laundry queue itself, etc. After running X overnight (i915 can now run overnight on drm-next-4.7!), I end up with a little over half of my system memory in the laundry queue and a bunch of swap utilization. Even after closing X and shutting down lots of services, I see the following in top: Please try the drm-next branch now. Up until very recently, the shrinkers responsible for culling ttm/gem allocations were never run. I've now implemented the shrinker, but it's driven from vm_lowmem, so you'll probably still see what looks like a leak until you hit low memory conditions. The shrinker should probably be run from uma_timeout, but there isn't an eventhandler for that and I haven't looked any further. -M Hi, I am now testing the `drm-next` branch, but I'm finding it crashes much more frequently (a la https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than `drm-next-4.7`. While the 4.7 branch would sometimes only last a few minutes, it would sometimes run for a day or more. On `drm-next`, however, I think I'm yet to have 20 minutes of uptime. So, I haven't run into the memory shrinker yet because I haven't had enough uptime to use lots of memory. :) I will continue testing... any specific things I ought to be doing? Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 2 Jan 2017, at 13:33, Mark Johnston wrote: On Mon, Jan 02, 2017 at 10:31:50AM -0330, Jonathan Anderson wrote: Hi all, I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of not-quite-CURRENT, it's also very possible that I don't understand how the laundry queue is supposed to work. Nonetheless, I thought I'd check whether there is a tunable I should change, an issue with the laundry queue itself, etc. My suspicion is that this is a memory leak of some sort and unrelated to PQ_LAUNDRY itself. That is, with the previous policy you would see lots of swap usage and a large inactive queue instead. That sounds very plausible... I'm testing with the new DRM drivers to see if that helps. After running X overnight (i915 can now run overnight on drm-next-4.7!), I end up with a little over half of my system memory in the laundry queue and a bunch of swap utilization. Even after closing X and shutting down lots of services, I see the following in top: ``` Mem: 977M Active, 31M Inact, 4722M Laundry, 1917M Wired, 165M Free ARC: 697M Total, 67M MFU, 278M MRU, 27K Anon, 22M Header, 331M Other Swap: 4096M Total, 2037M Used, 2059M Free, 49% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 911 root 1 520 57788K 4308K select 1 0:00 0.00% sshd 974 root 1 200 43780K 0K wait2 0:00 0.00% 1406 jon 1 200 33520K 2748K select 0 0:04 0.00% gpg-agent 2038 jon 1 200 31280K 5452K ttyin 3 0:18 0.00% zsh 1251 jon 1 220 31280K 4500K pause 3 0:02 1.46% zsh 7102 jon 1 200 31280K 3744K ttyin 0 0:00 0.00% zsh 1898 jon 1 200 31280K 3036K ttyin 1 0:00 0.00% zsh 1627 jon 1 210 31280K 0K pause 0 0:00 0.00% 22989 jon 1 200 31152K 6020K ttyin 1 0:01 0.00% zsh 22495 jon 1 490 31152K 6016K ttyin 0 0:02 0.00% zsh 1621 jon 1 200 28196K 8816K select 2 0:40 0.00% tmux 6214 jon 1 520 27008K 2872K ttyin 1 0:00 0.00% zsh 6969 jon 1 520 27008K 2872K ttyin 3 0:00 0.00% zsh 6609 root 1 200 20688K 4604K select 1 0:00 0.00% wpa_supplicant 914 root 1 200 20664K 5232K select 2 0:02 0.00% sendmail 917 smmsp 1 200 20664K 0K pause 0 0:00 0.00% 24206 jon 1 230 20168K 3500K CPU00 0:00 0.00% top 921 root 1 200 12616K 608K nanslp 1 0:00 0.00% cron ``` Are there any things I could do (e.g., sysctls, tunables) to figure out what's happening? Can I manually force the laundry to be done? `swapoff -a` fails due to a lack of memory. Is that the full list of processes? Does "ipcs -m" show any named shm segments? Looking at the DRM code, the GEM uses swap objects to back allocations by the drivers, so this could be the result of a kernel page leak in the drm-next branch. If so, you'll need a reboot to recover. That was the full list of processes, yes. I haven't been able to reproduce this particular issue on new DRM code, as I'm now confronted with a different issue. :) If I do get back to this condition, I'll try checking `ipcs -m`, thanks. Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
PQ_LAUNDRY: unexpected behaviour
Hi all, I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of not-quite-CURRENT, it's also very possible that I don't understand how the laundry queue is supposed to work. Nonetheless, I thought I'd check whether there is a tunable I should change, an issue with the laundry queue itself, etc. After running X overnight (i915 can now run overnight on drm-next-4.7!), I end up with a little over half of my system memory in the laundry queue and a bunch of swap utilization. Even after closing X and shutting down lots of services, I see the following in top: ``` Mem: 977M Active, 31M Inact, 4722M Laundry, 1917M Wired, 165M Free ARC: 697M Total, 67M MFU, 278M MRU, 27K Anon, 22M Header, 331M Other Swap: 4096M Total, 2037M Used, 2059M Free, 49% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 911 root 1 520 57788K 4308K select 1 0:00 0.00% sshd 974 root 1 200 43780K 0K wait2 0:00 0.00% 1406 jon 1 200 33520K 2748K select 0 0:04 0.00% gpg-agent 2038 jon 1 200 31280K 5452K ttyin 3 0:18 0.00% zsh 1251 jon 1 220 31280K 4500K pause 3 0:02 1.46% zsh 7102 jon 1 200 31280K 3744K ttyin 0 0:00 0.00% zsh 1898 jon 1 200 31280K 3036K ttyin 1 0:00 0.00% zsh 1627 jon 1 210 31280K 0K pause 0 0:00 0.00% 22989 jon 1 200 31152K 6020K ttyin 1 0:01 0.00% zsh 22495 jon 1 490 31152K 6016K ttyin 0 0:02 0.00% zsh 1621 jon 1 200 28196K 8816K select 2 0:40 0.00% tmux 6214 jon 1 520 27008K 2872K ttyin 1 0:00 0.00% zsh 6969 jon 1 520 27008K 2872K ttyin 3 0:00 0.00% zsh 6609 root 1 200 20688K 4604K select 1 0:00 0.00% wpa_supplicant 914 root 1 200 20664K 5232K select 2 0:02 0.00% sendmail 917 smmsp 1 200 20664K 0K pause 0 0:00 0.00% 24206 jon 1 230 20168K 3500K CPU00 0:00 0.00% top 921 root 1 200 12616K 608K nanslp 1 0:00 0.00% cron ``` Are there any things I could do (e.g., sysctls, tunables) to figure out what's happening? Can I manually force the laundry to be done? `swapoff -a` fails due to a lack of memory. Thanks, Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UTF-8 by default?
On 20 Jul 2016, at 9:13, Tim Čas wrote: So, without further ado: 1) What are the reasons that UTF-8 isn't the default yet? 2) Would it be possible to make this the default in 11.0? What about 12.0? 3) Assuming an effort is started towards making UTF-8 the default, what changes would be required? At least according to one of my students (who makes more extensive use of i18n than I do), enabling UTF-8 by default is pretty straightforward: https://github.com/musec/freebsd/wiki/Common-setup#utf-8-support If there's anything missing there, I'd love to hear about it. Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 11-ALPHA6 bsdinstall(8) fails with root on ZFS + GELI
On 5 Jul 2016, at 6:35, Marin BERNARD wrote: Hi all, Ive been trying to install FreeBSD Current (11.0 ALPHA5 & ALPHA6) with encrypted root on ZFS, and was unable to complete the setup process. The installation stops just after the GELI volume is initialized, and bsdinstall(8) reports : mkdir : /mnt/boot : No such file or directory. The debug log file is attached. Note that this is from an Hyper-V VM, but the same error also happens on real hardware. Any idea ? Thanks ! Marin BERNARD I've done some speculating in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210815, but no answers there yet. I think the problem might be that the bootpool hasn't actually been mounted yet, so the /mnt/boot symlink points to a non-existent directory (/mnt/bootpool/boot). Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 19 Apr 2016, at 19:42, Matthew Grooms wrote: I suspect that most of the negative reactions people are having is due to the line being blurred between the base system and everything else. Historically there has always been a clear distinction. By packaging base and throwing it in with everything else, you erase that distinction. I certainly agree that the distinction is changing, but I wouldn't say it's being erased. In fact, I'd argue that a packaged base system will clarify the conversation around the base/not-base dichotomy by forcing us to think about the underlying distinctions rather than of the delivery mechanism. For instance, I'd say that the biggest blurring between base and ports doesn't come from packages, it comes from vendor branches. If the base system is "an atomic, maintained-by-us snapshot of all the stuff you need to get a computer running and bootstrap your applications"... well, first, stop me here if I'm wrong! Assuming I'm not entirely wrong: we have lots of code in base that is "built by the FreeBSD project" and entirely maintained by "us". However, there is also a lot of code in base that comes from an upstream source and is primarily maintained by "them" (who may overlap with "us"), yet is essential to building or using the FreeBSD base system. This is a necessity of modern life (compilers are good), and yet I'm not entirely clear on the distinction between a lightly-patched compiler that lives in our source tree and a lightly-patched compiler that lives in the ports tree. So, now that the base compiler and a ports compiler will be installed using the same tools, it might be worth thinking about how they're really different (if at all). Not that there are any good answers... Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Mouse on Inspiron ?
On 28 Feb 2016, at 14:15, Larry Rosenman wrote: Ok, a verbose boot tells me /dev/psm0 can't allocate an IRQ. Ideas? Verbose boot attached Hi Larry, I believe that someone encountered (and fixed!) a similar problem last year: https://lists.freebsd.org/pipermail/freebsd-stable/2015-February/081757.html It seems that this is becoming an issue on new notebooks: I know that my new ASUS notebook has the same problem (but, unfortunately, Mauro's fix doesn't apply to my machine). Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZenBook UX305CA touchpad
On 26 Feb 2016, at 13:23, Jonathan Anderson wrote: Hello -CURRENT, I just picked up an Asus ZenBook UX305CA on sale. The screen is beautiful (with unaccelerated scfb graphics), the wi-fi works (with just the occasional fatal firmware error) and I'm generally a satisfied customer, except: the touchpad doesn't seem to work. It doesn't even show up as a PS/2 mouse: `dmesg | grep psm` yields nothing. I now see that, after a verbose boot, I do have one psm0 message in dmesg (attached as dmesg.out): psm0: unable to allocate IRQ Jon I saw that some Linux folks had troubles with this trackpad too: https://florisvanvugt.wordpress.com/2015/12/26/making-asus-ux305ca-touchpad-work-in-ubuntu/ https://bugzilla.redhat.com/show_bug.cgi?id=1275718#c7 Does that provide any useful information for my FreeBSD problem? Jon -- Jonathan Anderson jonat...@freebsd.orgTable 'FACP' at 0x86d67eb8 Table 'APIC' at 0x86d67fc8 APIC: Found table at 0x86d67fc8 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 02:07:17 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. PPIM 0: PA=0xc000, VA=0x8221, size=0x7e9000, mode=0x1 VT(efifb): resolution 1920x1080 Preloaded elf kernel "/boot/kernel/kernel" at 0x820ba000. Preloaded /boot/entropy "/boot/entropy" at 0x820bb3a8. Preloaded elf obj module "/boot/kernel/if_iwn.ko" at 0x820bb3f8. module iwn already present! Calibrating TSC clock ... TSC clock: 1512067196 Hz CPU: Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz (1512.07-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406e3 Family=0x6 Model=0x4e Stepping=3 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x121<LAHF,ABM,Prefetch> Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> VT-x: Basic Features=0xda0400<SMM,INS/OUTS,TRUE> Pin-Based Controls=0x7f<ExtINT,NMI,VNMI,PreTmr> Primary Processor Controls=0xfff9fffe<INTWIN,TSCOff,HLT,INVLPG,MWAIT,RDPMC,RDTSC,CR3-LD,CR3-ST,CR8-LD,CR8-ST,TPR,NMIWIN,MOV-DR,IO,IOmap,MTF,MSRmap,MONITOR,PAUSE> Secondary Processor Controls=0x1fbcff<APIC,EPT,DT,RDTSCP,x2APIC,VPID,WBINVD,UG,PAUSE-loop,RDRAND,INVPCID,VMFUNC,EPT#VE,XSAVES> Exit Controls=0xda0400<PAT-LD,EFER-SV,PTMR-SV> Entry Controls=0xda0400 EPT Features=0x6334141<XO,PW4,UC,WB,2M,1G,INVEPT,AD,single,all> VPID Features=0xf01<INVVPID,individual,single,all,single-globals> TSC: P-state invariant, performance statistics Data TLB: 1 GByte pages, 4-way set associative, 4 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries Instruction TLB: 2M/4M pages, fully associative, 8 entries Instruction TLB: 4KByte pages, 8-way set associative, 64 entries 64-Byte prefetching Shared 2nd-Level TLB: 4 KByte /2 MByte pages, 6-way associative, 1536 entries. Also 1GBbyte pages, 4-way, 16 entries L2 cache: 256 kbytes, 8-way associative, 64 bytes/line real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0001 - 0x00053fff, 278528 bytes (68 pages) 0x00059000 - 0x0009dfff, 282624 bytes (69 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x020fc000 - 0x82fc, 2163032064 bytes (528084 pages) 0x82ffb000 - 0x8304bfff, 331776 bytes (81 pages) 0x8348d000 - 0x859befff, 39002112 bytes (9522 pages) 0x8641b000 - 0x86a3cfff, 6430720 bytes (1570 pages) 0x87ffe000 - 0x87ffefff, 4096 bytes (1 pages) 0x0001 - 0x000263f9cfff, 5972283392 bytes (1458077 pages) avail memory = 8122744832 (7746 MB) Table 'FACP' at 0x86d67eb8 Table 'APIC' at 0x86d67fc8 Table 'FPDT' at 0x86d68050 Table 'FIDT' at 0x86d68098 Table 'MCFG' at
ZenBook UX305CA touchpad
Hello -CURRENT, I just picked up an Asus ZenBook UX305CA on sale. The screen is beautiful (with unaccelerated scfb graphics), the wi-fi works (with just the occasional fatal firmware error) and I'm generally a satisfied customer, except: the touchpad doesn't seem to work. It doesn't even show up as a PS/2 mouse: `dmesg | grep psm` yields nothing. I saw that some Linux folks had troubles with this trackpad too: https://florisvanvugt.wordpress.com/2015/12/26/making-asus-ux305ca-touchpad-work-in-ubuntu/ https://bugzilla.redhat.com/show_bug.cgi?id=1275718#c7 Does that provide any useful information for my FreeBSD problem? Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot hang: Sony VAIO
On Jun 17, 2015, at 2:39 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Jun 17, 2015 at 02:32:16PM -0230, Jonathan Anderson wrote: The system boots the 11-CURRENT kernel in safe mode (not sure if it???s the kern.mp.disabled or kern.eventtimer.periodic that???s causing that), after which `dmesg -a` produces the following output: https://people.freebsd.org/~jonathan/vaio-acpi-dmar.txt Try a loader tunable hw.x2apic_enable=0. Your UP boot was successfull with x2APIC mode enabled and set, but there are rumors that some SandyBridge BIOSes are buggy. That seems to fix it... thanks! Is there a Wiki page somewhere for people to document these kinds of workarounds for particular configurations? Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Boot hang: Sony VAIO
Hi all, I’m trying to upgrade an old Sony VAIO laptop from 10.1 to -CURRENT. Everything seemed to work well with 10.1, but on -CURRENT I get no further in the boot than: ``` ACPI: No DMAR table found Event timer “LAPIC” quality 600 ACPI APIC Table: Sony VAIO ``` If I disable ACPI, I get: ``` APIC: Could not find any APICS. panic: running without device atpic requires a local APIC ``` What’s changed between 10 and 11, ACPI-wise? Any thoughts on what I might be able to do (besides stay on 10)? Thanks, Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot hang: Sony VAIO
On Jun 17, 2015, at 12:00 PM, Konstantin Belousov kostik...@gmail.com wrote: Show bootverbose dmesg. Is that different from the “Verbose” option in the loader menu? When I do a loader-menu-driven verbose boot, I see: https://drive.google.com/file/d/0B2eLORKzuvdOZ1I4SVB0aFNSenM Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot hang: Sony VAIO
On Jun 17, 2015, at 2:24 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Jun 17, 2015 at 02:19:14PM -0230, Jonathan Anderson wrote: On Jun 17, 2015, at 12:00 PM, Konstantin Belousov kostik...@gmail.com wrote: Show bootverbose dmesg. Is that different from the ???Verbose??? option in the loader menu? When I do a loader-menu-driven verbose boot, I see: https://drive.google.com/file/d/0B2eLORKzuvdOZ1I4SVB0aFNSenM This is useless, it omits information I want to see. Get the verbose dmesg from the bootable system, please. Hi again, The system boots the 11-CURRENT kernel in safe mode (not sure if it’s the kern.mp.disabled or kern.eventtimer.periodic that’s causing that), after which `dmesg -a` produces the following output: https://people.freebsd.org/~jonathan/vaio-acpi-dmar.txt Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Error building -CURRENT from 10.1
Hi all,
I’m attempting to `make buildworld` from a 10.1-RELEASE box, and I’m
encountering an error in the “bootstrap tools stage. It looks like gzip, which
is part of the bootstrap tools, depends on `futimens` from a newish (since
February?) libc / syscall API:
$ make buildworld
[...]
usr.bin/gzip/gzip.c:1103:6: warning: implicit declaration of function
'futimens' is invalid in C99 [-Wimplicit-function-declaration]
if (futimens(fd, times) 0)
^
1 warning generated.
gzip.o: In function `copymodes':
usr.bin/gzip/gzip.c:(.text+0x2240): undefined reference to `futimens’
But we haven’t built the new libc yet:
$ grep ‘===’ build.log do_some_manual_compression
=== tools/build (obj,includes,depend,all,install)
=== lib/clang/libllvm{support,tablegen} (obj,depend,all,install)
=== usr.bin/clang/[clang-]tblgen (obj,depend,all,install)
=== kerberos5/[stuff] (obj,depend,all,install)
=== usr.bin/compile_et (obj,depend,all,install)
=== lib/libelf (obj,depend,all,install)
=== lib/libdwarf (obj,depend,all,install)
=== cddl/usr.bin/sgsmsg (obj,depend,all,install)
=== cddl/lib/libctf (obj,depend,all,install)
=== cddl/usr.bin/ctf{convert,merge} (obj,depend,all,install)
=== games/fortune/strfile (obj,depend,all,install)
=== gnu/usr.bin/gperf (obj,depend,all,install)
=== gnu/usr.bin/groff (obj,depend,all,install)
=== usr.bin/soelim (obj,depend,all,install)
=== gnu/usr.bin/dtc (obj,depend,all,install)
=== usr.bin/lorder (obj,depend,all,install)
=== lib/libohash (obj,depend,all,install)
=== lib/libsqlite3 (obj,depend,all,install)
=== usr.bin/mandoc (obj,depend,all,install)
=== usr.bin/gzip (obj,depend,all,install)
So, how do I bootstrap 11-CURRENT from 10.1-RELEASE? Could there be something
wrong with my specific environment? I don’t have any /etc/make.conf or
/etc/src.conf.
Thanks,
Jon
—
jonat...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error building -CURRENT from 10.1
On Jun 3, 2015, at 12:35 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Wed, Jun 03, 2015 at 12:29:12PM -0230, Jonathan Anderson wrote: So, how do I bootstrap 11-CURRENT from 10.1-RELEASE? Update your source tree. My source tree is up-to-date as of a few hours ago. Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error building -CURRENT from 10.1
On Jun 3, 2015, at 12:44 PM, Baptiste Daroussin b...@freebsd.org wrote: On Wed, Jun 03, 2015 at 12:42:13PM -0230, Jonathan Anderson wrote: On Jun 3, 2015, at 12:35 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Wed, Jun 03, 2015 at 12:29:12PM -0230, Jonathan Anderson wrote: So, how do I bootstrap 11-CURRENT from 10.1-RELEASE? Update your source tree. My source tree is up-to-date as of a few hours ago. Update it again :) Best regards, Bapt Ah, I see... *really* update. :) Sorry Steve, I guess I’m not used to moving at the speed of -CURRENT! Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] Jenkins running in FreeBSD cluster
This is great stuff, thanks! Can you say what the relationship with tinderbox is intended to be? Is this supposed to subsume tinderbox, or will they have different niches? Is Jenkins going to start e-mailing likely culprits (with e.g. https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin)? Also, can we see more architectures built by Jenkins? Thanks, Jon On 22 February 2014 19:54, Craig Rodrigues rodr...@freebsd.org wrote: Hi, I just wanted to let the FreeBSD community know that with the help of some FreeBSD hackers, we have set up an initial Jenkins Continuous Integration server in the FreeBSD cluster. We are the jenkins-admin team and you can contact us at jenkins-ad...@freebsd.org. We have a few initial builds going and you can see things here: https://jenkins.freebsd.org We are still working on a few problems, and have some ambitious plans moving forward, which you can read about on our status page: http://wiki.freebsd.org/Jenkins Lastly, if you are able to attend the FreeBSD DevSummit in Ottawa later this year, we will have a working group discussion on Jenkins and Continuous Integration testing for FreeBSD on May 15, 2014: https://wiki.freebsd.org/201405DevSummit/Jenkins We'd love to get more FreeBSD hackers involved to get this going and improve continuous integration and testing on FreeBSD. We would like to use the freebsd-test...@freebsd.org mailing list for followup discussions. I'd like to thank my fellow members of the jenkins-admin team for helping to get things going: Steve Kreuzer skreu...@freebsd.org Li-Wen Hsu lw...@freebsd.org Steve Wills swi...@freebsd.org R. Tyler Croy ty...@freebsd.org If we can integrate more automated testing of FreeBSD with this, that would be really great! -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
The Base System (was: rcs)
On 8 October 2013 16:04, sth...@nethelp.no wrote:
- For some of us, the attraction of FreeBSD is that it is a tightly
integrated system, and the base contains enough useful functionality
that we don't *have* to add a lot of packages.
- Each package that is moved out of the base system means less useful
functionality in the base system - and for me: Less reason to use
FreeBSD instead of Linux.
I absolutely see the problem of maintaining out-of-date packages in
the base system, and the desirability of making the base system less
reliant on GPL. I'm mostly troubled by the fact that there seems to
be a rather strong tendency the last few years of having steadily
less functionality in the base system - and I'm not at all convinced
that the right balance has been found here.
I think this is the core problem at the root of many discussions
besides this one. What is the base system?
FreeBSD users tend to agree that we like a self-contained wad of stuff
called The Base System but disagree quite strongly about what should
be in it. There are several approaches to the problem, ranging from
concrete and specific (exactly what shipped with 4.4BSD, a.k.a.
Originalism) to principled but open to interpretation (what 4.4BSD
would ship if it were released today, a.k.a. Founders' Intent).
We will never all agree on exactly what should be in base vs
ports/packages, but can we perhaps build consensus around principles?
When you first take it out of the box, does The Base System need to be:
- self-bootstrapping
- POSIX-compliant
- administerable
- with local shell
- with local tools (e.g. RCS, vim, git...)
- with remote shell (SSH)
- with remote tools (e.g. Puppet)
- with enterprise integration (e.g. Kerberos, LDAP, 802.1x, SMB...)
- useful for end-user workloads:
- [cross-]building FreeBSD
- [cross-]building {program X in language Y}
- file server
- DNS server
- Kerberos server
- SVN server
- Postgres server
- Web server
- Hadoop node
- X server
- desktop
- able to install packages / build ports to do the above
- able to run Linux binaries
?
I think we all agree with the first two items, but where should we
draw the line?
Suppose we distributed install media with The Base System + some
packages tailored to a particular environment; would that change what
needs to be in The Base System? If FreeBSD Enterprise Edition or
FreeBSD Hacker Edition shipped with The Base System plus whatever
packages you need for that environment/workload, and if the installer
knew how to install those packages, could The Base System itself be
smaller, e.g. just what we need to bootstrap FreeBSD itself?
Jon
--
Jonathan Anderson
jonat...@freebsd.org
http://freebsd.org/~jonathan/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rcs
On 8 October 2013 16:04, sth...@nethelp.no wrote:
- For some of us, the attraction of FreeBSD is that it is a tightly
integrated system, and the base contains enough useful functionality
that we don't *have* to add a lot of packages.
- Each package that is moved out of the base system means less useful
functionality in the base system - and for me: Less reason to use
FreeBSD instead of Linux.
I absolutely see the problem of maintaining out-of-date packages in
the base system, and the desirability of making the base system less
reliant on GPL. I'm mostly troubled by the fact that there seems to
be a rather strong tendency the last few years of having steadily
less functionality in the base system - and I'm not at all convinced
that the right balance has been found here.
I think this is the core problem at the root of many discussions
besides this one. What is the base system?
FreeBSD users tend to agree that we like a self-contained wad of stuff
called The Base System but disagree quite strongly about what should
be in it. There are several approaches to the problem, ranging from
concrete and specific (exactly what shipped with 4.4BSD, a.k.a.
Originalism) to principled but open to interpretation (what 4.4BSD
would ship if it were released today, a.k.a. Founders' Intent).
We will never all agree on exactly what should be in base vs
ports/packages, but can we perhaps build consensus around principles?
When you first take it out of the box, does The Base System need to be:
- self-bootstrapping
- POSIX-compliant
- administerable
- with local shell
- with local tools (e.g. RCS, vim, git...)
- with remote shell (SSH)
- with remote tools (e.g. Puppet)
- with enterprise integration (e.g. Kerberos, LDAP, 802.1x, SMB...)
- useful for end-user workloads:
- [cross-]building FreeBSD
- [cross-]building {program X in language Y}
- file server
- DNS server
- Kerberos server
- SVN server
- Postgres server
- Web server
- Hadoop node
- X server
- desktop
- able to install packages / build ports to do the above
- able to run Linux binaries
?
I think we all agree with the first two items, but where should we
draw the line?
Suppose we distributed install media with The Base System + some
packages tailored to a particular environment; would that change what
needs to be in The Base System? If FreeBSD Enterprise Edition or
FreeBSD Hacker Edition shipped with The Base System plus whatever
packages you need for that environment/workload, and if the installer
knew how to install those packages, could The Base System itself be
smaller, e.g. just what we need to bootstrap FreeBSD itself?
Jon
--
Jonathan Anderson
jonat...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw
On Friday, 30 August 2013 at 08:35, David Chisnall wrote: I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will have to install a libstdc++ package. I don't see how that's very different from requiring a gcc/g++ package. Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildkernel is broken
On Tuesday, 2 July 2013 at 22:16, Steve Kargl wrote: It seems that # Enable FreeBSD7 compatibility syscalls options COMPAT_FREEBSD7 is required in a kernel config file. If it is mandatory to have this option on FreeBSD 10, it may be appropriate to expand the comment to # Enable FreeBSD7 compatibility syscalls # This option is MANDATORY. Do not remove. options COMPAT_FREEBSD7 So... a non-optional option? Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 24 Aug 2012, at 23:38, Doug Barton do...@freebsd.org wrote: Let me rephrase that more simply ... very few users are ever going to need the bootstrapping tool that will be in the base. But surely the whole point of pkgng is that people *will* use pkg as the default method of acquiring third-party software, so they'll want to pkg install foo and have it Just Work. To say either you must download the ports tree in order to use binary packages or you must use pkg_add to install pkg seems to miss the point... Jon -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Saturday, 25 August 2012 at 01:33, Glen Barber wrote: On Sat, Aug 25, 2012 at 01:25:15AM +0100, Jonathan Anderson wrote: On 24 Aug 2012, at 23:38, Doug Barton do...@freebsd.org (mailto:do...@freebsd.org) wrote: Let me rephrase that more simply ... very few users are ever going to need the bootstrapping tool that will be in the base. So, then they won't use it. I fail to see the problem here. I also fail to see the problem. :) Just to be clear, my post was arguing against Doug's assertion that few will use pkg's bootstrapper (and that this is a problem): I hope that pkgng and package sets will vastly increase the use of binary packages by FreeBSD consumers. /usr/sbin/pkg installs /usr/local/sbin/pkg without requiring the Ports Collection to be available locally. Which is exactly the behaviour that I want: I view the ports tree as a last resort to be used only if binary packages fail to fulfil my needs. Sometimes I don't even bother fetching it. Once again, we may be in violent agreement here. :) Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: new BSD-licensed sort available
On 14 Mar 2012, at 21:10, Adrian Chadd wrote: Hi, This makes me think of the whole debian-y way of replacing the mailer programs using some magic alias program. So you could intall gnusort, bsdsort, and then some config file would determine which was used. 'sort' would then be a symlink to said magic program, that'd look at its argv[0], look at the contents of that file, and exec() the right one. In fact, the runtime behaviour of the Debian alternatives system is simpler than that: http://segfault.in/2010/04/using-the-debian-alternatives-system/ The custom Perl script with a config file is used to set up symlinks, which at runtime are... well, just symlinks. For instance, /usr/bin/vim is a symlink to /etc/alternatives/vim, which is itself a symlink to a binary like vim.gtk (example shamelessly stolen from the linked page, since I no longer have any Debian boxes to check for myself on :). No magic binaries or argv[0] fu. In one way, it's an elegant solution. On the other, it's a classic example of Wheeler's Law in action. :) Jon -- Jonathan Anderson Research Student, Security Group Computer Laboratory University of Cambridge +44 (1223) 763747 jonathan.ander...@cl.cam.ac.uk___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PANIC: ffs_valloc: dup alloc on boot
That's ok, a more aggressive fsck-from-a-rescue-disk strategy managed to clean things up. J Anderson On 6 October 2011 15:58, Benjamin Kaduk ka...@mit.edu wrote: On Thu, 6 Oct 2011, Jonathan Anderson wrote: On 5 October 2011 23:50, Jonathan Anderson jonat...@freebsd.org wrote: I was about to upgrade my build VM from BETA2 to BETA3, but I can't seem to boot BETA2 any more: I get a ffs_valloc: dup alloc panic on boot, every time. fsck runs and says, ok, I've cleaned things up for you, but then later on, when trying to update motd, FFS dies. Here are two screenshots: fsck succeeding and the relevant backtrace. Mailman seems to have stripped them. -Ben Kaduk -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PANIC: ffs_valloc: dup alloc on boot
On 5 October 2011 23:50, Jonathan Anderson jonat...@freebsd.org wrote: I was about to upgrade my build VM from BETA2 to BETA3, but I can't seem to boot BETA2 any more: I get a ffs_valloc: dup alloc panic on boot, every time. fsck runs and says, ok, I've cleaned things up for you, but then later on, when trying to update motd, FFS dies. Here are two screenshots: fsck succeeding and the relevant backtrace. Jon -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
PANIC: ffs_valloc: dup alloc on boot
I was about to upgrade my build VM from BETA2 to BETA3, but I can't seem to boot BETA2 any more: I get a ffs_valloc: dup alloc panic on boot, every time. fsck runs and says, ok, I've cleaned things up for you, but then later on, when trying to update motd, FFS dies. Unfortunately, this is the VM that I normally use to run kgdb against other VMs, so my normal debugging setup does not apply. I'll see if this hotel will let me download an ISO so that I can install a fresh VM for debugging... Jon -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Installer Feedback: Partitioning
Hi, Love the new installer, but I do have a very small criticism of the guided partitioning screen: it's unclear at first glance which of the available buttons (Create, Delete, ..., Exit) means write the partitions to disk and carry on to the next step. I presume that the point of a guided setup is to make it easy on first-time FreeBSD installers; we might want to make it a little easier still by labelling the relevant button OK, Save, Next, Do It! or something instead of Exit. Jon -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
