Re: FreeBSD-13.0-RC1-amd64-disc1.iso unbootable on memstick
Hi. Are you shure you're using *.memstick.img? *.iso are for optical drives. If your memstick can perfectly (or at least enough for CD loader and kernel) mimic optical drive, maybe with help by firmware, it would be able to boot. Otherwise, you should write FreeBSD-13.0-RC1-*-memstick.img with dd. If you are using enough-sized memstick and amd64 arch PC, FreeBSD-13.0-RC1-amd64-mrmstick.img should be preferred. Note that if you downloaded smaller xz compressed image, you shoule decompress it before writing. If you are using *-memstick.img, something should need fixed. On Sun, 7 Mar 2021 01:06:14 -0800 (PST) "Rodney W. Grimes" wrote: > Glen, > Things get worse... I could at least boot the BETA4 .iso when > I wrote it to a memstick. I can NOT boot the RC1. I have checked > the sha512 of my image, wrote it twice, same results, I get: > > CD Loader 1.2 > > Bulding the boot loader arguments > Looking up /BOOT/LOADER... File not found > Looking up /boot/loader... File not found > Boot failed > > I have tried 2 different systems, all known to have booted and > installed many many many FreeBSD's from prior .iso written to > memstick. > > Regards, > -- > Rod Grimes rgri...@freebsd.org > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: what 3rd party boot mgr is required to boot multiple freebsd versions?
On Tue, 17 Mar 2020 01:31:59 +0300 Andrey Fesenko wrote: > On Tue, Mar 17, 2020 at 1:24 AM Chris wrote: > > > > I'm attempting to boot multiple versions of FreeBSD. > > I started with an install of older 11 with a (u)efi > > boot partition installed. I then grabbed an current 11 > > usbstick, and installed that. Which stated it needed to > > install a (u)efi boot partition. I let it do it. But the > > new (additional) install doesn't show up at boot. Altho > > my UEFI BIOS sees it. > > I guess there are just too many uefi bios versions, > > and too many changes in the FreeBSD uefi boot code > > to expect consistent results over the long haul. > > Should I just convert the 1st efi (GPT) boot partition > > to a PMBR, and delete the second efi partition. Or is > > there a recommended bootmanager I can use to boot multiple > > versions of FreeBSD? Windows? > > > > upgrade system and use > https://www.freebsd.org/cgi/man.cgi?query=efibootmgr&sektion=8&manpath=freebsd-release-ports > ;) > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Or if you want boot-time selection, try the patch proposed on Bug 207940 [1]. efibootmgr can be used only for "next boot and later", IIUC. The latest patch is for head and stable/12. Applicable on top of /usr/src. Patch for stable/11 is NOT tested / maintained for more than one year, so possibly doesn't apply / work anymore. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error building stable/12 (amd64) at r355087
r347836 (not MFC'ed) on head eliminates inclusion of machine/bus.h for usr.sbin/camdd/camdd.c. This whole commit introduces some bool functions, but head builds fine. I'm not shure applying camdd.c part alone is OK, so cherry-picked this revision excluding sys/compat/linuxkpi/common/src/linux_pci.c part and it fixes build. Not yet tested r355089, though. On Mon, 25 Nov 2019 16:21:41 +0200 Konstantin Belousov wrote: > On Mon, Nov 25, 2019 at 03:58:10AM -0800, David Wolfskill wrote: > > This is during a source-based update from r355048 to r355087, during > > "stage 4.3: building everything" (using META_MODE); meta file reads: > > > > # Meta data file > > /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd/camdd.o.meta > > CMD cc -target x86_64-unknown-freebsd12.1 > > --sysroot=/common/S3/obj/usr/src/amd64.amd64/tmp > > -B/common/S3/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -std=gnu99 > > -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign > > -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int > > -Wno-unused-const-variable -Qunused-arguments -c > > /usr/src/usr.sbin/camdd/camdd.c -o camdd.o > > CMD > > CWD /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd > > TARGET camdd.o > > -- command output -- > > In file included from /usr/src/usr.sbin/camdd/camdd.c:54: > > In file included from > > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus.h:6: > > In file included from > > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus.h:1043: > > In file included from > > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus_dma.h:34: > > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:1: > > error: unknown type name 'bool' > > bool bus_dma_dmar_set_buswide(device_t dev); > > ^ > > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:31: > > error: unknown type name 'device_t' > > bool bus_dma_dmar_set_buswide(device_t dev); > > ^ > > 2 errors generated. > > > > *** Error code 1 > > I hope that this is fixed by r355089. I did not tracked down how HEAD > was immune to the problem. > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS root mount regression
Hi. Maybe different problem (as mav@ noted) with Garrett's but related to parallel-mounting. *For Garrett's problem, +1 with Trond. For myself, I incorporate drive type and No. in pool name to avoid collision between 2 physical drives (one working, and one emergency) in the same host. After ZFS parallel mounting is committed (both head and stable/12), auto-mounting from manually-imported non-root pool(s) looks racy and usually fails (some datasets are shown as mounted, but not accessible until manual unmount/remount is proceeded). *I'm experiencing the problem when I import another root pool by `zpool import -R /mnt -f poolname`. Patch from ZoL on bug 237517 [1] seems to fix the parallel mounting race. (Named ZoL fix by fullermd.) As it seemed to be race condition, I'm not 100% shure the patch is really correct. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237517 On Sun, 21 Jul 2019 17:41:59 -0400 Alexander Motin wrote: > Hi, > > I am not sure how the original description leads to conclusion that > problem is related to parallel mounting. From my point of view it > sounds like a problem that root pool mounting happens based on name, not > pool GUID that needs to be passed from the loader. We have seen problem > like that ourselves too when boot pool names collide. So I doubt it is > a new problem, just nobody got to fixing it yet. > > On 20.07.2019 06:41, Eugene Grosbein wrote: > > CC'ing Alexander Motin who comitted the change. > > > > 20.07.2019 1:21, Garrett Wollman wrote: > > > >> I recently upgraded several file servers from 11.2 to 11.3. All of > >> them boot from a ZFS pool called "tank" (the data is in a different > >> pool). In a couple of instances (which caused me to have to take a > >> late-evening 140-mile drive to the remote data center where they are > >> located), the servers crashed at the root mount phase. In one case, > >> it bailed out with error 5 (I believe that's [EIO]) to the usual > >> mountroot prompt. In the second case, the kernel panicked instead. > >> > >> The root cause (no pun intended) on both servers was a disk which was > >> supplied by the vendor with a label on it that claimed to be part of > >> the "tank" pool, and for some reason the 11.3 kernel was trying to > >> mount that (faulted) pool rather than the real one. The disks and > >> pool configuration were unchanged from 11.2 (and probably 11.1 as > >> well) so I am puzzled. > >> > >> Other than laboriously running "zpool labelclear -f /dev/somedisk" for > >> every piece of media that comes into my hands, is there anything else > >> I could have done to avoid this? > > > > Both 11.3-RELEASE announcement and Release Notes mention this: > > > >> The ZFS filesystem has been updated to implement parallel mounting. > > > > I strongly suggest reading Release documentation in case of troubles > > after upgrade, at least. Or better, read *before* updating. > > > > I guess this parallelism created some race for your case. > > > > Unfortunately, a way to fall back to sequential mounting seems undocumented. > > libzfs checks for ZFS_SERIAL_MOUNT environment variable to exist having any > > value. > > I'm not sure how you set it for mounting root, maybe it will use kenv, > > so try adding to /boot/loader.conf: > > > > ZFS_SERIAL_MOUNT=1 > > > > Alexander should have more knowledge on this. > > > > And of course, attaching unrelated device having label conflicting > > with root pool is asking for trouble. Re-label it ASAP. > > > > -- > Alexander Motin > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot
On Wed, 28 Nov 2018 19:39:21 +0100 "O. Hartmann" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Wed, 28 Nov 2018 15:00:42 +0100 > Emmanuel Vadot schrieb: > > > Hi, > > > > On Wed, 28 Nov 2018 10:51:11 +0100 > > "O. Hartmann" wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware is > > > latest, r1.22 > > > from 2013). The E751 is of model series S26391-K326-V100 and equipted > > > with a Core > > > i5-2520M CPU and supposed to be also equipted with a iGPU HM65 according > > > to the > > > techniscal specifications from Fujitsu. > > > > > > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent I > > > could grap > > > from the download page), the screen becomes distorted immediately after > > > the kernel has > > > loaded and initialised/booted. The screen is at the loader's all right so > > > far. > > > > > > Trying to disable graphics mode via escaping to the loader's prompt and > > > setting > > > > > > set hw.vga.textmode=1 > > > > > > subsequently loading the kernel and then booting, doesn't help. The > > > screen is > > > distorted again. The notebook seems UEFI only and doesn't boot off from > > > MBR partioned > > > devices (i.e. NanoBSD I used to use). > > > > > > Loading /boot/kernel/i915kms.ko > > > > > > after manually having loaded /boot/kernel/kernel (and not booted yet) > > > doesn't change > > > anything either. > > > > > > Booting off and installing Linux (Ubuntu, Mint so far, most revent > > > verions I can get > > > my hands on) is no problem. The console works fine from the beginning and > > > so the > > > graphics. > > > > > > Is there a chance to get a FreeBSD booting the easy way? > > > > > > The provided boot images do not contain any of the > > > graphics/drm-stable|next|legacy-kmod stuff, I tried to load i915kms.ko off > > > from /boot/modules/ (were those modules from the ports are supposed to > > > reside) but no > > > chance. > > > > > > Before starting investigating this issue further I'd like to ask wether > > > there is a > > > general support provided or is that type of notebook dead matter for > > > FreeBSD of the > > > modern kind? > > > > > > Thanks in advance, > > > > > > oh > > > > > > p.s. please CC me, I'm not subscribing all lists. > > > > > > - -- > > > O. Hartmann > > > -BEGIN PGP SIGNATURE- > > > > > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY > > > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP > > > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf > > > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg > > > =XD7b > > > -END PGP SIGNATURE- > > > > Could you post a picture somewhere ? > > > > I have a laptop which have efifb problem, what I need to do is (at > > loader prompt) : > > > > gop set 4 (to switch to a different mode) > > gop set 0 (switch to the correct mode) > > > > You can gop list (iirc) to checks the available mode. > > > > The problem is that we are mixing serial and gop in loader.efi and > > when you set one mode in serial (or for SIMPLE_TEXT_PROTOCOL) is can > > mess the graphical mode. > > > > Sorry, I have no upload place to put some screenshots. > > The natural resolution of the display is 1280x800 pixel. > > When existing to the loader and issuing as recommended the command "gop > list", I get > three modes: > > mode 0: 1024x768x32, stride=1024 > mode 1: 640x480x32, stride=640 > mode 2: 800x600x32, stride=800 > > Setting mode 1 and 2 via gop set X solves the problem and the screen is, at > least during > a live session of the latest 12-PRE USB image, readable and looking normal. > > As soon as I have an installation media, I'll check whether the screen is > operable after > installation (and, of course, loader settings as required), or not. Hi. So you can try efi_max_resolution="800x600" or efi_max_resolution="640x480" in /etc/loader.conf. Se
Re: 12-STABLE uname -a misses timestamp of the build
WITHOUT_REPRODUCIBLE_BUILD should be default for now on stable/12, as releng/12.0 already branched. As I already proposed on -current ML, REPRODUCIBLE_BUILD should be enabled only for release/* and releng/*. https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071151.html I didn't noticed as I have WITHOUT_REPRODUCIBLE_BUILD=yes in src.conf. On Sat, 24 Nov 2018 15:13:15 +0300 Yuri Pankov wrote: > Jakub Lach wrote: > > Is there a way to restore it? I liked the old behaviour better, it was > > useful > > info for me. > > See 20180913 in UPDATING and WITHOUT_REPRODUCIBLE_BUILD in src.conf(5). > -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted
Hi. Booted as expected on ThinkPad T420. Fixed with descrete (nvidia) GPU, CPU internal GPU is disabled. Both UEFI and Legacy (CSM) boot are enabled. UEFI first : Boot on UEFI mode. [Confirmed efifb is used.] Legecy first: Boot on CSM mode. [Confirmed vt(vga) is used.] UEFI boot is much faster than legacy (CSM) boot. Is firmware version needed? On Wed, 30 May 2018 15:50:39 + Glen Barber wrote: > Hi, > > Could folks please help boot-test the most recent 12.0-CURRENT amd64 > memstick images on various hardware? Note, this is not a request to > install 12.0-CURRENT, only a boot-test with various system knobs > tweaked. > > The most recent images are available at: > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we > would like to get this included in the upcoming 11.2-RELEASE if the > change that had been committed addresses several boot issues reported > recently. > > Please help test, and report back (both successes and failures). > > Thanks, > > Glen > -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: r334229 breaks build kernel
Looks simple mis-merge. On hunk 1, original (head) r323831 has "hz / isc->quanta" at 2nd arg, while r334229 (stable/11) has "hz / isc->quanta1". r334228 and before had "hz / isc->quanta - 1", so missingly removed " - " instead of " - 1". Any other hunks looks fine. Regards. On Sat, 26 May 2018 10:37:34 -0600 Warner Losh wrote: > Looks like sean's merge was incomplete somehow. > > Warner > > On Sat, May 26, 2018 at 9:02 AM, Dmitriy Makarov wrote: > > > Hi, > > > > probably this last changes https://svnweb.freebsd.org/ > > base?view=revision&revision=334229 breaks buildkernel in stable/11 > > > > If it is related my kernel config contains IOSCHED option: > > options CAM_IOSCHED_DYNAMIC > > > > > > cc -target x86_64-unknown-freebsd11.2 --sysroot=/usr/obj/usr/src/tmp > > -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -g > > -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL > > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer > > -mno-omit-leaf-frame-pointer -MD -MF.depend.cam_iosched.o -MTcam_iosched.o > > -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > > -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > > -fdiagnostics-show-option -Wno-unknown-pragmas > > -Wno-error-tautological-compare > > -Wno-error-empty-body -Wno-error-parentheses-equality > > -Wno-error-unused-function -Wno-error-pointer-sign > > -Wno-error-shift-negative-value -Wno-error-address-of-packed-member > > -mno-aes -mno-avx -std=iso9899:1999 -W > > error /usr/src/sys/cam/cam_iosched.c > > > > /usr/src/sys/cam/cam_iosched.c:513:40: error: no member named 'quanta1' > > in 'struct cam_iosched_softc'; did you mean 'quanta'? > > callout_reset(&isc->ticker, hz / isc->quanta1, cam_iosched_ticker, > > isc); > > ^~~ > > quanta > > /usr/src/sys/sys/callout.h:115:28: note: expanded from macro > > 'callout_reset' > > callout_reset_on((c), (on_tick), (fn), (arg), -1) > >^ > > /usr/src/sys/sys/callout.h:112:43: note: expanded from macro > > 'callout_reset_on' > > callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),\ > > ^ > > /usr/src/sys/cam/cam_iosched.c:267:7: note: 'quanta' declared here > > int quanta; /* Number of quanta per > > second */ > > ^ > > 1 error generated. > > ___ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- 青木 知明 [Tomoaki AOKI] Date: Sun May 27 03:55:00 2018 Log: Fix mis-merge on r334229. On r323831, 2nd param is "hz / isc->quanta", not "hz / isc->quanta1". Modified: stable/11/sys/cam/cam_iosched.c Modified: stable/11/sys/cam/cam_iosched.c == --- stable/11/sys/cam/cam_iosched.c Fri May 25 23:18:06 2018 (r334229) +++ stable/11/sys/cam/cam_iosched.c Fri May 27 03:55:00 2018 (Working Copy) @@ -510,7 +510,7 @@ cam_iosched_ticker(void *arg) struct cam_iosched_softc *isc = arg; sbintime_t now, delta; - callout_reset(&isc->ticker, hz / isc->quanta1, cam_iosched_ticker, isc); + callout_reset(&isc->ticker, hz / isc->quanta, cam_iosched_ticker, isc); now = sbinuptime(); delta = now - isc->last_time;___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: build kernel failure stable11 iwi related
Would be broken by r330233. This revision assumes member c_pktflags in struct ieee80211_rx_stats, but this addition (done at r306837 on head) is NOT yet MFC'ed. Reverting r330233 allowed me build, install and boot kernel. *I'm not shure MFC'ing r306837 is sufficent or not. OTOH, not shure MFC'ing whole r306837 is OK or not. So I'd personally reverted r330233 alone. On Thu, 1 Mar 2018 07:46:36 -0600 Kyle Evans wrote: > On Thu, Mar 1, 2018 at 7:34 AM, Trond Endrest〓l > wrote: > > On Thu, 1 Mar 2018 14:09+0100, Trond Endrest〓l wrote: > > > >> If you revert to r330229, i.e. svn up -r330229 /usr/src, you should be > >> able to build a working kernel. > >> > >> r330230 added "17" to line 1939 of sys/conf/files breaking iwm(fw), > >> and I suspect "17" should be "22", or maybe the "D" should be removed. > >> > >> r330233 caused the errors you reported. > >> > >> I hope these errors will be corrected shortly. > > > > r330229 is also broken. I had to revert to r330113 to avoid any of the > > recent iwm commits. > > Hi, > > CC'ing Eitan, so hopefully he can fix this mess as soon as he wakes up... > > Thanks, > > Kyle Evans > _______ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: automount usb msdosfs no partition table
Does sysutils/automount (not sysutils/automounter) work as expected?
*Need fix for head, though. The fix itself is easy, but I've stuck
with version check to create extra patch for ports.
Attached patch for head. If you want to use sysutils/automount on head,
apply it as root AFTER install for now.
On Mon, 9 Oct 2017 21:07:29 +0200
Tomasz CEDRO wrote:
> On Mon, Oct 9, 2017 at 8:59 PM, Scott Bennett wrote:
> > Tomasz CEDRO wrote:
> >> i cannot format that device, as its the "firmware feature" that it has no
> >> partition table.. i would have to fix the firmware.. but it would be nice
> >> to automount it anyway as macos, linux and windoze can :-)
> > Well, put a partition table onto it, then. You can use either gpart(8)
> > or fdisk(8) to do that and to create a slice, and then use newfs_msdos(8) to
> > create the file system.
> > I understood from your previous message that you wanted to create a
> > FAT32
> > file system on /dev/da0 rather than on /dev/da0s1, which meant on the bare
> > device rather than on a slice. Otherwise, create the partition table,
> > create
> > a slice, and proceed.
>
> The problem is device has hardcoded filesystem, with no partition
> table, all this is created by firmware on device boot, cannot get
> formatted nor partitioned.. I can mount it by hand.. but it does not
> get automounted.. and exactly this part is the problem and quest here
> :-) :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
--
Tomoaki AOKI
--- /usr/local/sbin/automount.orig 2015-09-21 16:10:07.114602000 +0900
+++ /usr/local/sbin/automount 2017-09-30 00:23:51.855577000 +0900
@@ -423,12 +423,12 @@ case ${2} in
__log "${DEV}: fsck_msdosfs ${LINE}"
done
__wait_for_device ${DEV}
-if mount_msdosfs ${OPTS} -o large -o longnames -m 644 -M 755 \
+if mount_msdosfs ${OPTS} -o longnames -m 644 -M 755 \
-D ${CODEPAGE} -L ${ENCODING} ${DEV} ${MNT}
then
ADD=1
else
- __log "${DEV}: mount failed (fat) 'mount_msdosfs ${OPTS} -o large -o longnames -D ${CODEPAGE} -L ${ENCODING} -m 644 -M 755 ${DEV} ${MNT}'"
+ __log "${DEV}: mount failed (fat) 'mount_msdosfs ${OPTS} -o longnames -D ${CODEPAGE} -L ${ENCODING} -m 644 -M 755 ${DEV} ${MNT}'"
exit 1
fi
__log "${DEV}: mount (fat)"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
MFC of r304443?
Hi. Any chance for MFC r304443 before releng/11.1 branch? [1] [2] It had "MFC After: 3 days" but already passed by about 10 months. [1] https://lists.freebsd.org/pipermail/svn-src-head/2016-August/090570.html [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210686 Yes, this false-positive can workaround by setting kern.cam.ada.0.quirks="0x0"# No need for 4k quirks. or kern.cam.ada.0.quirks="0x1"# 4k quirks is required. on /boot/loader.conf, but it's NOT sufficiently documented, especially for newbies, and IS annoying. Regards. -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Nvidia_load not working
If you're booting via UEFI, it should be because r305779 (MFC of r305484) is not yet MFS'ed (causing insufficient memory to load nvidia.ko). See below for detail. https://lists.freebsd.org/pipermail/svn-src-stable-11/2016-September/000503.html If so, while waiting for MFS, you can load it via rc.conf by adding nvidia-modeset.ko (or nvidia.ko depending on which version you're installing) on kldlist= line, or directly writing kldload command in rc.conf, or rebuild loader.efi with the patch obtained below applied. https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=302408&r2=305779&view=patch don't forget to give -p2 option to patch command line. If you're booting via legacy BIOS mode, sorry, I have no idea. :-( On Sun, 18 Sep 2016 18:58:38 -0700 Charles Cowart wrote: > I did a clean install of RC3 over RC2, and I noticed that nvidia_load="yes" > no longer appears to work in /boot/loader.conf. I can still load the module > from etc/rc.conf > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- 青木 知明 [Tomoaki AOKI] ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Nvidia_load not working
I suspect loader.efi issue rather than that you mentioned. https://lists.freebsd.org/pipermail/svn-src-stable-11/2016-September/000503.html nvidia.ko is loaded as a dependency of nvidia-modeset.ko, so if nvidia.ko failed to load, nvidia-modeset.ko should fail as well. On Sun, 18 Sep 2016 19:02:55 -0700 David Wolfskill wrote: > On Sun, Sep 18, 2016 at 06:58:38PM -0700, Charles Cowart wrote: > > I did a clean install of RC3 over RC2, and I noticed that nvidia_load="yes" > > no longer appears to work in /boot/loader.conf. I can still load the module > > from etc/rc.conf > > ... > > As the nvidia kernel module is part of a port/package, I suspect that > this is more of a "ports" issue than a "stable" issue; in particular, if > the version of the nvidia-driver you're using is sufficiently recent, > you may find a recent ports/UPDATING entry relevant: > > 20160829: > AFFECTS: users of x11/nvidia-driver > AUTHOR: c...@freebsd.org > > The NVidia driver has been updated to version 367.35. Starting with > version 358.09, new kernel module was added, nvidia-modeset.ko. This > new driver component works in conjunction with the nvidia.ko kernel > module to program the display engine of the GPU. > > Users that experience hangs when starting X11 server, or observe > > (II) NVIDIA(0): Validated MetaModes: > (II) NVIDIA(0): "NULL" > > messages in their /var/log/Xorg.0.log file should replace ``nvidia'' > with ``nvidia-modeset'' in /boot/loader.conf or /etc/rc.conf files, > depending on how they prefer to load NVidia driver kernel module. > > Peace, > david > -- > David H. Wolfskillda...@catwhisker.org > Those who would murder in the name of God or prophet are blasphemous cowards. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0-RELEASE status update
Any chance for MFC'ing r304443? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210686 If not, the workaround should be better documented in RELNOTES. On Thu, 1 Sep 2016 21:10:00 + Glen Barber wrote: > As some of you may be aware, a few last-minute showstoppers appeared > since 11.0-RC1 (and before RC1). > > One of the showstoppers has been fixed in 12-CURRENT, and merged to > stable/11 and releng/11.0 that affected booting from large volumes: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212139 > > There is one issue that is still being investigated, which we are > classifying as an EN candidate, given the manifestations of the issue > and reproducibility: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212168 > > There is one blocker before 11.0-RELEASE, that affects libarchive, which > we are waiting for feedback. Once feedback is received, the schedule > for 11.0-RELEASE will be updated on the website to reflect reality. > > There are a few post-release EN items on our watch list as well, so if > something was not mentioned here, that does not mean it will not be > fixed in 11.0-RELEASE. > > Apologies for the delay, and as always, thank you for your patience. > > Glen > On behalf of: re@ > -- 青木 知明 [Tomoaki AOKI] ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems with em0 driver after upgrade to r303832
Hi Unfortunately, the revision shown by `uname -a` etc. is NOT the actual newest revision of the branch, because the set of revision numbers is exactly the same throuout every branches. # It relies on when he / she `svn(lite) up`'ed and gets newest rev. So the easiest way to determine the actual revision is, for this case, to look into the pipermail archive of freebsd-src-stable10 and look for the maximum nunber NOT EXCEEDING the revision shown. This case, the actual revision Pete has should be r303827. On Tue, 9 Aug 2016 13:40:23 +0200 Kurt Jaeger wrote: > Hi! > > > I upgraded my local machine to the above revision a few days ago. Since > > then I have seen the local em0 card locking up and getting he following > > messages in dmesg > > > > em0: Watchdog timeout -- resetting > > em0: link state changed to DOWN > > em0: link state changed to UP > > > > > > I thought it was the physical card, but I have swapped this out > > for a completely different one and the problems remain. > > What does pciconf -lvb display for the PCI IDs for this card ? > > If you use r303832, this is CURRENT (12.x) ? Then maybe the > question should be discussed on curr...@freebsd.org. > > -- > p...@opsec.eu+49 171 3101372 4 years to > go ! > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sed command does not behave equal from 10.3 to 11.0
Hi. There were some collation related changes (*1) between 10.3 and 11. So the results can be changed even with the same locale. *1: For example, r302512. https://lists.freebsd.org/pipermail/svn-src-head/2016-July/088919.html But I cannot understand why ASCII range of characters are affected with UTF-8 encoding. On Wed, 27 Jul 2016 11:19:06 +0200 Jos〓 Garc〓a Juanino wrote: > On 27 July 2016 at 11:01, Matthew D. Fuller wrote: > > On Wed, Jul 27, 2016 at 09:45:23AM +0100 I heard the voice of > > krad, and lo! it spake thus: > >> are you sure you aren't hitting a port or something? > > > > Locale dependant. > > > > % echo "abc_ABC.def" | env LANG=C sed -e 's/[^A-Z0-9]//g' > > ABC > > > > % echo "abc_ABC.def" | env LANG=en_US.UTF-8 sed -e 's/[^A-Z0-9]//g' > > bcABCdef > > > > (pre-branch -CURRENT) > > > > The issue is that, under the same locale, the output is not the same > in 10.3 as 11.0. It sounds to me a bug ... > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting from separate zfs pool
And with this feature, if I understood correctly, old kernel keeps on running after this type of reboot. If so, kernel modules loaded via /etc/rc.conf[.local] can cause version mismatch with running kernel, forcing single user mode. So I'd prefer making 'zboot' pool as real rootfs and mount needed datasets from main pool. (Use povot-root only for userland-only updates.) # Pivot-root would be similar to configuration below. Right? *Use UEFI loader of 10.3 or later *UFS having /boot *ZFS NOT having /boot (at least, /boot/loader.efi) */boot/loader.conf has vfs.root.mountfrom line pointing inside ZFS Below can be optional. *UFS is mounted to some mountpoint such as /ufsboot after boot *ZFS has symlink /boot pointing /ufsboot On Thu, 28 Apr 2016 20:39:51 +0900 Tomoaki AOKI wrote: > Finished at r293744 (MFC of r290548), right? > > > https://lists.freebsd.org/pipermail/svn-src-stable-10/2016-January/007753.html > > > On Thu, 28 Apr 2016 11:57:44 +0100 > Steven Hartland wrote: > > > I thought that was in 10.3 as well? > > > > > > On 28/04/2016 11:55, krad wrote: > > > I think the new pivotroot type stuff in 11 may help a lot with this > > > > > > https://www.freebsd.org/news/status/report-2015-10-2015-12.html#Root-Remount > > > > > > > > > > > > On 28 April 2016 at 10:31, Malcolm Herbert wrote: > > > > > >> On Thu, Apr 28, 2016 at 12:44:28PM +0500, Eugene M. Zheganin wrote: > > >> |So, I'm still struggling with my problem when I cannot boot from a big > > >> |zfs 2T pool (I have written some messages about a year ago, the whole > > >> |story is too long and irrelevant to retell it, I'll only notice that I > > >> |took the path where I'm about to boot from a separate zfs pool closer to > > >> |the beginning of the disk). > > >> > > >> it's no an answer to your question, but I'm wondering wether the solution > > >> to this may also help with beadm being unable to work with crypted ZFS > > >> root > > >> volumes as the boot zpool is not the same as zroot ... I've got that > > >> issue > > >> myself ... > > >> > > >> -- > > >> Malcolm Herbert > > >> m...@mjch.net > > >> ___ > > >> freebsd-stable@freebsd.org mailing list > > >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > >> > > > ___ > > > freebsd-stable@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > > _______ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > > > -- > Tomoaki AOKIjunch...@dec.sakura.ne.jp > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting from separate zfs pool
Finished at r293744 (MFC of r290548), right? https://lists.freebsd.org/pipermail/svn-src-stable-10/2016-January/007753.html On Thu, 28 Apr 2016 11:57:44 +0100 Steven Hartland wrote: > I thought that was in 10.3 as well? > > > On 28/04/2016 11:55, krad wrote: > > I think the new pivotroot type stuff in 11 may help a lot with this > > > > https://www.freebsd.org/news/status/report-2015-10-2015-12.html#Root-Remount > > > > > > > > On 28 April 2016 at 10:31, Malcolm Herbert wrote: > > > >> On Thu, Apr 28, 2016 at 12:44:28PM +0500, Eugene M. Zheganin wrote: > >> |So, I'm still struggling with my problem when I cannot boot from a big > >> |zfs 2T pool (I have written some messages about a year ago, the whole > >> |story is too long and irrelevant to retell it, I'll only notice that I > >> |took the path where I'm about to boot from a separate zfs pool closer to > >> |the beginning of the disk). > >> > >> it's no an answer to your question, but I'm wondering wether the solution > >> to this may also help with beadm being unable to work with crypted ZFS root > >> volumes as the boot zpool is not the same as zroot ... I've got that issue > >> myself ... > >> > >> -- > >> Malcolm Herbert > >> m...@mjch.net > >> ___ > >> freebsd-stable@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > >> > > ___ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting from separate zfs pool
On Thu, 28 Apr 2016 11:52:27 +0100 krad wrote: > I would not use the root dataset. Create a ROOT/ one so it looks for > the kernel in "zboot:/ROOT/fist/boot/kernel/kernel" or similar. This way > you are compatible with beadm. And of course, dataset zboot:/ROOT/fist in above example should set as bootfs by #zpool set bootfs=zboot/ROOT/fist zboot and mountpoints of zboot and zboot/ROOT should be set to NONE by #zfs set mountpoint=none zboot #zfs set mountpoint=none zboot/ROOT respectively. Otherwise, boot would fail. When I forgot to set bootfs, got boot failure, even I've set vfs.root.mountfrom in /boot/loader.conf properly. Are these OK? # This is easily forgotten on manual installation. :-< > > > > On 28 April 2016 at 08:44, Eugene M. Zheganin wrote: > > > Hi. > > > > So, I'm still struggling with my problem when I cannot boot from a big > > zfs 2T pool (I have written some messages about a year ago, the whole > > story is too long and irrelevant to retell it, I'll only notice that I > > took the path where I'm about to boot from a separate zfs pool closer to > > the beginning of the disk). > > > > I've created such a smaller pool, called it zboot. I've read pjd@ letter > > explaining that when FreeBSD sees several bootable pools, it chooses the > > first one - that's fine with me, since the new pool partition's number > > is smaller than the big one. So, I created zboot, set the mountpoint to > > legacy, wrote the content to it's /boot directory (and yes, I did call > > the 'make installkernel DESTDIR=/zboot') and rebooted. Strage thing > > happened next - I got > > > > > > Can't find /boot/zfsloader > > > > FreeBSD/x86 boot > > Default: zboot:/boot/kernel/kernel > > boot: > > | > > Can't find /boot/kernel/kernel > > > > > > I booted back from USB stick (that I'm using to boot my machine) and > > rechecked these files - everything mentioned here is in it's place. > > > > Does someone have the idea what I'm doing wrong ? May be this has > > something to do with the fact that zboot does contain only the /boot > > directory, and not the full rootfs ? > > > > Thanks. > > Eugene. > > ___ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: fat32 question
According to "Real Hardware Gotchas" section in [1], FAT32 fs creation of FreeBSD seems to have some problems. Try formatting by the hardware you're going to transfer files from FreeBSD, if available. Once formatted by other OS, read/write/delete files in FAT32 formatted media would be OK with FreeBSD. If not, and if the file you want to transfer is small enough, partition the media and use FAT16. (The safest maximum is 32MB, but maybe under 2GB would be OK.) [1] https://wiki.freebsd.org/UEFI On Sun, 20 Sep 2015 06:55:19 +0200 Zoran Kolic wrote: > I have a device to which I'd like to connect otg cable > and insert 16gb usb stick. Tried "newfs_msdos -F32 /dev/da0". > Mounted, copied files. The device does not see the file > system at all. > Any idea what to do further? Another option might be extfs. > Best regards > > Zoran > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will 10.2 also ship with a very stale NTP?
Xin, Ian: Confirmed MFC of ntp 4.2.8p3 and related kernel fix. Thanks for your work! re@: Thanks for approving MFC at this timing, before creating releng/10.2. John: Congraturations! We have latest stable version of ntp with 10.2. :-) On Sun, 12 Jul 2015 12:48:49 -0600 Ian Lepore wrote: > On Mon, 2015-07-13 at 04:31 +1000, Peter Jeremy wrote: > > On 2015-Jul-12 09:41:43 -0600, Ian Lepore wrote: > > >And let's all just hope that a week or two of testing is enough when > > >jumping a major piece of software forward several years in its > > >independent evolution. > > > > Whilst I support John's desire for NTP to be updated, I also do not > > think this is the appropriate time to do so. That said, the final > > decision is up to re@. > > > > >The import of 4.2.8p2 several months ago resulted in complete failure of > > >timekeeping on all my arm systems. Just last week I tracked it down to > > >a kernel bug (which I haven't committed the fix for yet). While the bug > > >has been in the kernel for years, it tooks a small change in ntpd > > >behavior to trigger it. > > > > > >Granted it's an odd corner-case problem that won't affect most users > > >because they just use the stock ntp.conf file (and it only affects > > >systems that have a large time step due to no battery-backed clock). > > >But it took me weeks to find enough time to track down the cause of the > > >problem. > > > > I'm not using the stock ntp.conf on my RPis and didn't notice any NTP > > issues. Are you able to provide more details of either the ntp.conf > > options that trigger the bug or the kernel bug itself? A quick search > > failed to find anything. > > > > I just committed the kernel fix as r285424; the commit message has some > info on why the new ntpd made the problem visible. > > I should have said "stock rc.conf and ntp.conf"... To get the problem to > happen you've got to set rc.conf ntpd_sync_on_start=NO and allow ntpd to > make a large step (-g without -q, or tinker panic 0). I don't remember > why I had sync on start disabled on most of my arm systems (probably a > one-time experiment that I forgot to undo and it got copied around), but > I suspect most people who don't have battery clocks will have it set to > yes, and that's why nobody else saw this problem. > > To me, the problem was mainly illustrative of how a tiny innocuous > change (ntpd making a series of ntp_adjtime() calls in a different, but > still correct, order than it used to) can expose a completely unexpected > longstanding bug in our code. Gotta wonder if any more of those are > lurking. :/ > > -- Ian > > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will 10.2 also ship with a very stale NTP?
Wow! Thanks for your time and quick response. I'm looking forward to seeing it MFCed. :-) On Sun, 12 Jul 2015 08:56:26 + Xin LI wrote: > I've spent some time on the MFC, the testing would still take some time > (likely a day or two) and once that's finished I'll ask re@ for approval. > On Sat, Jul 11, 2015 at 11:44 PM Tomoaki AOKI > wrote: > > > As I already mentioned in another post, head has 4.2.8 p3 in-tree. > > > > So the answer should be MFC before creation of releng/10.2 is planned > > or not. > > > > > > On Sun, 12 Jul 2015 15:04:43 +1000 > > Peter Jeremy wrote: > > > > > On 2015-Jul-11 23:22:56 -0400, Chris Nehren < > > cnehren+freebsd-sta...@pobox.com> wrote: > > > >On Sat, Jul 11, 2015 at 09:58:11 +1000, John Marshall wrote: > > > >> It's me again with my annual NTP whinge. > > > > > > > >The answer to the perennial "will release $foo ship with old / insecure > > > >/ otherwise deficient $bar?" is still "install $bar from ports". > > > > > > That's a non-answer. It just changes the question to "why bother to > > > include $bar in base when I need to install the port anyway". > > > > > > -- > > > Peter Jeremy > > > > > > -- > > Tomoaki AOKIjunch...@dec.sakura.ne.jp > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will 10.2 also ship with a very stale NTP?
As I already mentioned in another post, head has 4.2.8 p3 in-tree. So the answer should be MFC before creation of releng/10.2 is planned or not. On Sun, 12 Jul 2015 15:04:43 +1000 Peter Jeremy wrote: > On 2015-Jul-11 23:22:56 -0400, Chris Nehren > wrote: > >On Sat, Jul 11, 2015 at 09:58:11 +1000, John Marshall wrote: > >> It's me again with my annual NTP whinge. > > > >The answer to the perennial "will release $foo ship with old / insecure > >/ otherwise deficient $bar?" is still "install $bar from ports". > > That's a non-answer. It just changes the question to "why bother to > include $bar in base when I need to install the port anyway". > > -- > Peter Jeremy -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will 10.2 also ship with a very stale NTP?
Hi As head already has 4.2.8 p3 in tree, MFCing this before BETA2 would be nice because... *At least, authorized open stratum 1 by NICT supports only 4.2.6 or later for configuration line (in ntp.conf) like below. pool ntp.nict.jp *This type of configuration is NOT supported by 4.2.4 branch. 4.2.4 still works for now, but NOT supported by NICT. *JST (Japanese Standard Time) is maintained by NICT. http://www.nict.go.jp/JST/JST_E.html http://www2.nict.go.jp/aeri/sts/tsp/PubNtp/index-e.html So syncing to their NTP server by officially supported way with BASE should be nice for Japanese users, I think. Of course, ports has 4.2.8p3. But head also has it. The best way would be MFCing. Is there any problem (with GPS, authenticate, etc.)? On Sat, 11 Jul 2015 09:58:11 +1000 John Marshall wrote: > It's me again with my annual NTP whinge. > > https://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075580.html > https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/079830.html > > Here we are at the start of another release cycle and 10-STABLE still > includes (patched) ntp 4.2.4p8 software that was released in December > 2009. > - ntp 4.2.6 superseded 4.2.4 and was also released in December 2009. > - ntp 4.2.8 superseded 4.2.6 and was released in December 2014. > > Will 10.2 be released with a version of ntp that is two generations old > and that has been legacy since December 2009? > > I am really pleased to see that there has been some recent activity with > respect to ntp in -CURRENT, and that the latest point release (4.2.8p3) > has actually been imported. Is there any likelihood of this being > MFC'd before releng/10.2 is branched? > > Thank you for your patience with me, and thank you to committers who are > working in this space but perhaps not with an eye to -STABLE. I just > think it's really sad that we are shipping very old ntp software with > lots of patches when a current release is available. > > I also note that phk@ was working on an ntp client which he hoped to > offer as a replacement but that is presumably not ready yet. I also > note that we have current versions of ntp available in ports; but I'm > talking about what we ship in the base system. > > -- > John Marshall -- 青木 知明 [Tomoaki AOKI] junch...@dec.sakura.ne.jp mxe02...@nifty.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
