Re: extremely slow to get to loader
On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude wrote: > On 2016-04-21 10:46, Johannes Dieterich wrote: >> Dear all, >> >> with r298385, I observe extremely long times from turning on my laptop >> to reach loader. This is a regression compared to a roughly 1 week old >> CURRENT. >> >> This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup. >> >> Please let me know how I can help to solve this issue. >> >> Thanks, >> >> Johannes >> ___ >> 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" >> > > Can you describe where exactly it is slow? Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes before it eventually continues. > Once you get to the loader menu (the beastie menu), can you choose the > option to go to the loader prompt, and type: > bcachestat > > And provide the output of that. Here we go (w/o mistakes I hope...): cache blocks: 32768 cache blocksz: 572 unit cache blocks: 32768 cached units: 1 1162 ops 0 bypasses 12109 hits 739 misses Thanks so much for the response! Johannes ___ 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: Re: Installworld, BW, IK fixed, here are the in > out loader.conf lines
On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" wrote: > > > On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" > wrote: > > > > > > > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" > > wrote: > > > > > > > > > > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude > > > wrote: > > > > > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > > > unistd > > > > > > > > > > > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected > > > > > function body after function declarator > > > > > intexecl( . > > > > > 332:46: > > > > > same... > > > > > > > > > > stops libc > > > > > otherwise clang36 seems to be building so far, if it builds unsure > > > > > about installworld > > > > > ___ > > > > > 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" > > > > > > > > > > > > > The mailing list strips attachments. Can you upload it somewhere and > > > > provide a link > > > > > > > > -- > > > > Allan Jude > > > > ___ > > > > 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" > > > > > > > > > Well, it is now r298350 Wed Apr 20... > > > However several problems > > > > > > SINGLE-USER BOOT PROBLEMS > > > 1... usual boot fails, this is single-user adjusted, but I cannot add > > > swap (swapon? swapctl?) > > > 1a... the last time, it was fixed with using the old /kernel ... > > > > > > multi-user boot problems > > > > > > 2... the last usual boot dumped with vm_pager or something, verbose boot > > > times out with xpt_config not completing. > > > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet > > > updated (which it now is ) for the latter > > > case I have yet to reboot to test > > > 2b... Reboot to test takes longer, /rescue/mount each filesystem > > > individually... > > > > > > > > > As one might surmise, I'd rather see buildworld made more foolproof than > > > other recent improvements > > > (pkg, zfs, ...) > > > > From backup, I have r288246 kernel and nvidia.ko (v11) > > from source, I have world and all except those TWO files at r298350 )(v11), > > nvidia (newer) won't load with older kernel > > A few at-boot scripts no longer work as expected... but no other major > > problems (swap is present again) > > (multi-user boot works) > > > > Best practice maybe to update the kernel? It is a custom one from way back > > in 2004 initially > > without sound drivers and without debug symbols... and many esoteric lines > > added which I cobbled > > together at first then changed per diffs of GENERIC over the years... > > > > Thanks for any known methods > > > > J. Bouquet > > ___ > > 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" > > > Updated to a slightly-less-than-full GENERIC. Still dumped core. Moved > loader.conf out of > the way, works fine. What will take some time now is moving loader.conf back > piece by piece > [until/if there is/ever was a utility to do it for us... ] to find the > problematic line or two, then > resume testing of the install of the custom kernel that also is 'fail' status > at this point... unless/until > I decide to also test it, THEN resume the loader.conf line-by-line back in... > > tl;dr loader.conf problematic line and maybe an additional unknown in > either kernel text file. > ___ > 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" Half of loader.conf removed. (as below). Custom kernel restored and working. # out snd_pcm_load="YES" # out snd_acm_load="YES" # out kern.msgbufsize="13" # out kern.ipc.shmmni="1024" # out kern.ipc.shmseg="1024" # out hw.snd.maxautovchans="4" # out hw.snd.targetirqrate="36" # out hint.pcm.0.buffersize="65536" # out hw.snd.verbose="3" # out kern.ipc.semmns="240" # out kern.ipc.semume="40" # out kern.ipc.semmnu="120" # out vfs.read_max="128" # out kern.randompid="1" # out kern.ipc.shmmax="67108864" # out kern.ipc.shmall="32768" # out vm.kmem_size="700M" # out vm.kmem_size_max="700M" # out vfs.zfs.arc_max="250M" # out kern.sched.preempt_thresh="224" # out vfs.usermount="1" # out kern.geom.part.check_integrity="0" # out vm.overcommit="1" # out kern.maxfilesperproc="
Re: [CFT] packaging the base system with pkg(8)
Yes, you are right it misses the media change handler in devd.conf. maybe it should bementioned somewhere in a man page if it is not already there. Thanks for the pointer. Anyway, if I would have written the system, what I would have done is to consolidate both user mode daemons into one and make this daemon a client of devd, fstyp a library, and handle all removable media inside transparent to the user, without requiring any modifications to devd.conf, and without relaying on shell scripts. Is there any reason you did not took this approach ? This is not criticism, I am genuinely interested. > and simply > retrofit the changes back to autofs - but that hasn't happened (yet). Please consider doing it. A kevent on /media would allow other programs to see how volumes come and go, and I can imagine several situations where this can be handy. And too many directories left there do become annoying. > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała wrote: > > On 0421T1526, Dan Partelly wrote: >> The scenario is: >> >> Let’s say I have autofs_enable , working with media map. >> >> If I have a CD in CD drive , all is well and when the system is fully booted >> up >> /media contains a directory through which I can access the content of the >> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. >> /media does not contain a new access point for the new disk inserted in the >> device. >> >> What I would expect is when I change the media in Cd-rom , a new >> access point for the volume in question should be reated in /media. >> >> Perhaps this functionality is exposed differently by the automounter, >> but them I would not expect the CDrom to be accessible at all though the >> media map. > > If by "access point" you mean the directory, then it will, unless the CD > doesn't have a label - in that case the device name will be used instead, > and since it's the same device, it will be the same name - usually "cd0". > > However - I've just checked to make sure and it works the way it should. > What you're decribing seems like you're missing the part of devd.conf(5) > responsible for notifying autofs about media change. Do you? > >>> he problem here is that it's quite hard to fix, there's a risk >>> of breaking existing functionality, and the problem is largely cosmetic. >> >> until you have more than 10 of them there, when it largely annoying. >> anyway, what is the reason it is very hard to fix and it would break existing >> functionality. can you please shed some light ? > > Basically, the autofs doesn't support removing the nodes. It wasn't > really required for the usual use case, and it simplified the code a lot. > Plan was to pick it up again with my next filesystem project, and simply > retrofit the changes back to autofs - but that hasn't happened (yet). > > [..] ___ 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"
[Solved] [WAS:libc build error] Mostly all solved bw-iw-ik from 4-20-2016
On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" wrote: > > > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" > wrote: > > > > > > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude > > wrote: > > > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > > unistd > > > > > > > > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected > > > > function body after function declarator > > > > intexecl( . > > > > 332:46: > > > > same... > > > > > > > > stops libc > > > > otherwise clang36 seems to be building so far, if it builds unsure > > > > about installworld > > > > ___ > > > > 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" > > > > > > > > > > The mailing list strips attachments. Can you upload it somewhere and > > > provide a link > > > > > > -- > > > Allan Jude > > > ___ > > > 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" > > > > > > Well, it is now r298350 Wed Apr 20... > > However several problems > > > > SINGLE-USER BOOT PROBLEMS > > 1... usual boot fails, this is single-user adjusted, but I cannot add swap > > (swapon? swapctl?) > > 1a... the last time, it was fixed with using the old /kernel ... > > > > multi-user boot problems > > > > 2... the last usual boot dumped with vm_pager or something, verbose boot > > times out with xpt_config not completing. > > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet > > updated (which it now is ) for the latter > > case I have yet to reboot to test > > 2b... Reboot to test takes longer, /rescue/mount each filesystem > > individually... > > > > > > As one might surmise, I'd rather see buildworld made more foolproof than > > other recent improvements > > (pkg, zfs, ...) > > From backup, I have r288246 kernel and nvidia.ko (v11) > from source, I have world and all except those TWO files at r298350 )(v11), > nvidia (newer) won't load with older kernel > A few at-boot scripts no longer work as expected... but no other major > problems (swap is present again) > (multi-user boot works) > > Best practice maybe to update the kernel? It is a custom one from way back > in 2004 initially > without sound drivers and without debug symbols... and many esoteric lines > added which I cobbled > together at first then changed per diffs of GENERIC over the years... > > Thanks for any known methods > > J. Bouquet > ___ > 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" Updated to a slightly-less-than-full GENERIC. Still dumped core. Moved loader.conf out of the way, works fine. What will take some time now is moving loader.conf back piece by piece [until/if there is/ever was a utility to do it for us... ] to find the problematic line or two, then resume testing of the install of the custom kernel that also is 'fail' status at this point... unless/until I decide to also test it, THEN resume the loader.conf line-by-line back in... tl;dr loader.conf problematic line and maybe an additional unknown in either kernel text file. ___ 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 0421T1526, Dan Partelly wrote: > The scenario is: > > Let’s say I have autofs_enable , working with media map. > > If I have a CD in CD drive , all is well and when the system is fully booted > up > /media contains a directory through which I can access the content of the > CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. > /media does not contain a new access point for the new disk inserted in the > device. > > What I would expect is when I change the media in Cd-rom , a new > access point for the volume in question should be reated in /media. > > Perhaps this functionality is exposed differently by the automounter, > but them I would not expect the CDrom to be accessible at all though the > media map. If by "access point" you mean the directory, then it will, unless the CD doesn't have a label - in that case the device name will be used instead, and since it's the same device, it will be the same name - usually "cd0". However - I've just checked to make sure and it works the way it should. What you're decribing seems like you're missing the part of devd.conf(5) responsible for notifying autofs about media change. Do you? > > he problem here is that it's quite hard to fix, there's a risk > > of breaking existing functionality, and the problem is largely cosmetic. > > until you have more than 10 of them there, when it largely annoying. > anyway, what is the reason it is very hard to fix and it would break existing > functionality. can you please shed some light ? Basically, the autofs doesn't support removing the nodes. It wasn't really required for the usual use case, and it simplified the code a lot. Plan was to pick it up again with my next filesystem project, and simply retrofit the changes back to autofs - but that hasn't happened (yet). [..] ___ 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: extremely slow to get to loader
On 2016-04-21 10:46, Johannes Dieterich wrote: > Dear all, > > with r298385, I observe extremely long times from turning on my laptop > to reach loader. This is a regression compared to a roughly 1 week old > CURRENT. > > This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup. > > Please let me know how I can help to solve this issue. > > Thanks, > > Johannes > ___ > 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" > Can you describe where exactly it is slow? Once you get to the loader menu (the beastie menu), can you choose the option to go to the loader prompt, and type: bcachestat And provide the output of that. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: CFR: extend use of nitems() macro in the kernel.
On 04/18/16 13:27, John Baldwin wrote: On Saturday, April 16, 2016 01:25:09 PM Pedro Giffuni wrote: Hello; Using coccinelle, and some hand re-formatting, I generated a patch to make use of the nitems() macro in sys, which is too big for phabricator [1]. I was careful to exclude anything from the contrib directory or any code that is shared with userland (as to not have to include additional headers). The patch is big but pretty safe, I think. The changes are small but still it touches many files[1]. I would like some feedback on the convenience of doing such replacement. If it is a good idea we could do the same for roundup2() and, in fact, I think DragonFly has already done this. Regards, Pedro. [1] https://people.freebsd.org/~pfg/patches/sys-nitems.diff [2] For those too lazy to check [1], here is a list of affected files. M sys/amd64/amd64/amd64_mem.c M sys/amd64/amd64/machdep.c M sys/amd64/linux/linux_sysvec.c M sys/amd64/linux32/linux32_sysvec.c M sys/arm/amlogic/aml8726/aml8726_clkmsr.c M sys/arm/arm/db_interface.c M sys/arm/at91/at91_pmc.c M sys/arm/mv/armadaxp/armadaxp.c M sys/arm/ti/cpsw/if_cpsw.c M sys/arm/xscale/ixp425/ixp425.c M sys/boot/common/part.c M sys/boot/efi/loader/bootinfo.c M sys/boot/mips/beri/boot2/boot2.c M sys/boot/uboot/common/metadata.c M sys/cam/ata/ata_da.c M sys/cam/ata/ata_xpt.c I would perhaps remove ata_quirk_table_size entirely and replace its use with nitems() directly. Probably best if that was a separate commit though from the near-mechanical replacement. M sys/cam/cam.c Same here. num_cam_status_entries is only used in one place and I think directly using nitems() is probably clearer overall. M sys/cam/scsi/scsi_all.c Possibly the same here with sense_key_table_size. M sys/cam/scsi/scsi_cd.c M sys/cam/scsi/scsi_da.c M sys/cam/scsi/scsi_sa.c M sys/cam/scsi/scsi_xpt.c Same as for ata_quirk_table_size (ironically this used the size in one place and the expanded form of nitems in another while the ata variant at least used the size in both places). M sys/cam/scsi/smp_all.c M sys/compat/linux/linux_socket.c M sys/ddb/db_variables.c M sys/dev/adb/adb_kbd.c M sys/dev/advansys/adv_isa.c M sys/dev/advansys/advlib.c M sys/dev/advansys/adw_pci.c Same here for num adw_num_pci_devs (only used once) M sys/dev/advansys/adwlib.c Probably the same here for adw_num_sync_rates (used twice). M sys/dev/ae/if_ae.c Same here for AE_DEVS_COUNT (only used once). M sys/dev/age/if_age.c M sys/dev/agp/agp.c M sys/dev/agp/agp_ali.c M sys/dev/agp/agp_amd64.c M sys/dev/aha/aha_isa.c M sys/dev/aic/aic.c M sys/dev/aic/aic_cbus.c Same here for AIC_ISA_NUMPORTS (only used once). M sys/dev/aic/aic_isa.c As above. M sys/dev/ale/if_ale.c M sys/dev/altera/atse/if_atse.c M sys/dev/atkbdc/atkbd.c M sys/dev/atkbdc/atkbdc.c M sys/dev/atkbdc/psm.c M sys/dev/bktr/bktr_core.c M sys/dev/bwi/bwirf.c M sys/dev/bwn/if_bwn.c M sys/dev/cardbus/cardbus_cis.c M sys/dev/digi/digi.c M sys/dev/digi/digi_isa.c M sys/dev/dwc/if_dwc.c M sys/dev/ed/if_ed_hpp.c M sys/dev/ed/if_ed_isa.c M sys/dev/ed/if_ed_pci.c M sys/dev/fb/creator.c Same here for CREATOR_FB_MAP_SIZE (only used once). M sys/dev/fb/fb.c M sys/dev/fb/machfb.c M sys/dev/fb/vesa.c M sys/dev/fb/vga.c M sys/dev/flash/mx25l.c M sys/dev/hatm/if_hatm.c M sys/dev/hifn/hifn7751.c M sys/dev/hwpmc/hwpmc_amd.c Same here for amd_event_codes_size (only used twice). M sys/dev/hwpmc/hwpmc_core.c Same here for niap_events. M sys/dev/hwpmc/hwpmc_e500.c e500_event_codes_size isn't even used. It should just be removed. M sys/dev/hwpmc/hwpmc_mips24k.c M sys/dev/hwpmc/hwpmc_mips74k.c M sys/dev/hwpmc/hwpmc_mpc7xxx.c Same here for mpc7xxx_event_codes_size. M sys/dev/hwpmc/hwpmc_octeon.c M sys/dev/hwpmc/hwpmc_uncore.c Same here for nucp_events. M sys/dev/hwpmc/hwpmc_xscale.c Same here for xscale_event_codes_size. M sys/dev/if_ndis/if_ndis.c M sys/dev/jme/if_jme.c M sys/dev/kbd/kbd.c M sys/dev/le/if_le_isa.c M sys/dev/le/if_le_lebuffer.c Same here for NLEMEDIA (only used once). M sys/dev/le/if_le_ledma.c M sys/dev/mlx/mlx.c M sys/dev/mxge/if_mxge.c M sys/dev/nand/nand_id.c M sys/dev/ncr/ncr.c M sys/dev/nctgpio/nctgpio.c M sys/dev/nfe/if_nfe.c M sys/dev/patm/if_patm_attach.c M sys/dev/pccard/pccard_cis_quirks.c Same here for n_pccard_cis_quirks (only used once). M sys/dev/rc/rc.c M sys/dev/re/if_re.c M sys/dev/rl/if_rl.c M sys/dev/rndtest/rndtest.c Same here for RNDTEST_NTESTS (
some mtree missing in buildworld
Hi current@ There seems some invocation of mtree missing in make buildworld, & also an undefined reference to `_libmd* I detected it upgrading a year old current to today's current: -- uname -a FreeBSD blak.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #11881: Sun Mar 22 19:23:17 CET 2015 j...@blak.js.berklix.net:/usr/src/sys/amd64/compile/BLAK.small amd64 rm -rf /usr/src mkdir /usr/src cd /usr/src ctm -q /pub/FreeBSD/development/CTM/src-cur/src-cur.12300xEmpty.gz ctm -q /pub/FreeBSD/development/CTM/src-cur/src-*.1[0-9][0-9][0-9][0-9].gz cat .ctm* src-cur 12446 # That's todays latest cat .svn_revision 298360 /etc/src.conf is an empty file ie all commented out make obj make buildworld cc -O2 -pipe -DBERKLIX=YES -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -DDEBUGDIR=\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/kgdb/../arch/amd64 -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/amd64 -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../../lib/libreadline/readline/.. -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-loca! l-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o kgdb.full main.o kld.o kthr.o trgt.o trgt_amd64.o /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../gdb/libgdb/libgdb.a /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/libbfd.a /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libopcodes/libopcodes.a /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libiberty/libiberty.a -lm -L/usr/obj/usr/src/gnu/lib/libreadline/readline -L/usr/obj/usr/src/gnu/lib/libreadline/readline -lreadline -lncursesw -lncursesw -lncursesw -lgnuregex -lkvm main.o: In function `main': /usr/src/gnu/usr.bin/gdb/kgdb/main.c:478: undefined reference to `kgdb_trgt_pc_fixup' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[6]: stopped in /usr/src/gnu/usr.bin/gdb/kgdb make includes Various breakages repaired by my subsequent manual mkdir eg mkdir -p /usr/include/private/bsdstat make includes ===> lib/libcasper/services (includes) ===> lib/libcasper/services/cap_dns (includes) install -C -o root -g wheel -m 444 /usr/src/lib/libcasper/services/cap_dns/cap_dns.h /usr/include/casper/ install: /usr/include/casper/: No such file or directory *** Error code 71 cd /usr/src/etc/mtree make install cd /etc/mtree vi -c/casper BSD.include.dist cd /usr/src make _worldtmp cd /usr/obj/usr/src/tmp tar cf - . | ( cd / && tar xf - ) ls -la /usr/include/casper total 12 drwxr-xr-x 2 root wheel 512 Apr 21 17:08 ./ drwxr-xr-x 60 root wheel 6656 Apr 21 17:09 ../ cd /usr/src make includes cd /usr/src/gnu/usr.bin/gdb/kgdb ; make Runs for a while cd /usr/src/gnu/usr.bin/gdb/; make Runs for a while make upgrade_checks make buildworld cc -O2 -pipe -DBERKLIX=YES -I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o xinstall.full xinstall.o getid.o -lmd -legacy xinstall.o: In function `digest_init': /usr/src/usr.bin/xinstall/xinstall.c:414: undefined reference to `_libmd_MD5Init' ... /usr/src/usr.bin/xinstall/xinstall.c:470: undefined reference to `_libmd_SHA512_End' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[3]: stopped in /usr/src/usr.bin/xinstall cd /usr/src/lib/libmd ; make ; make install cd /usr/src/usr.bin/xinstall ; make ; make install cd /usr/src; make buildworld Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/ Mail plain text, No quoted-printable, HTML, base64, MS.doc. Prefix old lines '> ' Reply below old, like play script. Break lines by 80. Let Brits in EU vote on Brexit https://petition.parliament.uk/petitions/112142 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
extremely slow to get to loader
Dear all, with r298385, I observe extremely long times from turning on my laptop to reach loader. This is a regression compared to a roughly 1 week old CURRENT. This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup. Please let me know how I can help to solve this issue. Thanks, Johannes ___ 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)
The scenario is: Let’s say I have autofs_enable , working with media map. If I have a CD in CD drive , all is well and when the system is fully booted up /media contains a directory through which I can access the content of the CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. /media does not contain a new access point for the new disk inserted in the device. What I would expect is when I change the media in Cd-rom , a new access point for the volume in question should be reated in /media. Perhaps this functionality is exposed differently by the automounter, but them I would not expect the CDrom to be accessible at all though the media map. > he problem here is that it's quite hard to fix, there's a risk > of breaking existing functionality, and the problem is largely cosmetic. until you have more than 10 of them there, when it largely annoying. anyway, what is the reason it is very hard to fix and it would break existing functionality. can you please shed some light ? > Huh, never heard about that. I'd expect the existing mechanism to handle > that case just fine. Could you submit a PR? > On 21 Apr 2016, at 12:57, Edward Tomasz Napierała wrote: > > On 0420T1545, dan_partelly wrote: > > [..] > >> Another example is the autofs mounter. The prject was marked as complete >> by FreeBSD foundation in 2014. Last I tried it to autmount removable >> devices, it left directory after directory in the autofs managed directory. >> This is known behavior. > > Yup. The problem here is that it's quite hard to fix, there's a risk > of breaking existing functionality, and the problem is largely cosmetic. > >> It also did not worked as it should ??? (show it >> manage removable media correctly ) changing CD/DVD media disks. Presumably >> In could have somehow manage it to work by making yet another scaffolding >> of scripts as a questionable glue between devd and automounters. That if >> devd receives media change notifications. I dont know. If not I could patch >> the kernel, yeah. But it is just much to simple to not bother at all and >> use OSx. > > Huh, never heard about that. I'd expect the existing mechanism to handle > that case just fine. Could you submit a PR? > > [..] > > ___ > 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: limits: setrlimit umtxp: Invalid argument
On Thu, 10 Mar 2016 07:16:05 +0900, Brendan Sechter wrote: > > Subject: Re: limits: setrlimit umtxp: Invalid argument > > From: florian.ermi...@alumni.tu-berlin.de > > Date: Wed, 9 Mar 2016 18:45:37 +0100 > > To: e...@vangyzen.net; sg...@hotmail.com; freebsd-current@freebsd.org > > > > Am 9. März 2016 16:59:47 MEZ, schrieb Eric van Gyzen : > >> On 03/09/2016 09:49, Brendan Sechter wrote: > >>> I am running an 11.0-CURRENT VM. > >>> After recently updating, the following appears on startup and > >>> dhclient fails to start. > >>> > >>> Starting dhclient. > >>> limits: setrlimit umtxp: Invalid argument > >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient > >>> > >>> Similar messages appear for the following. > >>> > >>> devd pflog syslogd ntpd powerd sshd sendmail_submit > >>> sendmail_msp_queue cron > >>> > >>> Reverting to the previous kernel did not resolve the issue. > >>> I can manually start dhclient and ntp, but not sshd. > >>> > >>> I do not trust that my uname information is being updated with > >>> with build, but here it is. > >>> > >>> $ uname -vm > >>> FreeBSD 11.0-CURRENT #0 r287598: Thu Sep 10 14:45:48 JST 2015 > >>> root@:/usr/obj/usr/src/sys/MIRAGE_KERNEL amd64 > >> > >> This information comes directly from the running kernel, so it looks > >> like your kernel is not getting updated. This seems consistent > >> with the above error messages, although I haven't tested this > >> case. The userland tools are aware of the newly added umtxp > >> limit, but the kernel is not aware. > >> > >> Eric > > > > I got this problem on my laptop, too. I somehow managed not to > > install the kernel during a recent update so my userland is slightly > > newer than my 11-CURRENT r292755 kernel (and also forgot to > > make proper ZFS snapshots…). > > > > While I can build a newer kernel but when I boot i.e. r296556 > > `zfs(8)' coredumps and I can't mount anything but the rootfs… > > I guess I need to get kernel & userland back in sync to fix this. > > > > I will try to build the userland matching my kernel first as > > I know its revision from `uname -a`. > > If anyone has a better approach or tips, please let me know. > > My userland was up to date. This is what I did to get the kernel > in sync enough to resolve the issue. > > svn up /usr/src # omit if want to use the exact same version as world > cd /usr/src > make buildkernel KERNCONF=MYKERNEL > make installkernel KERNCONF=MYKERNEL > > I found a problem with my kernel configuration in the process. > The plan is to rebuild everything after the configuration issue is > sorted out. You may wish to use GENERIC just to get things up > and running again. > > Regards, > -Brendan > ___ > 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" I've a working pf.ko kernel and nvidia.ko from r288246 Sep 26 2015 and an installed buildworld from yesterday Apr 20 2016. The kernel is custom and I've also a large-ish loader.conf. I've no wish to run GENERIC with either debugging symbols nor sound enabled. sendmail_submit is broken, not a showstopper but root gets none of his mail. cron is broken, not a showstopper but one cron I've setup does not run Per this thread which narrowed down the issue of out of sync problems, dhclient devd pflog syslogd ntpd and sshd *if I had them used* would be not functional. Unsure in each case. Given a 2004-ish custom kernel, a GENERIC from this month, and a GENERIC from Sept 2015, is there any not time consuming way to do a diff between two or three of them and bring the custom kernel upto par with the GENERIC as far as bootability, considering the possibility that it is a loader.conf setting that is at fault? something like /sbin/kernel-too-old ^^^ " please check foo foo from loader conf " or "please check bar bar from CUSTOM-K " or even " foo bar from CUSTOM-K is missing... " ...a utility that would lessen the need for adding/subtracting blocks of (custom ) kernel stuff to/from generic and recompiling one-by-one, or vice-versa, to/from the custom kernel config, seems like a 40 day project UNLESS someone has run into a similar custom -vs- generic situation as a matter of course and has a workflow to lessen whatever time and compilation effort it takes, which is basically what I am asking here unless a summer of code expert coder of FreeBSD fame knows that the hypothetical binary above could be crafted more easily than not and be a tool for developers as well as simple FreeBSD users such as myself... Thanks PS I encourage anyone with a readily helpful answer to add it to UPDATING as a resource for persons other than myself who encounter the same difficulty... ___ freebsd-current@freebsd.org mailing li
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Mark Linimon changed: What|Removed |Added Keywords||patch -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 0420T1545, dan_partelly wrote: [..] > Another example is the autofs mounter. The prject was marked as complete > by FreeBSD foundation in 2014. Last I tried it to autmount removable > devices, it left directory after directory in the autofs managed directory. > This is known behavior. Yup. The problem here is that it's quite hard to fix, there's a risk of breaking existing functionality, and the problem is largely cosmetic. > It also did not worked as it should ??? (show it > manage removable media correctly ) changing CD/DVD media disks. Presumably > In could have somehow manage it to work by making yet another scaffolding > of scripts as a questionable glue between devd and automounters. That if > devd receives media change notifications. I dont know. If not I could patch > the kernel, yeah. But it is just much to simple to not bother at all and > use OSx. Huh, never heard about that. I'd expect the existing mechanism to handle that case just fine. Could you submit a PR? [..] ___ 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: OCZ ssdpx-1rvd0120 REVODRIVE support
> > > HI! I've recently got a SSD device. Yes, not a disk, but a device. > > > It's called, i. e. one of the first REVODRIVEs. > > > It's a PCI-express card with two embedded ssd disks about ~ 55GB size. > > > And it's a raid card. Fake software raid. You can set it up as a > > > RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured > > > or set it as JBOD or something else. > > > You just won't be able to boot from this device in that case. I used to have one of these in my workstation (mine was recognized as 4 SATA drives of about 60GB). I had put these into a zfs pool with raidz1 and was able to boot from the card without any issue. BIOS reported them as 4 individual drives. These are pre-NVME, so no NVME driver was necessary. Unfortunately, the card recently died of old age, so I can't provide any more than historic references. The type was OCZSSDPX-1RVDX0240 . Cheers, Markus ___ 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"