Re: Boot failure, amd64 (HP EliteBook 650 G10)

Hi Graham, On 3/9/24 10:52, Graham Perrin wrote: amd64. AFAICT the EliteBook 650 G10 was introduced around May 2023. Does anything in the three photographs tally with a report in Bugzilla? Any overlap with

Re: Boot failure, amd64 (HP EliteBook 650 G10)

I'd love to borrow one of these machines fir a week or so. Warner On Sat, Mar 9, 2024, 2:52 AM Graham Perrin wrote: > > > amd64. > > AFAICT the EliteBook 650 G10 was introduced around May 2023. > > Does anything in the three photographs t

Boot failure, amd64 (HP EliteBook 650 G10)

amd64. AFAICT the EliteBook 650 G10 was introduced around May 2023. Does anything in the three photographs tally with a report in Bugzilla? Any overlap with fo

Re: 14.0 boot failure

On 09/08/2023 07:10, Kevin Oberman wrote: I closed the ticket. I wasn't aware of a ticket, thanks for the update. Yesterday's 09c20a293280 boots fine for me.

Re: 14.0 boot failure

I closed the ticket. I think I may have pulled sources just as the MAXCPU size was updated. I did another pull the next day and it built and is running fine. On Tue, Aug 8, 2023 at 10:56 AM Matthias Apitz wrote: > > A kernel git cloned on August 6 boots fine. > > -- > Matthias Apitz > E-mail: g.

Re: 14.0 boot failure

A kernel git cloned on August 6 boots fine. -- Matthias Apitz E-mail: g...@unixarea.de WWW: http://www.unixarea.de/ phone: +49-170-4527211 Am 08.08.2023 19:39, schrieb Graham Perrin: On 05/08/2023 00:45, Kevin Oberman wrote: A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fai

Re: 14.0 boot failure

On 05/08/2023 00:45, Kevin Oberman wrote: A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails to boot. … I refrained from updating after reading this. Any news? TIA OpenPGP_signature Description: OpenPGP digital signature

14.0 boot failure

A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails to boot. This is the output of the boot attempt: VT-x: PAT,HLT, MTF, PAUSE, EPT, UG, VPID, VID, Post Intr TSC: P-state invariant, performance statistics real memory = 25769883776 (24576 MB) panic: vm_phys_enq_range: page 0xff

Boot failure on a ThinkPad T14/Ryzen 7 Pro 6850U

Hello all! I confess that this issue exists on 13.1 and 13.2 in addition to the 14-CURRENT snapshot from last week but hopefully there is more to try. This Pr covers the fundamental issue and I have been updating it a I try suggestions: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2707

FYI: Example USB3 boot failure on RPi4B ZFS-on-root system booting main: uhub_reattach_port notices involved

In upgrading from (grabbed from a system not updated yet): # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n246411-a6ca7519f89c-dirty: Sat May 1 19:07:50 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NO

FreeBSD 12.2-RC1 install media boot failure

I just tried to boot FreeBSD 12.1-RC1 in KVM/QEMU. Specifically, I booted FreeBSD-12.2-RC1-amd64-memstick.img as a virtual USB HDD. The console was flooded with error messages about "Device not configured"and errors from the rc scripts, then it hanged. Screenshot linked. Any ideas? http://bayi

Re: Boot failure on refreshed Dell Precision 7550

> On 10. Jul 2020, at 16:43, Shawn Webb wrote: > > On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: >> >> >>> On 10. Jul 2020, at 16:25, Shawn Webb wrote: >>> >>> Hey all, >>> >>> I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD >>> on it and UEFI boot fai

Re: Boot failure on refreshed Dell Precision 7550

> On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > Hey all, > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > on it and UEFI boot failed. The screen goes black immedately when > selecting the memstick and around ten to twenty seconds later, the > system reboots. > >

Re: Boot failure on refreshed Dell Precision 7550

On Fri, Jul 10, 2020 at 09:43:59AM -0400, Shawn Webb wrote: > On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: > > > > > > > On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > > > > > Hey all, > > > > > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > > > on

