grub2 cfg errors in 18

[Frank McCormick]

Still trying to discover the cause of errors being generated when 
grub2-mkconfig is run.
Tne problem first surfaced after a new kernel during a recent update on 
Fedora 18. The error was something along the lines of "can't find a 
usable template" .
So I tried to manually generate a grub.cfg file using grub2-mkconfig. It 
says there are errors in the generated file ..it refers to a line about 
TBOOT..whatever that is.

Can anyone offers suggestions ?

Thanks

-- 
--Cheers--

[Bill Davidsen]

Frank McCormick wrote:
>  Still trying to discover the cause of errors being generated when
> grub2-mkconfig
>  is run.
>  Tne problem first surfaced after a new kernel during a recent update on Fedora
>  18. The error was something along the lines of "can't find a usable
> template" .
>  So I tried to manually generate a grub.cfg file using grub2-mkconfig. It says
>  there are errors in the generated file ..it refers to a line about
>  TBOOT..whatever that is.
>
>  Can anyone offers suggestions ?
>  
Maybe. I have been looking at this issue, and can at least give you a little 
information. The fedup generates a dubious boot file in /boot/grub2/grub.cfg, 
which contains both a SYSFONT= and KEYTABLE= options. Removing those will avoid 
the error messages but not make the update boot work.

I'm still working on this as I type, so I may have more later.

-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[Frank McCormick]

On 02/03/13 09:00 PM, Bill Davidsen wrote:
>  Frank McCormick wrote:
> > Still trying to discover the cause of errors being generated when 
> > grub2-mkconfig
> > is run.
> > Tne problem first surfaced after a new kernel during a recent update 
> > on Fedora
> > 18. The error was something along the lines of "can't find a usable 
> > template" .
> > So I tried to manually generate a grub.cfg file using grub2-mkconfig. 
> > It says
> > there are errors in the generated file ..it refers to a line about
> > TBOOT..whatever that is.
> >
> > Can anyone offers suggestions ?
> >
>  Maybe. I have been looking at this issue, and can at least give you a 
>  little information. The fedup generates a dubious boot file in 
>  /boot/grub2/grub.cfg, which contains both a SYSFONT= and KEYTABLE= 
>  options. Removing those will avoid the error messages but not make the 
>  update boot work.
>
>  I'm still working on this as I type, so I may have more later.
>  
    Very interesting...am I one of the very few affected by this ?? I 
found a bug on bugzilla
that referred to programs in the util-linux package as causing the 
problem...they were apparently
updated but that didn't solve my problem. For now I have grub installed 
from my Debian partition so the lack of a working grub.cfg
doesn't cause me major problems.

-- 
--Cheers--

[Reindl Harald]

Am 03.03.2013 13:50, schrieb Frank McCormick:
>  Very interesting...am I one of the very few affected by this ?? I
> found a bug on bugzilla
>  that referred to programs in the util-linux package as causing the problem...they were
> apparently
>  updated but that didn't solve my problem 
and you made sure the damage was fixed?

* /etc/mtab is there AND a symlink
* "which ld" gives a correct output

[harry@srv-rhsoft:~]$ LANG=C; stat /etc/mtab
  File: '/etc/mtab' -> '/proc/mounts'
  Size: 12              Blocks: 0          IO Block: 4096   symbolic link
Device: 901h/2305d      Inode: 1178629     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-02-06 11:42:55.191988840 +0100
Modify: 2013-02-06 11:42:55.191988840 +0100
Change: 2013-02-06 11:42:55.191988840 +0100
 Birth: -

[harry@srv-rhsoft:~]$ which ld
/usr/bin/ld

[Frank McCormick]

On 03/03/2013 11:12 AM, Reindl Harald wrote:
>  Am 03.03.2013 13:50, schrieb Frank McCormick:
> > Very interesting...am I one of the very few affected by this ?? I found a bug on
> bugzilla
> > that referred to programs in the util-linux package as causing the problem...they
> were apparently
> > updated but that didn't solve my problem
>  and you made sure the damage was fixed?
>
>  * /etc/mtab is there AND a symlink
>  * "which ld" gives a correct output 
     There is no /etc/mtab on my machine...there is a mtab.fuselock with 
a size of 0
     I tried to create an mtab symlink to /proc/mounts. It would not 
allow me.

    In the /proc directory, mounts  is a symlink to /self/mounts.
>  [harry@srv-rhsoft:~]$ LANG=C; stat /etc/mtab
>     File: '/etc/mtab' -> '/proc/mounts'
>     Size: 12              Blocks: 0          IO Block: 4096   symbolic link
>  Device: 901h/2305d      Inode: 1178629     Links: 1
>  Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
>  Access: 2013-02-06 11:42:55.191988840 +0100
>  Modify: 2013-02-06 11:42:55.191988840 +0100
>  Change: 2013-02-06 11:42:55.191988840 +0100
>    Birth: - 
>  [harry@srv-rhsoft:~]$ which ld
>  /usr/bin/ld 
      which ld on my machine comes up with /bin/ld...
      /usr/bin/has a symlink which point to /etc/alternatives/ld


     Why is a so screwed up ? The installation was made about
4 months ago from the official release.



>  

-- 
--Cheers--

[Michael Schwendt]

On Sun, 03 Mar 2013 11:33:58 -0500, Frank McCormick wrote:

>  > [harry@srv-rhsoft:~]$ which ld
>  > /usr/bin/ld
>  
>        which ld on my machine comes up with /bin/ld... 
Consider $PATH.

  $ which ld
  /usr/bin/ld
  $ su -
  Password:
  # which ld
  /bin/ld

