2012/4/18 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>:
> On 18.04.2012 17:06, Mike Gilbert wrote:
>> 2012/4/18 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>:
>>> On 15.04.2012 04:21, Mike Gilbert wrote:
>>>> On 04/11/2012 11:52 AM, Mike Gilbert wrote:
>>>>> 2012/4/11 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>:
>>>>>> On 11.04.2012 04:56, Mike Gilbert wrote:
>>>>>>> On 04/07/2012 05:54 PM, Mike Gilbert wrote:
>>>>>>>> Secondly, genkernel looks for the "real_root" kernel command line
>>>>>>>> option
>>>>>>>> to determine the root filesystem. This is a holdover from the days when
>>>>>>>> we used true initrd images and we needed to use root=/dev/ram0.
>>>>>>>>
>>>>>>> It was brought to my attention that genkernel's initramfs code will in
>>>>>>> fact utilize "root" if "real_root" is unset. This part of my previous
>>>>>>> patch is therefore pointless.
>>>>>>>
>>>>>>> I have attached a revised patch containing only the changes necessary to
>>>>>>> detect a genkernel initramfs image.
>>>>>>>
>>>>>> pushd/popd isn't POSIX so we can't use it in our scripts. Also I don't
>>>>>> feel like glob expansion is the right thing to use here. Why not infer
>>>>>> the architecture from uname ?
>>>>> That should also work. Here's the logic that genkernel uses to populate
>>>>> ARCH:
>>>>>
>>>>> ARCH=`uname -m`
>>>>> case "${ARCH}" in
>>>>> i?86)
>>>>> ARCH="x86"
>>>>> ;;
>>>>> mips|mips64)
>>>>> ARCH="mips"
>>>>> ;;
>>>>> arm*)
>>>>> ARCH=arm
>>>>> ;;
>>>>> *)
>>>>> ;;
>>>>> esac
>>>>>
>>>>> I'm thinking it would be a good idea to rename ARCH to something like
>>>>> GENKERNEL_ARCH. We should also let the user override this in
>>>>> /etc/default/grub.
>>>>>
>>>>> Does that sound ok?
>>>> I have modified my patch to implement what I describe above.
>>>>
>>> What is the reason to make it configurable? There shouldn't be any need
>>> to configure something that is autodetected
>>>
>> genkernel allows the user to cross-compile their kernel and/or
>> initramfs, in which case uname -m would not provide the correct value.
>>
>> I don't have a clear picture in my mind of how that would work with
>> grub, but I figure it would be better to err on the side of
>> flexibility.
> grub-mkconfig doesn't support cross-configuration and arch name is just
> one of the problems. Unless we have a designed system for this case it's
> useless to add stray bits which don't work anyway.
>
Alright, not a bit deal. Do you need a new patch from me?
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