Re: Boot failure on refreshed Dell Precision 7550

On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: > > > > On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > > > Hey all, > > > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > > on it and UEFI boot failed. The screen goes black immedately when > > selecting

Boot failure on refreshed Dell Precision 7550

Hey all, I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD on it and UEFI boot failed. The screen goes black immedately when selecting the memstick and around ten to twenty seconds later, the system reboots. I'm thinking there might be a bug in the UEFI loader. I have zero exp

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

On Tue, 27 Aug 2019 08:43:53 +0300 Toomas Soome wrote: > > On 27 Aug 2019, at 08:08, Warner Losh wrote: > > > > On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran > > wrote: > >> On 8/26/19 5:22 AM, O. Hartmann wrote: > >> > >>> > >>> the other thing is the weird Lenovo handli

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Wed, 21 Aug 2019 22:34:21 +0300 Toomas Soome schrieb: > > On 21 Aug 2019, at 22:30, O. Hartmann wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Am Wed, 21 Aug 2019 22:14:46 +0300 > > Toomas Soome mailto:tso...@me.co

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Wed, 21 Aug 2019 22:29:29 + greg@unrelenting.technology schrieb: > August 22, 2019 12:23 AM, "O. Hartmann" wrote: > > > Am Wed, 21 Aug 2019 15:58:24 -0500 > > Karl Denninger schrieb: > > > >> I would see if you can get REFIND loaded and

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

