Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
> On 2 Dec 2018, at 01:11, Mark Martinec wrote: > > 2018-11-29 18:43, Toomas Soome wrote: >> I just did push biosdisk updates to stable/12, I wonder if you could >> test those bits… > > Thank you! I haven't tried it yet, but I wonder whether this fix was > already incorporated into 12.0-RC3, which would make my rescue easier. > > Otherwise I can build a stable/12 on another host and transplant > the problematic file(s) to the affected host - if I knew which files > to copy. > > I wonder also, if the today's posting by cksalexan...@q.com on the > freebsd-stable ML titled "FreeBSD-12.0-RC3-i386-disc1.iso does not boot" > could be describing the same problem? > > Mark > The files are /boot/loader* binaries - to be exact, check which one is linked to /boot/loader. I can provide binaries if needed. Can not tell about post in freebsd-stable - it simply does not provide enough information. rgds, toomas > >>> On 29 Nov 2018, at 17:01, Mark Martinec >>> wrote: >>> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64, >>> zfs, bios), I tried my luck with one of our production hosts, and ended up >>> with a stuck loader after rebooting with a new kernel (after the first >>> stage of upgrade). >>> These were the steps, and all went smoothly and normally until a reboot: >>> freebsd-update upgrade -r 12.0-RC2 >>> freebsd-update install >>> shutdown -r now >>> While booting, the 'BTX loader' comes up, lists the BIOS drives, >>> then the spinner below the list comes up and begins turning, >>> stuttering, and after a couple of seconds it grinds to a standstill >>> and nothing happens afterwards. >>> At this point the ZFS and the bootstrap loader is supposed to >>> come up, but it doesn't. >>> This host has too zfs pools, the system pool consists of two SSDs >>> in a zfs mirror (also holding a freebsd-boot partition each), the >>> other pool is a raidz2 with six JBOD disks on an LSI controller. >>> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2, >>> both zpool versions are up-to-date with 11.2. The 'zpool status -v' >>> is happy with both pools. >>> After rebooting from an USB drive and reverting the /boot directory >>> to a previous version, the machine comes up normally again >>> with the 11.2-RELEASE-p4. >>> I found a file init.core in the / directory, slightly predating the >>> last reboot with a salvaged system - although it was probably not >>> a cause of the problem, but a consequence of the rescue operation. >>> It is unfortunate that this is a production host, so I can't play >>> much with it. One or two more quick experiments I can probably >>> afford, but not much more. Should I just first wait for the >>> official 12.0 release? Should I try booting with a 12.0 on USB >>> and try to import pools? Suggestions welcome. >>> Now that the /boot has been manually restored to the 11.2 state, >>> A SECOND QUESTION is about freebsd-update, which still thinks we are >>> in the middle of an upgrade procedure. Trying now to just update >>> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains: >>> # uname -a >>> FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 >>> # >>> # freebsd-version >>> 11.2-RELEASE-p4 >>> # >>> # freebsd-update fetch >>> src component not installed, skipped >>> You have a partially completed upgrade pending >>> Run '/usr/sbin/freebsd-update install' first. >>> Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway. >>> So what is the right way to get rid of all traces of the >>> unsuccessful upgrade, and let freebsd-update believe we are cleanly >>> at 11.2-p4 ? Removing /var/db/freebsd-update did not help. >>> Mark > ___ > 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: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Fri, 30 Nov 2018 14:32:52 + Gary Palmer schrieb: > 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 Thank you very much for this hint! Much appreciated. With adding those lines to the ppp.linkup script, the outer interface, tun0, now obtains two valid IPv6 addresses - on is always marked temporary, the other is comprised from the MAC of the physical interface from which is tun0 is cloned. But when the ISP is changing the IPs (both IPv4 and IPv6), without any further actoin I have a bunch of IPv6 addresses over time associated with tun0. The documentation lacks in many aspects how to deal with IPv6, especially when it comes to "well known things from the old IPv4 world". Since DDNS also is still something people use with IPv6, MYADDR6 doesn't carry the IPV6 address obtained after rtsold has been started and rtsol tun0 has been issued as described above (MYADDR6/HISADDR6 are assigned with the linklocal addresses). Thanks for the help! Kind regards, Oliver - -- 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/86TrS528fyFhYlAUCXARSrgAKCRDS528fyFhY lHrHAf97f7pFLQtUugVqtQkkcmOwZfDT3hSpJzCKy+2SUBu1p08TRNnO6t2lt+q2 8Bj9edB/Ybbsx/K8LNaYU5IcIZRSAf9nnBNwNvfdqLQ8hm7zLE2mpgroBfaT+Nkk /iWEqhAaSNA5Msg8jmE32qm7vRippUyEzOeG5l8P/miGHVWCaR6d =ewBW -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"
Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Fri, 30 Nov 2018 16:41:02 + "Bjoern A. Zeeb" schrieb: Sorry for the late reply, had a long weekend off ... > 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. In my case. IPV6CP indeed does only negotiate the linklocal addresses (fe80::) on my WAN interface ... > > 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). Studying the manpage for ppp(8), one might not get that IPV6CP does only negotiate the IPv6 linklocal address ... > > 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" - -- 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/86TrS528fyFhYlAUCXARQZAAKCRDS528fyFhY lMXRAf9RE7lygi/eqfkL5U+iAWiQYDEmuITolg6sOpyqMVUIKZeg1zA1HQL8Cw70 7vMSc6Rwbvtuz8b8N+chelawH4dxAf9K2Rs9O+cw91PRO0CNN+JcuRnk/gj/ivYo pn24sPi8MIoXOOecR2WSLg1e0uspStEBGr0kdxPJ0aJBNVu1AuLd =cnfs -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"
WITH_CTF breaks CD loader: "File too big"
Hi, Building disc1.iso using `make release` and having WITH_CTF set in src.conf leads to "File too big" displayed when booting the image. Would it make sense to build loader and related parts without CTF unconditionally as it doesn't look useful there? signature.asc Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
> On 2 Dec 2018, at 17:08, Yuri Pankov wrote: > > Hi, > > Building disc1.iso using `make release` and having WITH_CTF set in > src.conf leads to "File too big" displayed when booting the image. > > Would it make sense to build loader and related parts without CTF > unconditionally as it doesn't look useful there? > +1 rgds, toomas ___ 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 3 Dec 2018, at 08:15, O. Hartmann wrote:
>
>
> The documentation lacks in many aspects how to deal with IPv6, especially
> when it comes
> to "well known things from the old IPv4 world". Since DDNS also is still
> something people
> use with IPv6, MYADDR6 doesn't carry the IPV6 address obtained after rtsold
> has been
> started and rtsol tun0 has been issued as described above (MYADDR6/HISADDR6
> are assigned
> with the linklocal addresses).
FWIW I use dhcp6c to get an IPv6 range from my ISP.
My /usr/local/etc/dhcp6c.conf looks like..
interface ng0 {
send ia-pd 0;
};
id-assoc pd {
prefix-interface bridge0 {
sla-id 0;
sla-len 8;
};
};
I am using mpd5 for PPPoE and bridge0 is my LAN interface.
My /etc/rtadvd.conf looks like..
# Leaving rltime at the default gives
http://www.freebsd.org/cgi/query-pr.cgi?pr=162547
# setting it to 0 prevents it being used as a router. Setting to 1800 (the
putative default)
# works..
bridge0:\
:rltime#1800:\
:rdnss="xxx":\
:dnssl="yyy":
where xxx is the IPv6 address of my server and yyy is my domain.
(I'm not sure if the comment regarding rltime is true any more though but it
works so I don't touch it ;)
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
___
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: WITH_CTF breaks CD loader: "File too big"
On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote: > Hi, > > Building disc1.iso using `make release` and having WITH_CTF set in > src.conf leads to "File too big" displayed when booting the image. > > Would it make sense to build loader and related parts without CTF > unconditionally as it doesn't look useful there? > Fully agree with you Best regards, Bapt signature.asc Description: PGP signature
