Re: Grub kfreebsd with pxe & nfs
В Sun, 26 Oct 2014 21:19:38 +0200
Beeblebrox пишет:
>
> > > * First is, code snippet to get mount_root to use NFS V3 instead of
> > > V2. grub.cfg code should be as below, but does not work
>
> > This should be kFreeBSD
> Still does not work with
> {set kFreeBSD.boot.nfsroot.options="nfsv3"}
> mount_root this time does not hang, but resulting mounted root is still V2
>
> * grub.cfg does not accept kFreeBSD for all parameters, and needs mixed
> syntax. Example:
> menuentry 'FreeBSD 11_amd64' {
>kfreebsd kernel/kernel
> # NOT kFreeBSD kernel/kernel
kfreebsd is not parameter, it is command. kFreeBSD. is variable name
prefix.
>set FreeBSD.acpi_load=YES
>kfreebsd_loadenv device.hints
> # NOT kFreeBSD_loadenv device.hints
>kfreebsd_module kernel/if_sis.ko
> # NOT kFreeBSD_module kernel/if_sis.ko
>
> * I disabled these 3 params:
># set kFreeBSD.vfs.root.mountfrom="nfs:192.168.2.1:/data/amd64"
># set kFreeBSD.vfs.root.mountfrom.options="ro"
># set kFreeBSD.boot.nfsroot.options="nfsv3"
> And saw that FreeBSD boots normally through grub. This means that the {set
> kFreeBSD.*} settings are very likely being ignored as boot settings.
It is possible to verify that those variables are actually passed from
grub to kernel?
> The mount_root is successful because FreeBSD executes what is passed
from dhcp.
>
> Regards.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: workaround install boot on btrfs with windows partition scheme
On Oct 30, 2014, at 2:32 AM, Michael Chang wrote: > Many shipped Windows created it's first partition aligned in 63 > (cylinder) and therefore can't offer enough room for core.img. Even > worse the partitions has been created as logical. > >> sudo /sbin/fdisk -l > Disk /dev/sda: 64.4 GB, 64424509440 bytes, 125829120 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk label type: dos > Disk identifier: 0x0001c622 > > Device Boot Start End Blocks Id System > /dev/sda1 63 2056319 1028128+ b W95 FAT32 > /dev/sda2 * 2058240 12582911961885440f W95 Ext'd > (LBA) > /dev/sda5 2060288 5302271 1620992 82 Linux swap / > Solaris > /dev/sda6 53043204724735920971520 83 Linux > /dev/sda747249408 12580454339277568 83 Linux > > This leaves us currently no option to succeed in installation if boot is > on btrfs, or any other filesystems that block lists can't be used and > core.img must be embedded in order to be reliably addressed. > > The attached patch try to workaround this scenario by placing the core.img > in filesystem's (btrfs) bootloader embedding area if available to overcome > the too small MBR gap which gets loaded by boot.img placed in MBR. > > Please kindly review the patch or suggests for how to fix this scenario > sanely. Why not have a dedicated partition with MBR type code for core.img, equivalent to BIOSBoot currently used on GPT? freedesktop.org has a proposal to use type code 0xEA for this purpose (in part). The boot.img code in the MBR can arbitrarily jump to any LBA, so 0xEA doesn't need to be a primary partition does it? Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: workaround install boot on btrfs with windows partition scheme
On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov wrote: > > I still believe this is more flexible; in particular, /boot/grub on > btrfs has problems with unwritable grubenv (quite a few people are hit > by this now, when openSUSE defaults to single btrfs partition) so > having separate /boot as ext2 makes sense. Hmm, interesting. What's the nature of this problem with grubenv on btrfs? Is the current grubenv code expecting the file to be contiguous, and due to COW on btrfs it ends up not being contiguous? Does setting xattr +C on grubenv fix the problem? Having separate /boot on ext was fine as a short/medium term work around, but /boot on btrfs has use case benefits so it really needs to work eventually. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: workaround install boot on btrfs with windows partition scheme
В Sat, 1 Nov 2014 14:35:57 -0600 Chris Murphy пишет: > > On Oct 30, 2014, at 2:32 AM, Michael Chang wrote: > > > Many shipped Windows created it's first partition aligned in 63 > > (cylinder) and therefore can't offer enough room for core.img. Even > > worse the partitions has been created as logical. > > > >> sudo /sbin/fdisk -l > > Disk /dev/sda: 64.4 GB, 64424509440 bytes, 125829120 sectors > > Units = sectors of 1 * 512 = 512 bytes > > Sector size (logical/physical): 512 bytes / 512 bytes > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > Disk label type: dos > > Disk identifier: 0x0001c622 > > > > Device Boot Start End Blocks Id System > > /dev/sda1 63 2056319 1028128+ b W95 FAT32 > > /dev/sda2 * 2058240 12582911961885440f W95 Ext'd > > (LBA) > > /dev/sda5 2060288 5302271 1620992 82 Linux swap / > > Solaris > > /dev/sda6 53043204724735920971520 83 Linux > > /dev/sda747249408 12580454339277568 83 Linux > > > > This leaves us currently no option to succeed in installation if boot is > > on btrfs, or any other filesystems that block lists can't be used and > > core.img must be embedded in order to be reliably addressed. > > > > The attached patch try to workaround this scenario by placing the core.img > > in filesystem's (btrfs) bootloader embedding area if available to overcome > > the too small MBR gap which gets loaded by boot.img placed in MBR. > > > > Please kindly review the patch or suggests for how to fix this scenario > > sanely. > > Why not have a dedicated partition with MBR type code for core.img, > equivalent to BIOSBoot currently used on GPT? freedesktop.org has a proposal > to use type code 0xEA for this purpose (in part). The boot.img code in the > MBR can arbitrarily jump to any LBA, so 0xEA doesn't need to be a primary > partition does it? > It is rarely needed in simple cases; in complicated cases (btrfs or LVM) we already have space dedicated for core.img. It seems more logical to use this space. Also you still need to tell grub-setup to use this special partition at which point why not extend it to support arbitrary location for core.img? It could be made check partition type and not refuse to install on raw partition for special 0xEA type then as a bonus. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: workaround install boot on btrfs with windows partition scheme
В Sat, 1 Nov 2014 19:34:56 -0600 Chris Murphy пишет: > > On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov wrote: > > > > I still believe this is more flexible; in particular, /boot/grub on > > btrfs has problems with unwritable grubenv (quite a few people are hit > > by this now, when openSUSE defaults to single btrfs partition) so > > having separate /boot as ext2 makes sense. > > Hmm, interesting. What's the nature of this problem with grubenv on btrfs? Is > the current grubenv code expecting the file to be contiguous, and due to COW > on btrfs it ends up not being contiguous? Does setting xattr +C on grubenv > fix the problem? > btrfs code does not execute hooks so block list collection always gives empty block list and file size 0. That's unfortunate, because it also means e.g. progress display is not possible. btrfs data is checksummed so overwriting it would involve recomputing checksums and replacing them. It is not possible to do in place because checksums are checksummed themselves ... you get the idea. btrfs can be on multiple devices so we cannot even expect grubenv to be located on single disk; and blocklists simply do not support it. btrfs can be compressed so you cannot even expect that new data will fit into existing space. > Having separate /boot on ext was fine as a short/medium term work around, but > /boot on btrfs has use case benefits so it really needs to work eventually. > So far nobody suggested solution for grubenv on unwritable location. Not to mention implementation ... ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add support for passing EFI framebuffer into FreeBSD 10.1 and later
On 10/28/2014 16:32, Kris Moore wrote: > Got another patch for review today. > > This patch adds support for FreeBSD's new VT console driver when booting > in EFI mode on FreeBSD 10.1 and later. > > Please let me know any comments, or things that need addressed to get > this merged in. > > Thanks! > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel An updated version of this patch is now in the FreeBSD ports tree: https://svnweb.freebsd.org/ports/head/sysutils/grub2-efi/files/patch-grub-efi-framebuffer?revision=371769&view=co This updated version adds some ACPI detection / hints that the FreeBSD kernel requires to UEFI boot on most systems. Thanks! -- Kris Moore PC-BSD Software iXsystems ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