> On Aug 26, 2019, at 11:43 PM, Toomas Soome wrote: > > For me it is still confusing if this is path versus upper-lower capital > chars. > > If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page > 91), then the file name should also end with .EFI. (and yes, I know, th

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

> On 27 Aug 2019, at 08:08, Warner Losh wrote: > > On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran > wrote: > >> On 8/26/19 5:22 AM, O. Hartmann wrote: >> >>> >>> the other thing is the weird Lenovo handling of the UEFI vars. The only >> way to >>> boot the E540 (after

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

On 2019-08-26 23:08, Warner Losh wrote: > > That's the first machine I've seen where you have to set the name like > that... there is a larger story here and we are getting incomplete reports > because it doesn't quite make sense yet... > > But there are enough reasons not to do that by default. Fo

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran wrote: > On 8/26/19 5:22 AM, O. Hartmann wrote: > > > > > the other thing is the weird Lenovo handling of the UEFI vars. The only > way to > > boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding > > everything) was to set the loader's n

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

On 8/26/19 5:22 AM, O. Hartmann wrote: the other thing is the weird Lenovo handling of the UEFI vars. The only way to boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi. Setting the variable to contain EFI/BOOT/

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

On Thu, 22 Aug 2019 08:58:55 +0300 Toomas Soome wrote: > > On 22 Aug 2019, at 06:04, O. Hartmann wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Am Wed, 21 Aug 2019 22:29:29 + > > greg@unrelenting.technology schrieb: > > > >> August 22, 2019 12:23 AM, "O. Hart

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

> On 22 Aug 2019, at 06:04, O. Hartmann wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am Wed, 21 Aug 2019 22:29:29 + > greg@unrelenting.technology schrieb: > >> August 22, 2019 12:23 AM, "O. Hartmann" wrote: >> >>> Am Wed, 21 Aug 2019 15:58:24 -0500 >>> Karl Denninger

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

August 22, 2019 12:23 AM, "O. Hartmann" wrote: > Am Wed, 21 Aug 2019 15:58:24 -0500 > Karl Denninger schrieb: > >> I would see if you can get REFIND loaded and use that. I have a Lenovo >> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot >> (e.g. Win10 and FreeBSD) easily.

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Wed, 21 Aug 2019 15:58:24 -0500 Karl Denninger schrieb: > BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Am Wed, 21 Aug 2019 22:34:21 +0300 > > Toomas Soome schrieb: > > > > >> On 21 Aug 2019, at 22:30, O. Hartmann wrote: > > >>

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

> On 22 Aug 2019, at 00:07, Clay Daniels Jr. wrote: > > I would agree with Karl & Steffen about using rEFInd. It really gives you a > lot more control of your computers boot. Take a look at Rod Smith's pages: > http://www.rodsbooks.com/refind/ > > I use it to triple boot Windows 10, MX Linux,

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

I would agree with Karl & Steffen about using rEFInd. It really gives you a lot more control of your computers boot. Take a look at Rod Smith's pages: http://www.rodsbooks.com/refind/ I use it to triple boot Windows 10, MX Linux, and FreeBSD. Clay On Wed, Aug 21, 2019 at 3:59 PM Karl Denninger

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am Wed, 21 Aug 2019 22:34:21 +0300 > Toomas Soome schrieb: > > >> On 21 Aug 2019, at 22:30, O. Hartmann wrote: > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA256 > >> > >> Am Wed, 21 Aug 2019 22:14:46 +0300 > >> Toomas Soome mailto:

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

On Wed, Aug 21, 2019 at 2:50 PM O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am Wed, 21 Aug 2019 22:34:21 +0300 > Toomas Soome schrieb: > > > > On 21 Aug 2019, at 22:30, O. Hartmann wrote: > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > >

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Wed, 21 Aug 2019 22:34:21 +0300 Toomas Soome schrieb: > > On 21 Aug 2019, at 22:30, O. Hartmann wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Am Wed, 21 Aug 2019 22:14:46 +0300 > > Toomas Soome mailto:tso...@me.co

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Wed, 21 Aug 2019 22:34:21 +0300 Toomas Soome schrieb: > > On 21 Aug 2019, at 22:30, O. Hartmann wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Am Wed, 21 Aug 2019

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

O. Hartmann wrote in <20190821145234.6fe455b4@freyja>: |I ran into serious trouble booting several boxes off UEFI. On modern \ |hardware, |the ESP is around 200 - 300 MB in size and usually I install |/efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On \ |some older |hardware,

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Wed, 21 Aug 2019 22:14:46 +0300 Toomas Soome schrieb: > If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you > should have > fs0: or like for ESP. > > rgds, > toomas Hello, I can't even stop to gain access to the shel

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

> On 21 Aug 2019, at 22:30, O. Hartmann wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am Wed, 21 Aug 2019 22:14:46 +0300 > Toomas Soome mailto:tso...@me.com>> schrieb: > >> If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you >> should have >> fs0:

HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

I ran into serious trouble booting several boxes off UEFI. On modern hardware, the ESP is around 200 - 300 MB in size and usually I install /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some older hardware, specifically on a Lenovo E540 with latest available firmware (2.28), w

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you should have fs0: or like for ESP. rgds, toomas > On 21 Aug 2019, at 20:58, O. Hartmann wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I ran into serious trouble booting several boxes off UEFI. On mo

HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I ran into serious trouble booting several boxes off UEFI. On modern hardware, the ESP is around 200 - 300 MB in size and usually I install /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some older hardware, specifically on a Len

Re: CURRENT >r349150: boot failure in rc.conf.local

On Tue, Jun 18, 2019 at 11:49:58AM -0700, Conrad Meyer wrote: > Hi everyone, > > Please find a proposed fix in https://reviews.freebsd.org/D20686 . > > I didn't notice this thread because I'm already subscribed to current > and CC's don't display any differently in my mail reader. (I don't > rea

Re: CURRENT >r349150: boot failure in rc.conf.local

Hi everyone, Please find a proposed fix in https://reviews.freebsd.org/D20686 . I didn't notice this thread because I'm already subscribed to current and CC's don't display any differently in my mail reader. (I don't read every thread on current.) Take care, Conrad On Tue, Jun 18, 2019 at 11:0

Re: CURRENT >r349150: boot failure in rc.conf.local

Looping in the committer of r349154. On June 18, 2019 8:39:34 AM PDT, Takanori Watanabe wrote: >On Tue, Jun 18, 2019 at 09:03:17AM -0400, Jung-uk Kim wrote: >> On 19. 6. 18., O. Hartmann wrote: >> > On all CURRENT boxes running CURRENT > r349150 we face the very >same bo

Re: CURRENT >r349150: boot failure in rc.conf.local

On Tue, Jun 18, 2019 at 09:03:17AM -0400, Jung-uk Kim wrote: > On 19. 6. 18., O. Hartmann wrote: > > On all CURRENT boxes running CURRENT > r349150 we face the very same boot > > failure, if /etc/rc.conf.local is present (i.e. on CURRENT, 13.0-CURRENT #7 > > r349169: Tue J

Re: CURRENT >r349150: boot failure in rc.conf.local

On 19. 6. 18., O. Hartmann wrote: > On all CURRENT boxes running CURRENT > r349150 we face the very same boot > failure, if /etc/rc.conf.local is present (i.e. on CURRENT, 13.0-CURRENT #7 > r349169: Tue Jun 18 10:34:13 CEST 2019 amd64): > > The box boots and thentries

CURRENT >r349150: boot failure in rc.conf.local

On all CURRENT boxes running CURRENT > r349150 we face the very same boot failure, if /etc/rc.conf.local is present (i.e. on CURRENT, 13.0-CURRENT #7 r349169: Tue Jun 18 10:34:13 CEST 2019 amd64): The box boots and thentries to start services denominated in /etc/rc.conf.local, like net/openl

Re: r335282: first stage boot failure on PCengines APU 2C4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Mon, 18 Jun 2018 07:42:20 -0600 Warner Losh schrieb: > On Mon, Jun 18, 2018, 3:01 AM Olivier Cochard-Labbé > wrote: > > > On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann > > wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA51

Re: r335282: first stage boot failure on PCengines APU 2C4

On Mon, Jun 18, 2018, 3:01 AM Olivier Cochard-Labbé wrote: > On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Running CURRENT as routing and firewalling appliance on a PCengines APU > > 2C4 with the > > latest (official) SEAB

Re: r335282: first stage boot failure on PCengines APU 2C4

On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Running CURRENT as routing and firewalling appliance on a PCengines APU > 2C4 with the > latest (official) SEABios available for this product, NanoBSD (FreeBSD > CURRENT FreeBSD > 12.0-CURR

r335282: first stage boot failure on PCengines APU 2C4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Running CURRENT as routing and firewalling appliance on a PCengines APU 2C4 with the latest (official) SEABios available for this product, NanoBSD (FreeBSD CURRENT FreeBSD 12.0-CURRENT #60 r335278: Sun Jun 17 07:57:20 CEST 2018 amd64)is unable to b

Re: Boot failure: panic: No heap setup

> On 30 Mar 2018, at 18:03, Stefan Esser wrote: > > Am 29.03.18 um 07:15 schrieb Toomas Soome: >> >> >>> On 29 Mar 2018, at 01:06, Stefan Esser wrote: >>> >>> Am 28.03.18 um 22:28 schrieb Warner Losh: > Hmmm, the code references point into the boot loader code - I had > expected tha

Re: Boot failure: panic: No heap setup

Am 29.03.18 um 07:15 schrieb Toomas Soome: > > >> On 29 Mar 2018, at 01:06, Stefan Esser wrote: >> >> Am 28.03.18 um 22:28 schrieb Warner Losh: Hmmm, the code references point into the boot loader code - I had expected that there is a problem in the kernel, not the boot loader. >>

Re: Boot failure: panic: No heap setup

> On 29 Mar 2018, at 01:06, Stefan Esser wrote: > > Am 28.03.18 um 22:28 schrieb Warner Losh: >>> Hmmm, the code references point into the boot loader code - I had >>> expected that there is a problem in the kernel, not the boot loader. >>> [1] https://svnweb.freebsd.org/base/head/st

Re: Boot failure: panic: No heap setup

Am 28.03.18 um 22:28 schrieb Warner Losh: > > Hmmm, the code references point into the boot loader code - I had > > expected that there is a problem in the kernel, not the boot loader. > > > >> [1] > >> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 >

Re: Boot failure: panic: No heap setup

ic: No heap setup > >>> > >>> I recovered by booting from an alternate boot device and kept my system > >>> running until today, where I decided to give the LUA boot another try. > >>> > >>> The boot failure happened again, with identical me

Re: Boot failure: panic: No heap setup

gt; (i.e. did not print the initial FreeBSD version line), but instead >>> stopped >>> with: >> >> >> Oy =/ >> >>> panic: No heap setup >>> >>> I recovered by booting from an alternate boot device and kept my system >>&g

Re: Boot failure: panic: No heap setup

recovered by booting from an alternate boot device and kept my system running until today, where I decided to give the LUA boot another try. The boot failure happened again, with identical message: panic: No heap setup Hmm... that's an sbrk panic [1], indicating that setheap hadn't b

Re: Boot failure: panic: No heap setup

from an alternate boot device and kept my system > running until today, where I decided to give the LUA boot another try. > > The boot failure happened again, with identical message: > > panic: No heap setup Hmm... that's an sbrk panic [1], indicating that setheap hadn

Boot failure: panic: No heap setup

give the LUA boot another try. The boot failure happened again, with identical message: panic: No heap setup I tried booting a GENERIC kernel, but only rebuilding the boot loader (gptzfsloader in my case) without LUA support fixed the issue for me ... The system is -CURRENT (built today) on

Re: r324353: boot failure: failed with error 19

On Fri, 2017-10-06 at 22:33 +0200, O. Hartmann wrote: > First of all, I think something has changed, since /dev/ufs doesn't get > populated anymore > by usage of "gpart label" command. Second, there is a high chance that I > messed up > NanoBSD a bit, a couple of days ago I tried to sync with the

Re: r324353: boot failure: failed with error 19

Am Fri, 6 Oct 2017 15:27:52 +0200 (CEST) Trond Endrestøl schrieb: > On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote: > > > I run a small appliance on an APU from PCengines. This box is bootet via SD > > card, the > > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning

Re: r324353: boot failure: failed with error 19

Am Fri, 6 Oct 2017 07:10:44 -0700 Warner Losh schrieb: > On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann wrote: > > > I run a small appliance on an APU from PCengines. This box is bootet via > > SD card, the > > image is created by a modified NanoBSD, which creates GPT/UEFI > > partitioning and boo

Re: r324353: boot failure: failed with error 19

On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann wrote: > I run a small appliance on an APU from PCengines. This box is bootet via > SD card, the > image is created by a modified NanoBSD, which creates GPT/UEFI > partitioning and booting > images. > > That worked until two days ago (I do not track the

Re: r324353: boot failure: failed with error 19

On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote: > I run a small appliance on an APU from PCengines. This box is bootet via SD > card, the > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning > and booting > images. > > That worked until two days ago (I do not track th

r324353: boot failure: failed with error 19

I run a small appliance on an APU from PCengines. This box is bootet via SD card, the image is created by a modified NanoBSD, which creates GPT/UEFI partitioning and booting images. That worked until two days ago (I do not track the revision numer) when I wrote (via dd) the last image out. Toda

Re: r316677:EFI boot failure: Can't load kernel

> On 12. apr 2017, at 22:48, Chris H wrote: > > On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA > mailto:i...@amail.plala.or.jp>> wrote > >>> replaced /boot/loader with /boot/loader.old (which was from end of >>> March) >>> >>> copied /boot/loader.efi from the r315864 snapshot USB

Re: r316677:EFI boot failure: Can't load kernel

> On 12. apr 2017, at 22:48, Chris H wrote: > > On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA > mailto:i...@amail.plala.or.jp>> wrote > >>> replaced /boot/loader with /boot/loader.old (which was from end of >>> March) >>> >>> copied /boot/loader.efi from the r315864 snapshot USB

Re: r316677:EFI boot failure: Can't load kernel

On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA wrote > > replaced /boot/loader with /boot/loader.old (which was from end of > > March) > > > > copied /boot/loader.efi from the r315864 snapshot USB image > > into /boot/loader.efi of the broken systems. > > > > Aprt from the fact tha

Re: r316677:EFI boot failure: Can't load kernel

>> I'm using dell xps12 9q33 (core i7-4500U) with an internal SSD. >> As reporting Bug 218473, I cannot boot /boot/loader.efi after >> r316585. Replacing only loader.efi before r316584, I can boot >> again. > > Yea, it seems to be the same issue for both of you, now have some work to do > to i

Re: r316677:EFI boot failure: Can't load kernel

> On 11. apr 2017, at 17:42, Masachika ISHIZUKA wrote: > >> replaced /boot/loader with /boot/loader.old (which was from end of >> March) >> >> copied /boot/loader.efi from the r315864 snapshot USB image >> into /boot/loader.efi of the broken systems. >> >> Aprt from the fact that I don't know

Re: r316677:EFI boot failure: Can't load kernel

> replaced /boot/loader with /boot/loader.old (which was from end of > March) > > copied /boot/loader.efi from the r315864 snapshot USB image > into /boot/loader.efi of the broken systems. > > Aprt from the fact that I don't know which one is broken, the boxes are > booting again. > > Conclusion

Re: r316677:EFI boot failure: Can't load kernel

On Mon, 10 Apr 2017 21:04:04 +0200 "O. Hartmann" wrote: > Am Mon, 10 Apr 2017 21:59:00 +0300 > Toomas Soome schrieb: > > > > On 10. apr 2017, at 21:04, O. Hartmann > > > wrote: > > > > > > Am Mon, 10 Apr 2017 16:14:21 +0300 > > > Toomas Soome schrieb: > > > > > >>> On 10. apr 2017, at 1

Re: r316677:EFI boot failure: Can't load kernel

On Mon, 10 Apr 2017 21:04:04 +0200 "O. Hartmann" wrote: > Am Mon, 10 Apr 2017 21:59:00 +0300 > Toomas Soome schrieb: > > > > On 10. apr 2017, at 21:04, O. Hartmann > > > wrote: > > > > > > Am Mon, 10 Apr 2017 16:14:21 +0300 > > > Toomas Soome schrieb: > > > > > >>> On 10. apr 2017, at 1

Re: r316677:EFI boot failure: Can't load kernel

Am Mon, 10 Apr 2017 21:59:00 +0300 Toomas Soome schrieb: > > On 10. apr 2017, at 21:04, O. Hartmann wrote: > > > > Am Mon, 10 Apr 2017 16:14:21 +0300 > > Toomas Soome schrieb: > > > >>> On 10. apr 2017, at 15:58, Hartmann, O. wrote: > >>> > >>> After today's update to r316677, some UEFI b

Re: r316677:EFI boot failure: Can't load kernel

> On 10. apr 2017, at 21:04, O. Hartmann wrote: > > Am Mon, 10 Apr 2017 16:14:21 +0300 > Toomas Soome schrieb: > >>> On 10. apr 2017, at 15:58, Hartmann, O. wrote: >>> >>> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740 >>> XEON) reject to boot properly. They die immed

Re: r316677:EFI boot failure: Can't load kernel

Am Mon, 10 Apr 2017 16:14:21 +0300 Toomas Soome schrieb: > > On 10. apr 2017, at 15:58, Hartmann, O. wrote: > > > > After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740 > > XEON) reject to boot properly. They die immediately after > > loading /boot/loader.efi and jump into loa

Re: r316677:EFI boot failure: Can't load kernel

> On 10. apr 2017, at 15:58, Hartmann, O. wrote: > > After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740 > XEON) reject to boot properly. They die immediately after > loading /boot/loader.efi and jump into loader prompt: > > [...] > \ > can't load 'kernel' > > > I had to in

r316677:EFI boot failure: Can't load kernel

After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740 XEON) reject to boot properly. They die immediately after loading /boot/loader.efi and jump into loader prompt: [...] \ can't load 'kernel' I had to investigate with an USB flashdrive the filesystem, but everything seems to b

Re: Boot failure - svn up from this morning

Hi, I had the same problems, however, there is one more regression after these changes. It stably reproduces if you use EFI_STAGING_SIZE. I have custom FreeBSD distributive which has a sufficiently large mfsroot which is loaded through UEFI mode. To solve the problem, it was suggested to increase

Re: Boot failure - svn up from this morning

On 7 Mar 2017, at 16:50, Chris H wrote: On Tue, 07 Mar 2017 16:27:59 -0330 "Jonathan Anderson" wrote Hi, On 5 Mar 2017, at 20:31, Chris H wrote: OK copying the boot.efi from the install DVD will only hose the system (EFI). Before I attempt to do the same thing... what do you mean by "ho

RE: Boot failure - svn up from this morning

> From: Alex Deiter [mailto:alex.dei...@gmail.com] > Hello Dexuan, > This issue reproduced at least for 4 different HW platform > How can I help you resolve this issue ? > > The same result for r314862: Hi guys, Sorry, I had to commit a new patch (r314891) just now to really fix the off-by-one bu

RE: Boot failure - svn up from this morning

ima > ; Sepherosa Ziehau > Subject: Re: Boot failure - svn up from this morning > > Hello Dexuan, > > This issue reproduced at least for 4 different HW platform: > > Supermicro 6037R-TXRF > Supermicro A1SRM-2758F > Supermicro X9SCM-F > Gigabyte GA-C1037UN-EU &g

Re: Boot failure - svn up from this morning

yaneurabeya) ; Michael Tuexen >> ; Roberto Rodriguez Jr ; Guido >> Falsi ; Warner Losh ; Ultima >> ; Sepherosa Ziehau >> Subject: RE: Boot failure - svn up from this morning >> >>> From: Alex Deiter [mailto:alex.dei...@gmail.com] >>> Sent: Tuesday, Mar

Re: Boot failure - svn up from this morning

On Tue, 07 Mar 2017 16:27:59 -0330 "Jonathan Anderson" wrote > Hi, > > On 5 Mar 2017, at 20:31, Chris H wrote: > > > OK copying the boot.efi from the install DVD will only > > hose the system (EFI). > > Before I attempt to do the same thing... what do you mean by "hose the > system"? Is the c

Re: Boot failure - svn up from this morning

Hi, On 5 Mar 2017, at 20:31, Chris H wrote: OK copying the boot.efi from the install DVD will only hose the system (EFI). Before I attempt to do the same thing... what do you mean by "hose the system"? Is the correct recovery path to build a new USB image with "make release" post-r314828?

Re: Boot failure - svn up from this morning

On Mon, 6 Mar 2017 04:01:04 + Dexuan Cui wrote > > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > > curr...@freebsd.org] On Behalf Of Dexuan Cui > > Hi Chris, > > Thank you very much for the screenshots!!! > > > > On the host there is a 1MB LoaderData memory range, which sp

RE: Boot failure - svn up from this morning

> From: Dexuan Cui > I committed r314770 just now to minimize the impact: > https://svnweb.freebsd.org/base?view=revision&revision=314770 > > Please let me know in case this can't solve the issue. Sorry, r314770 has a bug, so I had to commit r314828 for this: https://svnweb.freebsd.org/base?vie

RE: Boot failure - svn up from this morning

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > curr...@freebsd.org] On Behalf Of Dexuan Cui > Hi Chris, > Thank you very much for the screenshots!!! > > On the host there is a 1MB LoaderData memory range, which splits > the big Conventional Memory range into a small one (15MB)

RE: Boot failure - svn up from this morning

> From: Dexuan Cui > Sent: Monday, March 6, 2017 13:10 > Can you please try the below patch? > https://reviews.freebsd.org/D9904 > You can find the URL of the "Download Raw Diff" in the page and > 'wget' the patch and then apply it. > > It should be able to fix the recent UEFI-boot issue introduce

Re: Boot failure - svn up from this morning

On Mon, 6 Mar 2017 04:01:04 + Dexuan Cui wrote > > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > > curr...@freebsd.org] On Behalf Of Dexuan Cui > > Hi Chris, > > Thank you very much for the screenshots!!! > > > > On the host there is a 1MB LoaderData memory range, which sp

