Re: Issues with gptboot loader
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. :) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Issues with gptboot loader
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. :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Issues with gptboot loader
Hello all, We have following situations with FreeBSD 12.1 Release. Updating to FreeBSD 12 Stable does not change the situation. We have Server with 8T UFS root partition created on top of AVAGO 9361-4i RAID 10 with lastest firmware. It works on FreeBSD 11.1 Stable, before upgrade and boot in normal fashion. After the ugprade the OS to FreeBSD 12.1 or 12.2 it was unable to boot. We backup the content of system disk and start playing with the RAID configuration, changing RAID cards and so on. Our results are as follow with FreeBSD12.1 Release IMG: When the RAID is 8T the booting process freezes on message "gptboot: invalid backup GPT header" When we recreate the RAID of 4T it boots to mountfrom> prompt and to continue, we need to enter the same disk device, which is described in the fstab manualy, etc: ufs:/dev/da0p2 When we recreate the RAID with (500G and 2500G) it boots normal and mount the root partiion. The issues described above are valid only for gptboot loader. With zfs installed there is this message: "Shortening read at 4294967200" from 16 to 15 Then we decide to exclude the RAID card from the setup and connect one 6T drive to the motherboard and here the major factor of succesful boot becomes the presence of usb drive with freebsd install image. When we install FeeBSD on partition with size up to 5T, the system boots normaly mount the root partition and the OS is ready for operations. Here does not matter if the flash drive is present or not. When we install FreeBSD on the full size of the HDD 6T( eg 5.5T usable ) and try to boot with usb drive plugged, the booting process fails with message "can't load kernel". If the flash drive is removed from the Server, the booting proccess goes successful. 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 ? -- Chhers Rumen Palov ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