>        /usr/bin/ld has a symlink which point to /etc/alternatives/ld
Correct.

-- 
Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git11.1.fc19.x86_64
loadavg: 0.09 0.11 0.13

[Reindl Harald]

Am 03.03.2013 17:33, schrieb Frank McCormick:
> > and you made sure the damage was fixed?
> >
> > * /etc/mtab is there AND a symlink
> > * "which ld" gives a correct output
>  
>  There is no /etc/mtab on my machine... 
and you wonder about anything?

>  there is a mtab.fuselock with a size of 0 
does nto interest in this context (Google: fuse)

>  I tried to create an mtab symlink to /proc/mounts. It would not allow
> me. 
sorry but "It would not allow me" is a really stupid answer
what about posting input and output?

* did you do it as root because naturally this is a root-task
* ln -s /proc/mounts /etc/mtab

>  In the /proc directory, mounts  is a symlink to /self/mounts. 
yes but this does not help you because /etc/mtab is missing

> > [harry@srv-rhsoft:~]$ which ld
> > /usr/bin/ld
>       which ld on my machine comes up with /bin/ld...
>       /usr/bin/has a symlink which point to /etc/alternatives/ld
>
>  Why is a so screwed up ? The installation was made about
>  4 months ago from the official release 
this doe snot matter
/bin and /usr/bin is the same after UsrMove

since i am pdeantic i fixed as much as possible to point
directly to /usr/bin because why did we made UsrMove if we
rely on the symlinks forever and YES this si critism for
EVERY package-manager which does not fix it's crap

[Frank McCormick]

On 03/03/2013 11:42 AM, Reindl Harald wrote:
>  Am 03.03.2013 17:33, schrieb Frank McCormick:
> >> and you made sure the damage was fixed?
> >>
> >> * /etc/mtab is there AND a symlink
> >> * "which ld" gives a correct output
> > 

     Sorry, I stand corrected....it's early.

[frank@localhost etc]$ stat mtab
   File: ‘mtab’ -> ‘/proc/mounts’
   Size: 12              Blocks: 0          IO Block: 4096   symbolic link
Device: 805h/2053d      Inode: 5242886     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/ root)
Access: 2013-03-02 14:27:44.925020411 -0500
Modify: 2013-02-28 19:32:31.454657287 -0500
Change: 2013-02-28 19:32:31.454657287 -0500
  Birth: -
[frank@localhost etc]$


> > In the /proc directory, mounts  is a symlink to /self/mounts.
>
> >> [harry@srv-rhsoft:~]$ which ld
> >> /usr/bin/ld
> >       which ld on my machine comes up with /bin/ld...
> >       /usr/bin/has a symlink which point to /etc/alternatives/ld
> >
> >
> > this does not matter
> > /bin and /usr/bin is the same after UsrMove 

       What does not matter? That which ld comes up with /bin/ld ?
> >
> > since i am pdeantic i fixed as much as possible to point
> > directly to /usr/bin because why did we made UsrMove if we
> > rely on the symlinks forever and YES this si critism for
> > EVERY package-manager which does not fix it's crap
> >
>  
       ??


        I modified root's PATH to ensure /usr/bin was first...which ld 
now result in /usr/bin/ld....
but   grub2-mkconfig -o /boot/grub2/grub.cfg as root still generates syntax
errors in the output file.

With every new kernel grubby complains it could not find a usable template.



-- 
--Cheers--

[Reindl Harald]

Am 03.03.2013 18:18, schrieb Frank McCormick:
> >> this does not matter
> >> /bin and /usr/bin is the same after UsrMove
>  
>  
>  What does not matter? That which ld comes up with /bin/ld ? 
clearly yes

/bin is a symlink to /usr/bin
/sbin is a symlink to /usr/sbin

both are the same files

[Frank McCormick]

On 03/03/2013 12:41 PM, Reindl Harald wrote:
>  Am 03.03.2013 18:18, schrieb Frank McCormick:
> >>> this does not matter
> >>> /bin and /usr/bin is the same after UsrMove
> >
> > What does not matter? That which ld comes up with /bin/ld ?
>  clearly yes
>
>  /bin is a symlink to /usr/bin
>  /sbin is a symlink to /usr/sbin
>
>  both are the same files 

    Well with the PATH modified so ld comes up as /usr/bin/ld and mtab 
existing in /etc
I am still faced with the original problem. grub2-mkconfig still 
generates grub.cfg with syntax errors and grubby
complains it can't find a template.

Should I file another bug...or just boot into 17 all the time ?


-- 
--Cheers--

[Frank McCormick]

On 03/03/2013 07:26 PM, Frank McCormick wrote:
>  On 03/03/2013 12:41 PM, Reindl Harald wrote:
> >
> > Am 03.03.2013 18:18, schrieb Frank McCormick:
> >>>> this does not matter
> >>>> /bin and /usr/bin is the same after UsrMove
> >>
> >> What does not matter? That which ld comes up with /bin/ld ?
> > clearly yes
> >
> > /bin is a symlink to /usr/bin
> > /sbin is a symlink to /usr/sbin
> >
> > both are the same files
>
>
>     Well with the PATH modified so ld comes up as /usr/bin/ld and mtab 
>  existing in /etc
>  I am still faced with the original problem. grub2-mkconfig still 
>  generates grub.cfg with syntax errors and grubby
>  complains it can't find a template.
>
>  Should I file another bug...or just boot into 17 all the time ?
>
>  

    Well I solved my problem I **think**....removed the grub2-efi 
package ( I don't need it)...and it all
started working again. Long term....we'll see.



-- 
--Cheers--