FreeBSD 12.0-RC3 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The third RC build of the 12.0-RELEASE release cycle is now available. Installation images are available for: o 12.0-RC3 amd64 GENERIC o 12.0-RC3 i386 GENERIC o 12.0-RC3 powerpc GENERIC o 12.0-RC3 powerpc64 GENERIC64 o 12.0-RC3 powerpcspe MPC85XXSPE o 12.0-RC3 sparc64 GENERIC o 12.0-RC3 armv6 RPI-B o 12.0-RC3 armv7 BANANAPI o 12.0-RC3 armv7 BEAGLEBONE o 12.0-RC3 armv7 CUBIEBOARD o 12.0-RC3 armv7 CUBIEBOARD2 o 12.0-RC3 armv7 CUBOX-HUMMINGBOARD o 12.0-RC3 armv7 RPI2 o 12.0-RC3 armv7 PANDABOARD o 12.0-RC3 armv7 WANDBOARD o 12.0-RC3 armv7 GENERICSD o 12.0-RC3 aarch64 GENERIC o 12.0-RC3 aarch64 RPI3 o 12.0-RC3 aarch64 PINE64 o 12.0-RC3 aarch64 PINE64-LTS Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/12.0" branch. A summary of changes since 12.0-RC2 includes: o Fix for vulnerabilities in NFS server code. (FreeBSD-SA-18:13.nfs) o The if_ixlv.ko kernel module had been added as a link to if_iavf.ko for backwards compatibility when upgrading from earlier releases. o Various memory leak fixes. o Various miscellaneous fixes. A list of changes since 11.2-RELEASE is available in the releng/12.0 release notes: https://www.freebsd.org/releases/12.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 12.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/12.0-RC3/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: ap-south-1 region: ami-082a7bdd08cce857d eu-west-3 region: ami-0e5bf0c23c2f034ec eu-west-2 region: ami-00e75258395bf0985 eu-west-1 region: ami-01d05467033f84d08 ap-northeast-2 region: ami-041d5c88c9c542863 ap-northeast-1 region: ami-0e9466d3fc6570b45 sa-east-1 region: ami-00773c92d14429ca7 ca-central-1 region: ami-020ac944459518342 ap-southeast-1 region: ami-0371782ca788ddd83 ap-southeast-2 region: ami-03eff86446727a6af eu-central-1 region: ami-03834365d9c0cb186 us-east-1 region: ami-01cd7b8e38fafb16a us-east-2 region: ami-004916da58945349a us-west-1 region: ami-041117214e0cb24fa us-west-2 region: ami-0955fea3a26a6f651 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-12.0-RC3 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 12.0-RC3 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install
Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
As someone who controls both ends of the link (runs the ISP, has service from the ISP), so far (a bit out of laziness) I have the following solution... Now... of note is that we statically assign addresses. This is not just being nice, but being practical. We deal out IPv4 addresses vi IPCP, but they are, in fact, statically assigned. In radius we assign IPv6 addresses. On the servers, we run this ifaceup script: #!/bin/bash # # Add a route to the interface, if appropriate. PATH=/sbin:/usr/local/bin:$PATH date=`date` interface="$1" authname="$5" route=`psql -tA --user mpd5 --host postgres.host.com -c "select value from radreply where username = '$authname' and attribute = 'Framed-IPv6-Route'" radius` if [ -n "$route" ]; then route -n6 add $route -iface $interface fi echo $interface $authname $route $date >>/tmp/mpd5-if-up It may be prudent to note here that OSPF keeps track of these routes, so we don't need to. There's no ifdown script because mpd5 destroys the ngX interface which deletes the route (99 out of 100 times). On the client side, we enable ipv6cp (for link local stuff). Then we add an ifup script: /sbin/route -n add -inet6 default -iface ng0 >/tmp/ipv6routeup.log 2>&1 ... it might be useful to note that non-BSD endpoints (we use the linux-based SmartRG modems) seem to add the IPv6 default route automatically. We then set the first address statically to the ethernet device. This, so far, has been enough to make things work smoothly. (obPitch: if you're in Canada and can get DSL where you are, hit me up for a FreeBSD-only (no Cisco) connection) ___ 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: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
## Bjoern A. Zeeb (bzeeb-li...@lists.zabbadoz.net): > No, IPV6CP, to my very best 15 year old memory only negotiates the > interface identifiers, which are used to generate the link-local addresses. Ah, you're right - it's IPV6CP-then-NDP, not "IPV6CP or NDP". I got ahead of the protocol... Regards, Christoph -- Spare Space ___ 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: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
On 11/30/2018 7:12 AM, O. Hartmann wrote: > > For IPv6, I only see my local linklocal address, fe80::... > > Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: > linklocal address > assigned to the variable HISADDR. Somehow, the tun0 never obtains a > IPv6 aprefix so far. > > Can someone give a tip? What does you ppp.conf look like ? -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ 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: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
On 30 Nov 2018, at 15:59, Christoph Moench-Tegeder wrote: > ## O. Hartmann (ohartm...@walstatt.org): > >> As far as I know, with the IPv4 stack a IPv4 address is obtained >> automatically, so I would expect the same for IPv6. > > The fun with "automatically" is that there's more than one way... > DHCPv6 and NDP (IPV6 Neighbour Discovery Protocol/Router Solicitation) > have been mentioned, the third option is IPV6CP (PPP options, just as > PPP-with-IPv4 does with IPCP). I've no idea what your provider does, so... No, IPV6CP, to my very best 15 year old memory only negotiates the interface identifiers, which are used to generate the link-local addresses. There is no negotiation for full prefix/global addresses, hence it is different to the IPCP NCP used for IPv4. One wants to run rtsol on the link and then depending on the O/M bits possibly also DHCPv6 I’d assume. There’s a couple of other options and shortcuts, on how to configure global addresses (as always, if you know you have a static prefix assigned, one can do it by hand for example); and then there are shortcuts as to when you’d perform DAD, which shouldn’t bother the user. These days there should also be options with regards to RFC4941 (privacy extensions for stateless address autoconf). It may no be uncommon to run the ptp-link with link-local addresses only and configure an address from a prefix on lo0 or the internal interface only; but I am doubtful FreeBSD’s userland implementation is that sophisticated. /bz ___ 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: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
## O. Hartmann (ohartm...@walstatt.org): > As far as I know, with the IPv4 stack a IPv4 address is obtained > automatically, so I would expect the same for IPv6. The fun with "automatically" is that there's more than one way... DHCPv6 and NDP (IPV6 Neighbour Discovery Protocol/Router Solicitation) have been mentioned, the third option is IPV6CP (PPP options, just as PPP-with-IPv4 does with IPCP). I've no idea what your provider does, so... If it's IPV6CP, make sure it's enabled in ppp (it is by default), and check with "show ipv6cp". If you expect NDP, amke sure you don't drop icmp6 packets and use rtsol et al. I would not expect DHCPv6 - that's more work to set up on the ISP side - but if that's what you get, you'd need net/isc-dhcp44-client or similar (net/dhcpv6 might work, base dhclient does not look like it supports IPv6). Regards, Christoph -- Spare Space ___ 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: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
On Fri, Nov 30, 2018 at 01:12:32PM +0100, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > My ISP is offering IPv6 only "as an experimental feature", so I had to ask to > enable the > IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a > router/firewall/PBX system, FreeBSD's onboard ppp client is performing the > uplink and > authetication and this works well with IPv4 for years for now. > > I'm using IPFW as my filtering system, reading the standard > /etc/rc.ipfirewall and add > some custom rules regarding my setup. > > As far as I know, with the IPv4 stack a IPv4 address is obtained > automatically, so I > would expect the same for IPv6. > > I'm new to IPv6 and I've trouble with my provider for a long time now, so > there is a > slight possibility that my ISP is not truthful on what they say. On the other > hand, there > is still a high probability that I do something wrong. I need need to send > this ahead, > before continueing. > > When booting off, I see the classic tun0 uplink with > > MYADDR -> HISADDR > > For IPv6, I only see my local linklocal address, fe80::... > > Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: linklocal > address > assigned to the variable HISADDR. Somehow, the tun0 never obtains a IPv6 > aprefix so far. > > Can someone give a tip? I have : shell /sbin/ifconfig tun0 inet6 -ifdisabled -no_radr accept_rtadv shell /sbin/rtsol tun0 & in a ppp.linkup file. The alternative is to use dhcp6c, which also worked for my provider. (there are other lines in the linkup file also, but I think those are the relevant ones) Regards, Gary ___ 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: 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. See /etc/defaults/loader.conf for more info. The loader.conf man page doesn't show what's the default value. > > Thanks for the quick help! > > Kind regards, > > O. Hartmann > > - -- > O. Hartmann > > Ich widerspreche der Nutzung oder 〓bermittlung meiner Daten f〓r > Werbezwecke oder f〓r die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). > -BEGIN PGP SIGNATURE- > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/7g9AAKCRDS528fyFhY > lGKLAf9uL2wkoLhxrT/ca/EylOlGvOZ/n+9TVCuI1YZyhjHAjQICN863czLtfIvF > pu7OyWNxeWvDS5bvdCol1bpOQ8kUAgCDGZZT3Y2GSALuyfk2L2M4xGb/uegdnlD1 > 7M9gnnIwQ5bfyZkF1kvN3MGMn3WtnVZduSpjg8SURmkC+1xFDXNl > =XJxh > -END PGP SIGNATURE- > ___ > freebsd-sta...@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
Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
Hi, > On 30 Nov 2018, at 12:12, O. Hartmann wrote: > > Signed PGP part > My ISP is offering IPv6 only "as an experimental feature", so I had to ask to > enable the > IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a > router/firewall/PBX system, FreeBSD's onboard ppp client is performing the > uplink and > authetication and this works well with IPv4 for years for now. > > I'm using IPFW as my filtering system, reading the standard > /etc/rc.ipfirewall and add > some custom rules regarding my setup. > > As far as I know, with the IPv4 stack a IPv4 address is obtained > automatically, so I > would expect the same for IPv6. > > I'm new to IPv6 and I've trouble with my provider for a long time now, so > there is a > slight possibility that my ISP is not truthful on what they say. On the other > hand, there > is still a high probability that I do something wrong. I need need to send > this ahead, > before continueing. > > When booting off, I see the classic tun0 uplink with > > MYADDR -> HISADDR > > For IPv6, I only see my local linklocal address, fe80::... > > Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: linklocal > address > assigned to the variable HISADDR. Somehow, the tun0 never obtains a IPv6 > aprefix so far. > > Can someone give a tip? Guessing because I haven’t used v6 over ppp, but: - You probably need net.inet6.ip6.accept_rtadv set to 1 to accept IPv6 router advertisement from upstream. You should get a prefix from the upstream router. - You may also possibly need to run rtsold(8). > Regards, > > oh > > -- Bob Bishop r...@gid.co.uk signature.asc Description: Message signed with OpenPGP
ipv6/ppp: FreeBSD obtains linklocal on tun0 only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 My ISP is offering IPv6 only "as an experimental feature", so I had to ask to enable the IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a router/firewall/PBX system, FreeBSD's onboard ppp client is performing the uplink and authetication and this works well with IPv4 for years for now. I'm using IPFW as my filtering system, reading the standard /etc/rc.ipfirewall and add some custom rules regarding my setup. As far as I know, with the IPv4 stack a IPv4 address is obtained automatically, so I would expect the same for IPv6. I'm new to IPv6 and I've trouble with my provider for a long time now, so there is a slight possibility that my ISP is not truthful on what they say. On the other hand, there is still a high probability that I do something wrong. I need need to send this ahead, before continueing. When booting off, I see the classic tun0 uplink with MYADDR -> HISADDR For IPv6, I only see my local linklocal address, fe80::... Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: linklocal address assigned to the variable HISADDR. Somehow, the tun0 never obtains a IPv6 aprefix so far. Can someone give a tip? Regards, oh -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXAEpSwAKCRDS528fyFhY lMwHAf9XXmHWMWPjNH/oIMOCG50M7X8tcWrS0aZy7tsJchYBzu6bos/qXXEJHtxs 3XwPOyli0NuAo8i0MEAQMOnnOFyxAf9ey6qPJxC0dYyfJW4QHFyCCCVHEG+HEv9i vHkpvZrrV0OpuF6ReM0xFiXlZkhrLoptsQ8V859NeWk5K5P+Ox4r =nsq2 -END PGP SIGNATURE- ___ 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"
