[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] pvgrub2 is merged



On 28.11.2013 14:07, Fabio Fantoni wrote:
> Il 27/11/2013 18:35, Andrey Borzenkov ha scritto:
>> Ð Wed, 27 Nov 2013 17:24:53 +0100
>> Fabio Fantoni <fabio.fantoni@xxxxxxx> ÐÐÑÐÑ:
>>
>>> Il 27/11/2013 17:03, Vladimir 'Ï-coder/phcoder' Serbinenko ha scritto:
>>>> On 27.11.2013 16:59, Fabio Fantoni wrote:
>>>>> Il 27/11/2013 12:50, Vladimir 'Ï-coder/phcoder' Serbinenko ha scritto:
>>>>>> That pretty much explains what happened: you don't have any
>>>>>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB
>>>>>> found
>>>>>> its own memdisk and fell into recursion. I'm not sure what should
>>>>>> be the
>>>>>> proper way to solve this recursion.
>> Yes, it was a bit naive on my side. Recursion in principle can be
>> stopped by using global variable, but search is limited to the first
>> match only anyway, so I guess it is not worth it.
>>
>>>>> Anyone know how to exclude memdisk from the search please?
>> Please look in grub2 sources at docs/osdetect.cfg. It implements
>> advanced run-time detection of possible bootable files from
>> various operating systems. It boils down to loop across all devices,
>> and of course you can either limit device names (like looking for hd*
>> only) or explicitly exclude known ones (like memdisk).
>>
>>> Is it possible to specify a different default grub.cfg path (different
>>> from all other distributions) changing this command:
>>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O
>>> x86_64-xen -d grub-core/ boot/grub/grub.cfg
>>> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set?
>>>
>> Not really. Currently the situation is
>>
>> - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub
>> - after launch grub unconditionally starts "normal" module if at all
>>    possible
>> - normal module always tries to load and execute $prefix/grub.cfg if no
>>    explicit configuration file name is given as argument
>>
>> But I think that using osdetect.cfg or something based on this idea
>> won't require changing defaults at all.
> 
> Thanks for your reply.
> 
> I did this script that is working about finding and include the grub.cfg
> of pv domUs with many cases:
> 
> cat > boot/grub/grub.cfg <<EOF
> insmod lvm
> insmod ext2
> insmod part_msdos
> insmod part_gpt
> insmod btrfs
> 
> insmod regexp
> for dev in (*); do
>     # $device: parenthesis removed from $dev
>     regexp -s device '\((.*)\)' $dev
>     set root=$device
>     for file in /boot/vmlinuz-* /boot/linux-*; do
>         if test -f $file; then
>             set saved_root=$root
>         fi
>     done
> done
> set root=$saved_root
> 
> if test -f /boot/grub2/grub.cfg ; then
>     configfile /boot/grub2/grub.cfg
> elif test -f /boot/grub/grub.cfg ; then
>     configfile /boot/grub/grub.cfg
> fi
> EOF
> 
> @xen developer: Are there other modules to insert for other partitions
> or file systems, other grub cfg path for other distributions or other
> kernel type to search that support xen pv domUs?
> I think is good do and post complete pvgrub2 cfg that support all pv domUs.
> 
> @xen and grub developer: I'm still unable to boot any entry of Sid pv
> domU using official kernel:
> xl -vvv create -c /etc/xen/sid.cfg
> ...
> Caricamento Linux 3.11-1-amd64...
> Caricamento ramdisk iniziale...
> xc: debug: hypercall buffer: total allocations:247 total releases:247
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7
> 
> Any ideas?
> 
Ah I forgot: you need to "insmod xzio" since debian ones are compressed.
> If you need more tests/informations tell me and I'll post them.
> 
> Thanks for any reply.
> 


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.