Re: [PATCH] Install to LVM PVs
В Fri, 27 Sep 2013 14:48:33 +0200 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com пишет: On 27.09.2013 12:39, Gabriel de Perthuis wrote: Le 26/09/2013 10:53, Vladimir 'φ-coder/phcoder' Serbinenko a écrit: On 25.09.2013 14:39, Gabriel de Perthuis wrote: Hello, This patch lets grub install to a reserved area in LVM physical volumes. These bootloader areas can be created with LVM 2.02.99 and the --bootloaderareasize argument to pvcreate and vgconvert. I tested it in QEMU, installing to and booting a disk that contains a PV and no partition table. This is not how the use of this area was imagined. There are couple of subtleties which your patch didn't take in account. Currently there is joint developpement with LVM guys but it wasn't published yet. For anyone else who may be interested, apparently patches exist and are waiting for Peter Rajnoha to finish them. They haven't been posted or discussed publicly and I've never seen them. According to Vladimir: the zone will be subdivided to cover more cases and the agreement was to use pvs to get offsets rather than having own code for this As shipped in 2.02.99, pvs exposes exactly one ba_start/ba_size area. Other areas will have to use extra extension fields and extra fields in the pvs output, to be compatible with released versions of LVM. No, you didn't understand: this area will have another header, GRUB one which will subdivide it. LVM gives us area and we take care of subdivision. Did anything happen with it? Do you have any pointers to suggested design? Parsing pvs output would be easy, and will behave exactly the same as this patch. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel pgp0g8I_NqNpV.pgp Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Live-ISO's over PXE+HTTP using loopback
Hi.
I'm trying to boot several live ISO's using my PXE-boot server and Grub
loopback. ISO's are fetched by Grub from an HTTP server on the same host.
* I can boot the kernels of all live ISO's through PXE+HTTP transfer.
* Boot process fails at mount-root stage, where rootfs will obviously be
mounted from the ISO. Error message is usually similar could not find the
ISO or unable to find medium containing a live file system.
* A sample menu entry I'm using (thanks to previous answers from this list):
menuentry Debian-testing-i386-lxde.iso --class gnu-linux --class gnu
--class os {
set root=http,192.168.2.100
set isofile=debian-testing-i386-lxde.iso
loopback loop0 ($root)/iso/$isofile
linux (loop0)/install.386/vmlinuz
initrd (loop0)/install.386/initrd.gz
As the first step of solving this problem: Is ISO modification the only choice,
or is it possible to boot a normal ISO by passing the correct parameters to
grub.cfg? I think the problem could be that ramdisk fails to be created when
PXE is involved.
Regards
--
FreeBSD_amd64_11-Current_RadeonKMS
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
On Sat, Feb 14, 2015 at 08:23:45PM +0300, Andrei Borzenkov wrote: В Wed, 11 Feb 2015 08:20:04 + Jan Beulich jbeul...@suse.com пишет: On 10.02.15 at 22:27, daniel.ki...@oracle.com wrote: After some testing we have found at least one machine on which this thing does not work. It is Dell PowerEdge R820 with latest firmware. Machine crashes/stops because early 32-bit code is not relocatable and must live under 0x10 address. (side note: I am surprised how it worked without any issue until now; Multiboot protocol, any version, does not guarantee that OS image will be loaded at specified/requested address; How does it not? It's an ELF binary without relocations that's being loaded - I can't see how such could be validly loaded anywhere but at the virtual address(es) its program header states (and I don't know whether grub [1 or 2] would correctly process relocations if there were any, but I doubt it). grub2 relocates own modules when loading them. It does not do Great! However, it also ignores MULTIBOOT_TAG_TYPE_EFI_BS flag and overwrite BS if it leaves in region requested by image. It is a bug which I have just discovered. I will fix it. relocation when loading Xen binary, but it does not sound impossible. Ugh... You are right. I was confused because multiboot2 command just allocate memory outside reserved regions. I thought that this is final destination. However, later if you execute boot command then image is relocated to final destination. Facepalm! Anyway, we must support relocatable images in multiboot2 protocol. I think that image (any format, e.g. PE) could inform loader that it can live anywhere below 4 GiB by setting special flag in multiboot2 header. Or ELF image could have relocation section which would be interpreted by loader. Both approaches make sense and are feasible. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Add a module for retrieving SMBIOS information
On Wed, Feb 11, 2015 at 6:34 AM, Andrei Borzenkov arvidj...@gmail.com wrote:
В Sun, 08 Feb 2015 13:54:46 -0500
David Michael fedora@gmail.com пишет:
+@item
+Specifying @option{-t} will only print entries with a matching @var{type}.
The
+type can be any value from 0 to 255. Specify a value outside this range to
+match entries with any type. The default is -1.
I think out of range value should result in error.
Okay, but I think the user should still be able to specify a value
that can remove a previously specified type. Maybe a separate long
option --no-type or a magic value like -t any?
+ /* Write the entry's mandatory four header bytes. */
+ length = ptr[1];
+ grub_printf (Entry: Type=0x%02x Length=0x%02x Handle=0x%04x\n,
+ ptr[0], length, *(1 + (grub_uint16_t *)ptr));
Could you reverse the order in 1 + (grub_uint16_t *)ptr and in other
places too?
I'll replace all these pointer casts+dereferences with functions that
avoid alignment issues.
+ /* Dump of the formatted area (including the header) in hex. */
+ grub_printf ( Hex Dump: );
+ while (length-- 0)
+grub_printf (%02x, *ptr++);
+ grub_printf (\n);
+
+ /* Print each string found in the appended string list. */
+ while (ptr[0] != 0 || ptr[1] != 0)
I wonder do we have any ad hoc way to limit it? It looks like Linux
kernel does more sanity checks and does not blindly trust data.
The entry point structure has a two-byte field for total SMBIOS table
length, so that can put an upper limit on the string sets.
Thanks for the detailed review. I hope to be able to be able to send
a new revision later in the week.
Side note: A new major version of the SMBIOS specification was posted
last week which includes 64-bit addresses and such. I'm not planning
to try to add this at the moment, unless anyone has a need for it.
Thanks.
David
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Live-ISO's over PXE+HTTP using loopback
В Sun, 15 Feb 2015 21:37:13 +0200
Beeblebrox zap...@berentweb.com пишет:
Hi.
I'm trying to boot several live ISO's using my PXE-boot server and Grub
loopback. ISO's are fetched by Grub from an HTTP server on the same host.
* I can boot the kernels of all live ISO's through PXE+HTTP transfer.
* Boot process fails at mount-root stage, where rootfs will obviously be
mounted from the ISO. Error message is usually similar could not find the
ISO or unable to find medium containing a live file system.
* A sample menu entry I'm using (thanks to previous answers from this list):
menuentry Debian-testing-i386-lxde.iso --class gnu-linux --class gnu
--class os {
set root=http,192.168.2.100
set isofile=debian-testing-i386-lxde.iso
loopback loop0 ($root)/iso/$isofile
linux (loop0)/install.386/vmlinuz
initrd (loop0)/install.386/initrd.gz
As the first step of solving this problem: Is ISO modification the only
choice, or is it possible to boot a normal ISO by passing the correct
parameters to grub.cfg? I think the problem could be that ramdisk fails to be
created when PXE is involved.
You need to tell your kernel/initrd where to find ISO and it should be
able to fetch data from it via HTTP.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Live-ISO's over PXE+HTTP using loopback
Hi Andrei, thanks for the answer. You need to tell your kernel/initrd where to find ISO and it should be able to fetch data from it via HTTP. I was advised on debian-live, if ISO contains httpfs, you can boot by pointing the live initramfs to the iso location on your web server; essentially the same thing you stated. That's done by params in the linux line then? Something like this? loopback loop0 ($root)$path$isofile linux (loop0)/casper/vmlinuz.efi boot=casper fromiso=$isofile httpfs=$loop0 initrd (loop0)/casper/initrd.lz } This is not working though, so: * Should fromiso= be full path ($root)$path$isofile? * For httpfs=, can loop0 be used or should I revert to ($root)$path$isofile? * Any other suggestions in above syntax appreciated. Thanks and Regards. -- FreeBSD_amd64_11-Current_RadeonKMS ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Live-ISO's over PXE+HTTP using loopback
On Mon, Feb 16, 2015 at 10:25 AM, Beeblebrox zap...@berentweb.com wrote: Hi Andrei, thanks for the answer. You need to tell your kernel/initrd where to find ISO and it should be able to fetch data from it via HTTP. I was advised on debian-live, if ISO contains httpfs, you can boot by pointing the live initramfs to the iso location on your web server; essentially the same thing you stated. That's done by params in the linux line then? Something like this? loopback loop0 ($root)$path$isofile linux (loop0)/casper/vmlinuz.efi boot=casper fromiso=$isofile httpfs=$loop0 grub2 device names are not known by linux, so at least the last kernel parameter is obviously bogus. initrd (loop0)/casper/initrd.lz } This is not working though, so: * Should fromiso= be full path ($root)$path$isofile? * For httpfs=, can loop0 be used or should I revert to ($root)$path$isofile? See above. It should use whatever kernel/initrd understands and neither $loop nor $root are understood by kernel. The fact is that linux kernel cannot read from grub2 (loop) device so unless necessary support is in initrd this simply cannot be done. * Any other suggestions in above syntax appreciated. Thanks and Regards. -- FreeBSD_amd64_11-Current_RadeonKMS ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
