Date: Wed, 7 Oct 2020 17:53:15 +0300 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9Cw0LvQvtCy?= <rpalov@e-card.bg> To: "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-stable@freebsd.org Subject: Re: Issues with gptboot loader Message-ID: <ee0b0f78-68ea-6ed1-bb25-5d7cfaae12ff@e-card.bg> In-Reply-To: <5c66c531-4828-60d8-b2ea-ff498ead033f@yandex.ru> References: <bda95d97-c8f6-81f4-198e-fd591ca6ffdf@e-card.bg> <5c66c531-4828-60d8-b2ea-ff498ead033f@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Andrey, Yes, we try UEFI boot and there was no difference. We have one other server SuperMicro, MB "X9DRi-LN4+" , with 7T System Disk, FreeBSD 11.4. To have succesful boot, we need to enter each time the root partition,( mountroot> prompt ), which is already described in the fstab file. After the manual entered (ufs:/dev/da0p2) the boot process mount the partition and booting finish as usual. Maybe it worth to try "vfs.root_mount_always_wait" knob in above case. Cheers Rumen Palov On 2020-10-07 12:49, Andrey V. Elsukov wrote: > On 06.10.2020 13:16, Румен Палов via freebsd-stable wrote: >> Here we do not repeat the steps with zfsloader. >> >> The motherboard is SUPERMICRO X11DPI-NT with lates BIOS firmware. >> >> >> Is any one having issues like this ? >> >> Is this behavior enougth for PR request ? > > Hi, > > Did you try use UEFI? gptboot relies on API provided by BIOS. BIOS > usually is not tested with such large disks and may have bugs and > incompatibilities, especially related to 32-bit limitations. > > The cause when it worked before upgrade, may be that blocks with data > were accessible even with BIOS limitations, but after time file system > may place data into new blocks, that become inaccessible. > > UEFI is targeted to avoid limitations that BIOS have, and GPT is part of > UEFI specification, they both designed for each other. :) >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ee0b0f78-68ea-6ed1-bb25-5d7cfaae12ff>