Re: LILO documentation
Le 20.04.2013 16:12, Richard Owlett a écrit :
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
Source code? XD
Sorry about the joke, but I have no clue. Maybe you could ask it's dev
team?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/b4452d50ac91f37f539f529253e49...@neutralite.org
Re: LILO documentation
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the user documentation
and the technical (i.e. internal) docs at http://lilo.alioth.debian.org/
--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172a58d.8070...@vanderhoff.org
Re: LILO documentation
berenger.mo...@neutralite.org wrote:
Le 20.04.2013 16:12, Richard Owlett a écrit :
I need complete documentation on LILO with emphasis on
lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They
presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
Source code? XD
Sorry about the joke, but I have no clue. Maybe you could
ask it's dev team?
snicker :
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172aafc.3050...@cloud85.net
Re: LILO documentation
Tony van der Hoff wrote:
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the user documentation
and the technical (i.e. internal) docs at http://lilo.alioth.debian.org/
One of places I had been :{
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172ab36.1050...@cloud85.net
Re: LILO documentation
On 20/04/13 15:50, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the user documentation
and the technical (i.e. internal) docs at http://lilo.alioth.debian.org/
One of places I had been :{
Care to explain why you don't like it/what you really want?
--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172ac05.7040...@vanderhoff.org
Re: LILO documentation
Tony van der Hoff wrote:
On 20/04/13 15:50, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the user documentation
and the technical (i.e. internal) docs at http://lilo.alioth.debian.org/
One of places I had been :{
Care to explain why you don't like it/what you really want?
In my three score and ten I've learned to recognize when I
am too clueless to ask a reasonable question ;/
The immediate surface symptoms include almost no change to
/etc/lilo.conf having the expected effect.
I can't get the menu to display automatically - even if at
the moment it would have only one choice.
[It does display if I hit the space-bar when LILO appears on
screen.]
I can't the text describing the one menu item I have.
I suspect the document I desire would spend a dozen pages
describing only lilo.conf.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172b1fa.5070...@cloud85.net
Re: LILO documentation
On 20/04/13 16:19, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:50, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the user documentation
and the technical (i.e. internal) docs at
http://lilo.alioth.debian.org/
One of places I had been :{
Care to explain why you don't like it/what you really want?
In my three score and ten I've learned to recognize when I am too
clueless to ask a reasonable question ;/
The immediate surface symptoms include almost no change to
/etc/lilo.conf having the expected effect.
I can't get the menu to display automatically - even if at the moment it
would have only one choice.
[It does display if I hit the space-bar when LILO appears on screen.]
I can't the text describing the one menu item I have.
I suspect the document I desire would spend a dozen pages describing
only lilo.conf.
I guess you've been here, too:
http://www.netadmintools.com/html/5lilo.conf.man.html, but the conf is
so simple that it's hard to get it wrong.
From your problem description, it almost sounds as if you're failing to
run /sbin/lilo after making changes to the lilo.conf file to allow it to
compile the conf.
I resisted the migration to grub for many years, on the basis that lilo
was a much better hammer, being as simple as required to do the job.
However, I was eventually worn down, and bent to progress, so haven't
used lilo in a while :(
In all that time, I never found the need to delve much deeper into the
config than what was available in the above page.
--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172b8c4.7070...@vanderhoff.org
Re: LILO documentation
Tony van der Hoff wrote:
On 20/04/13 16:19, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:50, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the user documentation
and the technical (i.e. internal) docs at
http://lilo.alioth.debian.org/
One of places I had been :{
Care to explain why you don't like it/what you really want?
In my three score and ten I've learned to recognize when I am too
clueless to ask a reasonable question ;/
The immediate surface symptoms include almost no change to
/etc/lilo.conf having the expected effect.
I can't get the menu to display automatically - even if at the moment it
would have only one choice.
[It does display if I hit the space-bar when LILO appears on screen.]
I can't the text describing the one menu item I have.
I suspect the document I desire would spend a dozen pages describing
only lilo.conf.
I guess you've been here, too:
http://www.netadmintools.com/html/5lilo.conf.man.html,
Yepp
but the conf is
so simple that it's hard to get it wrong.
But I'm so talented ;/
From your problem description, it almost sounds as if you're failing to
run /sbin/lilo after making changes to the lilo.conf file to allow it to
compile the conf.
Discovered that error early.
I've played with delay= statement and that works as expected.
I resisted the migration to grub for many years, on the basis that lilo
was a much better hammer, being as simple as required to do the job.
However, I was eventually worn down, and bent to progress, so haven't
used lilo in a while :(
I found grub2 annoying in that it wanted the menu to appear
its way not mine.
I'd likely would have been happy with grub legacy as its
configuration was set in a single easily edited file. But
what I've read seems to indicate it is being declared
dead/unsupported/abandoned/... .
In all that time, I never found the need to delve much deeper into the
config than what was available in the above page.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172be1b.4010...@cloud85.net
Re: LILO documentation
On Sat, 20 Apr 2013 10:12:51 -0400 (EDT), Richard Owlett wrote: I need complete documentation on LILO with emphasis on lilo.conf. I don't know about complete documentation, but the best lilo tutorial that I know of is http://users.wowway.com/~zlinuxman/lilo.htm I wrote the above-mentioned web page myself; so if you have any complaints, the buck stops here. Also, if you have any suggestions for improving the page, I'm open to suggestions. If, after reading the entire page, you have any specific questions, I'll be happy to at least try to answer them. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526983301.764795.1366476714640.javamail.r...@md01.wow.synacor.com
Re: LILO documentation
On 04/20/2013 12:11 PM, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 16:19, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:50, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is a fair
approximation) with a computer and a set of install disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the user documentation
and the technical (i.e. internal) docs at
http://lilo.alioth.debian.org/
One of places I had been :{
Care to explain why you don't like it/what you really want?
In my three score and ten I've learned to recognize when I am too
clueless to ask a reasonable question ;/
The immediate surface symptoms include almost no change to
/etc/lilo.conf having the expected effect.
I can't get the menu to display automatically - even if at the moment it
would have only one choice.
[It does display if I hit the space-bar when LILO appears on screen.]
I can't the text describing the one menu item I have.
I suspect the document I desire would spend a dozen pages describing
only lilo.conf.
I guess you've been here, too:
http://www.netadmintools.com/html/5lilo.conf.man.html,
Yepp
but the conf is
so simple that it's hard to get it wrong.
But I'm so talented ;/
From your problem description, it almost sounds as if you're failing to
run /sbin/lilo after making changes to the lilo.conf file to allow it to
compile the conf.
Discovered that error early.
I've played with delay= statement and that works as expected.
I resisted the migration to grub for many years, on the basis that lilo
was a much better hammer, being as simple as required to do the job.
However, I was eventually worn down, and bent to progress, so haven't
used lilo in a while :(
I found grub2 annoying in that it wanted the menu to appear its way not
mine.
I'd likely would have been happy with grub legacy as its configuration
was set in a single easily edited file. But what I've read seems to
indicate it is being declared dead/unsupported/abandoned/... .
In all that time, I never found the need to delve much deeper into the
config than what was available in the above page.
ISTR around the time that grub2 was introduced, one of our users, I
'THINK' his name was Stephen Powell, gave some good arguments for using
Lilo. Again, ISTR, he put up a very good web page explaining how to use
install it.
You might find the thread on the D-U archives or Google. Yep, a goohle
search for Lilo 'Stephen Powell' has it as the first link.
Google IS your friend.
HTH
--
Wayne
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172cf41.3030...@gmail.com
Re: LILO documentation
Stephen Powell wrote:
On Sat, 20 Apr 2013 10:12:51 -0400 (EDT), Richard Owlett wrote:
I need complete documentation on LILO with emphasis on lilo.conf.
I don't know about complete documentation, but the best lilo tutorial
that I know of is
http://users.wowway.com/~zlinuxman/lilo.htm
I wrote the above-mentioned web page myself; so if you have any complaints,
the buck stops here. Also, if you have any suggestions for improving the
page, I'm open to suggestions. If, after reading the entire page, you have
any specific questions, I'll be happy to at least try to answer them.
I don't yet know if you succeeded, but you were targeting
people like me :)
I've only quickly read the section titled Installing and
Configuring LILO. It has pointed out several areas I need
to do more background reading. If retirement isn't for
education, what use is it.
THANK YOU
{be warned questions likely to follow ;}
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172d048.9070...@cloud85.net
Re: LILO documentation
Wayne Topa wrote:
On 04/20/2013 12:11 PM, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 16:19, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:50, Richard Owlett wrote:
Tony van der Hoff wrote:
On 20/04/13 15:12, Richard Owlett wrote:
I need complete documentation on LILO with emphasis
on lilo.conf .
Assume I'm stranded on a desert isle (SW Missouri is
a fair
approximation) with a computer and a set of install
disks.
What *ONE* document will answer ALL my LILO questions.
Hint: man pages and mini-HOTO's don't hack it. They
presume and
summarize too much.
{I'm installing using the 8 DVD set of Debian 6.0.5}
I don't know about one document, but there's the
user documentation
and the technical (i.e. internal) docs at
http://lilo.alioth.debian.org/
One of places I had been :{
Care to explain why you don't like it/what you really
want?
In my three score and ten I've learned to recognize
when I am too
clueless to ask a reasonable question ;/
The immediate surface symptoms include almost no change to
/etc/lilo.conf having the expected effect.
I can't get the menu to display automatically - even if
at the moment it
would have only one choice.
[It does display if I hit the space-bar when LILO
appears on screen.]
I can't the text describing the one menu item I have.
I suspect the document I desire would spend a dozen
pages describing
only lilo.conf.
I guess you've been here, too:
http://www.netadmintools.com/html/5lilo.conf.man.html,
Yepp
but the conf is
so simple that it's hard to get it wrong.
But I'm so talented ;/
From your problem description, it almost sounds as if
you're failing to
run /sbin/lilo after making changes to the lilo.conf file
to allow it to
compile the conf.
Discovered that error early.
I've played with delay= statement and that works as expected.
I resisted the migration to grub for many years, on the
basis that lilo
was a much better hammer, being as simple as required to
do the job.
However, I was eventually worn down, and bent to
progress, so haven't
used lilo in a while :(
I found grub2 annoying in that it wanted the menu to
appear its way not
mine.
I'd likely would have been happy with grub legacy as its
configuration
was set in a single easily edited file. But what I've read
seems to
indicate it is being declared
dead/unsupported/abandoned/... .
In all that time, I never found the need to delve much
deeper into the
config than what was available in the above page.
ISTR around the time that grub2 was introduced, one of our
users, I 'THINK' his name was Stephen Powell, gave some good
arguments for using
Lilo. Again, ISTR, he put up a very good web page
explaining how to use
install it.
You might find the thread on the D-U archives or Google.
Yep, a goohle search for Lilo 'Stephen Powell' has it as the
first link.
Google IS your friend.
I KNOW. I KNOW ;)
But you need to know the right key words.
As a matter of fact Mr. Powell had just responded to my post
suggesting I read one of his pagers.
He beat you by minutes.
Thanks.
HTH
--
Wayne
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5172d732.7050...@cloud85.net
Re: LILO documentation
On Saturday 20 April 2013 17:51:54 Stephen Powell wrote: On Sat, 20 Apr 2013 10:12:51 -0400 (EDT), Richard Owlett wrote: I need complete documentation on LILO with emphasis on lilo.conf. I don't know about complete documentation, but the best lilo tutorial that I know of is http://users.wowway.com/~zlinuxman/lilo.htm I wrote the above-mentioned web page myself; so if you have any complaints, the buck stops here. Also, if you have any suggestions for improving the page, I'm open to suggestions. If, after reading the entire page, you have any specific questions, I'll be happy to at least try to answer them. -- .''`. Stephen Powell I had been thinking What's happened to Stephen Powell? This is very much his pigeon. I hope that he is all right. Nice to see that you are all right, Stephen. :-)) Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201304201907.29307.lisi.re...@gmail.com
Re: LILO documentation
On 04/20/2013 02:07 PM, Lisi Reisz wrote: On Saturday 20 April 2013 17:51:54 Stephen Powell wrote: On Sat, 20 Apr 2013 10:12:51 -0400 (EDT), Richard Owlett wrote: I need complete documentation on LILO with emphasis on lilo.conf. I don't know about complete documentation, but the best lilo tutorial that I know of is http://users.wowway.com/~zlinuxman/lilo.htm I wrote the above-mentioned web page myself; so if you have any complaints, the buck stops here. Also, if you have any suggestions for improving the page, I'm open to suggestions. If, after reading the entire page, you have any specific questions, I'll be happy to at least try to answer them. -- .''`. Stephen Powell I had been thinking What's happened to Stephen Powell? This is very much his pigeon. I hope that he is all right. Nice to see that you are all right, Stephen. :-)) +1 -- Wayne -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5172dc14.3060...@gmail.com
Re: LILO documentation
Le 20.04.2013 19:58, Richard Owlett a écrit : Wayne Topa wrote: I KNOW. I KNOW ;) But you need to know the right key words. As a matter of fact Mr. Powell had just responded to my post suggesting I read one of his pagers. He beat you by minutes. Thanks. HTH -- Wayne So, may we conclude this by, debian is a best friend than google? :p -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/823a3d556e4292ed0e933a514e78d...@neutralite.org
Re: lilo - keytable read/checksum error
On 03/04/2013 07:24 AM, Camaleón wrote: El Mon, 04 Mar 2013 07:46:56 -0300, francisco cid escribió: Francisco, estás enviando los correos con formato html lo cual se recomienda evitar en esta lista por lo que deberías configurar el cliente de correo para usar formato texto. Si no sabes cómo hacerlo tienes más ayuda sobre el proceso en la Wiki de Debian. Y si no eres capaz de encontrar la página en cuestión, pues lo dices y te la mando... El 3 de marzo de 2013 11:56, Camaleón noela...@gmail.com escribió: El Sat, 02 Mar 2013 23:05:53 -0300, francisco cid escribió: hola, e estado solucionar este problema todo el dia, ¿Qué problema, el del asunto? ¿Y cuándo te aparece, exactamente, nada más iniciar? ¿Y te apareció sin más, de un día para otro sin haber hecho nada? si, un día se me quedó el notebook prendido, hibernó, y luego al prender, me mandó ese error. Ah, vale. El error te apareció al intentar restaurar el sistema, ok. Apenas conozco LILO... ¿has probado buscando en Google por ese mensaje? si lo hice! (...) ¿Y no obtuviste ninguna pista, probaste alguna de las sugerencias y si es así, qué exactamente y con qué resultado? Normalmente *quien pregunta* es quien debe *proporcionar* la mayor cantidad de datos, más que nada porque suele ser el más interesado en resolver *su problema* :-) ¿Cómo y dónde instalaste GRUB2? con el cd de instalacion entre a una consola y le dí un fsck al sistema de ficheros raíz, porque tenia algunos archivos con errores, luego pude entrar al sistema, pero sólo con una herramienta llamada super grub disk, una vez dentro de mi debian , instalé el grub, lo configuré y se solucionó. creo que todo se debía a un error físico en mi disco duro Es posible... aunque quizá se haya quedado traspuesto al restaurar el sistema tras hibernar (p. ej., si ha encontrado un cambio que no haya sabido interpretar). No te sabría decir, no he trabajado apenas con LILO pero sí recuerdo que con este gestor de arranque había que ejecutar algún comando cuando se actualizaba el kernel (al menos eso pasaba antiguamente no sé cómo será ahora o si se habrá automatizado de alguna forma). Saludos, /sbin/lilo Cual error? -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5135c92c.3080...@lavabit.com
Re: lilo - keytable read/checksum error
El Mon, 04 Mar 2013 07:46:56 -0300, francisco cid escribió: Francisco, estás enviando los correos con formato html lo cual se recomienda evitar en esta lista por lo que deberías configurar el cliente de correo para usar formato texto. Si no sabes cómo hacerlo tienes más ayuda sobre el proceso en la Wiki de Debian. Y si no eres capaz de encontrar la página en cuestión, pues lo dices y te la mando... El 3 de marzo de 2013 11:56, Camaleón noela...@gmail.com escribió: El Sat, 02 Mar 2013 23:05:53 -0300, francisco cid escribió: hola, e estado solucionar este problema todo el dia, ¿Qué problema, el del asunto? ¿Y cuándo te aparece, exactamente, nada más iniciar? ¿Y te apareció sin más, de un día para otro sin haber hecho nada? si, un día se me quedó el notebook prendido, hibernó, y luego al prender, me mandó ese error. Ah, vale. El error te apareció al intentar restaurar el sistema, ok. Apenas conozco LILO... ¿has probado buscando en Google por ese mensaje? si lo hice! (...) ¿Y no obtuviste ninguna pista, probaste alguna de las sugerencias y si es así, qué exactamente y con qué resultado? Normalmente *quien pregunta* es quien debe *proporcionar* la mayor cantidad de datos, más que nada porque suele ser el más interesado en resolver *su problema* :-) ¿Cómo y dónde instalaste GRUB2? con el cd de instalacion entre a una consola y le dí un fsck al sistema de ficheros raíz, porque tenia algunos archivos con errores, luego pude entrar al sistema, pero sólo con una herramienta llamada super grub disk, una vez dentro de mi debian , instalé el grub, lo configuré y se solucionó. creo que todo se debía a un error físico en mi disco duro Es posible... aunque quizá se haya quedado traspuesto al restaurar el sistema tras hibernar (p. ej., si ha encontrado un cambio que no haya sabido interpretar). No te sabría decir, no he trabajado apenas con LILO pero sí recuerdo que con este gestor de arranque había que ejecutar algún comando cuando se actualizaba el kernel (al menos eso pasaba antiguamente no sé cómo será ahora o si se habrá automatizado de alguna forma). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kh2ec3$knf$3...@ger.gmane.org
Re: lilo - keytable read/checksum error
On 02/03/13 19:05, francisco cid wrote: hola, e estado solucionar este problema todo el dia, intente recuperar el inicio de mi debian con el cd de instalacion en modo recuperacion, intente instalar grub, desinstalar lilo, pero sigue el error, y no me deja hacer nada. uso debian testing amd64 sin ningun otro SO más me gustaria poder eliminar lilo, y cambiarme a grub. saludos! debian live (no el disco de instalacion normal, es otro), http://www.debian.org/CD/live/ en la obcion de modo de rescate , (o recuperacion no recuerdo bien ), reinstala GRUB es muy facil. lilo , hoy en dia se dice entre los usuarios expertos que yo conosco que se quedo atrado ese programa a comparacion de GRUB que GRUB es MUCHO mas manejable suerte ;-) -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5132f9bb.1010...@gmail.com
Re: Lilo not recognizing keyboard SOLVED)
On Thu, 29 Mar 2012 22:31:05 -0400 (EDT), Marc Shapiro wrote: I apologize for not posting this sooner, but this was the first chance that I had to reboot and go into the BIOS Setup. To answer your questions... AMI BIOS v02.54 4/22/2005 Features Setup USB Function For DOSEnabled (Default was Disabled) I have updated my LILO web page http://users.wowway.com/~zlinuxman/lilo.htm to include the information above. There is now a new section entitled USB Keyboards. Please look it over and let me know if there are any factual errors. Thanks for your contribution. As a LILO user, any other suggestions you may have for improving the web page will be considered as well. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1464208053.251378.1333205733847.javamail.r...@md01.wow.synacor.com
Re: Lilo not recognizing keyboard SOLVED)
On Thu, 29 Mar 2012 19:39:54 -0700, Marc wrote in message
4f751cfa.1050...@gmail.com:
On 03/27/12 03:59, Arnt Karlsen wrote:
On Mon, 26 Mar 2012 05:43:45 -0500, Stan wrote in message
..one thing lilo will do, is hop back to the old disk if you make
that a menu option. Found that out trying to boot /dev/md0 rather
than dance between /dev/hd{a,b}0. ;o)
Absolutely! I left the menu option for the old disk, and even for
the previous kernel on the old disk. I had no intentions of removing
those options until I was sure that I could boot without problems on
the new disk.
In fact, I left the menu item for the old boot as the default. A
good thing, too. If linux had not wanted to boot from the new disk
and I could not select the old boot from the menu because of the USB
keyboard, I would have been up a creek... It would have taken me a
lot longer, with a lot more trouble, to find out that I needed to
change the BIOS settings and find the correct setting.
Now that everything is definitely booting correctly, I have changed
Lilo's default to the new drive, but the menu option for the old
drive is still there, and will probably remain until I install a new
kernel. Then I will have my current kernel on the new disk as my
backup option.
ALWAYS have a plan!
.._and_, an healthy bunch of back-up plans, most plans fails,
and you need at least one plan that works, to get away with
it. ;o)
--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120330152514.0f155...@nb6.lan
Re: Lilo not recognizing keyboard SOLVED)
On Mon, 26 Mar 2012 05:43:45 -0500, Stan wrote in message
4f704861.1040...@hardwarefreak.com:
On 3/25/2012 10:58 PM, Marc Shapiro wrote:
I should have googled before posting. Aparently lilo is not
capable of recognizing USB keyboards, but the BIOS can. All I
needed to do was find the right BIOS option. The only tricky part
was that this option (in my BIOS) says nothing about keyboards.
The option was for allowing legacy USB support in DOS! Who looks
for that?!?
Anyone who has built/used PCs for say, 10 years, specifically
whitebox, and has spent a fair amount of time in AMI/Award BIOS.
Phoenix BIOS usually ships on retail branded boxen along with Intel
retail mobos, and usually has this function enabled by default on
anything sold within the past 7 years or so. So basically any
HardwareFreak would know what to look for. ;)
..one thing lilo will do, is hop back to the old disk if you make
that a menu option. Found that out trying to boot /dev/md0 rather
than dance between /dev/hd{a,b}0. ;o)
..but then grub offers cute things like ro[tab]. ;o)
--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120327125910.45302...@nb6.lan
Re: Lilo not recognizing keyboard SOLVED)
Stephen, I apologize for not posting this sooner, but this was the first chance that I had to reboot and go into the BIOS Setup. To answer your questions... AMI BIOS v02.54 4/22/2005 Features Setup USB Function For DOSEnabled (Default was Disabled) Marc On 03/26/12 17:27, Stephen Powell wrote: On Sun, 25 Mar 2012 23:58:15 -0400 (EDT), Marc Shapiro wrote: I should have googled before posting. Aparently lilo is not capable of recognizing USB keyboards, but the BIOS can. All I needed to do was find the right BIOS option. The only tricky part was that this option (in my BIOS) says nothing about keyboards. The option was for allowing legacy USB support in DOS! Who looks for that?!? Once I found it, everything is working just fine. Yes, LILO uses the BIOS interface to the keyboard (int 16h, functions 00h (GET KEYSTROKE), 01h (CHECK FOR KEYSTROKE), and 02h (GET SHIFT FLAGS); so the BIOS must be set up to allow these keyboard BIOS calls to work with USB keyboards. That's a useful tip, Marc. I have not encountered this in any of the machines that I use LILO on that have USB keyboards, but obviously not all machines use the BIOS settings that LILO needs by default. Please provide more detailed information (i.e. what kind of BIOS was it? Award? IBM? Phoenix? AMI? What was the BIOS date? Exactly what menu options did you drill down through to find the setting?) I'd like to include this as an example problem on my LILO web page http://users.wowway.com/~zlinuxman/lilo.htm so please be as detailed as you can. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f751ae9.8020...@gmail.com
Re: Lilo not recognizing keyboard SOLVED)
On 03/27/12 03:59, Arnt Karlsen wrote:
On Mon, 26 Mar 2012 05:43:45 -0500, Stan wrote in message
..one thing lilo will do, is hop back to the old disk if you make
that a menu option. Found that out trying to boot /dev/md0 rather
than dance between /dev/hd{a,b}0. ;o)
Absolutely! I left the menu option for the old disk, and even for the
previous kernel on the old disk. I had no intentions of removing those
options until I was sure that I could boot without problems on the new disk.
In fact, I left the menu item for the old boot as the default. A good
thing, too. If linux had not wanted to boot from the new disk and I
could not select the old boot from the menu because of the USB keyboard,
I would have been up a creek... It would have taken me a lot longer,
with a lot more trouble, to find out that I needed to change the BIOS
settings and find the correct setting.
Now that everything is definitely booting correctly, I have changed
Lilo's default to the new drive, but the menu option for the old drive
is still there, and will probably remain until I install a new kernel.
Then I will have my current kernel on the new disk as my backup option.
ALWAYS have a plan!
Marc
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f751cfa.1050...@gmail.com
Re: Lilo not recognizing keyboard SOLVED)
On 3/25/2012 10:58 PM, Marc Shapiro wrote: I should have googled before posting. Aparently lilo is not capable of recognizing USB keyboards, but the BIOS can. All I needed to do was find the right BIOS option. The only tricky part was that this option (in my BIOS) says nothing about keyboards. The option was for allowing legacy USB support in DOS! Who looks for that?!? Anyone who has built/used PCs for say, 10 years, specifically whitebox, and has spent a fair amount of time in AMI/Award BIOS. Phoenix BIOS usually ships on retail branded boxen along with Intel retail mobos, and usually has this function enabled by default on anything sold within the past 7 years or so. So basically any HardwareFreak would know what to look for. ;) -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f704861.1040...@hardwarefreak.com
Re: Lilo not recognizing keyboard SOLVED)
On Sun, 25 Mar 2012 23:58:15 -0400 (EDT), Marc Shapiro wrote: I should have googled before posting. Aparently lilo is not capable of recognizing USB keyboards, but the BIOS can. All I needed to do was find the right BIOS option. The only tricky part was that this option (in my BIOS) says nothing about keyboards. The option was for allowing legacy USB support in DOS! Who looks for that?!? Once I found it, everything is working just fine. Yes, LILO uses the BIOS interface to the keyboard (int 16h, functions 00h (GET KEYSTROKE), 01h (CHECK FOR KEYSTROKE), and 02h (GET SHIFT FLAGS); so the BIOS must be set up to allow these keyboard BIOS calls to work with USB keyboards. That's a useful tip, Marc. I have not encountered this in any of the machines that I use LILO on that have USB keyboards, but obviously not all machines use the BIOS settings that LILO needs by default. Please provide more detailed information (i.e. what kind of BIOS was it? Award? IBM? Phoenix? AMI? What was the BIOS date? Exactly what menu options did you drill down through to find the setting?) I'd like to include this as an example problem on my LILO web page http://users.wowway.com/~zlinuxman/lilo.htm so please be as detailed as you can. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1732680206.155249.1332808031296.javamail.r...@md01.wow.synacor.com
Re: Lilo not recognizing keyboard SOLVED)
On 03/25/12 20:31, Marc Shapiro wrote: I just migrated my / partition to a larger partition on a new disk. I used find piped to cpio which took care of everything except modifications to fstab and lilo.conf and then running lilo. I made those changes, leaving tho old setup in lilo.conf as the default and the old disk installed until I was sure that everything was booting OK. Then I ran lilo and everything was as expected... until I rebooted. The lilo screen came up, showing my new menu option and all of my previous options. The problem is that I can not select anything, so it eventually boots into the default option. I can not select the other options, either with the arrow keys, or by typing in the desired option. Anything that I do at the keyboard is simply ignored and the default option boots. I recently installed a new keyboard and this one is a USB keyboard, instead of my old PS2 keyboard. Could this have anything to do with the problem. The keyboard works fine after linux is loaded. I should have googled before posting. Aparently lilo is not capable of recognizing USB keyboards, but the BIOS can. All I needed to do was find the right BIOS option. The only tricky part was that this option (in my BIOS) says nothing about keyboards. The option was for allowing legacy USB support in DOS! Who looks for that?!? Once I found it, everything is working just fine. Marc Shapiro -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6fe957.8070...@gmail.com
Re: lilo
On Fri, 19 Nov 2010 16:45:34 +0100, Frédéric ZULIAN zul...@free.fr wrote: vérifie que: * /vmlinux pointe bien vers le kernel qui est dans boot * le kernel est bien présent dans /boot * qu'il y est en entier lilo setup length exceeds 31 -- Nice guys finish last. -- Leo Durocher -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101119163627.71740...@anubis.defcon1
Re: lilo
Frédéric ZULIAN a écrit : Bonjour, Distribution : testing noyau : 2.6.32-5-686 portable Acer aspire one J'ai lilo qui me dit : lilo setup length exceeds 31; kernel setup will overide boot loader. Si je reboote j'ai droit à un écran plein de Contenu du lilo.conf large memory boot=/dev/sda root=/dev/sda6 map=/boot/map delay=200 default=Linux image=/vmlinux label=Linux read-only image=/dev/sda3 label=Windows Il ne faudrait pas une option other plutôt que image pour spécifier la partition de boot de Windows ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ce699de.7050...@plouf.fr.eu.org
Re: lilo
On Fri, 19 Nov 2010 16:38:06 +0100, Pascal Hambourg pascal.m...@plouf.fr.eu.org wrote: ... Il ne faudrait pas une option other plutôt que image pour spécifier la partition de boot de Windows ? Si, et utiliser Windows comme label est une mauvaise idée, à moins d'être habitué à switcher d'un clavier fr à un us... -- Q: What is the difference between Texas and yogurt? A: Yogurt has culture. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101119164547.3355d...@anubis.defcon1
Re: lilo
Jean-Yves F. Barbier a écrit : Si, et utiliser Windows comme label est une mauvaise idée, à moins d'être habitué à switcher d'un clavier fr à un us... Yapa de touches fléchées sur l'Acer ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ce6a194.4090...@plouf.fr.eu.org
Re: lilo
On Fri, 19 Nov 2010 17:11:00 +0100, Pascal Hambourg pascal.m...@plouf.fr.eu.org wrote: Jean-Yves F. Barbier a écrit : Si, et utiliser Windows comme label est une mauvaise idée, à moins d'être habitué à switcher d'un clavier fr à un us... Yapa de touches fléchées sur l'Acer ? Ben tu sais, ACER c'est fabriqué à l'économie, alors... :) Perso je préfère 1, 2, 9 (new krnl, old krnl, caca), ptêt que la ligne de Cde laisse des traces finalement. -- Let's show this prehistoric bitch how we do things downtown! -- The Ghostbusters -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101119201020.4e24a...@anubis.defcon1
Re: lilo config is busted, need help fixing it
On Sat, 25 Sep 2010 12:28:00 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: On Sat, 25 Sep 2010 03:40:04 -0400 (EDT), bri...@aracnet.com wrote: I'm also going to need to see the output of the following commands: ls -Al /dev/disk/by-id/ lrwxrwxrwx 1 root root 9 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692 - ../../sda lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part4 - ../../sda4 lrwxrwxrwx 1 root root 9 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692 - ../../sda lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part4 - ../../sda4 lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_CF_SDDR-189_2008102301130-0:3 - ../../sde lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_mSD_SDDR-189_2008102301130-0:0 - ../../sdb lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_MSxDSDDR-189_2008102301130-0:2 - ../../sdd lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_SD_SDDR-189_2008102301130-0:1 - ../../sdc ls -Al /dev/disk/by-uuid/ lrwxrwxrwx 1 root root 10 Sep 26 18:12 4b764501-da53-4323-a751-3da37d7e2a91 - ../../sda3 lrwxrwxrwx 1 root root 10 Sep 26 18:12 558d7790-5914-494d-938f-3387296eed45 - ../../sda4 lrwxrwxrwx 1 root root 10 Sep 26 18:12 9EFC3C45FC3C1A4B - ../../sda1 lrwxrwxrwx 1 root root 10 Sep 26 18:12 a948d6b6-8395-49a1-9f0f-21a10ceee9c2 - ../../sda2 So there's something going on with the swap partition (/dev/sda4). I must have had an aborted resume from hibernate mode or something (don't remember doing it). either way, not good. It seems like I have two different problems. I have a lilo entry that doesn't work at all and another one which dumps me into this resume nonsense. ERROR! No initial RAM disk specified! Add: initrd=/boot/initrd.img ok. ERROR! No initial RAM disk image. Add: initrd=/boot/initrd.img.old ok. /etc/kernel-img.conf Where is it? I need to see the contents of that file. It's very important. # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = no relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = yes postinst_hook = lilo-update postrm_hook = lilo-update I haven't gone through the rest of the changes yet. Working on that right now. Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100926191429.2ede9...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Sat, 25 Sep 2010 12:28:00 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: Several problems here. S30initramfs, S50symlink_hook, K30initramfs, and K50symlink_hook, though they will still work, I now consider obsolete. S30initramfs and K30initramfs were made obsolete by newer versions of the initramfs-tools package. The initramfs-tools hook scripts appear to be missing. And you have a couple of scripts called initramfs-tools.dpkg-dist. Are they renamed versions of initramfs-tools? Are they the current versions of them? I would erase S30initramfs, K30initramfs, and both copies of initramfs-tools.dpkg-dist, and reinstall the latest version of the initramfs-tools package. This should install a script called initramfs-tools in both /etc/kernel/postinst.d and /etc/kernel/postrm.d. All done. I am now running the latest lilo: ii lilo 1:22.8-8.3 LInux LOader - The Classic OS loader can load Linux and others however: Setting up linux-image-2.6.32-5-amd64 (2.6.32-23) ... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64 Running lilo-update. User postinst hook script [lilo-update] failed to execute: No such file or directory dpkg: error processing linux-image-2.6.32-5-amd64 (--configure): subprocess installed post-installation script returned error exit status 255 configured to not write apport reports Errors were encountered while processing: linux-image-2.6.32-5-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) I also don't see any zz-lilo hook scripts, which the latest version of lilo would have installed. Reinstall the latest version of lilo. This should also install a file in /etc/initramfs/post-update.d called lilo or runlilo, depending on which version of lilo you are running. Then remove S50symlink_hook and K50symlink_hook. Finally, install the two zy-symlinks hook scripts available on my web site, one for /etc/kernel/postinst.d and one for /etc/kernel/postrm.d. Then make sure that Yes the zz scripts are there now. However it looks like the lilo install is borked. Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100926192934.34dd3...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Sun, 26 Sep 2010 22:14:29 -0400 (EDT), bri...@aracnet.com wrote: On Sat, 25 Sep 2010 12:28:00 -0400 (EDT), Stephen Powell wrote: I'm also going to need to see the output of the following commands: ls -Al /dev/disk/by-id/ lrwxrwxrwx 1 root root 9 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692 - ../../sda lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part4 - ../../sda4 lrwxrwxrwx 1 root root 9 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692 - ../../sda lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part4 - ../../sda4 lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_CF_SDDR-189_2008102301130-0:3 - ../../sde lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_mSD_SDDR-189_2008102301130-0:0 - ../../sdb lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_MSxDSDDR-189_2008102301130-0:2 - ../../sdd lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_SD_SDDR-189_2008102301130-0:1 - ../../sdc ls -Al /dev/disk/by-uuid/ lrwxrwxrwx 1 root root 10 Sep 26 18:12 4b764501-da53-4323-a751-3da37d7e2a91 - ../../sda3 lrwxrwxrwx 1 root root 10 Sep 26 18:12 558d7790-5914-494d-938f-3387296eed45 - ../../sda4 lrwxrwxrwx 1 root root 10 Sep 26 18:12 9EFC3C45FC3C1A4B - ../../sda1 lrwxrwxrwx 1 root root 10 Sep 26 18:12 a948d6b6-8395-49a1-9f0f-21a10ceee9c2 - ../../sda2 So there's something going on with the swap partition (/dev/sda4). I must have had an aborted resume from hibernate mode or something (don't remember doing it). either way, not good. ERROR! No initial RAM disk specified! Add: initrd=/boot/initrd.img ok. ERROR! No initial RAM disk image. Add: initrd=/boot/initrd.img.old ok. /etc/kernel-img.conf Where is it? I need to see the contents of that file. It's very important. # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = no relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = yes postinst_hook = lilo-update postrm_hook = lilo-update You need to remove those last two lines, the ones that have lilo-update in them. At one time I recommended this for squeeze users that use only stock kernels, but I don't anymore. Besides, either you didn't write a corresponding lilo-update script or it got deleted somehow. Either way, you need to get rid of those two lines in /etc/kernel-img.conf. I haven't gone through the rest of the changes yet. Working on that right now. Also, in /etc/initramfs-tools/conf.d/resume, the file should reference the swap partition, not the root partition, either directly or via a UUID. Older versions of the Debian installer contained a version of mkswap that did not assign a UUID. Also, if you install another operating system in another partition, such as Ubuntu, it may reformat the swap partition, which will change its UUID. You can either use RESUME=/dev/sda4 or RESUME=UUID=558d7790-5914-494d-938f-3387296eed45 -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1149458522.286368.1285545072636.javamail.r...@md01.wow.synacor.com
Re: lilo config is busted, need help fixing it
On Sun, 26 Sep 2010 22:29:34 -0400 (EDT), bri...@aracnet.com wrote: On Sat, 25 Sep 2010 12:28:00 -0400 (EDT), Stephen Powell wrote: Several problems here. S30initramfs, S50symlink_hook, K30initramfs, and K50symlink_hook, though they will still work, I now consider obsolete. S30initramfs and K30initramfs were made obsolete by newer versions of the initramfs-tools package. The initramfs-tools hook scripts appear to be missing. And you have a couple of scripts called initramfs-tools.dpkg-dist. Are they renamed versions of initramfs-tools? Are they the current versions of them? I would erase S30initramfs, K30initramfs, and both copies of initramfs-tools.dpkg-dist, and reinstall the latest version of the initramfs-tools package. This should install a script called initramfs-tools in both /etc/kernel/postinst.d and /etc/kernel/postrm.d. All done. I am now running the latest lilo: ii lilo 1:22.8-8.3 LInux LOader - The Classic OS loader can load Linux and others however: Setting up linux-image-2.6.32-5-amd64 (2.6.32-23) ... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64 Running lilo-update. User postinst hook script [lilo-update] failed to execute: No such file or directory dpkg: error processing linux-image-2.6.32-5-amd64 (--configure): subprocess installed post-installation script returned error exit status 255 configured to not write apport reports Errors were encountered while processing: linux-image-2.6.32-5-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) As I indicated in my previous post, you need to remove those last two lines from /etc/kernel-img.conf, the ones which have lilo-update in them. That will solve the above problem. I also don't see any zz-lilo hook scripts, which the latest version of lilo would have installed. Reinstall the latest version of lilo. This should also install a file in /etc/initramfs/post-update.d called lilo or runlilo, depending on which version of lilo you are running. Then remove S50symlink_hook and K50symlink_hook. Finally, install the two zy-symlinks hook scripts available on my web site, one for /etc/kernel/postinst.d and one for /etc/kernel/postrm.d. Then make sure that ... Yes the zz scripts are there now. Good. Don't forget the zy-symlinks hook scripts and to delete the other ones and to install the latest initramfs-tools package, and to make sure that do_symlinks = no is set in /etc/kernel-img.conf. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1802866504.286767.1285545696278.javamail.r...@md01.wow.synacor.com
Re: lilo config is busted, need help fixing it
On Sun, 26 Sep 2010 19:51:12 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = no relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = yes postinst_hook = lilo-update postrm_hook = lilo-update You need to remove those last two lines, the ones that have lilo-update in them. At one time I recommended this for squeeze users that use only stock kernels, but I don't anymore. Besides, either you didn't write a corresponding lilo-update script or it got deleted somehow. Either way, you need to get rid of those two lines in /etc/kernel-img.conf. done. that explains the errors. that's the problem with this stuff is unwinding the call stack. Is there a magic option to pass apt-get or dpkg which will produce more verbose output ? Didn't see anything obvious in the manpage except for the quiet parameter. I haven't gone through the rest of the changes yet. Working on that right now. Also, in /etc/initramfs-tools/conf.d/resume, the file should reference the swap partition, not the root partition, either directly or via a UUID. Older versions of the Debian installer contained a version of mkswap that did not assign a UUID. Also, if you install another operating system in another partition, such as Ubuntu, it may reformat the swap partition, which will change its UUID. You can either use RESUME=/dev/sda4 or RESUME=UUID=558d7790-5914-494d-938f-3387296eed45 I'm not use if it makes a difference, but that file was referencing the uuid, so I changed it to point at /dev/sda, simply to be consistent with my fstab and lilo.conf. my guess is that it will break if I put another disk drive in, right ? Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100926182458.23913...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Sun, 26 Sep 2010 20:01:36 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: I also don't see any zz-lilo hook scripts, which the latest version of lilo would have installed. Reinstall the latest version of lilo. This should also install a file in /etc/initramfs/post-update.d called lilo or runlilo, depending on which version of lilo you are running. Then remove S50symlink_hook and K50symlink_hook. Finally, install the two zy-symlinks hook scripts available on my web site, one for /etc/kernel/postinst.d and one for /etc/kernel/postrm.d. Then make sure that ... Yes the zz scripts are there now. Good. Don't forget the zy-symlinks hook scripts and to delete the other ones and to install the latest initramfs-tools package, and to make sure that done. do_symlinks = no is set in /etc/kernel-img.conf. ok. and. IT WORKS ! Talking to you from a freshly booted machine :-) First time it's booted properly in quite sometime. I'm not really clear on what exactly fixed things, although those missing initrd lines were probably key. Thank you very much for your help ! I _really_ appreciate it. Now that it's working I can go back to try and create a custom kernel :-) Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100926182737.535a8...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Fri, 24 Sep 2010 21:18:25 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: Before I post all that stuff, let me show you exactly what's happening on boot. I think there is something very strange going on and it may not be lilo. Lin_img0 is : /boot/vmlinuz When I boot using that entry I get the following error: kernel-Panic: not syncing : VFS : Unable to mount root fs on unknown - block(8,2) specifying Lin_img0 root=/dev/sda2 DOES NOT WORK. When I use the lilo entry Lin_2.6.32img5, /boot/vmlinuz-2.6.32-5-amd64, AND specify root=/dev/sda2, i.e. Lin_2.6.32img5 root=/dev/sda2 I get the following weirdness: Running /scripts/local-premount resume: could not stat the resume device file /dev/disk/by-uuid/558d7790-5914-4949 enter full path: at that point I enter /dev/sda2 and then it boots normally. don't have any idea what the uuid it's try to use is, but this is a real WTF !? It seems like I have two different problems. I have a lilo entry that doesn't work at all and another one which dumps me into this resume nonsense. Here's a really interesting observation: The Lin_img0 lilo entry behaves differently from the Lin_2.6.32img5, BUT THEY BOTH USE THE SAME IMAGE ! /boot/vmlinuz is a symlink to vmlinuz-2.6.32-5-amd64. ugh... Brian On Fri, 24 Sep 2010 20:42:56 -0400 (EDT), bri...@aracnet.com wrote: I've run lilo and rebooted multiple times and always get the same result. Interesting. What happens if you specify root=802 as an argument to the boot prompt? I get the above resume weirdness. Please post your entire /etc/lilo.conf. Also post: # Generated by liloconfig # This allows booting from any partition on disks with more than 1024 # cylinders. lba32 # Specifies the boot device boot=/dev/sda # Specifies the device that should be mounted as root. # If the special name CURRENT is used, the root device is set to the # device on which the root file system is currently mounted. If the root # has been changed with -r , the respective device is used. If the # variable ROOT is omitted, the root device setting contained in the # kernel image is used. It can be changed with the rdev program. root=/dev/sda2 # Bitmap configuration for /boot/debianlilo.bmp # bitmap=/boot/debianlilo.bmp # bmp-colors=1,,0;9,,0 # bmp-table=106p,144p,2,9,144p # bmp-timer=514p,144p,6,8,0 # Enables map compaction: # Tries to merge read requests for adjacent sectors into a single # read request. This drastically reduces load time and keeps the map # smaller. Using COMPACT is especially recommended when booting from a # floppy disk. # compact # Install the specified file as the new boot sector. # LILO supports built in boot sectory, you only need # to specify the type, choose one from 'text', 'menu' or 'bitmap'. # new: install=bmp old: install=/boot/boot-bmp.b # new: install=text old: install=/boot/boot-text.b # new: install=menu old: install=/boot/boot-menu.b or boot.b # default: 'menu' is default, unless you have a bitmap= line # Note: install=bmp must be used to see the bitmap menu. install=menu # install=bmp # Specifies the number of _tenths_ of a second LILO should # wait before booting the first image. LILO # doesn't wait if DELAY is omitted or if DELAY is set to zero. # delay=50 # Prompt to use certaing image. If prompt is specified without timeout, # boot will not take place unless you hit RETURN prompt timeout=50 # Enable large memory mode. large-memory # Specifies the location of the map file. If MAP is # omitted, a file /boot/map is used. map=/boot/map # Specifies the VGA text mode that should be selected when # booting. The following values are recognized (case is ignored): # NORMAL select normal 80x25 text mode. # EXTENDED select 80x50 text mode. The word EXTENDED can be # abbreviated to EXT. # ASK stop and ask for user input (at boot time). # number use the corresponding text mode. A list of available modes # can be obtained by booting with vga=ask and pressing [Enter]. vga=normal # Defines non-standard parameters for the specified disk. # If you are using removable USB drivers (with mass-storage) # you will need to tell LILO to not use these devices even # if defined in /etc/fstab and referenced in /proc/partitions. # Adjust these lines to your devices: # # disk=/dev/sda inaccessible # These images were automagically added. You may need to edit something. image=/boot/vmlinuz label=Lin img0 read-only image=/boot/vmlinuz-2.6.26-2-amd64 label=Lin 2.6.26img2 initrd=/boot/initrd.img-2.6.26-2-amd64 read-only image=/boot/vmlinuz-2.6.31-1-amd64 label=Lin 2.6.31img3 initrd=/boot/initrd.img-2.6.31-1-amd64 read-only image=/boot/vmlinuz-2.6.32-3-amd64 label=Lin 2.6.32img4 initrd=/boot/initrd.img-2.6.32-3-amd64 read-only image=/boot/vmlinuz-2.6.32-5-amd64 label=Lin 2.6.32img5
Re: lilo config is busted, need help fixing it
On Sat, 25 Sep 2010 00:17:30 -0500 Stan Hoeppner s...@hardwarefreak.com wrote: bri...@aracnet.com put forth on 9/24/2010 7:42 PM: right now I'm thinking I've got something misconfigured, but what ?? Running lilo manually should fix whatever's going on and it most certainly isn't. Did you possibly lose your BIOS LBA configuration before the dist-upgrade, and didn't know it? If your CMOS battery had died, which is quite common on 4-5+ year old systems, and you rebooted the PC, when it came back up your BIOS data would be at defaults. In this case your disk geometry in the BIOS may have changed from say, LBA, to LARGE, or NORMAL. If this occurred, it might explain your problems. Once the system is booted after you manually specify /dev/sda2 at the prompt, the ATA driver may be defaulting to LBA mode. Thus, when you run lilo, it's basing sector translation on block offsets using LBA. When you reboot, if the BIOS is set to NORMAL (CHS) or LARGE, the translation isn't going to match what lilo saved in the MBR or the first sector of a partition, whichever method you use. When you specify /dev/sda2 at the prompt, the bootloader is working with the current BIOS translation setting and correctly finds the disk sectors for the root filesystem. This may explain why you can successfully boot in this manner, but not using the normal automatic lilo boot--the sector translations may be different. This is all a shot in the dark and I could be smoking crack. But, it _seems_ possible given your symptoms. Check your mobo BIOS, or PCI card disk controller BIOS, if that's what your disk is attached to, and make sure the drive translation is set to LBA, which is likely what it was before. I have it set to auto which is what it's always been set to. Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100925004128.18a11...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Sat, 25 Sep 2010 00:54:12 -0400 (EDT), Stan Hoeppner wrote: Stephen Powell put forth on 9/24/2010 4:06 PM: Current stock Debian kernels for the amd64 architecture are right on the ragged edge of being too large for lilo to load below the 16M line And the bulk of these ~16MB stock kernels is the initrd, correct? Wow those are huge. I'm so glad I roll my own, from kernel.org source, and forgo the kitchen sink initrd setups of the stock kernels. -rw-r--r-- 1 root root 1.5M Jul 9 09:29 vmlinuz-2.6.34.1 -rw-r--r-- 1 root root 490K Jul 9 09:29 System.map-2.6.34.1 -rw-r--r-- 1 root root 29K Jul 9 09:29 config-2.6.34.1 At my pace of kernel file growth, I won't hit the lilo 22.8 16MB limit for a few decades. :) Correct me if I'm wrong Stephen, but isn't this 16MB ceiling more of a block device controller BIOS limitation than a lilo limitation? There are a couple of misconceptions here. It is true that the initial RAM disk images on disk, when the default value of MODULES=most is specified, are larger than the size of the kernel image on disk. But that is not what I'm talking about. I'm talking about the kernel itself. You see, the kernel image on disk, which gets loaded by lilo into memory, is partially compressed. That is, a small portion of the kernel code at the beginning of the kernel is uncompressed, but the majority of it is compressed. That's why the kernel image has the naming comvention vmlinuz-* instead of vmlinux-*. (The initial RAM disk image on disk is compressed too.) When lilo transfers control to the kernel, one of the first things the kernel does is to decompress its compressed portion. From what I can tell, it allocates some memory somewhere large enough to hold the decompressed portion of itself, does the decompression, frees the compressed portion of kernel memory, allocates a new chunk of memory starting where the compressed portion resides and the same size as the uncompressed hunk, copies the uncompressed hunk there, and then frees the working copy of the uncompressed hunk. The net effect is that the compressed kernel is decompressed in place. The compressed initial RAM file system image, also loaded by lilo, has not yet been touched at this point. lilo tries to load the compressed kernel image between the 1M line and the 15M line (total 14M), even when large-memory is specified, at as low an address as possible. lilo must determine whether the *decompressed* kernel will fit in this space. If not, memory above 16M must be used. The compression ratio for an amd64-architecture kernel is significantly higher than for an i386-architecture kernel. The current version of lilo underestimates the uncompressed size of an amd64-architecture kernel and may decide that the kernel will fit between 1M and 15M, when in reality, it won't. This is especially likely if the compressed initial RAM file system image is also being loaded in this space. lilo 23.0 fixes this problem. The uncompressed sizes of stock amd64 kernel images are quite large, and are close to the 14M limit of below-16M loading. If the uncompressed kernel won't fit there, then it must be loaded above 16M, even if the compressed image will fit below 16M easily. Some old BIOS do not support the BIOS calls that lilo, running in real mode, uses to copy a block of memory above the 16M line. This can be tested for using the lilo diagnostic diskette that I have posted on my web site. But I am not aware of any 64-bit machines with this restriction. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1689734423.261585.1285415112079.javamail.r...@md01.wow.synacor.com
Re: lilo config is busted, need help fixing it
On Sat, 25 Sep 2010 03:40:04 -0400 (EDT), bri...@aracnet.com wrote: Before I post all that stuff, let me show you exactly what's happening on boot. I think there is something very strange going on and it may not be lilo. Lin_img0 is : /boot/vmlinuz When I boot using that entry I get the following error: kernel-Panic: not syncing : VFS : Unable to mount root fs on unknown - block(8,2) specifying Lin_img0 root=/dev/sda2 DOES NOT WORK. After looking at your /etc/lilo.conf file, I'm not surprised. More later. When I use the lilo entry Lin_2.6.32img5, /boot/vmlinuz-2.6.32-5-amd64, AND specify root=/dev/sda2, i.e. Lin_2.6.32img5 root=/dev/sda2 I get the following weirdness: Running /scripts/local-premount resume: could not stat the resume device file /dev/disk/by-uuid/558d7790-5914-4949 enter full path: at that point I enter /dev/sda2 and then it boots normally. don't have any idea what the uuid it's try to use is, but this is a real WTF !? OK, I'm also goint to need to see the contents of /etc/initramfs-tools/conf.d/resume. I'm also going to need to see the output of the following commands: ls -Al /dev/disk/by-id/ ls -Al /dev/disk/by-uuid/ It seems like I have two different problems. I have a lilo entry that doesn't work at all and another one which dumps me into this resume nonsense. Agreed. Here's a really interesting observation: The Lin_img0 lilo entry behaves differently from the Lin_2.6.32img5, BUT THEY BOTH USE THE SAME IMAGE ! /boot/vmlinuz is a symlink to vmlinuz-2.6.32-5-amd64. ugh... That makes sense, given your config file. Stephen Powell wrote: Interesting. What happens if you specify root=802 as an argument to the boot prompt? I get the above resume weirdness. Good. It's consistent. That means that the kernel is treating root=/dev/sda2 and root=802 as equivalent, which it should. Stephen Powell wrote: Please post your entire /etc/lilo.conf. # Generated by liloconfig # This allows booting from any partition on disks with more than 1024 # cylinders. lba32 # Specifies the boot device boot=/dev/sda # Specifies the device that should be mounted as root. # If the special name CURRENT is used, the root device is set to the # device on which the root file system is currently mounted. If the root # has been changed with -r , the respective device is used. If the # variable ROOT is omitted, the root device setting contained in the # kernel image is used. It can be changed with the rdev program. root=/dev/sda2 # Bitmap configuration for /boot/debianlilo.bmp # bitmap=/boot/debianlilo.bmp # bmp-colors=1,,0;9,,0 # bmp-table=106p,144p,2,9,144p # bmp-timer=514p,144p,6,8,0 # Enables map compaction: # Tries to merge read requests for adjacent sectors into a single # read request. This drastically reduces load time and keeps the map # smaller. Using COMPACT is especially recommended when booting from a # floppy disk. # compact I would uncomment the above compact line for performance reasons, but this is not your problem and it is not required. # Install the specified file as the new boot sector. # LILO supports built in boot sectory, you only need # to specify the type, choose one from 'text', 'menu' or 'bitmap'. # new: install=bmp old: install=/boot/boot-bmp.b # new: install=text old: install=/boot/boot-text.b # new: install=menu old: install=/boot/boot-menu.b or boot.b # default: 'menu' is default, unless you have a bitmap= line # Note: install=bmp must be used to see the bitmap menu. install=menu # install=bmp # Specifies the number of _tenths_ of a second LILO should # wait before booting the first image. LILO # doesn't wait if DELAY is omitted or if DELAY is set to zero. # delay=50 # Prompt to use certaing image. If prompt is specified without timeout, # boot will not take place unless you hit RETURN prompt timeout=50 # Enable large memory mode. large-memory Good! # Specifies the location of the map file. If MAP is # omitted, a file /boot/map is used. map=/boot/map # Specifies the VGA text mode that should be selected when # booting. The following values are recognized (case is ignored): # NORMAL select normal 80x25 text mode. # EXTENDED select 80x50 text mode. The word EXTENDED can be # abbreviated to EXT. # ASK stop and ask for user input (at boot time). # number use the corresponding text mode. A list of available modes # can be obtained by booting with vga=ask and pressing [Enter]. vga=normal # Defines non-standard parameters for the specified disk. # If you are using removable USB drivers (with mass-storage) # you will need to tell LILO to not use these devices even # if defined in /etc/fstab and referenced in /proc/partitions. # Adjust these lines to your devices: # # disk=/dev/sda inaccessible # These images were automagically
Re: lilo config is busted, need help fixing it
Try reinstalling your kernel, or if you compiled your own, install a recent linux-image-2.6.32.5 from Sid. The postinstall script will point /etc/fstab and lilo.conf to the newer UUID references and then it should play. The postinstall for home-brew kernels does not do this for you, I'm afraid and I was dead in the water for a few weeks till I installed the stock image. (Afterwards, you do not need to keep it if your home-brew kernel now boots OK.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009241157.26007.d_ba...@012.net.il
Re: lilo config is busted, need help fixing it
On Fri, 24 Sep 2010 11:57:25 +0200 David Baron d_ba...@012.net.il wrote: Try reinstalling your kernel, or if you compiled your own, install a recent linux-image-2.6.32.5 from Sid. The postinstall script will point /etc/fstab and lilo.conf to the newer UUID references and then it should play. I'll give it a try,but I'm not clear on what the UUID reference has to do with anything. it boots fine with root=/dev/sda2 and my fstab is consistent, i.e. uses device designation and _not_ UUIDs. The postinstall for home-brew kernels does not do this for you, I'm afraid and I was dead in the water for a few weeks till I installed the stock image. I'm running a stock kernel. However it's certainly worth a try to see if it fixes it. I'm following Steve Powell's excellent kernel guide: http://www.wowway.com/~zlinuxman/Kernel.htm and I'm fairly certain I've done everything correctly. The real question here is: what tells lilo what the root device is ?? The lilo.conf file is correct. Is there something in one of the .map files are some other auxiliary file screwing things up ? Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100924070718.5465b...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Fri, 24 Sep 2010 11:57:25 +0200 David Baron d_ba...@012.net.il wrote: Try reinstalling your kernel, or if you compiled your own, install a recent linux-image-2.6.32.5 from Sid. The postinstall script will point /etc/fstab and lilo.conf to the newer UUID references and then it should play. The postinstall for home-brew kernels does not do this for you, I'm afraid and I was dead in the water for a few weeks till I installed the stock image. (Afterwards, you do not need to keep it if your home-brew kernel now boots OK.) I deleted one of the older images and when it finished I got this mess: Could not find postrm hook script [lilo-update]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' Examining /etc/kernel/postrm.d . Purging configuration files for linux-image-2.6.18-6-amd64 ... Could not find postrm hook script [lilo-update]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' Examining /etc/kernel/postrm.d . clearly I did not follow Mr. Powells guide correctly. Fun project for the weekend. Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100924071053.1c259...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Fri, 24 Sep 2010 10:10:53 -0400 (EDT), bri...@aracnet.com wrote: I deleted one of the older images and when it finished I got this mess: Could not find postrm hook script [lilo-update]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' Examining /etc/kernel/postrm.d . Purging configuration files for linux-image-2.6.18-6-amd64 ... Could not find postrm hook script [lilo-update]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' Examining /etc/kernel/postrm.d . clearly I did not follow Mr. Powells guide correctly. Fun project for the weekend. Hello, Brian. I have been following this thread, but I didn't want to respond until I tried it myself. There is an important difference between specifying root=/dev/sda2 at the boot prompt versus supplying it in /etc/lilo.conf. When you supply it on the command line at a boot prompt, I'm fairly sure that it passes that literal string to the kernel during boot. But when you specify it in /etc/lilo.conf, lilo's map installer translates it into a four-digit hexadecimal number consisting of a two-digit major number and a two-digit minor number. It is that number which gets passed to the kernel at boot time. In your case it would be root=802 (The leading zero is suppressed.) So it is theoretically possible that something changed in the kernel so that it does not correctly handle that type of root argument. Having said that, however, I cannot reproduce your results using the latest stock Debian kernel for squeeze for the i386 architecture: linux-image-2.6.32-5-686, version 2.6.32-23. Unless it is something specific to the amd64 architecture, which I doubt, I suspect that lilo didn't get run during the upgrade, as the above console log suggests. The first thing to try is to manually run lilo, shutdown and reboot, and see if it fixes the problem. If it does, then it's a pretty safe bet that lilo did not get run during the upgrade, or at least not at the right time. Due to changes in the way hook scripts are handled, I no longer recommend using a hook script invoked from /etc/kernel-img.conf, even when using stock kernels. And the latest version of lilo available for squeeze, 1:22.8-8.3, now includes its own hook scripts. These hook scripts do not maintain symbolic links, however. If you are using only stock kernels, you can take care of getting symlinks maintained by using do_symlinks = yes in /etc/kernel-img.conf, but if you use custom kernels at all, this won't cut it. In that case, you need my zy-symlinks hook scripts from my web site. Also, I am using lilo 23.0, which is available from upstream but not yet as an official Debian package; so that also might possibly explain why I cannot reproduce your problem. But I doubt it. Current stock Debian kernels for the amd64 architecture are right on the ragged edge of being too large for lilo to load below the 16M line; and lilo 23.0 contains some important fixes for amd64 users; so you might want to give lilo 23.0 a try. I suggest that you review http://www.wowway.com/~zlinuxman/Kernel.htm#Customize for a more complete treatment of the topic. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1437715587.253054.1285362403558.javamail.r...@md01.wow.synacor.com
Re: lilo config is busted, need help fixing it
On Fri, 24 Sep 2010 17:06:43 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: On Fri, 24 Sep 2010 10:10:53 -0400 (EDT), bri...@aracnet.com wrote: I deleted one of the older images and when it finished I got this mess: Could not find postrm hook script [lilo-update]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' Examining /etc/kernel/postrm.d . Purging configuration files for linux-image-2.6.18-6-amd64 ... Could not find postrm hook script [lilo-update]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' Examining /etc/kernel/postrm.d . clearly I did not follow Mr. Powells guide correctly. Fun project for the weekend. Hello, Brian. I have been following this thread, but I didn't want to respond until I tried it myself. There is an important difference between specifying root=/dev/sda2 at the boot prompt versus supplying it in /etc/lilo.conf. When you supply it on the command line at a boot prompt, I'm fairly sure that it passes that literal string to the kernel during boot. But when you specify it in /etc/lilo.conf, lilo's map installer translates it into a four-digit hexadecimal number consisting of a two-digit major number and a two-digit minor number. It is that number which gets passed to the kernel at boot time. In your case it would be root=802 (The leading zero is suppressed.) So it is theoretically possible that something changed in the kernel so that it does not correctly handle that type of root argument. Having said that, however, I cannot reproduce your results using the latest stock Debian kernel for squeeze for the i386 architecture: linux-image-2.6.32-5-686, version 2.6.32-23. Unless it is something specific to the amd64 architecture, which I doubt, I suspect that lilo didn't get run during the upgrade, as the above console log suggests. The first thing to try is to manually run lilo, shutdown and reboot, and see if it fixes the problem. If it does, then it's a pretty safe bet that lilo did not get run during the upgrade, or at least not at the right time. I've run lilo and rebooted multiple times and always get the same result. I suggest that you review http://www.wowway.com/~zlinuxman/Kernel.htm#Customize for a more complete treatment of the topic. I've been using that as my guide. right now I'm thinking I've got something misconfigured, but what ?? Running lilo manually should fix whatever's going on and it most certainly isn't. Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100924174256.283dd...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Fri, 24 Sep 2010 20:42:56 -0400 (EDT), bri...@aracnet.com wrote: I've run lilo and rebooted multiple times and always get the same result. Interesting. What happens if you specify root=802 as an argument to the boot prompt? right now I'm thinking I've got something misconfigured, but what ?? Running lilo manually should fix whatever's going on and it most certainly isn't. Please post your entire /etc/lilo.conf. Also post: /etc/kernel-img.conf A list of all files in /etc/kernel/postinst.d A list of all files in /etc/kernel/postrm.d A list of all files in /boot The definitions of the boot-related symlinks: vmlinuz initrd.img vmlinuz.old initrd.img.old The output of lilo -v -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1780951118.257185.1285377505422.javamail.r...@md01.wow.synacor.com
Re: lilo config is busted, need help fixing it
Stephen Powell put forth on 9/24/2010 4:06 PM: Current stock Debian kernels for the amd64 architecture are right on the ragged edge of being too large for lilo to load below the 16M line And the bulk of these ~16MB stock kernels is the initrd, correct? Wow those are huge. I'm so glad I roll my own, from kernel.org source, and forgo the kitchen sink initrd setups of the stock kernels. -rw-r--r-- 1 root root 1.5M Jul 9 09:29 vmlinuz-2.6.34.1 -rw-r--r-- 1 root root 490K Jul 9 09:29 System.map-2.6.34.1 -rw-r--r-- 1 root root 29K Jul 9 09:29 config-2.6.34.1 At my pace of kernel file growth, I won't hit the lilo 22.8 16MB limit for a few decades. :) Correct me if I'm wrong Stephen, but isn't this 16MB ceiling more of a block device controller BIOS limitation than a lilo limitation? -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9d8074.5040...@hardwarefreak.com
Re: lilo config is busted, need help fixing it
bri...@aracnet.com put forth on 9/24/2010 7:42 PM: right now I'm thinking I've got something misconfigured, but what ?? Running lilo manually should fix whatever's going on and it most certainly isn't. Did you possibly lose your BIOS LBA configuration before the dist-upgrade, and didn't know it? If your CMOS battery had died, which is quite common on 4-5+ year old systems, and you rebooted the PC, when it came back up your BIOS data would be at defaults. In this case your disk geometry in the BIOS may have changed from say, LBA, to LARGE, or NORMAL. If this occurred, it might explain your problems. Once the system is booted after you manually specify /dev/sda2 at the prompt, the ATA driver may be defaulting to LBA mode. Thus, when you run lilo, it's basing sector translation on block offsets using LBA. When you reboot, if the BIOS is set to NORMAL (CHS) or LARGE, the translation isn't going to match what lilo saved in the MBR or the first sector of a partition, whichever method you use. When you specify /dev/sda2 at the prompt, the bootloader is working with the current BIOS translation setting and correctly finds the disk sectors for the root filesystem. This may explain why you can successfully boot in this manner, but not using the normal automatic lilo boot--the sector translations may be different. This is all a shot in the dark and I could be smoking crack. But, it _seems_ possible given your symptoms. Check your mobo BIOS, or PCI card disk controller BIOS, if that's what your disk is attached to, and make sure the drive translation is set to LBA, which is likely what it was before. Like I said, it's a long shot...but worth checking. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9d85ea.6030...@hardwarefreak.com
Re: lilo config is busted, need help fixing it
bri...@aracnet.com put forth on 9/23/2010 10:50 PM: Boot image: /boot/vmlinuz-2.6.32-5-amd64 Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders, 63 sectors. Partition offset: 120583890 sectors. Using Volume ID 5879D4A8 on bios 80 Setup length is 27 sectors. Mapped 4708 sectors. Mapping RAM disk /boot/initrd.img-2.6.32-5-amd64 Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders, 63 sectors. Partition offset: 120583890 sectors. Using Volume ID 5879D4A8 on bios 80 RAM disk: 9407 sectors. Added Lin_2.6.32img5 dev=0xe0,hd=227,cyl=57,sct=204 ro root=802 I immediately noticed that dev=0xe0 shouldn't dev=0x82 !!?? No, that's normal. What had you changed on the system immediately prior to this boot problem occurring? Boot image: /boot/vmlinuz-2.6.34.1 Device 0x0801: BIOS drive 0x80, 16 heads, 969021 cylinders, 63 sectors. Partition offset: 63 sectors. Using Volume ID 37945249 on bios 80 Setup length is 23 sectors. Mapped 2909 sectors. Added Linux (alias 1) * dev=0xe0,hd=0,cyl=22,sct=25 ro root=802 Boot image: /boot/vmlinuz-2.6.32.9 Device 0x0801: BIOS drive 0x80, 16 heads, 969021 cylinders, 63 sectors. Partition offset: 63 sectors. Using Volume ID 37945249 on bios 80 Setup length is 23 sectors. Mapped 2879 sectors. Added LinuxOLD (alias 2) dev=0xe0,hd=0,cyl=22,sct=58 ro root=802 -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9c271d.1040...@hardwarefreak.com
Re: lilo config is busted, need help fixing it
On Thu, 23 Sep 2010 23:20:45 -0500 Stan Hoeppner s...@hardwarefreak.com wrote: bri...@aracnet.com put forth on 9/23/2010 10:50 PM: Boot image: /boot/vmlinuz-2.6.32-5-amd64 Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders, 63 sectors. Partition offset: 120583890 sectors. Using Volume ID 5879D4A8 on bios 80 Setup length is 27 sectors. Mapped 4708 sectors. Mapping RAM disk /boot/initrd.img-2.6.32-5-amd64 Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders, 63 sectors. Partition offset: 120583890 sectors. Using Volume ID 5879D4A8 on bios 80 RAM disk: 9407 sectors. Added Lin_2.6.32img5 dev=0xe0,hd=227,cyl=57,sct=204 ro root=802 I immediately noticed that dev=0xe0 shouldn't dev=0x82 !!?? No, that's normal. What had you changed on the system immediately prior to this boot problem occurring? apt-get dist-upgrade, natch. it's very odd, because it runs just fine. and it boots fine as long as I supply the root=/dev/sda2 aaargh. I've never had so much trouble in my entire linux/debian/life. I have had a smooth boot or bootloader upgrade on this computer since I fired it up. other one works good, though. but really, 1/2 _is_ bad. Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100923212556.0a8f9...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
On Thu, 23 Sep 2010 21:25:56 -0700 bri...@aracnet.com wrote: aaargh. I've never had so much trouble in my entire linux/debian/life. I have had a smooth boot or bootloader upgrade on this computer since I fired it up. other one works good, though. but really, 1/2 _is_ bad. I have NOT had a smooth, etc... Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100923213350.6b3e3...@windy.deldotd.com
Re: lilo config is busted, need help fixing it
bri...@aracnet.com put forth on 9/23/2010 11:25 PM: No, that's normal. What had you changed on the system immediately prior to this boot problem occurring? apt-get dist-upgrade, natch. WTF is natch? -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9c2ca9.3020...@hardwarefreak.com
Re: lilo config is busted, need help fixing it
In 4c9c2ca9.3020...@hardwarefreak.com, Stan Hoeppner wrote: bri...@aracnet.com put forth on 9/23/2010 11:25 PM: No, that's normal. What had you changed on the system immediately prior to this boot problem occurring? apt-get dist-upgrade, natch. WTF is natch? Shortening of naturally, which in this context is slang for of course or as expected. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Lilo: fatal: raid_setup: stat(/dev/hda)
On Fri, 03 Sep 2010 12:06:29 -0400 (EDT), Thomas H. George wrote: After latest upgrade installation of lilo fails. I am not using raid and have the entry boot=/dev/hda in lilo.conf as specified in the man page. The installation fails with error code 01 which according to the lilo man page means invalid disk command. Does it now want a UUID? If so, where do I find the correct UUID. Values for the partitions are listed in /etc/fstab but not for the MBR. I have checked several posibilities in /proc without success. In particular in /proc/bus there are now only three subdirectories, Input, pci and usb. Since this a new problem I checked the archives for August and September but found nothing about lilo. Your post is lacking important information to diagnose the problem. For example, (1) Are you running Lenny or Squeeze? (or something else) (2) What architecture? (i386 or amd64) (3) What kernel are you running? Is it stock or custom? If it is custom, exactly how did you build it? (4) What additional backup kernels (if any) do you have installed? (5) What files, if any, are present in the following directories: /etc/kernel/postinst.d /etc/kernel/postrm.d /etc/initramfs/post-update.d (6) I'd like to see the contents of the following files: /etc/kernel-img.conf /etc/fstab /etc/initramfs-tools/conf.d/resume /etc/initramfs-tools/conf.d/driver-policy /etc/lilo.conf (7) I'd like to see the output of the following commands: ls -Ald /dev/disk/by-uuid/ ls -Ald /dev/disk/by-path/ ls -Ald /dev/disk/by-id/ -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1738770522.590432.1283531048557.javamail.r...@md01.wow.synacor.com
Re: Lilo: fatal: raid_setup: stat(/dev/hda)
On Fri, Sep 03, 2010 at 12:24:08PM -0400, Stephen Powell wrote: On Fri, 03 Sep 2010 12:06:29 -0400 (EDT), Thomas H. George wrote: After latest upgrade installation of lilo fails. I am not using raid and have the entry boot=/dev/hda in lilo.conf as specified in the man page. The installation fails with error code 01 which according to the lilo man page means invalid disk command. Does it now want a UUID? If so, where do I find the correct UUID. Values for the partitions are listed in /etc/fstab but not for the MBR. I have checked several posibilities in /proc without success. In particular in /proc/bus there are now only three subdirectories, Input, pci and usb. Since this a new problem I checked the archives for August and September but found nothing about lilo. Your post is lacking important information to diagnose the problem. For example, (1) Are you running Lenny or Squeeze? (or something else) Squeeze (2) What architecture? (i386 or amd64) amd64 (3) What kernel are you running? Is it stock or custom? If it is custom, exactly how did you build it? Stock kernel 2.6.32-5-amd64 (4) What additional backup kernels (if any) do you have installed? /boot/vmlinuz-2.6.24-1-amd64.sav /boot/vmlinuz-2.6.26-1-amd64 /boot/vmlinuz-2.6.26-2-amd64 /boot/vmlinuz-2.6.30-1-amd64 /boot/vmlinuz-2.6.30-2-amd64 /boot/vmlinuz-2.6.32-3-amd64 /boot/vmlinuz-2.6.32-5-amd64 (5) What files, if any, are present in the following directories: /etc/kernel/postinst.d initramfs-tools pm-utils zz-lilo zz-update-grub /etc/kernel/postrm.d initramfs-tools zz-lilo zz-update-grub /etc/initramfs/post-update.d lilo (6) I'd like to see the contents of the following files: /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = no /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 # /dev/sdb1 / ext3errors=remount-ro 0 1 UUID=bfcd3316-153a-4279-ab86-286906857b98 / ext3 errors=remount-ro 0 1 # /dev/sdb5 noneswapsw 0 0 UUID=4b1523d0-bec9-4565-b085-0a151469b8db noneswapsw 0 0 # formerly named /dev/sda1 is now: UUID=507caf8f-f9cd-4ed2-91cc-3e46ae942e9d /bkups ext3 rw,user,noauto 0 2 # /dev/sda5 /ubuntu ext3defaults0 2 UUID=28a4eb99-6213-4b82-96a2-42b45097e256 /ubuntu ext3 defaults0 2 # /dev/sda6 /data ext3defaults0 2 UUID=36cb29b0-2694-4dee-9ae4-10351963b979 /data ext3 defaults0 2 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 # /dev/hda1 /temp ext2rw,user,auto0 2 UUID=4a2915d8-60cf-498e-a15c-f0bc6ebdb25e /temp ext2 rw,user,auto0 2 # /dev/hda5 /storageext2defaults0 2 UUID=408287f4-8b15-42d1-b6d3-bfeaefde3002 /storageext2 defaults0 2 # /etc/fstab: static file system information. # # file system mount point type options dump pass /dev/cdrom /cdrom iso9660 ro,user,noauto 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/scd0 /media/cddata autoro,user,noauto 0 0 /dev/scd1 /media/cdrom1 udf,iso9660 user,noauto 0 0 /dev/sdc1 /usbkey autorw,user,noauto 0 0 /dev/sdc5 /media/bkup ext3rw,user,noauto 0 0 /dev/sdc/media/fuze vfatrw,user,noauto 0 0 /dev/sr0/media/cdrw iso9660 rw,user,noauto 0 0 /dev/sr1/dvdrw iso9660 rw,user,noauto 0 0 /dev/sg0/sony iso9660 rw,user,noauto 0 0 /dev/sg1/usbdrive vfatrw,user,noauto 0 0 /dev/sdd1 /usbmem vfatrw,user,noauto 0 0 /etc/initramfs-tools/conf.d/resume # RESUME=/dev/sdb5 RESUME='UUID=4b1523d0-bec9-4565-b085-0a151469b8db' /etc/initramfs-tools/conf.d/driver-policy No such file /etc/lilo.conf # Automatically added by lilo postinst script large-memory # /etc/lilo.conf - See: `lilo(8)' and `lilo.conf(5)', # --- `install-mbr(8)', `/usr/share/doc/lilo/', # and `/usr/share/doc/mbr/'. # +---+ # |!!
Re: Lilo: fatal: raid_setup: stat(/dev/hda)
On Fri, 03 Sep 2010 14:15:23 -0400 (EDT), Thomas H. George wrote: On Fri, Sep 03, 2010 at 12:24:08PM -0400, Stephen Powell wrote: On Fri, 03 Sep 2010 12:06:29 -0400 (EDT), Thomas H. George wrote: After latest upgrade installation of lilo fails. I am not using raid and have the entry boot=/dev/hda in lilo.conf as specified in the man page. The installation fails with error code 01 which according to the lilo man page means invalid disk command. Does it now want a UUID? If so, where do I find the correct UUID. Values for the partitions are listed in /etc/fstab but not for the MBR. I have checked several posibilities in /proc without success. In particular in /proc/bus there are now only three subdirectories, Input, pci and usb. Since this a new problem I checked the archives for August and September but found nothing about lilo. Your post is lacking important information to diagnose the problem. For example, (1) Are you running Lenny or Squeeze? (or something else) Squeeze (2) What architecture? (i386 or amd64) amd64 (3) What kernel are you running? Is it stock or custom? If it is custom, exactly how did you build it? Stock kernel 2.6.32-5-amd64 (4) What additional backup kernels (if any) do you have installed? /boot/vmlinuz-2.6.24-1-amd64.sav /boot/vmlinuz-2.6.26-1-amd64 /boot/vmlinuz-2.6.26-2-amd64 /boot/vmlinuz-2.6.30-1-amd64 /boot/vmlinuz-2.6.30-2-amd64 /boot/vmlinuz-2.6.32-3-amd64 /boot/vmlinuz-2.6.32-5-amd64 (5) What files, if any, are present in the following directories: /etc/kernel/postinst.d initramfs-tools pm-utils zz-lilo zz-update-grub /etc/kernel/postrm.d initramfs-tools zz-lilo zz-update-grub /etc/initramfs/post-update.d lilo (6) I'd like to see the contents of the following files: /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = no /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc /proc procdefaults0 0 # /dev/sdb1 / ext3errors=remount-ro 0 1 UUID=bfcd3316-153a-4279-ab86-286906857b98 / ext3 errors=remount-ro 0 1 # /dev/sdb5 noneswapsw 0 0 UUID=4b1523d0-bec9-4565-b085-0a151469b8db noneswapsw 0 0 # formerly named /dev/sda1 is now: UUID=507caf8f-f9cd-4ed2-91cc-3e46ae942e9d /bkups ext3 rw,user,noauto 0 2 # /dev/sda5 /ubuntu ext3defaults0 2 UUID=28a4eb99-6213-4b82-96a2-42b45097e256 /ubuntu ext3 defaults0 2 # /dev/sda6 /data ext3defaults0 2 UUID=36cb29b0-2694-4dee-9ae4-10351963b979 /data ext3 defaults0 2 /dev/fd0 /media/floppy0 autorw,user,noauto 0 0 # /dev/hda1 /temp ext2rw,user,auto0 2 UUID=4a2915d8-60cf-498e-a15c-f0bc6ebdb25e /temp ext2 rw,user,auto0 2 # /dev/hda5 /storageext2defaults0 2 UUID=408287f4-8b15-42d1-b6d3-bfeaefde3002 /storageext2 defaults0 2 # /etc/fstab: static file system information. # # file system mount point type options dump pass /dev/cdrom/cdrom iso9660 ro,user,noauto 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/scd0 /media/cddata autoro,user,noauto 0 0 /dev/scd1 /media/cdrom1 udf,iso9660 user,noauto 0 0 /dev/sdc1 /usbkey autorw,user,noauto 0 0 /dev/sdc5 /media/bkup ext3rw,user,noauto 0 0 /dev/sdc /media/fuze vfatrw,user,noauto 0 0 /dev/sr0 /media/cdrw iso9660 rw,user,noauto 0 0 /dev/sr1 /dvdrw iso9660 rw,user,noauto 0 0 /dev/sg0 /sony iso9660 rw,user,noauto 0 0 /dev/sg1 /usbdrive vfatrw,user,noauto 0 0 /dev/sdd1 /usbmem vfatrw,user,noauto 0 0 /etc/initramfs-tools/conf.d/resume # RESUME=/dev/sdb5 RESUME='UUID=4b1523d0-bec9-4565-b085-0a151469b8db' /etc/initramfs-tools/conf.d/driver-policy No such file /etc/lilo.conf # Automatically added by lilo postinst script large-memory # /etc/lilo.conf - See: `lilo(8)' and `lilo.conf(5)', # --- `install-mbr(8)', `/usr/share/doc/lilo/', # and `/usr/share/doc/mbr/'.
Re: Lilo: fatal: raid_setup: stat(/dev/hda)
On Fri, Sep 03, 2010 at 03:49:10PM -0400, Stephen Powell wrote: On Fri, 03 Sep 2010 14:15:23 -0400 (EDT), Thomas H. George wrote: On Fri, Sep 03, 2010 at 12:24:08PM -0400, Stephen Powell wrote: On Fri, 03 Sep 2010 12:06:29 -0400 (EDT), Thomas H. George wrote: After latest upgrade installation of lilo fails. I am not using raid and have the entry boot=/dev/hda in lilo.conf as specified in the man page. The installation fails with error code 01 which according to the lilo man page means invalid disk command. Does it now want a UUID? If so, where do I find the correct UUID. Values for the partitions are listed in /etc/fstab but not for the MBR. I have checked several posibilities in /proc without success. In particular in /proc/bus there are now only three subdirectories, Input, pci and usb. Since this a new problem I checked the archives for August and September but found nothing about lilo. Your post is lacking important information to diagnose the problem. For example, (1) Are you running Lenny or Squeeze? (or something else) Squeeze (2) What architecture? (i386 or amd64) amd64 (3) What kernel are you running? Is it stock or custom? If it is custom, exactly how did you build it? Stock kernel 2.6.32-5-amd64 (4) What additional backup kernels (if any) do you have installed? /boot/vmlinuz-2.6.24-1-amd64.sav /boot/vmlinuz-2.6.26-1-amd64 /boot/vmlinuz-2.6.26-2-amd64 /boot/vmlinuz-2.6.30-1-amd64 /boot/vmlinuz-2.6.30-2-amd64 /boot/vmlinuz-2.6.32-3-amd64 /boot/vmlinuz-2.6.32-5-amd64 (5) What files, if any, are present in the following directories: /etc/kernel/postinst.d initramfs-tools pm-utils zz-lilo zz-update-grub /etc/kernel/postrm.d initramfs-tools zz-lilo zz-update-grub /etc/initramfs/post-update.d lilo (6) I'd like to see the contents of the following files: /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = no /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 # /dev/sdb1 / ext3errors=remount-ro 0 1 UUID=bfcd3316-153a-4279-ab86-286906857b98 / ext3 errors=remount-ro 0 1 # /dev/sdb5 noneswapsw 0 0 UUID=4b1523d0-bec9-4565-b085-0a151469b8db noneswapsw 0 0 # formerly named /dev/sda1 is now: UUID=507caf8f-f9cd-4ed2-91cc-3e46ae942e9d /bkups ext3 rw,user,noauto 0 2 # /dev/sda5 /ubuntu ext3defaults0 2 UUID=28a4eb99-6213-4b82-96a2-42b45097e256 /ubuntu ext3 defaults0 2 # /dev/sda6 /data ext3defaults0 2 UUID=36cb29b0-2694-4dee-9ae4-10351963b979 /data ext3 defaults0 2 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 # /dev/hda1 /temp ext2rw,user,auto0 2 UUID=4a2915d8-60cf-498e-a15c-f0bc6ebdb25e /temp ext2 rw,user,auto0 2 # /dev/hda5 /storageext2defaults0 2 UUID=408287f4-8b15-42d1-b6d3-bfeaefde3002 /storageext2 defaults0 2 # /etc/fstab: static file system information. # # file system mount point type options dump pass /dev/cdrom /cdrom iso9660 ro,user,noauto 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/scd0 /media/cddata autoro,user,noauto 0 0 /dev/scd1 /media/cdrom1 udf,iso9660 user,noauto 0 0 /dev/sdc1 /usbkey autorw,user,noauto 0 0 /dev/sdc5 /media/bkup ext3rw,user,noauto 0 0 /dev/sdc/media/fuze vfatrw,user,noauto 0 0 /dev/sr0/media/cdrw iso9660 rw,user,noauto 0 0 /dev/sr1/dvdrw iso9660 rw,user,noauto 0 0 /dev/sg0/sony iso9660 rw,user,noauto 0 0 /dev/sg1/usbdrive vfatrw,user,noauto 0 0 /dev/sdd1 /usbmem vfatrw,user,noauto 0 0 /etc/initramfs-tools/conf.d/resume # RESUME=/dev/sdb5 RESUME='UUID=4b1523d0-bec9-4565-b085-0a151469b8db' /etc/initramfs-tools/conf.d/driver-policy No such file /etc/lilo.conf # Automatically added by lilo postinst script large-memory # /etc/lilo.conf - See: `lilo(8)' and
Re: Lilo and Squeeze
Hello, At fist: I don't read list 'debian-user'. I am the new developer of lilo. See: http://alioth.debian.org/projects/lilo/ and: http://lilo.alioth.debian.org/ There has been a lot of talk about lilo and squeeze on the list lately, but I don't really want to get into that argument. I have been using lilo for a dozen years, since I started using linux. I am comfortable with lilo.conf. I have never bothered to figure out grub's menu.lst and I certainly don't understand grub2's grub.cfg. I installed Eeebuntu on my eeepc when I got it. It was using grub. I have since installed Squeeze, since I am happier with pure Debian. That install uses grub2. I would like to continue using lilo. This is the same for me. Now, lilo is still avaiilable in Squeeze, so I installed it and ran liloconfig. This resulted in an error saying that the root device might be a raid, or some other configuration that liloconfig could not handle, I see: liloconfig is to old for Squeeze. Thanks for this hint. This script needs some work. and that I should write my own lilo,conf. OK. I can do that. Having done so, however, and then running lilo, I get the following error: # lilo Warning: LBA32 addressing assumed Fatal: raid_setup: stat(UUID=5019cd9d-5d2e-4d7c-a6f4-0eccb5144c77) At first: set 'lba32' at the beginning of the lilo.conf. configuration. My lilo.conf is as follows: Please set this lines as following: use old device names, i. e. (note: inside lilo works interally with VolumeID's) boot=/dev/sda # or similar device : for each image another UUID, i. e. # partition /dev/sda1 root=UUID=5019cd9d-5d2e-4d7c-a6f4-0eccb5144c77 To list all UUID's use the tool 'blkid' from the package e2fsprogs (Lenny) or package util-linux (Squeeze). Can anyone tell me what is causing this? I have never had problems with lilo, before. It always 'just works'. I hope this infos can help you. Note: These config hints where tested with lilo version 22.8-8.1 (Squeeze) Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: Lilo and Squeeze
On Mon, 21 Jun 2010 15:56:01 -0400 (EDT), Joachim Wiedorn wrote:
At fist: I don't read list 'debian-user'. I am the new developer of lilo.
See: http://alioth.debian.org/projects/lilo/
and: http://lilo.alioth.debian.org/
Marc Shapiro wrote:
There has been a lot of talk about lilo and squeeze on the list lately,
but I don't really want to get into that argument. I have been using lilo
for a dozen years, since I started using linux. I am comfortable with
lilo.conf. I have never bothered to figure out grub's menu.lst and I
certainly don't understand grub2's grub.cfg.
I installed Eeebuntu on my eeepc when I got it. It was using grub. I
have since installed Squeeze, since I am happier with pure Debian. That
install uses grub2. I would like to continue using lilo.
This is the same for me.
Now, lilo is still avaiilable in Squeeze, so I installed it and ran
liloconfig. This resulted in an error saying that the root device might
be a raid, or some other configuration that liloconfig could not handle,
I see: liloconfig is to old for Squeeze. Thanks for this hint.
This script needs some work.
and that I should write my own lilo,conf. OK. I can do that. Having
done so, however, and then running lilo, I get the following error:
# lilo
Warning: LBA32 addressing assumed
Fatal: raid_setup: stat(UUID=5019cd9d-5d2e-4d7c-a6f4-0eccb5144c77)
At first: set 'lba32' at the beginning of the lilo.conf.
configuration. My lilo.conf is as follows:
Please set this lines as following:
use old device names, i. e.
(note: inside lilo works interally with VolumeID's)
boot=/dev/sda # or similar device
:
for each image another UUID, i. e.
# partition /dev/sda1
root=UUID=5019cd9d-5d2e-4d7c-a6f4-0eccb5144c77
So, you're saying that UUIDs are supported for root, but not for boot.
That means that you can boot either kernel (2.6.32-3 or 2.6.32-5),
but running lilo's map installer will fail if you use
boot=/dev/sda on the 2.6.32-3 kernel and it will fail if you
use boot=/dev/hda on the 2.6.32-5 kernel, right?
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1934770690.166180.1277152995730.javamail.r...@md01.wow.synacor.com
Re: Lilo and Squeeze
On Thu, 17 Jun 2010 19:04:51 -0400 (EDT), Marc Shapiro wrote: My lilo.conf is as follows: # /etc/lilo.conf boot=UUID=5019cd9d-5d2e-4d7c-a6f4-0eccb5144c77 ... Can anyone tell me what is causing this? I have never had problems with lilo, before. It always 'just works'. Marc, lilo does not support the specification of the boot device using UUIDs. The traditional /dev nomenclature must be used. For example, boot=/dev/sda The same goes for the root specification. This can be a problem if you want to boot back and forth between two kernels, one of which treats the devices as traditional IDE (/dev/hda) and the other of which treats the devices as SCSI emulation (/dev/sda). Let me warn you that the kernel maintainer scripts don't work with lilo as well as they used to. For example, simply specifying do_bootloader = yes used to cause lilo to be run in the event of a new kernel install or a kernel upgrade. That is no longer the case. I recommend that you visit the following web site: http://www.wowway.com/~zlinuxman/Kernel.htm. Scroll down to Step 10: customize the kernel installation process, and read the stuff there. This web site is primarily for people who want to build their own custom kernels, but much of the information in step 10 is also applicable to people who only run stock kernels. In particular, there is a section under Customizing the Lenny Environment that specifically explains how to convert from grub-pc to lilo. Yes, I know you are running Squeeze, not Lenny; but those instructions will work with Squeeze too, provided you use only stock kernels. If you want to roll your own kernel, you really should read the whole document. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1495487309.88581.1276823273612.javamail.r...@md01.wow.synacor.com
Re: Lilo and Squeeze
On Thu, 17 Jun 2010 21:07:53 -0400 (EDT), Stephen Powell wrote: In particular, there is a section under Customizing the Lenny Environment that specifically explains how to convert from grub-pc to lilo. Oops! That should read convert from grub (version 1) to lilo. You'll have to adapt the procedure slightly to convert from grub-pc to lilo. For example, you'll have to purge different package names. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/610552041.89084.1276824544619.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Wed, 02 Jun 2010 10:23:54 -0400 (EDT), John Hasler wrote: Tom H writes: I meant to say the Lenny repos (although I am curious to see whether [Lilo] will really disappear from the Squeeze repos once Squeeze is released). If it has an RC bug at the time of the release it will be removed. As of right now, lilo has no release-critical bugs. Bug number 505609 is marked as *affecting* lilo, and it is marked as release-critical, but it is actually assigned to linux-2.6. And I have now conclusively proved that this is a bug in the kernel maintainer scripts. (See my recent posts to the bug log.) The thing that amazes me is that this bug has been open since November 13, 2008. It doesn't look like anyone even tried to diagnose the problem. I was able to diagnose the problem simply by reading the symptoms in the bug report. And I was able to fix it by simply comparing the two maintainer scripts side by side. And I don't even know perl! The idea that modern kernels are too big for lilo to load is a myth: a myth whose origins are apparently tied to this bug report. I am currently running a machine that is using a recent stock Debian kernel, 2.6.32-3-686, using lilo, *without* the large-memory option, and it loads and runs just fine! (In fairness, I must also add that I use MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. I see no reason to put stuff in my initial RAM file system that I don't need.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1181465194.292533.1275667466658.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 01 Jun 2010 11:12:06 -0400 (EDT), thib wrote: Stephen Powell wrote: I am still hopeful that lilo will not be dropped from the distribution. I think it would be a mistake, and I believe lilo has many more years of useful life than most people think it does (or should have) at this point. But if they drop it, I'm prepared. I have already downloaded the source code, and I will build my own packages if I have to. For now at least, I *have* to use lilo for reasons previously discussed. Nice report, btw. Report? What report? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2123216912.292752.1275667954132.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Stephen Powell wrote: Report? What report? That was actually meant to be a quick off-list note about your post in 505609 which I thought deserved at least two nice words. ;-) -t -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c099f66.3000...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
On Fri, 04 Jun 2010 20:50:46 -0400 (EDT), thib wrote: Stephen Powell wrote: Report? What report? That was actually meant to be a quick off-list note about your post in 505609 which I thought deserved at least two nice words. ;-) Oh, thanks. And sorry. I figured you must have accidentally replied off list, but I didn't know to what you were referring. It does feel good to solve a mystery, but it may be too little too late unless someone steps forward and volunteers to become the upstream maintainer. I'm *willing* to become the upstream maintainer, but I'm just not qualified. I have to face facts. And by the time I am qualified, it will probably be too late. I sure wish I knew what happened to John Coffman. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/352731245.305743.1275700557080.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Wed, 02 Jun 2010 12:02:15 -0400 (EDT), Jon Dowland wrote: Just how often is a total restore-from-backup required, I wonder? A total restore from backup could be for one of two purposes: (1) To restore a machine in case of a hard drive failure. Replace the bad drive with a good drive and restore. (2) To clone a new machine similar to an existing machine, changing a few things after restore, such as IP address, MAC address, hostname, etc. Fortunately, its use for the first purpose is rare. It's use for the second purpose is more common. It's faster than a new install. This is done routinely for a Windows desktop machine. It's the quickest way to get rid of a virus/worm/Trojan, etc., provided the backup is not contaminated also. And it is done for new employess to give them a standard image. It's done less often for a back-end Linux server. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/652461449.281245.1275621488000.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Stephen Powell wrote: Actually, that is largely a myth. Lilo's only release-critical bug turned out not to be a bug at all. It was this bug that gave rise to the belief that stock kernels were getting too big for lilo to load. But the problem was that a new kernel was installed without lilo being run. And this is apparently the result of changes made to the stock kernel maintainer scripts that cause do_bootloader = yes in /etc/kernel-img.conf to not be honored anymore, as it once was. Whether this is a bug or a feature in the kernel maintainer scripts I am not sure. But I am sure that this is not a lilo bug. Too bad it already made the news[1]. 1: http://lists.debian.org/debian-news/2010/msg6.html -t -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c064424.1060...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
On Tue, Jun 1, 2010 at 5:32 AM, Stan Hoeppner s...@hardwarefreak.com wrote: Tom H put forth on 5/31/2010 1:04 AM: I have gone through various big changes in OSs, WinNT to Win2k, OS9 to OSX (although I was a Sol-Lin admin too so it wasn't as great a shock as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and they created more dislocation than a bootloader change. At the risk of sounding like a late-night infomercial (!), a smooth transition from lilo to grub2 is just a question of being positive (the un-unwanted and un-unneeded of above) - and putting in some work (the learning curve of above) of course. From a seasoned sysadmin perspective, a vendor forced change away from something as critical as a bootloader, causes immediate push back. In LILO's current state, and given the way I run kernels, I could likely used LILO 22.8 for the next 10 years without a problem, without any code changes. So it doesn't matter to me if it's currently maintained or not. The reason grub2 is being forced upon us all is the need of the desktop users who want a 20MB kitchen sink kernel and initrd that will support any piece of hardware on any machine they throw at it. Many sysadmins don't want or need that, and we're being forced to change our bootloader due to the perceived needs of others. LILO isn't broken and it works well enough for may folks such as myself. We should have the option of keeping it, as an installable package, until _we_ feel we need to change to something else. It's as much a philosophical issue as it is a practical one. There is no legitimate reason LILO can't be left in the distro as an optional package, just as it is now with Lenny. It's difficult to be positive when unnecessary change is being forced down one's throat. Don't you think that lilo will be left in the repos but not available at install time? You could then install lilo post-OS-install or through pre-seeding. Thanks for the tips below. I'll be hanging onto them until/if they're needed. grub2 basics-- You're welcome. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilnprnvodjzhoklujnoyji10zvdjsy-igxp7...@mail.gmail.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, Jun 1, 2010 at 3:44 PM, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: On Mon, May 31, 2010 at 01:29:15AM +0300, Andrei Popescu wrote: Having /boot on a separate partition for robustness, security or advanced features (encrypted LVM and stuff) is one thing, but having it because the default bootloader doesn't support current (ext4) and future (btrfs) filesystems seems like a hack to me. But I don’t think that everyone will switch to ext4 with the next release, even if they install new systems. Does the squeeze installer support ext4 or is this the new filesystem if you don’t choose one? Besides we are not talking about having grub1 for all eternity. If grub2 will support all features of grub1, we can replace the bootloader in squeeze + 1. software (Stephen's case), but we have to face it: * LILO is not developed anymore * Grub1 is not developed anymore Yes, but for now both bootloader are still working. They may not support ext4, but they do support things grub2 doesn’t. Unless there are people interested in further developing those code bases they will be gone sooner or later. And my feeling (as a Yes, but in the time for squeeze + 1, grub2 may get all missing features from grub1. Then we can at least through away grub1. I've installed Squeeze a few times (from the bcard and netinst isos); ext4 is available but there is no default. Maybe the larger isos default to ext4 like Ubuntu and Fedora. Anyway, if Debian wanted to have grub1 support ext4, it would simply have to apply whatever patch Fedora has... I can't think of a grub1 feature that grub2 doesn't have except the howmany variable - and it doesn't look like it will be re-introduced. On grub-devel, the idea was trashed (and, to a certain extent, misunderstood). And in the Debian bug pages, the answer was we don't want to deviate from upstream even though the grub1 howmany variable was a Debian enhancement. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin4i3ugecv3c-qly36qiz_ad4rqltkt92c3m...@mail.gmail.com
Re: lilo removal in squeeze (or, please test grub2)
On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote: Don't you think that lilo will be left in the repos but not available at install time? You could then install lilo post-OS-install or through pre-seeding. Not without an active upstream maintainer. That's the critical need now. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/268887301.224480.1275485450171.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Wed, Jun 2, 2010 at 9:30 AM, Stephen Powell zlinux...@wowway.com wrote: On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote: Don't you think that lilo will be left in the repos but not available at install time? You could then install lilo post-OS-install or through pre-seeding. Not without an active upstream maintainer. That's the critical need now. I meant to say the Lenny repos (although I am curious to see whether it will really disappear from the Squeeze repos once Squeeze is released). The difference between Lenny and Squeeze is: lilo (1:22.8-8.1) unstable; urgency=low * Non-maintainer upload. * Fix pending l10n issues. Debconf translations: - Czech (Miroslav Kure). Closes: #505912 - Vietnamese (Clytie Siddall). Closes: #513343 - Spanish (Francisco Javier Cuadrado). Closes: #523466 - Italian (Luca Monducci). Closes: #544597 - Basque (Iñaki Larrañaga Murgoitio). Closes: #545514 - Finnish (Esko Arajärvi). Closes: #545511 - Dutch (Vincent Zweije). Closes: #546509 -- Christian Perrier bubu...@debian.org Mon, 14 Sep 2009 19:54:16 +0200 lilo (1:22.8-8) unstable; urgency=low * Fix some more bashisms. (Closes: #535399) * debian/lilo.postinst: Add -H flag to only install to active MD arrays. (Closes: #507366) -- William Pitcock neno...@dereferenced.org Sat, 01 Aug 2009 15:54:10 -0500 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimwv73h5sox8inpoobw8te-6x9joqdjt0nul...@mail.gmail.com
Re: lilo removal in squeeze (or, please test grub2)
On Wed, 02 Jun 2010 09:55:58 -0400 (EDT), Tom H wrote: On Wed, Jun 2, 2010 at 9:30 AM, Stephen Powell zlinux...@wowway.com wrote: On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote: Don't you think that lilo will be left in the repos but not available at install time? You could then install lilo post-OS-install or through pre-seeding. Not without an active upstream maintainer. That's the critical need now. I meant to say the Lenny repos (although I am curious to see whether it will really disappear from the Squeeze repos once Squeeze is released). If they pull it, they will probably pull it *before* squeeze becomes the current stable release. Once a release becomes the stable release, it's almost impossible to pull a package from it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1507702440.225881.1275487539953.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Tom H writes: I meant to say the Lenny repos (although I am curious to see whether [Lilo] will really disappear from the Squeeze repos once Squeeze is released). If it has an RC bug at the time of the release it will be removed. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ohlcy2t@thumper.dhh.gt.org
Re: lilo removal in squeeze (or, please test grub2)
On 30/05/2010 14:04, thib wrote: Like any dist upgrade, squeeze will have release notes with upgrade instructions and I'm quite confident everything concerning lilo will be covered. There are probably many upgrade test patterns they'll have to try, that's true, but I would hope the transition goes smoothly for most systems. All the smoother with sufficient testing (which is what William was requesting with the OP) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c068101.5010...@debian.org
Re: lilo removal in squeeze (or, please test grub2)
On 01/06/2010 10:32, Stan Hoeppner wrote: The reason grub2 is being forced upon us all is the need of the desktop users who want a 20MB kitchen sink kernel and initrd that will support any piece of hardware on any machine they throw at it. Many sysadmins don't want or need that, and we're being forced to change our bootloader due to the perceived needs of others. LILO isn't broken and it works well enough for may folks such as myself. We should have the option of keeping it, as an installable package, until _we_ feel we need to change to something else. It's as much a philosophical issue as it is a practical one. There is no legitimate reason LILO can't be left in the distro as an optional package, just as it is now with Lenny. A perfectly legitimate reason is that there is one willing to maintain it. Lots of hot air on -user, but nobody prepared to do the work. IMHO the kernel size issue is just the straw that broke the camel's back. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0681df.6040...@debian.org
Re: lilo removal in squeeze (or, please test grub2)
On 24/05/2010 23:44, Stan Hoeppner wrote: So it would appear boot loaders in general have a lack of interested/committed developers? Both LILO and GRUB. sarcasm So instead of just LILO, why didn't the Debian team just throw both bootloaders out the window and start over with committed devs? /sarcasm There would indeed appear to be a manpower problem for grub2 and lilo *within* Debian, but the key issue here is that there is also a manpower problem for lilo *outside* Debian, too. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0682af.9030...@debian.org
Re: lilo removal in squeeze (or, please test grub2)
On 28/05/2010 17:39, Roger Leigh wrote: One obvious solution not already mentioned is to back up the bootloader *in Linux* as a normal file, so the backup software can then just back it up like any other file. It's a simple enough workaround to the deficiencies in your backup software. dd if=dev/hda of=/boot/bootsector-backup bs=512 count=nnn Stick it in as a daily cron job and you're done. When it comes to restoring, you can just dd it back and you're in business. I don't think this is necessary. It doesn't solve Stephen's problem (a machine restored from backup is not immediately bootable), and if you boot the machine via some other method, you can just as easily run update-grub (or whatever it's called) to re-create the boot. The solution is to have an external boot system to hand. A set of suitably configured USB keys would do it. They could even boot into a special init environment that just ran update-grub so that the macine was immediately recovered. Just how often is a total restore-from-backup required, I wonder? -- Jon Dowland
Re: lilo removal in squeeze (or, please test grub2)
On Wed, Jun 2, 2010 at 10:05 AM, Stephen Powell zlinux...@wowway.com wrote: On Wed, 02 Jun 2010 09:55:58 -0400 (EDT), Tom H wrote: On Wed, Jun 2, 2010 at 9:30 AM, Stephen Powell zlinux...@wowway.com wrote: On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote: Don't you think that lilo will be left in the repos but not available at install time? You could then install lilo post-OS-install or through pre-seeding. Not without an active upstream maintainer. That's the critical need now. I meant to say the Lenny repos (although I am curious to see whether it will really disappear from the Squeeze repos once Squeeze is released). If they pull it, they will probably pull it *before* squeeze becomes the current stable release. Once a release becomes the stable release, it's almost impossible to pull a package from it. I know. I chose the release as a check-point because I don't know at what previous milestone such a move would take place. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinipihiivoosafdkzoighwxemc_ppdhyztuv...@mail.gmail.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 01 Jun 2010 12:14:42 -0400 (EDT), John Hasler wrote: Stephen Powell writes: Actually, I've been tempted to volunteer to become the upstream maintainer for lilo myself. Please do so. However, although the SAPL is written in assembly language, it is written in s390 assembly language, which is totally different from x86 assembly language. I don't know x86 assembly language at all. Set up a Web site (I suggest tuxfamily.org for hosting) and ask for help. You'll find that there are people who can and will do the coding but who don't want the hassle and responsibility of running the project. I don't know. I would at least want to be able to review the work of my assistants and have some hope of being able to tell if it makes sense. I appreciate the encouragement, but I'm just not qualified for something like this yet. If lilo is worth saving, surely someone who *is* qualified will step up to the plate. I sure wish I knew what in the world happened to John Coffman though. He was doing a great job. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/770226811.246509.1275528114439.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Tom H put forth on 5/31/2010 1:04 AM: On Sat, May 29, 2010 at 11:46 PM, Stan Hoeppner s...@hardwarefreak.com wrote: Tom H put forth on 5/28/2010 10:55 PM: On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner s...@hardwarefreak.com wrote: Roger Leigh put forth on 5/28/2010 11:39 AM: For the most part, grub is a vast improvement over LILO, and except for the odd corner cases which grub doesn't cover, In what way is it a vast improvement over LILO? I've never had a problem with LILO. It's always just worked, which is what a bootloader should do. So how exactly would grub be a better choice for me? The reverse argument can be made too. Both grub1 and grub2 just work. Unless you are continually installing dual- and triple-boot this or that, you are not going to be changing you config continually no matter what bootloader you use and you will therefore not be interacting with it that much. So, except for Stephen P's case, what's the big deal? I frequently roll new kernels from kernel.org source using the Debian installation method, once every couple of months. I'm very comfortable with using LILO for this. I've pretty much zero experience with Grub (any version). If something goes wrong converting from LILO to Grub2, I'm screwed. And I'll probably have an unwanted and unneeded learning curve while continuing my current practice of rolling kernels frequently. Please don't debate the merits of customs kernels. I have very valid reasons for doing so. Let's focus on why or why not Grub2 will work for my needs, and not hose my systems either during the migration from LILO to Grub2, or installing custom kernels after the fact. I have absolutely no problem with custom kernels. (What I don't understand is people who jump up and down on various lists when someone says that he/she compiles custom kernels!) The reasons are very unflattering to the folks you point out, so I won't go into detail and start a fire. I haven't used lilo for nine-ten years but I don't see how adding a custom kernel to grub rather than lilo should affect your kernel compilation. I don't use the Debian tools so after make install, I run update-initramfs ... and update-grub, and I'm done. I don't see how, if I were using lilo, I would have to follow a different procedure, except for setting editing lilo.conf and running lilo after update-initramfs. Am I missing something? The part about that fact that I've never used grub, any of its variants. It may not present problems when installing my kernels. I don't know. That's why I brought it up, hoping folks would share their experience. As I said in my previous post, I would install Squeeze's grub2 on a Lenny box and reboot to check that it is working before the upgrade to Squeeze. Yep. I have gone through various big changes in OSs, WinNT to Win2k, OS9 to OSX (although I was a Sol-Lin admin too so it wasn't as great a shock as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and they created more dislocation than a bootloader change. At the risk of sounding like a late-night infomercial (!), a smooth transition from lilo to grub2 is just a question of being positive (the un-unwanted and un-unneeded of above) - and putting in some work (the learning curve of above) of course. From a seasoned sysadmin perspective, a vendor forced change away from something as critical as a bootloader, causes immediate push back. In LILO's current state, and given the way I run kernels, I could likely used LILO 22.8 for the next 10 years without a problem, without any code changes. So it doesn't matter to me if it's currently maintained or not. The reason grub2 is being forced upon us all is the need of the desktop users who want a 20MB kitchen sink kernel and initrd that will support any piece of hardware on any machine they throw at it. Many sysadmins don't want or need that, and we're being forced to change our bootloader due to the perceived needs of others. LILO isn't broken and it works well enough for may folks such as myself. We should have the option of keeping it, as an installable package, until _we_ feel we need to change to something else. It's as much a philosophical issue as it is a practical one. There is no legitimate reason LILO can't be left in the distro as an optional package, just as it is now with Lenny. It's difficult to be positive when unnecessary change is being forced down one's throat. grub2 basics-- Thanks for the tips below. I'll be hanging onto them until/if they're needed. -- Stan Setup Although grub2 sources a file in /usr/lib/grub when creating its config, the files that matter are /etc/default/grub and /etc/grub.d/*. You set various variables like the kernel options, the default entry, whether to create entries with single appended, ... in /etc/default/grub. When you run update-grub (which is a script that runs grub-mkconfig -o /boot/grub/grub.cfg), the grub2 menu's configuration,
Re: lilo removal in squeeze (or, please test grub2)
Stephen Powell put forth on 5/31/2010 8:57 PM: On Sun, 30 May 2010 03:48:50 -0400 (EDT), Andrei Popescu wrote: On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote: My gut instinct is that due to the above reasons and possibly others, the next dist upgrade is going to hose all my production servers whilst trying to forcibly convert them to Grub2. Is my instinct correct? Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the upgrade ;) Does anybody know what happened to John Coffman (the last known upstream maintainer for lilo)? Did he get bored with maintaining lilo? He was doing a great job. I think he's the one that added lba32 support. He seems to have fallen off the face of the earth. Did he die or what? That's a good question. I was just digging around (not very thoroughly) a few minutes ago and I can't find any recent posts from him via Google. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c04d533.8060...@hardwarefreak.com
Re: lilo removal in squeeze (or, please test grub2)
Stan Hoeppner wrote: LILO isn't broken and it works well enough for may folks such as myself. We should have the option of keeping it, as an installable package, until _we_ feel we need to change to something else. It's as much a philosophical issue as it is a practical one. There is no legitimate reason LILO can't be left in the distro as an optional package, just as it is now with Lenny. It's difficult to be positive when unnecessary change is being forced down one's throat. In the worst case, people will maintain unofficial packages in unofficial repositories. In fact, I'm not even sure there's still much to maintain with the package.. just keep it around. It's very true, official support is best, but I wouldn't go as far as saying the change is forced. This is all still open and hackable software, in the end, and hack here means pinning lilo and grub-pc, which should be it. It will still be manageable by apt. -t -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c051719.7080...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 01 Jun 2010 05:32:37 -0400 (EDT), Stan Hoeppner wrote: From a seasoned sysadmin perspective, a vendor forced change away from something as critical as a bootloader, causes immediate push back. In LILO's current state, and given the way I run kernels, I could likely used LILO 22.8 for the next 10 years without a problem, without any code changes. So it doesn't matter to me if it's currently maintained or not. Actually, I've been tempted to volunteer to become the upstream maintainer for lilo myself. I have worked on boot loaders before, on other platforms. For example, I have made local modifications to the Stand Alone Program Loader that ships with IBM's z/VM Operating System. The SAPL is used as the boot loader for the CP (Control Program) component of z/VM, as well as other stand-alone programs such as DDR (DASD Dump / Restore) and DSF (Device Support Facilities). I won't go into the details of what those local modifications are because they are not relevant here. The point is that I've worked on boot loaders before, and I like working on low-level stuff. However, although the SAPL is written in assembly language, it is written in s390 assembly language, which is totally different from x86 assembly language. I don't know x86 assembly language at all. And I am just learning C. So reason prevails over emotion and I don't volunteer. I am simply not qualified. Someday I may be, but not today. The reason grub2 is being forced upon us all is the need of the desktop users who want a 20MB kitchen sink kernel and initrd that will support any piece of hardware on any machine they throw at it. Many sysadmins don't want or need that, and we're being forced to change our bootloader due to the perceived needs of others. Actually, that is largely a myth. Lilo's only release-critical bug turned out not to be a bug at all. It was this bug that gave rise to the belief that stock kernels were getting too big for lilo to load. But the problem was that a new kernel was installed without lilo being run. And this is apparently the result of changes made to the stock kernel maintainer scripts that cause do_bootloader = yes in /etc/kernel-img.conf to not be honored anymore, as it once was. Whether this is a bug or a feature in the kernel maintainer scripts I am not sure. But I am sure that this is not a lilo bug. To the best of my knowledge, even the largest of today's kitchen sink kernel and initial RAM disk image combinations can be loaded by lilo with no trouble at all if the large-memory option is used and the BIOS support memory addressing above 16M, which is the case for almost all modern BIOS. (The 16M limit is apparently a hold-over from the days of the 80286 chip.) And if for some reason the BIOS do not support the large-memory option, simply using MODULES=dep instead of MODULES=most in your initial RAM file system is usually sufficient to allow lilo to work, even with these large kernels. (As a side note, it seems to me that the equivalent of the large-memory option should be possible even if the BIOS do not support it by asking the BIOS to read a block into storage below the 16M line and then copying the block above the 16M line under program control. Conceptually at least, it seems to me that that shouldn't be too hard. But I don't know.) LILO isn't broken and it works well enough for may folks such as myself. We should have the option of keeping it, as an installable package, until _we_ feel we need to change to something else. It's as much a philosophical issue as it is a practical one. There is no legitimate reason LILO can't be left in the distro as an optional package, just as it is now with Lenny. It's difficult to be positive when unnecessary change is being forced down one's throat. I agree. But I also sympathize with the poor package maintainer who is essentially functioning as both package maintainer and upstream support. That cannot go on forever. Someone has to step up to the plate and take over upstream support. I'd do it myself if I had the requisite skills. But as of now, I just don't. Perhaps one of the reasons that no-one has stepped up to the plate to take over upstream support is the perception that lilo can't handle today's large kernels and therefore we should just let it die. That is simply not true. I use stock kernels most of the time. And I use lilo. And I've never had a bit of trouble. I just have to make sure by the use of hook scripts that lilo actually gets run when a kernel is installed or updated. And that's easy enough to do. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/112473223.193825.1275402342029.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 01 Jun 2010 10:20:09 -0400 (EDT), thib wrote: In the worst case, people will maintain unofficial packages in unofficial repositories. In fact, I'm not even sure there's still much to maintain with the package.. just keep it around. It's very true, official support is best, but I wouldn't go as far as saying the change is forced. This is all still open and hackable software, in the end, and hack here means pinning lilo and grub-pc, which should be it. It will still be manageable by apt. I am still hopeful that lilo will not be dropped from the distribution. I think it would be a mistake, and I believe lilo has many more years of useful life than most people think it does (or should have) at this point. But if they drop it, I'm prepared. I have already downloaded the source code, and I will build my own packages if I have to. For now at least, I *have* to use lilo for reasons previously discussed. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1600857906.194739.1275403757931.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Stan Hoeppner wrote: The problem, in and of itself, is booting. Period. There is [no] way to test it but to replace LILO with Grub2 and see if the system boots afterward. I cannot do this on production servers, obviously. Cloning drives to play with on a lab machine would be a good idea, but I can't take production servers offline to clone the disks. How about temporarily booting from an alternate partition, disk, etc? For example: 1. Install a second instance of your current LILO installation on some other boot device. - Then boot from that device to make sure that booting from that device can boot your system normally. If not, boot from your normal boot partition, try to fix that second LILO installation, and try again. Once it works, proceed to step 2. 2. Install Grub2 on the main boot device. - Try booting. - If doesn't work, reboot from the device with the backup LILO installation in step one and try to fix the Grub2 installation, and try again. Once it works, you're done. Actually, you'd probably want to install the new loader (Grub2) on an alternative device first, so your system by default would still boot using the old boot loader setup. Then, when you think you have your Grub2 configuration worked out, create and test the LILO backup boot device as above, and install Grub2 on your main boot device. If it works, you're done; if it doesn't, you can reboot from the LILO backup boot device to work on your main-device Grub2 installation. That takes several reboots rather than just one, but then it means you're never more than one reboot away from a working system, rather than possibly dead in the water until you can figure out and fix whatever the problem is (either by fixing the Grub2 problem or by booting enough (viaa rescue disc) to re-install your LILO configuration. Daniel -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c051c29.60...@fgm.com
Re: lilo removal in squeeze (or, please test grub2)
Stephen Powell writes: Actually, I've been tempted to volunteer to become the upstream maintainer for lilo myself. Please do so. However, although the SAPL is written in assembly language, it is written in s390 assembly language, which is totally different from x86 assembly language. I don't know x86 assembly language at all. Set up a Web site (I suggest tuxfamily.org for hosting) and ask for help. You'll find that there are people who can and will do the coding but who don't want the hassle and responsibility of running the project. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxved91p@thumper.dhh.gt.org
Re: lilo removal in squeeze (or, please test grub2)
On Ma, 01 iun 10, 10:25:42, Stephen Powell wrote: Actually, I've been tempted to volunteer to become the upstream maintainer for lilo myself. I have worked on boot loaders before, on other platforms. [...] I agree. But I also sympathize with the poor package maintainer who is essentially functioning as both package maintainer and upstream support. That cannot go on forever. Someone has to step up to the plate and take over upstream support. I'd do it myself if I had the requisite skills. But as of now, I just don't. Perhaps one of the reasons that no-one has stepped up to the plate to take over upstream support is the perception that lilo can't handle today's large kernels and therefore we should just let it die. That is simply not true. I use stock kernels most of the time. And I use lilo. And I've never had a bit of trouble. I just have to make sure by the use of hook scripts that lilo actually gets run when a kernel is installed or updated. And that's easy enough to do. Maybe it would be enough if you just take over the maintenance of the Debian package. After all, you are very familiar with lilo and run it on many machines. If the code is as stable as I've read in this thread it shouldn't be too difficult. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: lilo removal in squeeze (or, please test grub2)
On Mon, May 31, 2010 at 01:29:15AM +0300, Andrei Popescu wrote: Having /boot on a separate partition for robustness, security or advanced features (encrypted LVM and stuff) is one thing, but having it because the default bootloader doesn't support current (ext4) and future (btrfs) filesystems seems like a hack to me. But I don’t think that everyone will switch to ext4 with the next release, even if they install new systems. Does the squeeze installer support ext4 or is this the new filesystem if you don’t choose one? Besides we are not talking about having grub1 for all eternity. If grub2 will support all features of grub1, we can replace the bootloader in squeeze + 1. Is it just me or does this sound like the KDE3 - KDE4 debate all over again? I don’t know, I don’t use KDE. ;-) But if I have to use KDE to help another user, I feel more comfortable with KDE3. KDE4 looks terribly and I don’t find anything. software (Stephen's case), but we have to face it: * LILO is not developed anymore * Grub1 is not developed anymore Yes, but for now both bootloader are still working. They may not support ext4, but they do support things grub2 doesn’t. Unless there are people interested in further developing those code bases they will be gone sooner or later. And my feeling (as a Yes, but in the time for squeeze + 1, grub2 may get all missing features from grub1. Then we can at least through away grub1. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: lilo removal in squeeze (or, please test grub2)
On Sat, May 29, 2010 at 11:46 PM, Stan Hoeppner s...@hardwarefreak.com wrote: Tom H put forth on 5/28/2010 10:55 PM: On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner s...@hardwarefreak.com wrote: Roger Leigh put forth on 5/28/2010 11:39 AM: For the most part, grub is a vast improvement over LILO, and except for the odd corner cases which grub doesn't cover, In what way is it a vast improvement over LILO? I've never had a problem with LILO. It's always just worked, which is what a bootloader should do. So how exactly would grub be a better choice for me? The reverse argument can be made too. Both grub1 and grub2 just work. Unless you are continually installing dual- and triple-boot this or that, you are not going to be changing you config continually no matter what bootloader you use and you will therefore not be interacting with it that much. So, except for Stephen P's case, what's the big deal? I frequently roll new kernels from kernel.org source using the Debian installation method, once every couple of months. I'm very comfortable with using LILO for this. I've pretty much zero experience with Grub (any version). If something goes wrong converting from LILO to Grub2, I'm screwed. And I'll probably have an unwanted and unneeded learning curve while continuing my current practice of rolling kernels frequently. Please don't debate the merits of customs kernels. I have very valid reasons for doing so. Let's focus on why or why not Grub2 will work for my needs, and not hose my systems either during the migration from LILO to Grub2, or installing custom kernels after the fact. I have absolutely no problem with custom kernels. (What I don't understand is people who jump up and down on various lists when someone says that he/she compiles custom kernels!) I haven't used lilo for nine-ten years but I don't see how adding a custom kernel to grub rather than lilo should affect your kernel compilation. I don't use the Debian tools so after make install, I run update-initramfs ... and update-grub, and I'm done. I don't see how, if I were using lilo, I would have to follow a different procedure, except for setting editing lilo.conf and running lilo after update-initramfs. Am I missing something? As I said in my previous post, I would install Squeeze's grub2 on a Lenny box and reboot to check that it is working before the upgrade to Squeeze. I have gone through various big changes in OSs, WinNT to Win2k, OS9 to OSX (although I was a Sol-Lin admin too so it wasn't as great a shock as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and they created more dislocation than a bootloader change. At the risk of sounding like a late-night infomercial (!), a smooth transition from lilo to grub2 is just a question of being positive (the un-unwanted and un-unneeded of above) - and putting in some work (the learning curve of above) of course. grub2 basics-- Setup Although grub2 sources a file in /usr/lib/grub when creating its config, the files that matter are /etc/default/grub and /etc/grub.d/*. You set various variables like the kernel options, the default entry, whether to create entries with single appended, ... in /etc/default/grub. When you run update-grub (which is a script that runs grub-mkconfig -o /boot/grub/grub.cfg), the grub2 menu's configuration, /boot/grub/grub.cfg, is built by running the scripts in /etc/grub.d/. I don't really like what the /etc/grub.d/ scripts do, so I chmod 644 them except for the last one, 40_custom, and I write my grub.cfg there. It is a script of the form: cat EOF my grub2 config EOF so my /boot/grub/grub.cfg ends up exactly like 40_custom except for the first two lines and the last one. The disadvantage of using this method is that I have to add and remove kernels manually to 40_custom, whereas the standard way is that the 00_header, 10_linux, and 30_os-prober scripts populate the grub2 menu automagically. The initial run of update-grub, after you install grub2, will give you a good base to create 40_custom if that is the way that you want to go. Unsurprisingly, since all that a bootloader does is point to and loads an initrd and kernel, /boot/grub/grub.cfg basically looks like lilo.conf (for a reference lilo config file, I am looking at Stephen P's kernel compilation page, which, btw, is included in the documentation of kernel-package) with a different syntax. There are global options (default entry, grub root partition, console or gfxterm, timeout, ...) and per-image options where menuentry corresponds to label, linux to image, and initrd to initrd. As an added twist, grub2 is modular so both (possibly redundantly but I have never tested this) the global and per-image sections have insmod invocations for filesystems, raid, lvm, framebuffer, ... Recovery You only have to net-boot or cd-boot a grub2 install to correct it if its first stage loader in the MBR is dead. If you net-boot or cd-boot to re-write to the MBR, you have to
Re: lilo removal in squeeze (or, please test grub2)
Maybe, but ext4 support is not really crucial. Simply make /boot ext2. Actually ext3 works fine. Having /boot on a separate partition for robustness, security or advanced features (encrypted LVM and stuff) is one thing, but having it because the default bootloader doesn't support current (ext4) and future (btrfs) filesystems seems like a hack to me. Until the bootloader is itself a Linux kernel (so it can directly use Linux fs drivers), the bootloader will always be playing catch-up. I've been using a /boot partition forever, because I have / on LVM. Nowadays, I use Grub2 on several of my machines, so I could put /boot directly in LVM, but why bother? The thing that I would find more useful is to get rid of things like update-grub, and instead have the bootloader generate the bootlist on the fly. I.e.: install the bootloader, and never touch it again. Also, the config has become so complicated you need another config file (/etc/default/grub) to configure how it will be generated :( Yes, that sucks as well. * LILO is not developed anymore * Grub1 is not developed anymore I've used Lilo a few times in the past and found it very useful because of its simplicity: tell it where are the files to boot, and on which drive to install itself, and that's it. For Grub1 (and worse for Grub2), you have to worry about the difference between where the files are now vs where the files will be when I boot, then multiply that by the different sorts of files (Grub2 modules, Grub config file, kernel/initrd files) and then you have to add the fact that the grub-install scripts try to hide these differences from you. E.g. I could never use Grub1's grub-install and be confident of the result, so I always used /usr/sbin/grub to install Grub1 instead. With Grub2 this is not even an option, so I use `grub-install' and then I just hope for the best. Luckily, my setups are usually simple. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvr5ksxaf1.fsf-monnier+gmane.linux.debian.u...@gnu.org
Re: lilo removal in squeeze (or, please test grub2)
On Sun, 30 May 2010 03:48:50 -0400 (EDT), Andrei Popescu wrote: On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote: My gut instinct is that due to the above reasons and possibly others, the next dist upgrade is going to hose all my production servers whilst trying to forcibly convert them to Grub2. Is my instinct correct? Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the upgrade ;) Does anybody know what happened to John Coffman (the last known upstream maintainer for lilo)? Did he get bored with maintaining lilo? He was doing a great job. I think he's the one that added lba32 support. He seems to have fallen off the face of the earth. Did he die or what? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1734713713.184635.1275357460852.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Stephen Powell put forth on 5/29/2010 9:48 AM: thorough explanation snipped As time goes on, these restrictions are getting more restrictive. And we are looking at alternatives to our existing backup software. But for now, I have to live within these restrictions. Implement VMware ESX and VMware Consolidate Backup (or whatever their marketing calls them today). The price is high, but the capability for platform consistent PIT backup is unmatched. Of course, you need at bare minimum a small FC or iSCSI SAN, preferably FC as it's over 4 times the throughput and lower latency. You can build such a SAN with a Qlogic 8 port 4Gb FC switch, FC HBAs for 4 or so servers, a Nexsan SATABoy storage array w/2GB cache and 14x500GB drives in RAID6 for about $20k USD. At least, *I* could build and integrate this relatively low end FC SAN for that. Add about $5k for the VCB server hardware and its largish 6TB worth of initial scratch space. I assume you already have an appropriate tape library. You'd have to contact a VMware rep for current ESX and VCB pricing. If an organization can afford it, it's the only way to fly, especially VCB. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c02143f.1090...@hardwarefreak.com
Re: lilo removal in squeeze (or, please test grub2)
On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote: My gut instinct is that due to the above reasons and possibly others, the next dist upgrade is going to hose all my production servers whilst trying to forcibly convert them to Grub2. Is my instinct correct? Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the upgrade ;) Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: lilo removal in squeeze (or, please test grub2)
Stan Hoeppner wrote: My gut instinct is that due to the above reasons and possibly others, the next dist upgrade is going to hose all my production servers whilst trying to forcibly convert them to Grub2. Is my instinct correct? Like any dist upgrade, squeeze will have release notes with upgrade instructions and I'm quite confident everything concerning lilo will be covered. There are probably many upgrade test patterns they'll have to try, that's true, but I would hope the transition goes smoothly for most systems. -t -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c026266.8020...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
On 20100529_223556, Stan Hoeppner wrote: thib put forth on 5/28/2010 9:44 PM: * If yes, should it still be presented as an expert option in d-i? Why not, I guess. If not, should extlinux be extensively tested to be provided as an alternative choice in d-i? I really don't know how much work would be needed for this. I'm far more concerned at this point with distribution upgrades than new installs. I've a number of production Lenny servers all using LILO. What will happen to the bootloader config on these machines when I perform a dist upgrade after Squeeze becomes Stable? These machines all use custom rolled kernels from kernel.org source (installed the Debian way), if that makes any difference. Also, the kernel images are in /boot, not in / with the traditional symlinks. My gut instinct is that due to the above reasons and possibly others, the next dist upgrade is going to hose all my production servers whilst trying to forcibly convert them to Grub2. Is my instinct correct? Yes, but ... I don't have anything as difficult to manage as you. But I am also far less adept. Long ago I gave up on dist-upgrade as a thing I wanted to do. I think I stopped using it even before it was renamed to dist-upgrade. Instead, I devote a few GB of hard disk to multiple partitions on which I can install successively newer releases of Debian, but only the parts that change in the new release. Thanks to HFS it is easy to determine which those are. I make a new clean install in a newly formatted partion. If it doesn't work, I can reboot back into what I had been running minutes before. It took me a while to work out all the kinks, but it is well worth the trouble. As an added benefit of this way, I mount the older root partition under a special non-standard mount point in the new installation. If(When) I get into trouble, I can refer to that partition to see how things were set up before I started mucking about. I know this is a waste of disk space, but it is impossible to buy a HD so small that it cannot hold several full installations of Debian/GNU/Linux. I suggest you rearrange your disks to make room for additional base-installs. Practice doing Lenny to Lenny transitions to make sure you have your plan fully worked out. And then, wait for Squeeze with the sure knowledge that you can reboot back into your existing software. I cannot believe Grub2 will remain in its current state of disarray when release of Squeeze finally happens. The module that finds pre-existing installs and adds them to the boot menu seems to work but when you do reboot at the end of the install process, the installations that were listed as having been found are not there in the boot menu. Just issue update-grub and reboot again. It is fixed. Does this post give you warm fuzzies about the coming release? -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100530153745.ga29...@big.lan.gnu
Re: lilo removal in squeeze (or, please test grub2)
On Fri, May 28, 2010 at 11:55:58PM -0400, Tom H wrote: The reverse argument can be made too. Both grub1 and grub2 just work. I accept this argument for grub1. Yes, I never had problems with grub1, but grub2 is simply not ready for prime time. While grub2 works for simple workstations, it can’t redirect its output to serial console and monitor like grub1 and it doesn’t understand XEN hypervisor kernels. As long as grub2 has so many missing features it should not be considered default bootloader in Debian. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: lilo removal in squeeze (or, please test grub2)
On 2010-05-30 18:29 +0200, Stephan Seitz wrote: On Fri, May 28, 2010 at 11:55:58PM -0400, Tom H wrote: The reverse argument can be made too. Both grub1 and grub2 just work. I accept this argument for grub1. Yes, I never had problems with grub1, but grub2 is simply not ready for prime time. While grub2 works for simple workstations, it can’t redirect its output to serial console and monitor like grub1 and it doesn’t understand XEN hypervisor kernels. The main problem with grub1 is the same as with lilo: there is no upstream maintainer, and crucial parts of the code are undocumented and not understandable¹. As long as grub2 has so many missing features it should not be considered default bootloader in Debian. So which bootloader should be the default? Grub1 is also lacking important features, albeit different ones than grub2 (e.g. ext4 support). Sven ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#237 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eigt5n7s@turtle.gmx.de
Re: lilo removal in squeeze (or, please test grub2)
Paul E Condon put forth on 5/30/2010 10:37 AM: On 20100529_223556, Stan Hoeppner wrote: I'm far more concerned at this point with distribution upgrades than new installs. snip My gut instinct is that due to the above reasons and possibly others, the next dist upgrade is going to hose all my production servers whilst trying to forcibly convert them to Grub2. Is my instinct correct? I don't have anything as difficult to manage as you. These systems are a breeze to manage currently, not difficult at all. But I am also far less adept. Long ago I gave up on dist-upgrade as a thing I wanted to do. I think I stopped using it even before it was renamed to dist-upgrade. Instead, I devote a few GB of hard disk to multiple partitions on which I can install successively newer releases of Debian, but only the parts that change in the new release. Thanks to HFS it is easy to determine which those are. I make a new clean install in a newly formatted partion. If it doesn't work, I can reboot back into what I had been running minutes before. Herein lies the problem with changing bootloaders. Your safe recovery methodology (which is quite smart btw and I've used it myself over the years) goes out the window in this case because the bootloader controls loading every one of your parallel installations. If the bootloader gets hosed, you can't load any of them. You're fscked. I know this is a waste of disk space, but it is impossible to buy a HD so small that it cannot hold several full installations of Debian/GNU/Linux. Not a waste of space at all, but a very good use of a tiny percentage of the space available on current drives. With 500GB drives at ~$50 USD, and a typical Debian install being ~5GB, you could have 10 parallel installations using only 10% of the drive's space. That's a smart investment in potential severe headache prevention. Ten parallel installs is extreme, but I'm simply demonstrating the cost of storage aspect. I suggest you rearrange your disks to make room for additional base-installs. Practice doing Lenny to Lenny transitions to make sure you have your plan fully worked out. And then, wait for Squeeze with the sure knowledge that you can reboot back into your existing software. What you suggest here doesn't really come into play. This isn't an issue of going from Lenny to Squeeze. This isn't about different package revs. It's not about Squeeze having problems and wanting to boot back into Lenny. The problem, in and of itself, is booting. Period. There is not way to test it but to replace LILO with Grub2 and see if the system boots afterward. I cannot do this on production servers, obviously. Cloning drives to play with on a lab machine would be a good idea, but I can't take production servers offline to clone the disks. The only real way to test this is to build a fresh Lenny test rig from scratch with LILO, tweak it to match my production systems, then install Grub2 and see what, if anything, breaks, and figure out how to get around the breakage. I cannot believe Grub2 will remain in its current state of disarray when release of Squeeze finally happens. The module that finds pre-existing installs and adds them to the boot menu seems to work but when you do reboot at the end of the install process, the installations that were listed as having been found are not there in the boot menu. Just issue update-grub and reboot again. It is fixed. I hope it's ready for prime time by then. Does this post give you warm fuzzies about the coming release? I'm not worried about the release. I've taken these machines through four live online apt upgrades all the way back from Woody to Lenny, 4 releases, without major issues. However, the bootloader never changed. LILO all the way through. This upgrade will be radically different in this respect. I guess I could start looking for an aftermarket bootloader to avoid this mess altogether, although I'd rather use a FOSS solution. Maybe extlinux. From what others have said here it shows some promise. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c02c573.4070...@hardwarefreak.com
Re: lilo removal in squeeze (or, please test grub2)
On Sun, May 30, 2010 at 07:11:19PM +0200, Sven Joachim wrote: The main problem with grub1 is the same as with lilo: there is no upstream maintainer, and crucial parts of the code are undocumented and not understandable¹. But at least grub1 is working in a wider field than grub2. And lilo is still working, too. Maybe not with the current Debian kernel, but it works for people building their own kernel. So which bootloader should be the default? Grub1 is also lacking important features, albeit different ones than grub2 (e.g. ext4 support). Maybe, but ext4 support is not really crucial. Simply make /boot ext2. I would say, the default bootloader should be grub1, expert installation can offer grub2 as well. Lilo should be in the distribution as well, so people can switch after installation. At least for the next release. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