Re: Boot failure - svn up from this morning

On Mon, 6 Mar 2017 03:00:20 + Dexuan Cui wrote > > From: Chris H [mailto:bsd-li...@bsdforge.com] > > Sent: Monday, March 6, 2017 09:57 > > > Thanks! I'm eager to see your screenshots. > > > The line whose "Physical" address contains 2MB is the most interesting to > > > me. And please at least

RE: Boot failure - svn up from this morning

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > curr...@freebsd.org] On Behalf Of Dexuan Cui > Hi Chris, > Thank you very much for the screenshots!!! > > On the host there is a 1MB LoaderData memory range, which splits > the big Conventional Memory range into a small one (15MB)

RE: Boot failure - svn up from this morning

> From: Chris H [mailto:bsd-li...@bsdforge.com] > Sent: Monday, March 6, 2017 09:57 > > Thanks! I'm eager to see your screenshots. > > The line whose "Physical" address contains 2MB is the most interesting to > > me. > > And please at least post the other lines around the line. > OK. Her you go. I

Re: Boot failure - svn up from this morning

Thank you verymuch for the reply, Dexuan! On Mon, 6 Mar 2017 00:34:19 + Dexuan Cui wrote > > From: Chris H [mailto:bsd-li...@bsdforge.com] > > > Hi Alex, > > > Thanks for the info! > > > Unluckily it looks the delay() in my patch didn't work here somehow, so > > > the screen scrolled up so q

