[arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Gerardo Exequiel Pozzi vmlinuz386 at yahoo.com.ar
Sat Jan 31 15:52:43 EST 2009


Dieter Plaetinck wrote:
> On Sat, 31 Jan 2009 20:52:34 +0100
> Dieter Plaetinck <dieter at plaetinck.be> wrote:
>
>   
>> On Sun, 01 Feb 2009 01:52:52 +1000
>> Allan McRae <allan at archlinux.org> wrote:
>>
>>     
>>> Gerardo Exequiel Pozzi wrote:
>>>       
>>>> Allan McRae wrote:
>>>>   
>>>>         
>>>>> Gerhard Brauer wrote:
>>>>>     
>>>>>           
>>>>>> Am Sat, 31 Jan 2009 20:23:34 +1000
>>>>>> schrieb Allan McRae <allan at archlinux.org>:
>>>>>>
>>>>>>  
>>>>>>       
>>>>>>             
>>>>>>> Would it be a good idea to move grub-gfx to [extra] if it is
>>>>>>> being used on the installer?
>>>>>>>     
>>>>>>>         
>>>>>>>               
>>>>>> Hmm, abstain...
>>>>>> First i wonder that we use a community package on/for
>>>>>> installation sources, but it's only the grub-gfx package. So i
>>>>>> have no problem belong this to community at all. (I also
>>>>>> thought about maintaining a separate grub-gfx only for
>>>>>> archiso...). I see the problem mainly on our testing procedure:
>>>>>> this behavior must have be detected earlier - and not from a
>>>>>> "beta tester"(Thanks Gerardo!), WE have had to detect this....
>>>>>> (I detect it on i686 and initiate that this got fixed. Myself
>>>>>> (only i686) don't look if x86_64 was rebuild also....
>>>>>>   
>>>>>>       
>>>>>>             
>>>>> Can someone clarify what package the grub being installed onto
>>>>> the users system is?   From the problems here, I am getting the
>>>>> impression that it is the grub-gfx package.
>>>>>
>>>>> Allan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>           
>>>> Hi
>>>>
>>>> In resume:
>>>> * The package installed at:
>>>>    the root-fs of ISO is grub-gfx.
>>>>    the root of new user system $DESTDIR is grub, but...
>>>>    the MBR/BOOT of the new system is grub-gfx because
>>>> $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not
>>>> $DESTDIR/sbin/grub (bin)
>>>>
>>>> * Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have
>>>> latest patches that the i686 version have.
>>>>
>>>> May be, a chroot to $DESTDIR and install grub from here with
>>>> grub-install, or use the old method from 2008.06 that uses grub
>>>> binary directly.
>>>> Or another solution.
>>>>   
>>>>         
>>> Thanks for the clarification.  I was concerned about grub-gfx being 
>>> installed to peoples systems by default but had not realized that
>>> this was because of a bug.
>>>
>>> Allan
>>>
>>>
>>>
>>>
>>>       
>> So do I understand correctly...
>>
>> *problem 1*: grub-gfx vs grub:
>> We can fix the problem that grub-gfx instead of grub is installed if
>> we just chroot I think.
>> Eg:
>> chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log
>> 2>&1  
>>
>> But, this only affects 64bit right? or not? (because in my tests the
>> grub didn't look very fancy..)  If so, can someone with a 64bit
>> (virtual) machine change the above line in /arch/setup and test it?
>> If okay, someone with access to archlinux-installer can fix the line
>> and repackage.
>>
>> If I understand correctly, this problem is unrelated to the "slightly
>> outdated grub package" problem ( see
>> http://bugs.archlinux.org/task/13068 ), eg if it were not for problem
>> 2, we wouldn't need to update the package.
>>
>>
>> *problem 2*:
>> Gerardo says "grub-gfx fails", this is the same as Alexanders problem,
>> right? ("I'm afraid I confirm the grub bug. In x86_64 images grub
>> isn't installed to the MBR of the chosen disk (when the boot
>> partition is an extX, if it is reiserfs it works perfectly)").
>>
>> IIRC Gerardo already tried the new package , tested it and confirmed
>> that it works.  So we just need to get it on the iso.
>> See http://bugs.archlinux.org/task/13068
>>
>> Dieter
>>
>>     
>
> Also,
> I went over all 2009.01 mails to see if we catched all issues.
> All of them are fixed or being handled right now, except one more grub
> related one posted by Gerardo:
> http://www.archlinux.org/pipermail/arch-releng/2009-January/000167.html
> quote:
> "And there is and error in tryboot.lst, it have a three fallback
> commands
> in menu entries, the fallback command is invalid at theses points, is
> only for "general section"
>
> timeout 0
> default 0
>
> title Scanning for /boot/grub/menu.lst
>     fallback 1
>     find --set-root --ignore-floppies /boot/grub/menu.lst
>     configfile /boot/grub/menu.lst
>
> ....
>
> "
> what is tryboot.lst? which fallback command? do you get any errors? or
> will this stuff be automagically fixed if we fix problem 1 and 2 from
> above?
>
> Dieter
>
>   
Hi Dieter

No, this are unrelated to the problems 1 and 2 from above, and does not
matter for the 2009.01 release.

tryboot.lst is a menu entry in GRUB boot menu from the install CD marked
as **experimental** and is located at "More options..."

Because it contains semantic error (fallback command is not valid in the
"title sections")
When "enter" to this option grub shows:

fallback 1

Error 27: Unrecognized command

I will create a bug entry in Flyspray to track this and others issues in
the boot menu from ISO.




-- 
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D



More information about the arch-releng mailing list