r326622 and r326820 broken?
Hi, I've fetched [1] and [2] and burned to USB and then boot by the USB, but both does not boot and stop at boot loader at the beginning: BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboad Basically,does r326622 and r326820 broken ? [1] FreeBSD-12.0-CURRENT-amd64-20171206-r326622-memstick.img [2] FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img --- KIRIYAMA Kazuhiko ___ 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: UEFI booting survey
> On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard wrote: > > > Warner Losh imp at bsdimp.com wrote on > > Mon Dec 18 20:29:45 UTC 2017 : > > > > > The specific thing we will stop doing is that in the absence of > > > instructions to the contrary, we will no longer search for root on a > > device > > > other than the one the loader.efi came from. > > > > Warner Losh imp at bsdimp.com wrote on > > Sun Dec 17 19:52:07 UTC 2017 : > > > > > In the coming months, we're looking at dropping boot1.efi and instead > > > installing /boot/loader.efi onto the ESP (most likely as > > > \efi\freebsd\loader.efi). > > > > > > Combining the two statements would appear to have consequences > > not obvious from the separate statements in isolation. Rewording > > the first to substitute where loader.efi comes from based on > > the second (if I interpret right): > > > > MISQUOTE > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root > > on other than the device for the ESP used (which will hold > > loader.efi). > > END MISQUOTE > > > > The specific thing we will stop doing is that in the absence of > instructions to the contrary, we will no longer search for root on other > than the device for the ESP used (which will hold now loader.efi as > boot1.efi will shortly be eliminated). Yes please, that is the correct behavior, our searching can lead to problems, and as you have pointed out, often more problems than it ever really fixed. > > Or the following pseudo-code with all the weird special cases removed for > clarity > > load loader.efi from ESP > if Boot uefi variable holds a second path, use that for root/kernel > otherwise if an override variable holds a kernel/root path, use that > otherwise scan for a usable ZFS pool, use that if it exists > otherwise use the same partition loader.efi was booted from for root/kernel > if it's usable > otherwise use the first UFS partition on the ESP that's usable. use the ACTIVE ufs partition, not the first, I can have more than 1 slice, only 1 of them can be set active. Do not use any ufs partitions if they are not in active slices, it is possible to have 0 partitions set active. > > A partition is usable if /boot/loader.rc exists on that path. A partition is usable if it is in an active slice, and ^above Is there any fallback to skip loader and go direct to /boot/kernel/kernel, back to /kernel any more? > What is being deleted is one final step: "otherwise use the first UFS > partition on any drive in a random order that's usable." which used to be > at the end of the boot1.efi psuedo code. It's my belief that no such > installations actually use this due to the random factor today (plug in a > new USB drive and it might take over). If my belief is wrong, it's my > belief that efibootmgr will solve it, and failing that, the fallback > mechanism (for platforms that use u-boot + EFI where UEFI variables don't > work) will allow the two or three people that are doing this today. > > Warner > ___ > 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" -- Rod Grimes rgri...@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: UEFI booting survey
Warner Losh imp at bsdimp.com wrote on Mon Dec 18 20:29:45 UTC 2017 : > The specific thing we will stop doing is that in the absence of > instructions to the contrary, we will no longer search for root on a device > other than the one the loader.efi came from. Warner Losh imp at bsdimp.com wrote on Sun Dec 17 19:52:07 UTC 2017 : > In the coming months, we're looking at dropping boot1.efi and instead > installing /boot/loader.efi onto the ESP (most likely as > \efi\freebsd\loader.efi). Combining the two statements would appear to have consequences not obvious from the separate statements in isolation. Rewording the first to substitute where loader.efi comes from based on the second (if I interpret right): MISQUOTE The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on other than the device for the ESP used (which will hold loader.efi). END MISQUOTE === Mark Millard markmi at dsl-only.net ___ 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: UEFI booting survey
On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard wrote: > Warner Losh imp at bsdimp.com wrote on > Mon Dec 18 20:29:45 UTC 2017 : > > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root on a > device > > other than the one the loader.efi came from. > > Warner Losh imp at bsdimp.com wrote on > Sun Dec 17 19:52:07 UTC 2017 : > > > In the coming months, we're looking at dropping boot1.efi and instead > > installing /boot/loader.efi onto the ESP (most likely as > > \efi\freebsd\loader.efi). > > > Combining the two statements would appear to have consequences > not obvious from the separate statements in isolation. Rewording > the first to substitute where loader.efi comes from based on > the second (if I interpret right): > > MISQUOTE > The specific thing we will stop doing is that in the absence of > instructions to the contrary, we will no longer search for root > on other than the device for the ESP used (which will hold > loader.efi). > END MISQUOTE > The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on other than the device for the ESP used (which will hold now loader.efi as boot1.efi will shortly be eliminated). Or the following pseudo-code with all the weird special cases removed for clarity load loader.efi from ESP if Boot uefi variable holds a second path, use that for root/kernel otherwise if an override variable holds a kernel/root path, use that otherwise scan for a usable ZFS pool, use that if it exists otherwise use the same partition loader.efi was booted from for root/kernel if it's usable otherwise use the first UFS partition on the ESP that's usable. A partition is usable if /boot/loader.rc exists on that path. What is being deleted is one final step: "otherwise use the first UFS partition on any drive in a random order that's usable." which used to be at the end of the boot1.efi psuedo code. It's my belief that no such installations actually use this due to the random factor today (plug in a new USB drive and it might take over). If my belief is wrong, it's my belief that efibootmgr will solve it, and failing that, the fallback mechanism (for platforms that use u-boot + EFI where UEFI variables don't work) will allow the two or three people that are doing this today. Warner ___ 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: UEFI booting survey
On Mon, Dec 18, 2017 at 1:21 PM, Maxim Sobolev wrote: > Not really specific to UEFI, but when ZFS is in use the /boot might be > partially or fully located on the drive that does not correspond to your > boot drive. We've bumped into this issue on AWS recently when our kernel > ended up on second drive after upgrade in a pool that were spanning two EBS > volumes. Now, it does not work with AWS (as boot code only has access to > the boot EBS volume apparently), but according to Alan such scenario is > totally supported on a physical hardware. So I am worried that by not > allowing loader to scan all drives in the system you'd make this scenario > fundamentally impossible. > Let's get one thing clear: nothing in what I've said would make this impossible. The first thing we do is to boot off something specific, no matter what that specific thing might be. If you want to boot a kernel off a floppy after loading /boot/loader.efi from cdrom, I don't care and won't prevent that since you can easily specify that with UEFI paths. For UFS the above scenario wouldn't automatically work, but could easily be made to work. ZFS is a bit special, since it spans multiple drives. I'm not touching the code that hunts for the zpools at all. If we can find them, and they have the right info, we'll still boot. I'm surprised the upgrade didn't work, especially with the code that's gone in to hunt for disks to present as devices in the loader itself. The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on a device other than the one the loader.efi came from. No other boot loader we have does that. No other loader outside of the tree does that to my knowledge. boot1.efi is the only one that did, and it was a bad call to do so. Warner > On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark > wrote: > >> On 12/17/17 20:52, Warner Losh wrote: >> >>> Greetings >>> >>> If you are booting off UEFI and have a bit of an unusual setup, I'd like >>> you to drop me a line. >>> >>> The setup that I'm looking for is any case where you load boot1.efi off >>> one >>> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that >>> drive, but on a different drive on the system. >>> >>> An example of this may be loading boot1.efi off what FreeBSD would call >>> /dev/ada0p1, but having root come from /dev/ada1p1. >>> >>> It's my belief that due to the fragility of this setup, few, if any, >>> people >>> have this setup. If you do, please take a minute to reply to this >>> message. >>> In the coming months, we're looking at dropping boot1.efi and instead >>> installing /boot/loader.efi onto the ESP (most likely as >>> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI >>> Boot Manager, we're dropping the 'search every device in the system' part >>> of the current boot1 algorithm. It will be possible to configure the >>> system >>> to continue booting (either via the new efibootmgr which will allow any >>> imaginable combination, or possibly via a fallback mechanism needed for >>> the >>> embedded EFIs that have poor UEFI Variable support at the moment), but as >>> part of an upgrade to a future FreeBSD 12, some intervention will be >>> necessary. >>> >>> Please let me know if you have an unusual setup like this. >>> >>> Warner >>> >> Hi Warner, >> >> I have what I guess is an unusual setup, not like what you describe >> above, but unusual because I tripple-boot my laptop using only the UEFI >> boot manager to select the OS to boot. >> I have FreeBSD-current, OpenBSD-current and Windows 10 on different >> partitions on one SSD. By default it boots FreeBSD. >> >> This was accomplished with bcdedit.exe in Windows, but now I realize this >> could be done with the new efibootmgr. >> I wanted to try it out, but it panics on my laptop. Sometimes just >> 'kldload efirt' just panics, sometimes it loads but panics as soon as I run >> efibootmgr or efivar. >> How can I help debugging this? >> >> Jakob >> >> ___ >> 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: UEFI booting survey
Not really specific to UEFI, but when ZFS is in use the /boot might be partially or fully located on the drive that does not correspond to your boot drive. We've bumped into this issue on AWS recently when our kernel ended up on second drive after upgrade in a pool that were spanning two EBS volumes. Now, it does not work with AWS (as boot code only has access to the boot EBS volume apparently), but according to Alan such scenario is totally supported on a physical hardware. So I am worried that by not allowing loader to scan all drives in the system you'd make this scenario fundamentally impossible. -Max On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark wrote: > On 12/17/17 20:52, Warner Losh wrote: > >> Greetings >> >> If you are booting off UEFI and have a bit of an unusual setup, I'd like >> you to drop me a line. >> >> The setup that I'm looking for is any case where you load boot1.efi off >> one >> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that >> drive, but on a different drive on the system. >> >> An example of this may be loading boot1.efi off what FreeBSD would call >> /dev/ada0p1, but having root come from /dev/ada1p1. >> >> It's my belief that due to the fragility of this setup, few, if any, >> people >> have this setup. If you do, please take a minute to reply to this message. >> In the coming months, we're looking at dropping boot1.efi and instead >> installing /boot/loader.efi onto the ESP (most likely as >> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI >> Boot Manager, we're dropping the 'search every device in the system' part >> of the current boot1 algorithm. It will be possible to configure the >> system >> to continue booting (either via the new efibootmgr which will allow any >> imaginable combination, or possibly via a fallback mechanism needed for >> the >> embedded EFIs that have poor UEFI Variable support at the moment), but as >> part of an upgrade to a future FreeBSD 12, some intervention will be >> necessary. >> >> Please let me know if you have an unusual setup like this. >> >> Warner >> > Hi Warner, > > I have what I guess is an unusual setup, not like what you describe above, > but unusual because I tripple-boot my laptop using only the UEFI boot > manager to select the OS to boot. > I have FreeBSD-current, OpenBSD-current and Windows 10 on different > partitions on one SSD. By default it boots FreeBSD. > > This was accomplished with bcdedit.exe in Windows, but now I realize this > could be done with the new efibootmgr. > I wanted to try it out, but it panics on my laptop. Sometimes just > 'kldload efirt' just panics, sometimes it loads but panics as soon as I run > efibootmgr or efivar. > How can I help debugging this? > > Jakob > > ___ > 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: r326820 stuck on bootloader
On Mon, Dec 18, 2017 at 9:52 AM, O. Hartmann wrote: > Am Mon, 18 Dec 2017 09:48:01 -0700 > Warner Losh schrieb: > > > On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann > wrote: > > > > > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) > > > "Rodney W. Grimes" schrieb: > > > > > > > > > > > > Hey all! > > > > > > > > > > I have just downloaded > > > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > > > internal video/keyboard" and then it's stuck. > > > > > > > > > > I actually have no idea how to debug, any help would be > appreciated. > > > > > > > > This snapshot may have broken boot code in it, I had problems > > > > installing it to a zfs system and had to post install replace > > > > my zfs boot blocks from those of 20171206. > > > > > > > > > > > > > Thanks in advance, > > > > > - -- > > > > > antranigv > > > > > > > > > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I > > > had no problems > > > with r326583, but r326584 and beyond had compilation issues). I tried > > > r326593 and it > > > worked for me (had issues on a serial console for the PCengine APU2C4). > > > > > > From usr/src/UPDATING, tag designated by "20171215": > > > > > > 20171215: > > > r326887 fixes the issue described in the 20171214 UPDATING > entry. > > > r326888 flips the switch back to building GELI support always. > > > > > > [...] > > > > > > I tried the first time r326888 on the APU 2C4 and it worked again - > this > > > doesn't imply > > > that the GPT GELI and ZFSBOOT loader are all right again, but Warner > Losh > > > stated it is > > > fixed. > > > > > > > Yes. I've confirmed that zfsboot works with or without the GELI code > > compiled in. I've not confirmed that ZFS + GELI partitions work. I > haven't > > updated my test scripts in tools/boot/genroot.sh to create them yet. If > > someone who knows this stuff really well wants to do that for one image > > (gpt + zfs + geli) I can (a) test and (b) generalize. > > > > Warner > > Oh, my bad. So it is still to use with caution? > I have good reason to believe it will work. I fixed the underlying issues that were broken in '593, so I think it will work again. I just haven't confirmed it and hoped that someone else could get to it before I could :) > At that point I can not understand why the build of bootable images is > still in progress. > People which desperate in need of a bootable image may download the wrong > one from the > FreeBSD site - and find out the harsh way it is broken. If the build of > those images is > automated - can this be stopped? That shouldn't be necessary. The normal images should be fine. Warner ___ 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: r326820 stuck on bootloader
Am Mon, 18 Dec 2017 09:48:01 -0700 Warner Losh schrieb: > On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann wrote: > > > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) > > "Rodney W. Grimes" schrieb: > > > > > > > > > Hey all! > > > > > > > > I have just downloaded > > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > > internal video/keyboard" and then it's stuck. > > > > > > > > I actually have no idea how to debug, any help would be appreciated. > > > > > > This snapshot may have broken boot code in it, I had problems > > > installing it to a zfs system and had to post install replace > > > my zfs boot blocks from those of 20171206. > > > > > > > > > > Thanks in advance, > > > > - -- > > > > antranigv > > > > > > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I > > had no problems > > with r326583, but r326584 and beyond had compilation issues). I tried > > r326593 and it > > worked for me (had issues on a serial console for the PCengine APU2C4). > > > > From usr/src/UPDATING, tag designated by "20171215": > > > > 20171215: > > r326887 fixes the issue described in the 20171214 UPDATING entry. > > r326888 flips the switch back to building GELI support always. > > > > [...] > > > > I tried the first time r326888 on the APU 2C4 and it worked again - this > > doesn't imply > > that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh > > stated it is > > fixed. > > > > Yes. I've confirmed that zfsboot works with or without the GELI code > compiled in. I've not confirmed that ZFS + GELI partitions work. I haven't > updated my test scripts in tools/boot/genroot.sh to create them yet. If > someone who knows this stuff really well wants to do that for one image > (gpt + zfs + geli) I can (a) test and (b) generalize. > > Warner Oh, my bad. So it is still to use with caution? At that point I can not understand why the build of bootable images is still in progress. People which desperate in need of a bootable image may download the wrong one from the FreeBSD site - and find out the harsh way it is broken. If the build of those images is automated - can this be stopped? -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpidP9wfk0VC.pgp Description: OpenPGP digital signature
Re: r326820 stuck on bootloader
On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann wrote: > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) > "Rodney W. Grimes" schrieb: > > > > > > Hey all! > > > > > > I have just downloaded > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > internal video/keyboard" and then it's stuck. > > > > > > I actually have no idea how to debug, any help would be appreciated. > > > > This snapshot may have broken boot code in it, I had problems > > installing it to a zfs system and had to post install replace > > my zfs boot blocks from those of 20171206. > > > > > > > Thanks in advance, > > > - -- > > > antranigv > > > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I > had no problems > with r326583, but r326584 and beyond had compilation issues). I tried > r326593 and it > worked for me (had issues on a serial console for the PCengine APU2C4). > > From usr/src/UPDATING, tag designated by "20171215": > > 20171215: > r326887 fixes the issue described in the 20171214 UPDATING entry. > r326888 flips the switch back to building GELI support always. > > [...] > > I tried the first time r326888 on the APU 2C4 and it worked again - this > doesn't imply > that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh > stated it is > fixed. > Yes. I've confirmed that zfsboot works with or without the GELI code compiled in. I've not confirmed that ZFS + GELI partitions work. I haven't updated my test scripts in tools/boot/genroot.sh to create them yet. If someone who knows this stuff really well wants to do that for one image (gpt + zfs + geli) I can (a) test and (b) generalize. Warner ___ 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: r326820 stuck on bootloader
On Mon, 18 Dec 2017 05:35:33 -0800 (PST) "Rodney W. Grimes" said > Hey all! > > I have just downloaded > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > decompressed it, trying to boot it on QEMU and I get "Consoles: > internal video/keyboard" and then it's stuck. > > I actually have no idea how to debug, any help would be appreciated. This snapshot may have broken boot code in it, I had problems installing it to a zfs system and had to post install replace my zfs boot blocks from those of 20171206. Like I said; I can confirm r326056 (2017-11-21) doesn't contain the boot regression. Warner advised me to try an earlier version when I indicated I had the problem you also described in this message. Yesterday, Warner indicated he believes he has corrected this regression, as well as add some other goodies. So it should be safe to svn up to the latest revision, after your initial install, and build from there. --Chris > Thanks in advance, > - -- > antranigv -- Rod Grimes rgri...@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" ___ 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: r326820 stuck on bootloader
Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) "Rodney W. Grimes" schrieb: > > > Hey all! > > > > I have just downloaded > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > internal video/keyboard" and then it's stuck. > > > > I actually have no idea how to debug, any help would be appreciated. > > This snapshot may have broken boot code in it, I had problems > installing it to a zfs system and had to post install replace > my zfs boot blocks from those of 20171206. > > > > Thanks in advance, > > - -- > > antranigv > The shit hit the fan at > r326593 (this is what Warner wrote me back, I had no problems with r326583, but r326584 and beyond had compilation issues). I tried r326593 and it worked for me (had issues on a serial console for the PCengine APU2C4). From usr/src/UPDATING, tag designated by "20171215": 20171215: r326887 fixes the issue described in the 20171214 UPDATING entry. r326888 flips the switch back to building GELI support always. [...] I tried the first time r326888 on the APU 2C4 and it worked again - this doesn't imply that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh stated it is fixed. I'm with FreeBSD 12.0-CURRENT #16 r326911: Sat Dec 16 20:49:38 CET 2017 amd64 and it is working well so far. 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). pgpkcLveWTro7.pgp Description: OpenPGP digital signature
Re: r326820 stuck on bootloader
> Ok, > > I will install the snapshot before. but is it fixed now? since after the > installation I will do buildworld, hope it will not brick. The boot code is in a lot of flux right now, so be carefull and pay attention to commit mail.You should keep the memstick image around for repair incase you have issues. > Thanks a lot! > > -- > antranigv > https://antranigv.am/|PGP Key ID : 0xDAB81456 > /* do one thing and do it well */ > > On Dec 18, 2017 5:35 PM, "Rodney W. Grimes" < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > Hey all! > > > > > > I have just downloaded > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > internal video/keyboard" and then it's stuck. > > > > > > I actually have no idea how to debug, any help would be appreciated. > > > > This snapshot may have broken boot code in it, I had problems > > installing it to a zfs system and had to post install replace > > my zfs boot blocks from those of 20171206. > > > > > > > Thanks in advance, > > > - -- > > > antranigv > > > > -- > > Rod Grimes > > rgri...@freebsd.org > > -- Rod Grimes rgri...@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: r326820 stuck on bootloader
Ok, I will install the snapshot before. but is it fixed now? since after the installation I will do buildworld, hope it will not brick. Thanks a lot! -- antranigv https://antranigv.am/|PGP Key ID : 0xDAB81456 /* do one thing and do it well */ On Dec 18, 2017 5:35 PM, "Rodney W. Grimes" < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > Hey all! > > > > I have just downloaded > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > internal video/keyboard" and then it's stuck. > > > > I actually have no idea how to debug, any help would be appreciated. > > This snapshot may have broken boot code in it, I had problems > installing it to a zfs system and had to post install replace > my zfs boot blocks from those of 20171206. > > > > Thanks in advance, > > - -- > > antranigv > > -- > Rod Grimes > rgri...@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: r326820 stuck on bootloader
> Hey all! > > I have just downloaded > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > decompressed it, trying to boot it on QEMU and I get "Consoles: > internal video/keyboard" and then it's stuck. > > I actually have no idea how to debug, any help would be appreciated. This snapshot may have broken boot code in it, I had problems installing it to a zfs system and had to post install replace my zfs boot blocks from those of 20171206. > Thanks in advance, > - -- > antranigv -- Rod Grimes rgri...@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: r326820 stuck on bootloader
On Mon, 18 Dec 2017 13:45:11 +0400 "antranigv" said -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey all! I have just downloaded FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and decompressed it, trying to boot it on QEMU and I get "Consoles: internal video/keyboard" and then it's stuck. I actually have no idea how to debug, any help would be appreciated. There was a problem in this area introduced somewhere in the beginning of December. Warner just landed the correction(s) yesterday (I don't have the revision handy). But it doesn't look like an install image with those chances has been cut yet. Your best option as it stands, it to download: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20171121-r326056-memstick.img.xz Which was cut before the regression. After installation. You can svn up to the latest revision, and build from there. Thereby getting the fixes Warner just added. HTH --Chris Thanks in advance, - -- antranigv https://antranigv.am/|PGP Key ID : 0xDAB81456 /* do one thing and do it well */ -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEfrjE/88u0Kph7jFZYGhrFNq4FFYFAlo3jiIACgkQYGhrFNq4 FFbuWw//du5kjUIR442fkCaCg8honaeZFJ666iwQE1grsSQS74kYzwQ1iSXBnGLV kPt6Nslz3YIRmIqDMuKr31a6zK33bLi7hfKbodIcPNIn/EBUY/D/Pq4FXgqZxu99 MGDAsbLafA3YhyeVuilxrHyDZjaUMDGfJCcBBB57/SxY9mEFT3g/zw1vdVDwpe52 /0bi3u3r/H4l88KGtECSI08WlqnpDyPeGuHImb/xrkQmGbl6PiHwvrijOP639JDf OpDEvLENRIwIBGYxsJPBk3EBPYEgpJKPm1yTU1swU/KJlCpau9O9WrG6OqO8qflO HOCzyhKvXJdXkphlVBLfYk6e8NKwHwc+7ZaMEDJDvqGJ9qFWXanALBkBRyREW61K ZY/8uLhoKNjPmAAMBgwbPihf35zWEXZhKLsaMza5f5NNniLCRrn+I4QhvhWlp10u 20tKX0bAJ+0sjQZInfqXftEwD5Mhw+H1sM1vk8igFFWyrMPCG9t0piV/AseixgDu SZ9IGl5EZSpq/q6Jhcjfxlplwi31SwkVWIRjDqBmzcVcYQO6khszCdi3S1b9Y5El T6gIswPuPWboJFGjPJxQN9V3APNUXT6c2p0aXq8S4NcvSRRmhyEc9mgc/LZrAX4a hwQSVmtJL15qhvBc6TgWEBAaLL9+eX2G9G2Wr1ZEBg5tx/1eY/I= =TQCj -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" ___ 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: UEFI booting survey
On 12/17/17 20:52, Warner Losh wrote: Greetings If you are booting off UEFI and have a bit of an unusual setup, I'd like you to drop me a line. The setup that I'm looking for is any case where you load boot1.efi off one drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that drive, but on a different drive on the system. An example of this may be loading boot1.efi off what FreeBSD would call /dev/ada0p1, but having root come from /dev/ada1p1. It's my belief that due to the fragility of this setup, few, if any, people have this setup. If you do, please take a minute to reply to this message. In the coming months, we're looking at dropping boot1.efi and instead installing /boot/loader.efi onto the ESP (most likely as \efi\freebsd\loader.efi). As part of the move to fully support the UEFI Boot Manager, we're dropping the 'search every device in the system' part of the current boot1 algorithm. It will be possible to configure the system to continue booting (either via the new efibootmgr which will allow any imaginable combination, or possibly via a fallback mechanism needed for the embedded EFIs that have poor UEFI Variable support at the moment), but as part of an upgrade to a future FreeBSD 12, some intervention will be necessary. Please let me know if you have an unusual setup like this. Warner Hi Warner, I have what I guess is an unusual setup, not like what you describe above, but unusual because I tripple-boot my laptop using only the UEFI boot manager to select the OS to boot. I have FreeBSD-current, OpenBSD-current and Windows 10 on different partitions on one SSD. By default it boots FreeBSD. This was accomplished with bcdedit.exe in Windows, but now I realize this could be done with the new efibootmgr. I wanted to try it out, but it panics on my laptop. Sometimes just 'kldload efirt' just panics, sometimes it loads but panics as soon as I run efibootmgr or efivar. How can I help debugging this? Jakob ___ 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"
base packages and subdirs with no regular files
Hi All! I use base package for more then a year now. It works mostly fine. However today I noticed that (some?) blank subdirectories are not removed while updating: --- % LANG=C ls -l /usr/lib/clang drwxr-xr-x 4 root wheel 4 Dec 22 2016 3.9.1 drwxr-xr-x 4 root wheel 4 Mar 3 2017 4.0.0 drwxr-xr-x 4 root wheel 4 Aug 28 14:50 5.0.0 drwxr-xr-x 4 root wheel 4 Dec 8 13:09 5.0.1 --- All previous (to 5.0.1) clang version dirs contain only directories, no regular files: --- % LANG=C ls -l /usr/lib/clang/5.0.0 total 25 drwxr-xr-x 3 root wheel 3 Dec 8 13:09 include drwxr-xr-x 3 root wheel 3 Aug 28 14:50 lib % LANG=C ls -l /usr/lib/clang/5.0.0/include total 1 drwxr-xr-x 2 root wheel 2 Dec 8 13:09 sanitizer % LANG=C ls -l /usr/lib/clang/5.0.0/include/sanitizer total 0 --- I use my personal base package builder and just "pkg upgrade" for, well, upgrades. -- WBR, bsam ___ 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"
r326820 stuck on bootloader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey all! I have just downloaded FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and decompressed it, trying to boot it on QEMU and I get "Consoles: internal video/keyboard" and then it's stuck. I actually have no idea how to debug, any help would be appreciated. Thanks in advance, - -- antranigv https://antranigv.am/|PGP Key ID : 0xDAB81456 /* do one thing and do it well */ -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEfrjE/88u0Kph7jFZYGhrFNq4FFYFAlo3jiIACgkQYGhrFNq4 FFbuWw//du5kjUIR442fkCaCg8honaeZFJ666iwQE1grsSQS74kYzwQ1iSXBnGLV kPt6Nslz3YIRmIqDMuKr31a6zK33bLi7hfKbodIcPNIn/EBUY/D/Pq4FXgqZxu99 MGDAsbLafA3YhyeVuilxrHyDZjaUMDGfJCcBBB57/SxY9mEFT3g/zw1vdVDwpe52 /0bi3u3r/H4l88KGtECSI08WlqnpDyPeGuHImb/xrkQmGbl6PiHwvrijOP639JDf OpDEvLENRIwIBGYxsJPBk3EBPYEgpJKPm1yTU1swU/KJlCpau9O9WrG6OqO8qflO HOCzyhKvXJdXkphlVBLfYk6e8NKwHwc+7ZaMEDJDvqGJ9qFWXanALBkBRyREW61K ZY/8uLhoKNjPmAAMBgwbPihf35zWEXZhKLsaMza5f5NNniLCRrn+I4QhvhWlp10u 20tKX0bAJ+0sjQZInfqXftEwD5Mhw+H1sM1vk8igFFWyrMPCG9t0piV/AseixgDu SZ9IGl5EZSpq/q6Jhcjfxlplwi31SwkVWIRjDqBmzcVcYQO6khszCdi3S1b9Y5El T6gIswPuPWboJFGjPJxQN9V3APNUXT6c2p0aXq8S4NcvSRRmhyEc9mgc/LZrAX4a hwQSVmtJL15qhvBc6TgWEBAaLL9+eX2G9G2Wr1ZEBg5tx/1eY/I= =TQCj -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: what's changed with newsyslog?
On Sun, Dec 17, 2017 at 04:41:29PM -0500, Michael Butler wrote: > On 12/17/17 16:38, Ben Woods wrote: > > On Mon, 18 Dec 2017 at 3:47 am, Michael Butler > > mailto:i...@protected-networks.net>> wrote: > > > > In the past week or so I've been getting warnings like this .. > > > > bzip2: Can't open input file /var/log/snmpd.log.0: No such file or > > directory. > > newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0 > > /var/log/fwlw_clean_log.0' terminated with a non-zero status (1) > > [ .. snip .. ] > > > > > > > Hints? > > > > imb > > > > Could this be related to bapt’s recent change 11 days ago to allow > > newsyslog to use different style of compression commands? > > https://svnweb.freebsd.org/base?view=revision&revision=326617 > > Yes - I reverted to r326616 and the issue no longer appears, > > imb > Should be fixed in r326930, sorry about that Best regards, Bapt signature.asc Description: PGP signature