RE: Boot failure - svn up from this morning

> From: Chris H [mailto:bsd-li...@bsdforge.com] > OK copying the boot.efi from the install DVD will only > hose the system (EFI). Do you mean copying the boot.efi from the install DVD doesn't work? If so we need to build a good boot.efi with the CURRENT code + reverting the offending commit. > So

RE: Boot failure - svn up from this morning

> From: Chris H [mailto:bsd-li...@bsdforge.com] > > Hi Alex, > > Thanks for the info! > > Unluckily it looks the delay() in my patch didn't work here somehow, so the > > screen scrolled up so quickly that we're unable to see the output clearly... > > :-( > > > > Luckily we can use this new method:

Re: Boot failure - svn up from this morning

On Sun, 05 Mar 2017 15:14:52 -0800 "Chris H" wrote > On Sun, 5 Mar 2017 10:48:32 + Dexuan Cui wrote > > > > From: Alex Deiter > > > Sent: Sunday, March 5, 2017 03:32 > > > > > > Hello, > > > > > > Screenshot: boot with patched loader: > > > Video: boot with patched loader: > > > > Hi Ale

Re: Boot failure - svn up from this morning

On Sun, 5 Mar 2017 10:48:32 + Dexuan Cui wrote > > From: Alex Deiter > > Sent: Sunday, March 5, 2017 03:32 > > > > Hello, > > > > Screenshot: boot with patched loader: > > Video: boot with patched loader: > > Hi Alex, > Thanks for the info! > Unluckily it looks the delay() in my patch did

RE: Boot failure - svn up from this morning

> From: Alex Deiter > Sent: Sunday, March 5, 2017 03:32 > > Hello, > > Screenshot: boot with patched loader: > Video: boot with patched loader: Hi Alex, Thanks for the info! Unluckily it looks the delay() in my patch didn't work here somehow, so the screen scrolled up so quickly that we're una

Re: Boot failure - svn up from this morning

On Fri, Mar 03, 2017 at 02:30:08PM +0100, Michael Tuexen wrote: > > On 3 Mar 2017, at 12:59, Dexuan Cui wrote: > > > >> From: Dexuan Cui > >> Sent: Friday, March 3, 2017 19:50 > >>> From: Alex Deiter > >>> Sent: Friday, March 3, 2017 17:22 > >>> Hello, > >>> The same issue with FreeBSD 12.0-CURRE

  1   2   3   >