On 18.04.2012 17:06, Mike Gilbert wrote:
> 2012/4/18 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@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 <phcoder@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.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko