Re: [HS] Lilo (et Grub)

[ajh-valmer]

On Friday 29 December 2023 09:33:52 Pierre Malard wrote:
> Personnellement toutes mes VM tournent sous formatage GPT et sans UEFI mais
> cela ne fait pas de différences. Effectivement il suffit d?une petite
> partition au début d?environ 1 Mo non formatée mais avec le flag
> « bios-grub ».

> Pour mettre jour le boot, voici ce que je fais alors :
> # update-grub
> # grub-install --modules=part_gpt /dev/sda :

Hélas, ça ne marche pas, toujours le message :
"Erreur, /boot/vmlinuz-5.10.0-21-amd64 non disponible,
le noyau doit d'abord être chargé". 

> Si on utilise UEFI il faut juste ajouter une partition VFAT 
> montée sur le répertoire /boot/efi :
Pas de répertoire ou fichier "efi" dans /boot.

> Coiffé au poteau :
> Périphérique Début   Fin  Secteurs Taille Type
> /dev/sdb1 2048  4095  2048 1M Amorçage BIOS
> Problème : à partir d'un disque déjà paritionné ça suppose de décaler
> le début de l'actuelle première partition d'1M ...
> Faisable avec gparted je pense :

Comment fait-on pour décaler le début de l'actuelle partition d'IM ?
gparted ne propose pas de modifier l'étiquette en msdos, c'est fdisk :
Créer une nouvelle étiquette :
g   créer une nouvelle table vide de partitions GPT
o   create a new empty MBR (DOS) partition table.

Voilà le topo.

Re: [HS] Lilo (et Grub)

[Eric DEGENETAIS]

bonjour,
Le ven. 29 déc. 2023 à 09:34, Pierre Malard
 a écrit :
>
> Le 28 déc. 2023 à 14:38, ajh-valmer  a écrit :
> >
> > Ok, j'attends avec impatience :
> > "le mécanisme d'amorçage compatible avec le mode legacy BIOS".
> > Merci d’avance.
>
> Bonjour,
>
> Personnellement toutes mes VM tournent sous formatage GPT et sans UEFI mais
> cela ne fait pas de différences. Effectivement il suffit d’une petite
> partition au début d’environ 1 Mo non formatée mais avec le flag
> « bios-grub ».
>
Coiffé au poteau :
Périphérique Début   Fin  Secteurs Taille Type
/dev/sdb1 2048  4095  2048 1M Amorçage BIOS

Problème : à partir d'un disque déjà paritionné ça suppose de décaler
le début de l'actuelle première partition d'1M ...
Faisable avec gparted je pense.
__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org

Re: [HS] Lilo (et Grub)

[Pierre Malard]

Le 28 déc. 2023 à 14:38, ajh-valmer  a écrit :
> 
>> Le jeu. 28 déc. 2023 à 12:44, ajh-valmer  a écrit :
>>> J'ai vérifié, le répertoire /boot contient bien tous les fichiers :
>>> System.map-5.10.0-21-amd64
>>> config-5.10.0-21-amd64
>>> initrd.img-5.10.0-21-amd64
>>> vmlinuz-5.10.0-21-amd64
>>> Quid ? Serait-ce le partitionnement 'hd1,gpt1' ?
>>> (pas possible d'écrire dans le mbr ?)
> 
>> Effectivement, GPT ne permet pas le mécanisme de boot classique. Je ne
>> suis pas au fait des détails techniques, mais il n'y a pas de notion
>> de master boot record.
>> Il existe par contre un mécanisme d'amorçage compatible avec le mode
>> legacy BIOS. Il me semble que ça consiste à réserver (partition
>> spéciale) un espace de l'ordre du Mb pour effectuer les écritures.
>> Malheureusement les détails m'échappent,
>> mais je tâcherai de remettre la main dessus ce soir, où j'aurai accès
>> à mon PC personnel qui amorce de cette façon.
> 
> Ok, j'attends avec impatience :
> "le mécanisme d'amorçage compatible avec le mode legacy BIOS".
> Merci d’avance.

Bonjour,

Personnellement toutes mes VM tournent sous formatage GPT et sans UEFI mais
cela ne fait pas de différences. Effectivement il suffit d’une petite
partition au début d’environ 1 Mo non formatée mais avec le flag
« bios-grub ».

Pour mettre jour le boot, voici ce que je fais alors :
# update-grub
et
# grub-install --modules=part_gpt /dev/sda


Voici un fdisk typique :
# fdisk -l /dev/sda
Disque /dev/sda : 16 GiB, 17179869184 octets, 33554432 secteurs
Modèle de disque : Virtual disk
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 8A91A527-7D9C-4196-90D5-324DE2BACF27

Périphérique   Début  Fin Secteurs Taille Type
/dev/sda1   20481843116384 8M Amorçage BIOS
/dev/sda2  18432  5261311  5242880   2,5G Partition d'échange Linux
/dev/sda35261312 33552383 28291072  13,5G Système de fichiers Linux

Si on utilise UEFI il faut juste ajouter une partition VFAT montée sur
le répertoire /boot/efi.

--
Pierre Malard
Responsable architectures système CDS DINAMIS/THEIA Montpellier
IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France

  « - Il n'y a que trois éléments indispensables à la vie.
Et il n'y a que les scientifiques pour penser que
c'est l'oxygène, l'hydrogène et le carbone...
  - Quoi alors ? L'eau, l'air et le feu ?
  - Non ! Le désir, le désordre et le danger... »
   Manon Briand ; La turbulence des fluides
(film québécois de 2001)
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: [HS] Lilo (et Grub)

[ajh-valmer]

> Le jeu. 28 déc. 2023 à 12:44, ajh-valmer  a écrit :
> > J'ai vérifié, le répertoire /boot contient bien tous les fichiers :
> > System.map-5.10.0-21-amd64
> > config-5.10.0-21-amd64
> > initrd.img-5.10.0-21-amd64
> > vmlinuz-5.10.0-21-amd64
> > Quid ? Serait-ce le partitionnement 'hd1,gpt1' ?
> > (pas possible d'écrire dans le mbr ?)

> Effectivement, GPT ne permet pas le mécanisme de boot classique. Je ne
> suis pas au fait des détails techniques, mais il n'y a pas de notion
> de master boot record.
> Il existe par contre un mécanisme d'amorçage compatible avec le mode
> legacy BIOS. Il me semble que ça consiste à réserver (partition
> spéciale) un espace de l'ordre du Mb pour effectuer les écritures.
> Malheureusement les détails m'échappent,
> mais je tâcherai de remettre la main dessus ce soir, où j'aurai accès
> à mon PC personnel qui amorce de cette façon.

Ok, j'attends avec impatience :
"le mécanisme d'amorçage compatible avec le mode legacy BIOS".
Merci d'avance.

Re: [HS] Lilo (et Grub)

[Eric DEGENETAIS]

Le jeu. 28 déc. 2023 à 12:44, ajh-valmer  a écrit :
>
> Hello,
>
bonjour
>
> J'ai vérifié, le répertoire /boot contient bien tous les fichiers :
> System.map-5.10.0-21-amd64
> config-5.10.0-21-amd64
> initrd.img-5.10.0-21-amd64
> vmlinuz-5.10.0-21-amd64
>
> Quid ? Serait-ce le partitionnement 'hd1,gpt1' ?
> (pas possible d'écrire dans le mbr ?)

Effectivement, GPT ne permet pas le mécanisme de boot classique. Je ne
suis pas au fait des détails techniques, mais il n'y a pas de notion
de master boot record.
Il existe par contre un mécanisme d'amorçage compatible avec le mode
legacy BIOS. Il me semble que ça consiste à réserver (partition
spéciale) un espace de l'ordre du Mb pour effectuer les écritures.
Malheureusement les détails m'échappent,
mais je tâcherai de remettre la main dessus ce soir, où j'aurai accès
à mon PC personnel qui amorce de cette façon.
>
>
> Merci, bonne journée?
>
bonne journée
__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org

Re: [HS] Lilo (et Grub)

[ajh-valmer]

Hello,
Je reviens sur mon problème de boot.
Il y avait un mauvais UUID dans "grub.cfg".
Ça boote sans problème sur le 1er disque dur sda2 (hd0,msdos2).

Le boot sur le 2ème, sdb1, estampillé set root='hd1,gpt1',
je reçois immédiatement ce message :
"Erreur, /boot/vmlinuz-5.10.0-21-amd64 non disponible,
le noyau doit d'abord être chargé". Donc boot impossible.

J'ai vérifié, le répertoire /boot contient bien tous les fichiers :
System.map-5.10.0-21-amd64
config-5.10.0-21-amd64
initrd.img-5.10.0-21-amd64
vmlinuz-5.10.0-21-amd64

Quid ? Serait-ce le partitionnement 'hd1,gpt1' ?
(pas possible d'écrire dans le mbr ?)

Merci, bonne journée?

Re: [HS] Lilo (et Grub)

[Michel Verdier]

Le 27 décembre 2023 Basile Starynkevitch a écrit :

> Toutefois, sur Debian ou Ubuntu le fichier de configuration de grub (à savoir
> /boot/grub/grub.cfg ) est la plupart du temps généré par l'utilitaire
> grub-mkconfig (un script shell)

En général on utilise la commande update-grub qui encapsule l'appel à
grub-mkconfig

Re: [HS] Lilo (et Grub)

[Basile Starynkevitch]

On 12/26/23 14:36, ajh-valmer wrote:

On Monday 25 December 2023 11:08:10 benoit wrote:

Pourquoi Debian et d'autres distributions ont abandonné lilo
au profit de GRUB?

Il me semble (mais à vérifier) que lilo avait ses limites, le secteur
d’amorçage(MBR) ne pouvait s’adresser qu’à une partition primaire.
Limite qu’il suffisait de contourner en utilisant une partition primaire
de qlq Mo pour /boot :

Lilo a été mis de côté pour de bonnes raisons,
mais Grub a beaucoup de défauts.
Le principal est la configuration de partitions qui contiennent
des n° UUID différents à l'intérieur de leur paragraphe concerné :
obligation de corriger ces n° UUID à la main.



Toutefois, sur Debian ou Ubuntu le fichier de configuration de grub (à 
savoir /boot/grub/grub.cfg ) est la plupart du temps généré par 
l'utilitaire grub-mkconfig (un script shell)


--
Basile Starynkevitch
 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: [HS] Lilo (et Grub)

[didier gaumet]

Le 26/12/2023 à 14:36, ajh-valmer a écrit :


Lilo a été mis de côté pour de bonnes raisons,
mais Grub a beaucoup de défauts.
Le principal est la configuration de partitions qui contiennent
des n° UUID différents à l'intérieur de leur paragraphe concerné :
obligation de corriger ces n° UUID à la main.


Bonjour,

c'est une caractéristique même si toi tu le vois comme un défaut.
ça n'a pas été fait pour embêter l'utilisateur mais pour résoudre des 
problèmes qui se posaient jusqu'alors:
 "Drive ordering in your operating system may not be the same as the 
boot drive ordering used by your firmware. Do not assume that your first 
hard drive (e.g. ‘/dev/sda’) is the one that your firmware will boot 
from. device.map (see Device map) can be used to override this, but it 
is usually better to use UUIDs or file system labels and avoid depending 
on drive ordering entirely."


Je n'ai jamais utilisé ça mais tu peux tenter ces options pour voir ce 
que ça donne:

GRUB_DISABLE_LINUX_UUID
GRUB_DISABLE_LINUX_PARTUUID
et surtout
GRUB_DISABLE_UUID
qui active automatiquement les deux premières

la doc Grub est là:
https://www.gnu.org/software/grub/manual/grub/grub.html

Re: [HS] Lilo (et Grub)

[ajh-valmer]

On Monday 25 December 2023 11:08:10 benoit wrote:
> > Pourquoi Debian et d'autres distributions ont abandonné lilo 
> > au profit de GRUB? 
> Il me semble (mais à vérifier) que lilo avait ses limites, le secteur
> d’amorçage(MBR) ne pouvait s’adresser qu’à une partition primaire. 
> Limite qu’il suffisait de contourner en utilisant une partition primaire 
> de qlq Mo pour /boot :

Lilo a été mis de côté pour de bonnes raisons,
mais Grub a beaucoup de défauts.
Le principal est la configuration de partitions qui contiennent 
des n° UUID différents à l'intérieur de leur paragraphe concerné :
obligation de corriger ces n° UUID à la main.

Re: [HS] Lilo

[Michel Verdier]

Le 24 décembre 2023 Alex PADOLY a écrit :

> Pourquoi Debian et d'autres distributions ont abandonné lilo au profit de
> GRUB?

grub apportait (apporte ?) plus de possibilités. Je crois notamment qu'un
beau boot graphique (avec un logo...) n'était pas possible avec lilo?
Est-ce que ça l'est aujourd'hui ?
Et grub permet de modifier le fichier de conf directement alors que lilo
demandait (demande ?) de réécrire le mbr, étape toujours sensible, après
avoir modifié la conf.
Je ne sais pas non plus comment lilo fait pour les partitions cryptées :
si / est crypté et/ou si /boot est crypté.

Re: [HS] Lilo

[didier gaumet]

Le 24/12/2023 à 05:29, Alex PADOLY a écrit :

Bonjour à tous,


J'ai participé hier à une install party ou nous avons installé la 
dernière version de SLACKWARE, j'ai été très surpris que cette 
distribution propose comme gestionnaire d'amorçage lilo.


La première version de Debian que j'ai installée (Potato) proposait lilo.

Pourquoi Debian et d'autres distributions ont abandonné lilo au profit 
de GRUB?



Merci pour vos réponses.


BONNES FÊTES !



Bonjour,

en gros, si je me souviens bien,

Lilo n'est pas compatible avec l'UEFI et n'est plus maintenu

Elilo était une variante de Lilo compatible avec l'UEFI qui n'est plus 
maintenue non plus


Slackware propose les trois bootloaders Lilo (par défault, strictement 
pour un PC en mode UEFI Legacy (pseudo-BIOS) ou BIOS), Elilo (pour un
PC UEFI) et Grub2 (pour les gens qui installent Slackware mais ne 
veulent pas forcément coller à 100% à la philosophie slackware)


L'usage de Lilo par Slackware est conforme au niveau de conservatisme 
élevé de Slackware (usage de SysV au lieu de Systemd, toujours pas de 
gestion de dépendances de paquets en standard, etc...).
Les distributions moins conservatives ont évolué vers Grub2 (et 
possiblement Systemd, Wayland, PulseAudio/Pipewire, etc...)

Re : [HS] Lilo

[nicolas . patrois]

On 24/12/2023 05:29:44, Alex PADOLY wrote:
> Bonjour à tous,

> J'ai participé hier à une install party ou nous avons installé la 
> dernière version de SLACKWARE, j'ai été très surpris que cette 
> distribution propose comme gestionnaire d'amorçage lilo.

> La première version de Debian que j'ai installée (Potato) proposait 
> lilo.

> Pourquoi Debian et d'autres distributions ont abandonné lilo au profit
> de GRUB?

J’utilise toujours lilo et en effet, ma Debian date de Potato.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

[HS] Lilo

[Alex PADOLY]

Bonjour à tous,

J'ai participé hier à une install party ou nous avons installé la 
dernière version de SLACKWARE, j'ai été très surpris que cette 
distribution propose comme gestionnaire d'amorçage lilo.


La première version de Debian que j'ai installée (Potato) proposait 
lilo.


Pourquoi Debian et d'autres distributions ont abandonné lilo au profit 
de GRUB?


Merci pour vos réponses.

BONNES FÊTES !

Re: booting Debian default kernel with lilo results in kernel panic

[Anssi Saari]

Fourhundred Thecat <400the...@gmx.ch> writes:

> How can I boot Debian kernel with lilo?

I have a vague memory you may need to specify root option per image in
lilo.conf. From my ancient lilo.conf:

# Jessie stock kernel
image = /boot/vmlinuz-3.16.0-4-amd64
  label = "Jessie"
  initrd = /boot/initrd.img-3.16.0-4-amd64
  #append="video=uvesafb:1280x1024,mtrr:2 usbcore.autosuspend=1 elevator=noop"
  append="usbcore.autosuspend=1 elevator=noop"
  root=/dev/sda6

booting Debian default kernel with lilo results in kernel panic

[Fourhundred Thecat]

Hello,

On Debian 10, I am using custom kernel, with lilo boot loader.

Now I want to boot the default Debian distribution kernel. I have
installed the debian kernel image:

  apt-get install linux-image-amd64

and added the entry to /etc/lilo.conf. Now my lilo.conf looks like this:

  https://justpaste.it/99qsr

However, when I boot this kernel, I get kernel panic:

  https://paste.pics/53199721ee9a9f7e4e6fea9e2a8fd7dc

What am I doing  wrong?

How can I boot Debian kernel with lilo?

thanks,

Re: Runnlevels are not entered (LILO prompt)

[Reco]

An update.

On Sun, Jun 10, 2018 at 08:03:31PM +0300, Reco wrote:
>   Hi.
> 
> On Sun, Jun 10, 2018 at 07:06:57PM +0300, Michelle Konzack wrote:
> > Am 2018-06-10 hackte Reco in die Tasten:
> > >   Hi.
> > >
> > > On Sun, Jun 10, 2018 at 02:25:30PM +0300, Michelle Konzack wrote:
> > >> Good day,
> > >>
> > >> I run Stretch on my Laptop with sysvinit.
> > >>
> > >> I had setup some profiles and tried to start them by passing 2, 3,
> > >> 4, 5 at the end of the Kernel commandline (I use LILO) but the
> > >> appropriated runnlevel ist not entered.
> > >>
> > >> Do I mis something?
> > >
> > > Whatever you did to LILO you did it wrong.
> > 
> > I have this parameter in "append" of each kernel section since ages!
> > to be more precise, since Woody and it was working!
> 
> Multiple exclamation signs are not a valid substitute for a
> configuration file. Please show an appropriate lilo.conf snippet.

Installed fresh Debian stretch installation.
Installed lilo.
Added this to lilo.conf:

append = "4"

Ran /sbin/lilo. Rebooted.


> > > Check your /proc/cmdline
> > > after the boot.
> > > Every init I've tested assumes a runlevel passed as a last argument of
> > > /proc/cmdline.
> > 
> > It show at the end 2/3/4 depending how I boot, but after login I am
> > in the default runlevel 2.
> 
> Again, show, do not tell.
> Install bootlogd, attach fresh /var/log/boot to your e-mail.
> Show /proc/cmdline. Post the output of 'who -r'.

After the reboot, /var/log/bootlogd contained:

INIT: Entering runlevel: 4

"who -r" showed current runlevel 4, last runlevel S.

Therefore, lilo worked as intended.


Took me 15 minutes to do all this.

Reco

Re: Runnlevels are not entered (LILO prompt)

[Reco]

Hi.

On Sun, Jun 10, 2018 at 07:06:57PM +0300, Michelle Konzack wrote:
> Am 2018-06-10 hackte Reco in die Tasten:
> > Hi.
> >
> > On Sun, Jun 10, 2018 at 02:25:30PM +0300, Michelle Konzack wrote:
> >> Good day,
> >>
> >> I run Stretch on my Laptop with sysvinit.
> >>
> >> I had setup some profiles and tried to start them by passing 2, 3,
> >> 4, 5 at the end of the Kernel commandline (I use LILO) but the
> >> appropriated runnlevel ist not entered.
> >>
> >> Do I mis something?
> >
> > Whatever you did to LILO you did it wrong.
> 
> I have this parameter in "append" of each kernel section since ages!
> to be more precise, since Woody and it was working!

Multiple exclamation signs are not a valid substitute for a
configuration file. Please show an appropriate lilo.conf snippet.


> > Check your /proc/cmdline
> > after the boot.
> > Every init I've tested assumes a runlevel passed as a last argument of
> > /proc/cmdline.
> 
> It show at the end 2/3/4 depending how I boot, but after login I am
> in the default runlevel 2.

Again, show, do not tell.
Install bootlogd, attach fresh /var/log/boot to your e-mail.
Show /proc/cmdline. Post the output of 'who -r'.


> The kernel parameter is ignored under Stretch.

Works for me. The question is - what you've done to achieve such
interesting result?

Reco

Re: Runnlevels are not entered (LILO prompt)

[Michelle Konzack]

Am 2018-06-10 hackte Reco in die Tasten:
>   Hi.
>
> On Sun, Jun 10, 2018 at 02:25:30PM +0300, Michelle Konzack wrote:
>> Good day,
>>
>> I run Stretch on my Laptop with sysvinit.
>>
>> I had setup some profiles and tried to start them by passing 2, 3,
>> 4, 5 at the end of the Kernel commandline (I use LILO) but the
>> appropriated runnlevel ist not entered.
>>
>> Do I mis something?
>
> Whatever you did to LILO you did it wrong.

I have this parameter in "append" of each kernel section since ages!
to be more precise, since Woody and it was working!

> Check your /proc/cmdline
> after the boot.
> Every init I've tested assumes a runlevel passed as a last argument of
> /proc/cmdline.

It show at the end 2/3/4 depending how I boot, but after login I am
in the default runlevel 2.

The kernel parameter is ignored under Stretch.

Thanks in advance

-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

Re: Runnlevels are not entered (LILO prompt)

[Reco]

Hi.

On Sun, Jun 10, 2018 at 02:25:30PM +0300, Michelle Konzack wrote:
> Good day,
> 
> I run Stretch on my Laptop with sysvinit.
> 
> I had setup some profiles and tried to start them by passing 2, 3,
> 4, 5 at the end of the Kernel commandline (I use LILO) but the
> appropriated runnlevel ist not entered.
> 
> Do I mis something?

Whatever you did to LILO you did it wrong. Check your /proc/cmdline
after the boot.
Every init I've tested assumes a runlevel passed as a last argument of
/proc/cmdline. Yes, that includes systemd, sysvinit and openrc.


> Since systemd anything is screwed up und nothing is working correctly.

I'm kind of surprised that you did not put the blame on some Russian
Hax0r crew or NSA honeypot. Are you completely certain that we can
exclude outside influence in this case?

Reco

Runnlevels are not entered (LILO prompt)

[Michelle Konzack]

Good day,

I run Stretch on my Laptop with sysvinit.

I had setup some profiles and tried to start them by passing 2, 3,
4, 5 at the end of the Kernel commandline (I use LILO) but the
appropriated runnlevel ist not entered.

Do I mis something?

Since systemd anything is screwed up und nothing is working correctly.


Thanks in advance

-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

Re: New stretch kernel: lilo boot fails with "EBDA is big" message

[deloptes]

Bill Brelsford wrote:

> Lilo has always met my needs well, so, although I've considered
> grub, I've never felt the need to switch.  But it was one of the
> next steps I was considering in this case -- especially if the
> problem turned out to be lilo.

if there was no need grub would not exist - I don't argue for grub, feel
free to use whatever is best for you

Re: New stretch kernel: lilo boot fails with "EBDA is big" message

[Bill Brelsford]

On Fri Oct 13 2017 at 01:20 AM +0200, deloptes wrote:
> Bill Brelsford wrote:
> 
> > This doesn't explain why I got the EBDA message in the first place,
> > but all is working now..
> 
> once again the question: why not use grub?

Lilo has always met my needs well, so, although I've considered
grub, I've never felt the need to switch.  But it was one of the
next steps I was considering in this case -- especially if the
problem turned out to be lilo.

Re: New stretch kernel: lilo boot fails with "EBDA is big" message

[deloptes]

Bill Brelsford wrote:

> This doesn't explain why I got the EBDA message in the first place,
> but all is working now..

once again the question: why not use grub?

Re: New stretch kernel: lilo boot fails with "EBDA is big" message

[Bill Brelsford]

On Mon Oct 09 2017 at 12:50 AM +0200, Bill Brelsford wrote:
> After the stretch 9.2 kernel upgrade to 4.9.0-4, lilo gives, at
> boot, "EBDA is big; kernel setup stack overlaps LILO second stage"
> and freezes.

Problem solved.  This is a dual-boot system, with the Win 10
bootloader passing control to lilo in the partion boot sector.
The bootloader was configured by EasyBCD (in windows), which
apparently saves its own copy of the partition boot sector, so
ignored changes to lilo.conf.  Guess I'll have to boot windows
and refresh whenever the kernel is updated.  (I originally tried
to use lilo to dual-boot, but ran into problems with windows.)

This doesn't explain why I got the EBDA message in the first place,
but all is working now..

-- 
Bill Brelsford
wbr...@k2di.net

Re: New stretch kernel: lilo boot fails with "EBDA is big" message

[deloptes]

Bill Brelsford wrote:

> Suggestions?

grub

New stretch kernel: lilo boot fails with "EBDA is big" message

[Bill Brelsford]

After the stretch 9.2 kernel upgrade to 4.9.0-4, lilo gives, at
boot, "EBDA is big; kernel setup stack overlaps LILO second stage"
and freezes.

Steps:
 - After upgrading, I installed irqbalance before re-booting.
 - Lilo then gave "Loading linux" followed by a line and a half of
"." and hung, both for the new and old (4.9.0-3) kernels.
 - Using the stretch install disk for rescue, I purged irqbalance and
re-ran lilo.
 - Now I get the "EBDA" message for the new kernel, but the old one
boots normally.
 - I've re-installed the kernel package and re-generated initramfs
(and re-run lilo), but it still fails.

The most common cause of the EBDA message seems to be neglecting to
run lilo, but I've done that.  Output from lilo -v appears to be
correct.

I upgraded 4 other machines with no problem.  All are i686 with
similar configuration, except that the failing one installs the
boot loader in a partition rather than in the MBR.

Suggestions?

-- 
Bill Brelsford
wbr...@k2di.net

Re: Recreating a second boot kernel in LILO

[Miroslav Skoric]

On 01/14/2017 05:38 PM, Stephen Powell wrote:

On Sat, Jan 14, 2017, at 10:05, Richard Owlett wrote:

On 1/14/2017 8:45 AM, Miroslav Skoric wrote:

Hello all,

Intro: I have been using LILO for ages. Now running Wheezy 7.11
LTS. As usual and for test purposes on older machines I have two
kernel flavours: 486 and 686-rt. In LILO boot menu they appear as
Linux486 and Linux686 (before renaming they were Linux and
LinuxOLD). Both work nice on two desktops of different age.

Anyway, few years ago I had a repetitive problem with the 686-rt
kernel slowing down the touch pad on a laptop, so I decided to
remove it completely. So in the LILO menu was left just one boot
option. Recently I decided to install 686-rt again, and during
the installation it added new config*, init.rd*, and vmlinuz*
into /boot, but it did not add any new init.rd* and vmlinuz*
links into /. And without that LILO still keeps one entry. Any
idea how to produce new links in / in order to recreate the
second boot entry? (In lilo.conf everything is the same as in
desktops, however /sbin/lilo complains about missing links in /)

M.S.


You may find Steve Powell's LILO Page useful -
http://www.stevesdebianstuff.org/lilo.htm
Also http://www.stevesdebianstuff.org/index.htm may be of interest.
HTH




The default installation of lilo assumes that the user is only interested
in booting the two most recently-installed kernels.  By Debian convention,
symbolic links are assigned to these kernels in / if "do_symlinks = yes"
is specified in /etc/kernel-img.conf.  The most recent kernel
is assigned the symbolic link name "vmlinuz", and the next-most-recent kernel
is assigned the symbolic link name "vmlinuz.old".  The same pattern is
followed with the initial RAM file system images that correspond to these
kernel images.  The most recent initial RAM file system image is given the
symbolic link name "initrd.img", and the next-most-recent initial RAM file
system image is given the symbolic link name "initrd.img.old".  If
"link_in_boot = yes" is present in /etc/kernel-img.conf, then these symbolic
links are maintained in /boot instead of in /.  However, these symbolic links
are maintained only for stock Debian kernels.  For custom kernels created
with make-kpkg or "make deb-pkg", "do_symlinks = yes" in /etc/kernel-img.conf
has no effect.  In my web page, referred to above by Richard Owlett, I provide
a reference to my kernel building web page where there are execs called
zy-symlinks which will provide equivalent function for custom kernels.

If there are special kernels that you want to be able to boot which are outside
the normal "last two", then you must manually edit /etc/lilo.conf to provide
the capability to boot this kernel, then run lilo.



Thank you all for your comments. Anyway, I think when I made the initial 
install several years ago (it was Squeeze 6.0.1a) it offered more than 
one kernel option for installation, so I probably chose two flavours to 
be installed, or something like that. So whenever a new kernel update 
appeared after that, it flawlessly updated both flavours (486 version & 
686-rt version). So I always ended with two new kernels, and I could 
test/use them interchangeably. Yes I know that was not in accord with 
best LILO practices, but it worked for me. And I also realized the risk 
of neither update to be of 100% quality, but what is a chance that both 
kernel flavours might fail in the same update cycle?


Anyway, I have managed to recreate a second boot kernel in LILO, so 
things work nice for now.


M.S.

Re: Recreating a second boot kernel in LILO

[Stephen Powell]

On Wed, Jan 18, 2017, at 20:49, Stephen Powell wrote:
> 
> ...
> The first two "image" entries define the standard "most recent" and
> "next-most recent" kernels and don't need to be messed with, provided
> that the standard symbolic link names are being maintained by
> "do_symlinks = yes" in /etc/kernel-img.conf or by installation of the
> xy-symlinks kernel hook scripts.
> ...

:1,$s/xy-symlinks/zy-symlinks/

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: Recreating a second boot kernel in LILO

[Stephen Powell]

On Wed, Jan 18, 2017, at 20:49, Stephen Powell wrote:
> ...
> One such program, memtest86+, provides a stand-alone memory testing
> program built to resemble a Linux kernel, so that Linuxboot loaders
> think it is a Linux kernel and will load it like one (the entire boot image is
> loaded, not just a single sector, as with "other").
> ...

:1,$s/Linuxboot/Linux boot/

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: Recreating a second boot kernel in LILO

[Stephen Powell]

On Sat, Jan 14, 2017, at 11:38, Stephen Powell wrote:
> 
> If there are special kernels that you want to be able to boot which are 
> outside
> the normal "last two", then you must manually edit /etc/lilo.conf to provide
> the capability to boot this kernel, then run lilo.
> 
As an example, here is a copy of my /etc/lilo.conf for one of my machines which
uses non-parity memory.  Non-parity memory is cheaper, but memory errors cannot
be directly detected.  However, there are programs one can run if one suspects 
that
he/she has a bad memory stick.  One such program, memtest86+, provides a 
stand-alone
memory testing program built to resemble a Linux kernel, so that Linuxboot 
loaders
think it is a Linux kernel and will load it like one (the entire boot image is
loaded, not just a single sector, as with "other").

# /etc/lilo.conf
#
# global options
#
#boot=/dev/sda1
boot=/dev/disk/by-uuid/e15c-a23a-4f1e-bb6b-8ca0b512cff2
compact
default=Linux
delay=40
#
# This allows lilo to correctly handle the USB-attached floppy drive.
# It is used in conjunction with a user-created udev rule which
# creates a symbolic link between /dev/fd0 and the actual device name
# for the USB-attached floppy drive in the current boot.
#
#disk=/dev/sdb
disk=/dev/fd0
bios=0x00
#
# This is the disk geometry reported by BIOS Int 13h Function 08h
# for the hard disk.  Specifying it here allows the "geometric"
# option to work.  However, we are not using the "geometric" option.
# The disk geometry reported by BIOS Int 13h Function 08h is
# reported here for reference purposes only.  
#
#disk=/dev/sda
disk=/dev/disk/by-id/ata-Samsung_SSD_840_EVO_120GB_S1D5NSBDB61675Y
sectors=63
heads=240
cylinders=1024
#
install=text
large-memory
#
# The BIOS supports EDD, but linear is used instead of lba32 in order
# to get maximum benefit out of the compact option: 128 sectors
# per BIOS call.
#
linear
map=/boot/map
#
# per-image options
#
image=/boot/vmlinuz
label=Linux
initrd=/boot/initrd.img
append="net.ifnames=0"
read-only
#root=/dev/sda6
root="UUID=1af2bc58-83f7-44f8-af32-94d1dd54701e"
vga=normal
#
image=/boot/vmlinuz.old
label=LinuxOLD
initrd=/boot/initrd.img.old
append="net.ifnames=0"
read-only
#root=/dev/sda6
root="UUID=1af2bc58-83f7-44f8-af32-94d1dd54701e"
vga=normal
optional
#
image=/boot/memtest86+.bin
label=memtest86+

The first two "image" entries define the standard "most recent" and
"next-most recent" kernels and don't need to be messed with, provided
that the standard symbolic link names are being maintained by
"do_symlinks = yes" in /etc/kernel-img.conf or by installation of the
xy-symlinks kernel hook scripts.
 
The third "image" entry defines the stand-alone memtest86+ program.
To run it, the user types "memtest86+" (without the quotes) at a LILO
"boot:" prompt.  This boot entry may be thought of as a special Linux
kernel which is outside the normal cycle of "most recent" and
"next-most recent".

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: Recreating a second boot kernel in LILO

[Stephen Powell]

On Sat, Jan 14, 2017, at 10:05, Richard Owlett wrote:
> On 1/14/2017 8:45 AM, Miroslav Skoric wrote:
> > Hello all,
> >
> > Intro: I have been using LILO for ages. Now running Wheezy 7.11
> > LTS. As usual and for test purposes on older machines I have two
> > kernel flavours: 486 and 686-rt. In LILO boot menu they appear as
> > Linux486 and Linux686 (before renaming they were Linux and
> > LinuxOLD). Both work nice on two desktops of different age.
> >
> > Anyway, few years ago I had a repetitive problem with the 686-rt
> > kernel slowing down the touch pad on a laptop, so I decided to
> > remove it completely. So in the LILO menu was left just one boot
> > option. Recently I decided to install 686-rt again, and during
> > the installation it added new config*, init.rd*, and vmlinuz*
> > into /boot, but it did not add any new init.rd* and vmlinuz*
> > links into /. And without that LILO still keeps one entry. Any
> > idea how to produce new links in / in order to recreate the
> > second boot entry? (In lilo.conf everything is the same as in
> > desktops, however /sbin/lilo complains about missing links in /)
> >
> > M.S.
> 
> You may find Steve Powell's LILO Page useful - 
> http://www.stevesdebianstuff.org/lilo.htm
> Also http://www.stevesdebianstuff.org/index.htm may be of interest.
> HTH
> 
> 

The default installation of lilo assumes that the user is only interested
in booting the two most recently-installed kernels.  By Debian convention,
symbolic links are assigned to these kernels in / if "do_symlinks = yes"
is specified in /etc/kernel-img.conf.  The most recent kernel
is assigned the symbolic link name "vmlinuz", and the next-most-recent kernel
is assigned the symbolic link name "vmlinuz.old".  The same pattern is
followed with the initial RAM file system images that correspond to these
kernel images.  The most recent initial RAM file system image is given the
symbolic link name "initrd.img", and the next-most-recent initial RAM file
system image is given the symbolic link name "initrd.img.old".  If
"link_in_boot = yes" is present in /etc/kernel-img.conf, then these symbolic
links are maintained in /boot instead of in /.  However, these symbolic links
are maintained only for stock Debian kernels.  For custom kernels created
with make-kpkg or "make deb-pkg", "do_symlinks = yes" in /etc/kernel-img.conf
has no effect.  In my web page, referred to above by Richard Owlett, I provide
a reference to my kernel building web page where there are execs called
zy-symlinks which will provide equivalent function for custom kernels.

If there are special kernels that you want to be able to boot which are outside
the normal "last two", then you must manually edit /etc/lilo.conf to provide
the capability to boot this kernel, then run lilo.

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: Recreating a second boot kernel in LILO

[Richard Owlett]

On 1/14/2017 8:45 AM, Miroslav Skoric wrote:

Hello all,

Intro: I have been using LILO for ages. Now running Wheezy 7.11
LTS. As usual and for test purposes on older machines I have two
kernel flavours: 486 and 686-rt. In LILO boot menu they appear as
Linux486 and Linux686 (before renaming they were Linux and
LinuxOLD). Both work nice on two desktops of different age.

Anyway, few years ago I had a repetitive problem with the 686-rt
kernel slowing down the touch pad on a laptop, so I decided to
remove it completely. So in the LILO menu was left just one boot
option. Recently I decided to install 686-rt again, and during
the installation it added new config*, init.rd*, and vmlinuz*
into /boot, but it did not add any new init.rd* and vmlinuz*
links into /. And without that LILO still keeps one entry. Any
idea how to produce new links in / in order to recreate the
second boot entry? (In lilo.conf everything is the same as in
desktops, however /sbin/lilo complains about missing links in /)

M.S.


You may find Steve Powell's LILO Page useful - 
http://www.stevesdebianstuff.org/lilo.htm

Also http://www.stevesdebianstuff.org/index.htm may be of interest.
HTH

Recreating a second boot kernel in LILO

[Miroslav Skoric]

Hello all,

Intro: I have been using LILO for ages. Now running Wheezy 7.11 LTS. As 
usual and for test purposes on older machines I have two kernel 
flavours: 486 and 686-rt. In LILO boot menu they appear as Linux486 and 
Linux686 (before renaming they were Linux and LinuxOLD). Both work nice 
on two desktops of different age.


Anyway, few years ago I had a repetitive problem with the 686-rt kernel 
slowing down the touch pad on a laptop, so I decided to remove it 
completely. So in the LILO menu was left just one boot option. Recently 
I decided to install 686-rt again, and during the installation it added 
new config*, init.rd*, and vmlinuz* into /boot, but it did not add any 
new init.rd* and vmlinuz* links into /. And without that LILO still 
keeps one entry. Any idea how to produce new links in / in order to 
recreate the second boot entry? (In lilo.conf everything is the same as 
in desktops, however /sbin/lilo complains about missing links in /)


M.S.

UEFI bootloaders (was: Re: reasons to ditch LILO before upgrading to jessie?)

[Joel Roth]

There has been some mention of booting UEFI systems in
this thread. This appears to be a comprehensive resource:

http://www.rodsbooks.com/efi-bootloaders/index.html

Many bootloaders are covered, and the author also 
mentions his own project, rEFInd

http://www.rodsbooks.com/refind/

cheers,


-- 
Joel Roth
  

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Sun 10 Jul 2016 at 08:38:15 -0500, Richard Owlett wrote:

> On 7/9/2016 4:00 PM, Stephen Powell wrote:
> >[snip]
> >>What I'd like to find which I've had no luck with so far, is finding a 
> >>Debian
> >>installer cmdline option to skip the waste of time that is installation of
> >>any bootloader. My disks get generic MBR code and Grub installed by me 
> >>before
> >>any OS gets installed. Thus, I have no need to see warnings about blocklists
> >>and unreliability from installers trying to do what I don't want or need 
> >>done
> >
> >If you do the installation in expert mode, you can skip the step to install a
> >boot loader.  But that's in interactive mode.  I've never done an automated
> >installation, so I don't know what can and cannot be done in that 
> >environment.
> >
> 
> Preseed.cfg apparently can do everything except "walk the dog".
> [Well really customized partitioning is annoying. But that is documented.]
> I tend to do multiple installs as I am experimenting with having Debian to
> do things in *MY* idiosyncratic way. I started with using EXPERT mode but
> found repetitive typing annoying. An appropriately edited preseed.cfg allows
> me to automate all options except the particular feature(s) of interest.
> 
> My only problem is finding a *SINGLE* references which lists *ALL* the
> choices which can be preseeded.
> 
> I find Debian documentation to frequently resemble the early _CPM-80
> Manual_. It's all there but finding it can me daunting.

The template files in the udebs are the definitive source for preseed
options. Some of them interact with each, requiring care and testing in
the writing of a reference guide.

What Felix Miata and Stephen Powell want is

  d-i grub-installer/skip boolean true

and 

  d-i lilo-installer/skip boolean true

in a preseed.cfg. It can also be done on the kernel line when booting
the installer; the Manual has details for this.

Re: reasons to ditch LILO before upgrading to jessie?

[Richard Owlett]

On 7/9/2016 4:00 PM, Stephen Powell wrote:

[snip]

What I'd like to find which I've had no luck with so far, is finding a Debian
installer cmdline option to skip the waste of time that is installation of
any bootloader. My disks get generic MBR code and Grub installed by me before
any OS gets installed. Thus, I have no need to see warnings about blocklists
and unreliability from installers trying to do what I don't want or need done


If you do the installation in expert mode, you can skip the step to install a
boot loader.  But that's in interactive mode.  I've never done an automated
installation, so I don't know what can and cannot be done in that environment.



Preseed.cfg apparently can do everything except "walk the dog".
[Well really customized partitioning is annoying. But that is 
documented.]
I tend to do multiple installs as I am experimenting with having 
Debian to do things in *MY* idiosyncratic way. I started with 
using EXPERT mode but found repetitive typing annoying. An 
appropriately edited preseed.cfg allows me to automate all 
options except the particular feature(s) of interest.


My only problem is finding a *SINGLE* references which lists 
*ALL* the choices which can be preseeded.


I find Debian documentation to frequently resemble the early 
_CPM-80 Manual_. It's all there but finding it can me daunting.

Re: reasons to ditch LILO before upgrading to jessie?

[Stephen Powell]

On Sun, Jul 10, 2016, at 03:31, Pascal Hambourg wrote:
> 
> AFAICS, elilo is not available any more in stretch and sid.
> 
I'm sorry to hear that.  I don't have any UEFI-based systems right now, so
it's not an issue for me -- yet.  But it may be someday.  On the other hand,
CSM-less UEFI systems may fail in the marketplace.  There have been attempts
in the past to eliminate 16-bit support which failed.  We'll just have to
wait and see.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Sun 10 Jul 2016 at 10:31:38 +0200, to...@tuxteam.de wrote:

> On Sat, Jul 09, 2016 at 11:15:08PM +0100, Brian wrote:
> 
> [...]
> 
> > This is a common misconception. Debian is about providing the best free
> > operating system possible.
> 
> In your humble opinion.
> 
> (sorry, I know I'm feeding it, but I couldn't resist).

Not just my opinion. Please see

  http://upsilon.cc/~zack/talks/2012/20121113-orange.pdf

On page 1:

 Debian: a Free Operating System
 ---
and its Relationships with the Outer World
--
   Stefano Zacchiroli
 Debian Project Leader
13 November 2012
 Paris, France
   Orange — Open Source Group
   2nd annual seminar

On page 5:
Debian: once upon a time

1st major distro developed “openly in the spirit of GNU”

On page 6:
1/3 of Debian: the operating system
---
flagship product: Debian stable

Finally, on page 9:

1/3 of Debian: the Project
--
Common goal:

 Create the best, Free operating system.


Is this authoritative enough?

Re: reasons to ditch LILO before upgrading to jessie?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jul 09, 2016 at 11:15:08PM +0100, Brian wrote:

[...]

> This is a common misconception. Debian is about providing the best free
> operating system possible.

In your humble opinion.

(sorry, I know I'm feeding it, but I couldn't resist).

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAleCB+oACgkQBcgs9XrR2kYwjgCffaje/B2wKNujDBfGmh8N7Zay
heUAn0yq5lqiJiSq19VDhj08Gwzhybda
=cj6k
-END PGP SIGNATURE-

Re: reasons to ditch LILO before upgrading to jessie?

[Pascal Hambourg]

Le 09/07/2016 à 22:41, Stephen Powell a écrit :

So I'm not concerned about it's maintenance status.  As long as there are
PCs with a BIOS, or a CSM, lilo will remain usable.  If the BIOS/CSM goes,
lilo goes with it.  lilo can't function without a BIOS/CSM.  But for UEFI-only
systems, there's elilo as a grub alternative.


AFAICS, elilo is not available any more in stretch and sid.

Re: reasons to ditch LILO before upgrading to jessie?

[Pascal Hambourg]

Le 09/07/2016 à 22:00, Brian a écrit :


All well and good but the installer inexplicably offers a choice between
GRUB and LILO. The installer manual is unhelpful on which to choose. A
newcomer wouldn't have a clue. We do them no service with this retrograde
offering. Get rid of it.

What is the point of a choice?


Maybe the choice is because GRUB won't install on some very specific 
setups while LILO will.


A boot loader is not just like any other program that you can install at 
anytime. It must be present for the whole system to start. So it makes 
sense to include it (and choice for it) in the installation sequence.

Re: reasons to ditch LILO before upgrading to jessie?

[Joel Roth]

Stephen Powell wrote:
> As far as LILO being unmaintained is concerned, I wouldn't be too concerned
> about that.  I've been thinking about offering to maintain it myself.  I 
> haven't
> heard from Joachim lately.  Maybe I'll drop him another line.

I think LILO is an important part of Linux infrastructure.
Please consider asking for contributions if you do take over
maintenance. 

You also mentioned elilo. This project appears to be
abandoned. 

https://sourceforge.net/projects/elilo/

Are you aware if there is much in common?

(E)LILO for GPT and UEFI would be helpful to Linux minimalists
dealing with modern hardware.

Thanks for  your LILO reference pages!

~Joel
 
> The three main things I like about LILO are (1) I understand how it works,
> (2) it is easy to configure, and (3) it doesn't use any unallocated sectors.
> 
> The main limitations to LILO's future viability, as I see it, are UEFI
> and GPT.  LILO is heavily dependent on the traditional BIOS.  Most UEFI
> systems have a CSM to provide a BIOS for forward compatibility, though it
> is often disabled by default.  But some of the newest systems are starting
> to ship with no CSM.  I won't buy one of those as long as I have a choice.
> And GPT is needed to break the 2 TiB disk size limit.  But none of my disks
> are anywhere near that big.
> 
> If your system has a BIOS and a traditional DOS-style partition table,
> there's no reason not to use LILO, unless you just don't want to.
>  
> -- 
>   .''`. Stephen Powell<zlinux...@fastmail.com>
>  : :'  :
>  `. `'`
>`-
> 

-- 
Joel Roth
  

Re: reasons to ditch LILO before upgrading to jessie?

[Stephen Powell]

On Sat, Jul 9, 2016, at 18:25, Brian wrote:
> On Sat 09 Jul 2016 at 16:41:24 -0400, Stephen Powell wrote:
>>
>> Long live choice!
> 
> For choice to exist it does not have to be presented as such in the
> installer.
> 

Your point is well taken.  The installer does not offer choice in everything,
just the big things.  A choice of desktop, for example.  However, even
desktop choice is not presented in the installation steps.  It's hidden
in installer options.  For example, I generally install with

   expert desktop=xfce

and then, if I select "Desktop Environment" in tasksel, I get an xfce
desktop instead of a gnome3 desktop.  Perhaps the boot loader choice could be
handled in a similar fashion.  Something like

   expert desktop=xfce bootloader=lilo

with the defaults being gnome3 and grub2, respectively.

(Dare I suggest adding initsystem=sysvinit as an option too?  No, I better not.
I don't want to get that flame war going again.)

Peace.

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: reasons to ditch LILO before upgrading to jessie?

[Felix Miata]

Brian composed on 2016-07-09 21:00 (UTC+0100):


...the installer inexplicably offers a choice between
GRUB and LILO. The installer manual is unhelpful on which to choose. A
newcomer wouldn't have a clue. We do them no service with this retrograde
offering. Get rid of it.


Probably a Bad idea. Apparently there are RAID and/or LVM configurations that 
are incompatible with booting via an inappropriate choice of bootloader. 
Details I cannot provide, as I use both RAID and Grub2 little, Lilo and LVM 
not at al, and don't remember of which I've repeatedly read in various help 
forums.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Sat 09 Jul 2016 at 16:41:24 -0400, Stephen Powell wrote:

> On Sat, Jul 9, 2016, at 16:00, Brian wrote:
> > 
> > All well and good but the installer inexplicably offers a choice between
> > GRUB and LILO. The installer manual is unhelpful on which to choose. A
> > newcomer wouldn't have a clue. We do them no service with this retrograde
> > offering. Get rid of it.
> > 
> > What is the point of a choice? Just offer GRUB; it is the bootloader for
> > Debian and  has many advantages over LILO in todayss Linux ecosystem.
> > People who have a great desire to use LILO can search it out.
> > 
> > Unmaintained in Debian, The bit-rot starts here.
> 
> I am not a member of the Debian installer team, and I am not authorized to
> speak for them.  However, I will make the observation that LILO used to be
> the default boot loader, indeed the only boot loader at one point, in the
> Debian installer for i386/amd64.  I suspect that LILO has been retained as
> an option in the Debian installer for that reason.

Historical reasons for doing something aren't necessarily bad reasons
but there comes a time when a reassessment of what goes into the
installer has to be made. For example, Stretch drops quite a few of what
in Jessie are Standard utilities. Not on technical grounds but because
of their usefulness to most users.

> The lilo package is maintained in Debian.  It's maintainer is Joachim Wiedorn.
> He is also the upstream maintainer.  He has ceased active development of
> lilo, but I believe he still accepts bug reports.  And if he wants rid of it,
> I know a couple of people who are interested in taking it over, myself 
> included.
> So I'm not concerned about it's maintenance status.  As long as there are
> PCs with a BIOS, or a CSM, lilo will remain usable.  If the BIOS/CSM goes,
> lilo goes with it.  lilo can't function without a BIOS/CSM.  But for UEFI-only
> systems, there's elilo as a grub alternative.

That's a good reason for keeping LILO in Debian. I would hope it doesn't
disappear.

> Long live choice!

For choice to exist it does not have to be presented as such in the
installer.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Sat 09 Jul 2016 at 22:05:45 +0200, Erwan David wrote:

> Le 09/07/2016 à 22:00, Brian a écrit :
> >
> > What is the point of a choice? Just offer GRUB; it is the bootloader for
> > Debian and  has many advantages over LILO in todayss Linux ecosystem.
> > People who have a great desire to use LILO can search it out.
> >
> > Unmaintained in Debian, The bit-rot starts here.
> >
> 
> What is the point of a choice, just use the windows provided with your PC...
> 
> Linux and debian is just about choice given to the user to use what
> he/she thinks is better for him/her.

This is a common misconception. Debian is about providing the best free
operating system possible.

As for choice in the installer, which was the point I made and which you
snipped: where is the choice of printing system, the choice of editor, the
choice of standard utilites such as netcat etc. Choice doesn't exist. Ok,
it does but you have to search it out and get it for yourself if you want
it at installation time.

On the other hand, LILO is presented as an alternative to the default,
well-supported and competent GRUB. No reason given; it's just there,
cluttering up the menu and most likely adding to the confusion of users
who use the expert install. Let those users who want it seek it out.

Re: reasons to ditch LILO before upgrading to jessie?

[Stephen Powell]

On Sat, Jul 9, 2016, at 16:33, Felix Miata wrote:
> 
> All that's well and good, but I see nothing there that equates to my 
> understanding of the meaning of "editing", which includes removal as well as 
> appending.

Oh, I see what you're saying.  Well, the Linux kernel generally does it's own
overriding.  For example, if the kernel command line contains conflicting 
options,
such as "ro" and "rw", the last one supplied takes precedence.  There are some
exceptions.  For example, if the "console" parameter is specified twice, both
consoles are used.  But, strictly speaking, you're right.  LILO appends options
supplied on the command line to options specified in the "append" configuration
file statement, it does not replace them.
> 
> What I'd like to find which I've had no luck with so far, is finding a Debian 
> installer cmdline option to skip the waste of time that is installation of 
> any bootloader. My disks get generic MBR code and Grub installed by me before 
> any OS gets installed. Thus, I have no need to see warnings about blocklists 
> and unreliability from installers trying to do what I don't want or need done 

If you do the installation in expert mode, you can skip the step to install a
boot loader.  But that's in interactive mode.  I've never done an automated
installation, so I don't know what can and cannot be done in that environment.

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: reasons to ditch LILO before upgrading to jessie?

[Stephen Powell]

On Sat, Jul 9, 2016, at 16:00, Brian wrote:
> 
> All well and good but the installer inexplicably offers a choice between
> GRUB and LILO. The installer manual is unhelpful on which to choose. A
> newcomer wouldn't have a clue. We do them no service with this retrograde
> offering. Get rid of it.
> 
> What is the point of a choice? Just offer GRUB; it is the bootloader for
> Debian and  has many advantages over LILO in todayss Linux ecosystem.
> People who have a great desire to use LILO can search it out.
> 
> Unmaintained in Debian, The bit-rot starts here.
> 

I am not a member of the Debian installer team, and I am not authorized to
speak for them.  However, I will make the observation that LILO used to be
the default boot loader, indeed the only boot loader at one point, in the
Debian installer for i386/amd64.  I suspect that LILO has been retained as
an option in the Debian installer for that reason.

The lilo package is maintained in Debian.  It's maintainer is Joachim Wiedorn.
He is also the upstream maintainer.  He has ceased active development of
lilo, but I believe he still accepts bug reports.  And if he wants rid of it,
I know a couple of people who are interested in taking it over, myself included.
So I'm not concerned about it's maintenance status.  As long as there are
PCs with a BIOS, or a CSM, lilo will remain usable.  If the BIOS/CSM goes,
lilo goes with it.  lilo can't function without a BIOS/CSM.  But for UEFI-only
systems, there's elilo as a grub alternative.

Long live choice!

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: reasons to ditch LILO before upgrading to jessie?

[Felix Miata]

Erwan David composed on 2016-07-09 22:05 (UTC+0200):


Brian composed:



What is the point of a choice? Just offer GRUB; it is the bootloader for
Debian...



What is the point of a choice, just use the windows provided with your PC...


:-D


Linux and debian is just about choice given to the user to use what
he/she thinks is better for him/her.


+++
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: reasons to ditch LILO before upgrading to jessie?

[Felix Miata]

Stephen Powell composed on 2016-07-09 13:19 (UTC-0400):


Felix Miata wrote:



Stephen Powell composed on 2016-07-09 08:58 (UTC-0400):



As for features, LILO has all the features that I need.



One feature it never acquired AFAIK, which Grub shares with Syslinux, is the

 ^

ability to edit the kernel cmdline at boot time, before kernel load. With

  

problematic hardware, problematic BIOS, and pre-release kernel and distro
versions, that ability is a big troubleshooting convenience. It's one of the
features that facilitated my decision to migrate from OS/2 to Linux as
primary OS.



Not true.  I use the traditional text-mode interface of LILO (install=text).
To supply kernel options during boot, press the Shift key (by itself) before
the "delay" timer expires to get a boot prompt ("boot:").  Then type the
label of the kernel you want followed by the desired boot parameters.
For example,



Linux single



to boot the kernel in single-user mode.  Or



Linux forcepae



to get a PAE-requiring kernel to boot on a Banias-class Pentium M or
Celeron M processor, if you forgot to specify



append="forcepae"



in /etc/lilo.conf before running lilo.  If you can't remember the names of
your kernel labels, press the Tab key at a "boot:" prompt.  LILO will
display the names of your kernel labels followed by another "boot:" prompt.


All that's well and good, but I see nothing there that equates to my 
understanding of the meaning of "editing", which includes removal as well as 
appending.



I've never used the menu-based interface of LILO, but I'm sure that there
is a way to supply kernel options at boot time with the menu-based interface
as well.


What I wrote probably assumed too much of the reader, as my use of Grub to 
boot virtually always begins in its Gfxboot incarnation, and on a multi-boot 
PC with various incarnations of pre-release OS installations. I keep Gfxboot 
configured in most cases to place the entirety of kernel appendages for the 
selected stanza in edit mode at the outset, so that I know exactly what to 
expect before proceeding.



See my LILO web page at



http://www.stevesdebianstuff.org/lilo.htm



for more information.



P.S.  I used to use OS/2 as well.  But I switched because OS/2, after Warp 4,
was more or less abandoned by IBM.  Besides, Linux is free.  If I had known
about Linux back then, I would probably have gone straight from DOS to Linux.


More recent incarnations of OS/2 remain the best host for a DOS application I 
still depend on constantly. Some things never get improved upon, or if they 
do, the "improvements" don't add meaningful value for every user context, or 
add complexity that outweighs putative benefit. e.g. for some, 64 bit, which 
is killing off 32 bit in more and more distros. Many don't need more power 
than it takes to run apps that can do everything needed of them in as little 
as an 8 or 16 bit OS, much less 32 or 64.


I'm glad to see Lilo remains available for those who remain content to use 
it. Debian's Grub (Legacy) is too broken for use on installations with EXT4 
filesystems even without 64 bit nodes, while openSUSE's keeps on keeping on 
pleasing me, needing no scripts to maintain to my liking.


What I'd like to find which I've had no luck with so far, is finding a Debian 
installer cmdline option to skip the waste of time that is installation of 
any bootloader. My disks get generic MBR code and Grub installed by me before 
any OS gets installed. Thus, I have no need to see warnings about blocklists 
and unreliability from installers trying to do what I don't want or need done 
in the first place.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: reasons to ditch LILO before upgrading to jessie?

[Erwan David]

Le 09/07/2016 à 22:00, Brian a écrit :
>
> What is the point of a choice? Just offer GRUB; it is the bootloader for
> Debian and  has many advantages over LILO in todayss Linux ecosystem.
> People who have a great desire to use LILO can search it out.
>
> Unmaintained in Debian, The bit-rot starts here.
>

What is the point of a choice, just use the windows provided with your PC...

Linux and debian is just about choice given to the user to use what
he/she thinks is better for him/her.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Sat 09 Jul 2016 at 13:19:08 -0400, Stephen Powell wrote:

> On Sat, Jul 9, 2016, at 10:53, Felix Miata wrote:
> > Stephen Powell composed on 2016-07-09 08:58 (UTC-0400):
> > 
> >> As for features, LILO has all the features that I need.
> > 
> > One feature it never acquired AFAIK, which Grub shares with Syslinux, is 
> > the 
> > ability to edit the kernel cmdline at boot time, before kernel load. With 
> > problematic hardware, problematic BIOS, and pre-release kernel and distro 
> > versions, that ability is a big troubleshooting convenience. It's one of 
> > the 
> > features that facilitated my decision to migrate from OS/2 to Linux as 
> > primary OS.
> 
> Not true.  I use the traditional text-mode interface of LILO (install=text).
> To supply kernel options during boot, press the Shift key (by itself) before
> the "delay" timer expires to get a boot prompt ("boot:").  Then type the
> label of the kernel you want followed by the desired boot parameters.
> For example,
> 
>Linux single
> 
> to boot the kernel in single-user mode.  Or
> 
>Linux forcepae
> 
> to get a PAE-requiring kernel to boot on a Banias-class Pentium M or
> Celeron M processor, if you forgot to specify
> 
>append="forcepae"
> 
> in /etc/lilo.conf before running lilo.  If you can't remember the names of
> your kernel labels, press the Tab key at a "boot:" prompt.  LILO will
> display the names of your kernel labels followed by another "boot:" prompt.
> 
> I've never used the menu-based interface of LILO, but I'm sure that there
> is a way to supply kernel options at boot time with the menu-based interface
> as well.
> 
> See my LILO web page at
> 
>http://www.stevesdebianstuff.org/lilo.htm
> 
> for more information.

All well and good but the installer inexplicably offers a choice between
GRUB and LILO. The installer manual is unhelpful on which to choose. A
newcomer wouldn't have a clue. We do them no service with this retrograde
offering. Get rid of it.

What is the point of a choice? Just offer GRUB; it is the bootloader for
Debian and  has many advantages over LILO in todayss Linux ecosystem.
People who have a great desire to use LILO can search it out.

Unmaintained in Debian, The bit-rot starts here.

Re: reasons to ditch LILO before upgrading to jessie?

[Stephen Powell]

On Sat, Jul 9, 2016, at 10:53, Felix Miata wrote:
> Stephen Powell composed on 2016-07-09 08:58 (UTC-0400):
> 
>> As for features, LILO has all the features that I need.
> 
> One feature it never acquired AFAIK, which Grub shares with Syslinux, is the 
> ability to edit the kernel cmdline at boot time, before kernel load. With 
> problematic hardware, problematic BIOS, and pre-release kernel and distro 
> versions, that ability is a big troubleshooting convenience. It's one of the 
> features that facilitated my decision to migrate from OS/2 to Linux as 
> primary OS.

Not true.  I use the traditional text-mode interface of LILO (install=text).
To supply kernel options during boot, press the Shift key (by itself) before
the "delay" timer expires to get a boot prompt ("boot:").  Then type the
label of the kernel you want followed by the desired boot parameters.
For example,

   Linux single

to boot the kernel in single-user mode.  Or

   Linux forcepae

to get a PAE-requiring kernel to boot on a Banias-class Pentium M or
Celeron M processor, if you forgot to specify

   append="forcepae"

in /etc/lilo.conf before running lilo.  If you can't remember the names of
your kernel labels, press the Tab key at a "boot:" prompt.  LILO will
display the names of your kernel labels followed by another "boot:" prompt.

I've never used the menu-based interface of LILO, but I'm sure that there
is a way to supply kernel options at boot time with the menu-based interface
as well.

See my LILO web page at

   http://www.stevesdebianstuff.org/lilo.htm

for more information.

P.S.  I used to use OS/2 as well.  But I switched because OS/2, after Warp 4,
was more or less abandoned by IBM.  Besides, Linux is free.  If I had known
about Linux back then, I would probably have gone straight from DOS to Linux.

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: reasons to ditch LILO before upgrading to jessie?

[Felix Miata]

Stephen Powell composed on 2016-07-09 08:58 (UTC-0400):


As for features, LILO has all the features that I need.


One feature it never acquired AFAIK, which Grub shares with Syslinux, is the 
ability to edit the kernel cmdline at boot time, before kernel load. With 
problematic hardware, problematic BIOS, and pre-release kernel and distro 
versions, that ability is a big troubleshooting convenience. It's one of the 
features that facilitated my decision to migrate from OS/2 to Linux as 
primary OS.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: reasons to ditch LILO before upgrading to jessie?

[Stephen Powell]

On Thu, Jul 7, 2016, at 20:53, Felix Miata wrote:
> Stephen Powell composed on 2016-07-07 20:30 (UTC-0400):
> 
> > If your system has a BIOS and a traditional DOS-style partition table,
> > there's no reason not to use LILO, unless you just don't want to.
> 
> Or, if you like to be able to boot without hunting down rescue media even 
> though you forgot to "rerun" some configuration utility after a kernel 
> upgrade. Once you understand how Grub's shell works, which includes command 
> history and tab completion much the same as *ash, it is simple (maybe not so 
> much in Grub2, which I don't use, as in Grub, which accounts for about 97% of 
> my bootloader installations). Grub's shell has built-in help. With Grub, 
> there's no reason to be scared when an expected boot menu doesn't show up.
> ...

I've been using LILO for about 16 years, and I've never had to use rescue
media because I forgot to run lilo.  Modern Debian systems make sure that
lilo gets run when it needs to be run.  As for features, LILO has all the
features that I need.  Chiefly, it has the feature of being able to load the
Linux kernel into storage (and it's initial RAM file system image) and transfer
control to it.  It does one thing, and it does that one thing very well: it
loads the Linux kernel.  I believe in the KISS philosophy (Keep It Simple,
Stupid).  If you're happy with grub-legacy, great.  I'm happy for you.
Keep using it.  I'm happy with LILO, and I intend to keep using it.  And
apparently, the OP is happy with LILO too; and there's no reason, at least
at this point, why *he* shouldn't keep using it. 

Inside every large program is a small program struggling to get out -- Hoare's
law of large programs.

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 08/07/16 07:06 PM, Brian wrote:

On Fri 08 Jul 2016 at 18:13:01 -0400, Gary Dale wrote:


On 08/07/16 02:19 PM, Brian wrote:

If you have some way of easily adjusting files in /etc/grub.d to the
needs of a user I wish you would say.

So that's the problem. You never took the time to RTFM. See
https://help.ubuntu.com/community/Grub2/Setup#File_Structure

That page, no matter how informative it may be, is not the manual. My
comment was intended to elicit some specific technical advice on how to
adjust an /etc/grub.d file(s) to perform a particular task. Something
like the topic in

   https://lists.debian.org/debian-user/2016/07/msg00278.html

Using labels in a hand written grub.cfg is a snap. Stopping it being
overwritten is another snap. Perhaps altering file X in grub.d is just
as easy and unstressful.

Maybe one day I will read 'pinfo grub'. :)
True enough, but it shows how much good information there is out there. 
As for altering the correct files, it is just as easy and unstressful.





same change either way but the grub template file won't get clobbered so
there is no need to run dpkg-divert.

It's not the same change. ("grub template file". What is that? There
isn't one as far as I can see).

Again, RTFM. There are lots of files for you to tinker with in /etc/grub.d.
You can even add your own and it's guaranteed not be tampered with by any
updates.

So there are. Users should stay away from them (40_custom excepted)
unless they know what they are doing.

Same is true for altering any file.




Moreover, you don't need to update a system manual to note that you are
diverting a package. You just need to note that a single file is not the
package maintainers default - something you have to do either way.

Diverting is a Debian thing. The GRUB manual would never mention it.


No, but you do have to document each system that you are running. If you are
doing anything that is not standard, it has to be recorded so that the next
person (or you 3 months later) will know that you've done it.

I gather from your comment that you aren't doing this. That's asking for
trouble, especially if you are running custom configurations and protecting
them with diversions. Complexity added onto complexity without documentation
is a good recipe for disaster.

I cannot argue with that.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 18:13:01 -0400, Gary Dale wrote:

> >>On 08/07/16 02:19 PM, Brian wrote:
> >
> >If you have some way of easily adjusting files in /etc/grub.d to the
> >needs of a user I wish you would say.
> So that's the problem. You never took the time to RTFM. See
> https://help.ubuntu.com/community/Grub2/Setup#File_Structure

That page, no matter how informative it may be, is not the manual. My
comment was intended to elicit some specific technical advice on how to
adjust an /etc/grub.d file(s) to perform a particular task. Something
like the topic in

  https://lists.debian.org/debian-user/2016/07/msg00278.html

Using labels in a hand written grub.cfg is a snap. Stopping it being
overwritten is another snap. Perhaps altering file X in grub.d is just
as easy and unstressful.

Maybe one day I will read 'pinfo grub'. :)

> >>same change either way but the grub template file won't get clobbered so
> >>there is no need to run dpkg-divert.
> >It's not the same change. ("grub template file". What is that? There
> >isn't one as far as I can see).
> Again, RTFM. There are lots of files for you to tinker with in /etc/grub.d.
> You can even add your own and it's guaranteed not be tampered with by any
> updates.

So there are. Users should stay away from them (40_custom excepted)
unless they know what they are doing.

> >>Moreover, you don't need to update a system manual to note that you are
> >>diverting a package. You just need to note that a single file is not the
> >>package maintainers default - something you have to do either way.
> >Diverting is a Debian thing. The GRUB manual would never mention it.
> >
> No, but you do have to document each system that you are running. If you are
> doing anything that is not standard, it has to be recorded so that the next
> person (or you 3 months later) will know that you've done it.
> 
> I gather from your comment that you aren't doing this. That's asking for
> trouble, especially if you are running custom configurations and protecting
> them with diversions. Complexity added onto complexity without documentation
> is a good recipe for disaster.

I cannot argue with that.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 16:57:30 -0500, David Wright wrote:

> On Fri 08 Jul 2016 at 21:16:00 (+0100), Brian wrote:
> 
> > Stop moaning. Do it or file file a bug, Then stop moaning and do it.
> 
> I'm the person without a complaint about Grub2, not the one moaning.

Apologies. I was intending to talk in general but it looks as though
my remark was directed solely at you. That wasn't my intent but I can
see how it looks that way.

Time to avoid controversy and try to stick to technical points. :)

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 08/07/16 03:51 PM, Brian wrote:

On Fri 08 Jul 2016 at 15:08:21 -0400, Gary Dale wrote:


On 08/07/16 02:19 PM, Brian wrote:

On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:


On 07/07/16 05:12 PM, Brian wrote:

On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:


On 07/07/16 02:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

The big selling feature of Grub over Lilo was that it didn't need to
updated each time you changed something. That fell by the wayside
with Grub 2. Now the big selling feature is that it works with more
than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.

However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
edit it, the changes will be overwritten the next time a debian upgrade
automatically regenerates it. The only method for preserving your changes is
to update the grub templates then run update-grub.

No it's not. dpkg-divert. That's sufficient to search the list archives
for something which has been mentioned a few times but has passed you by.

A lot of trouble for something that can be avoided if you just edit the
correct files in the first place.

Let's see. You write your own grub.cfg or edit the existing one. You
want to preserve your file from being changed so you use a *one line
command* to ensure that. But this one line command is a lot of trouble.
A one line command is onerous?

It is much easier to edit the unspecified "correct files" to stop any
changes to grub.cfg at a Debian upgrade which attempts to regenerate
it? One lives and learns.


Let's see then. You can edit a grub template file or grub.cfg. You make the

No. You edit or devise a grub,cfg. GRUB template files are not involved.
They are irrelevant. You can ignore them because you are doing you own
thing. You have decided what *you* want, not what /etc/grub.d wants to
give you.

If you have some way of easily adjusting files in /etc/grub.d to the
needs of a user I wish you would say.
So that's the problem. You never took the time to RTFM. See 
https://help.ubuntu.com/community/Grub2/Setup#File_Structure



same change either way but the grub template file won't get clobbered so
there is no need to run dpkg-divert.

It's not the same change. ("grub template file". What is that? There
isn't one as far as I can see).
Again, RTFM. There are lots of files for you to tinker with in 
/etc/grub.d. You can even add your own and it's guaranteed not be 
tampered with by any updates.





Moreover, you don't need to update a system manual to note that you are
diverting a package. You just need to note that a single file is not the
package maintainers default - something you have to do either way.

Diverting is a Debian thing. The GRUB manual would never mention it.

No, but you do have to document each system that you are running. If you 
are doing anything that is not standard, it has to be recorded so that 
the next person (or you 3 months later) will know that you've done it.


I gather from your comment that you aren't doing this. That's asking for 
trouble, especially if you are running custom configurations and 
protecting them with diversions. Complexity added onto complexity 
without documentation is a good recipe for disaster.

Re: reasons to ditch LILO before upgrading to jessie?

[David Wright]

On Fri 08 Jul 2016 at 21:16:00 (+0100), Brian wrote:
> On Fri 08 Jul 2016 at 14:23:01 -0500, David Wright wrote:
> > On Fri 08 Jul 2016 at 19:19:00 (+0100), Brian wrote:
> > > On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> > > > On 07/07/16 05:12 PM, Brian wrote:
> > > > >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> > > > >>On 07/07/16 02:55 PM, David Wright wrote:
> > > > >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> > > > >>>>The big selling feature of Grub over Lilo was that it didn't need to
> > > > >>>>updated each time you changed something. That fell by the wayside
> > > > >>>>with Grub 2. Now the big selling feature is that it works with more
> > > > >>>>than just Linux.
> > > > >>>I guess I don't know what you mean by "update".
> > > > >>>If I change the contents of grub.cfg, the effect is immediate:
> > > > >>>the changes will be seen at the next boot. I don't do anything more.
> > > > >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If 
> > > > >>you do
> > > > >>edit it, the changes will be overwritten the next time a debian 
> > > > >>upgrade
> > > > >>automatically regenerates it. The only method for preserving your 
> > > > >>changes is
> > > > >>to update the grub templates then run update-grub.
> > > > >No it's not. dpkg-divert. That's sufficient to search the list archives
> > > > >for something which has been mentioned a few times but has passed you 
> > > > >by.
> > > > 
> > > > A lot of trouble for something that can be avoided if you just edit the
> > > > correct files in the first place.
> > > 
> > > Let's see. You write your own grub.cfg or edit the existing one. You
> > > want to preserve your file from being changed so you use a *one line
> > > command* to ensure that. But this one line command is a lot of trouble.
> > > A one line command is onerous?
> > > 
> > > It is much easier to edit the unspecified "correct files" to stop any
> > > changes to grub.cfg at a Debian upgrade which attempts to regenerate
> > > it? One lives and learns.
> > 
> > I *think* I've worked out what this rant is all about: the replacement
> > of /boot/grub/menu.lst in old Grub by /boot/grub/grub.cfg in Grub2.
> 
> Was that a rant? If so, It has nothing whatsoever to do with GRUB
> legacy.

I was referring to the threads which started Thu, 7 Jul 2016 14:39:51 -0400
as quoted above. In them, I have argued against the view that something
"fell by the wayside" in Grub2 wrt the legacy version. Sorry if you
thought that I was accusing yourself of ranting.

> If you want GRUB to do what you want you write your own grub,cfg.

I do; unconventionally, but it suits me.

> Stop moaning. Do it or file file a bug, Then stop moaning and do it.

I'm the person without a complaint about Grub2, not the one moaning.

Cheers,
David.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 14:23:01 -0500, David Wright wrote:

> On Fri 08 Jul 2016 at 19:19:00 (+0100), Brian wrote:
> > On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> > > On 07/07/16 05:12 PM, Brian wrote:
> > > >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> > > >>On 07/07/16 02:55 PM, David Wright wrote:
> > > >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> > > >>>>The big selling feature of Grub over Lilo was that it didn't need to
> > > >>>>updated each time you changed something. That fell by the wayside
> > > >>>>with Grub 2. Now the big selling feature is that it works with more
> > > >>>>than just Linux.
> > > >>>I guess I don't know what you mean by "update".
> > > >>>If I change the contents of grub.cfg, the effect is immediate:
> > > >>>the changes will be seen at the next boot. I don't do anything more.
> > > >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If 
> > > >>you do
> > > >>edit it, the changes will be overwritten the next time a debian upgrade
> > > >>automatically regenerates it. The only method for preserving your 
> > > >>changes is
> > > >>to update the grub templates then run update-grub.
> > > >No it's not. dpkg-divert. That's sufficient to search the list archives
> > > >for something which has been mentioned a few times but has passed you by.
> > > 
> > > A lot of trouble for something that can be avoided if you just edit the
> > > correct files in the first place.
> > 
> > Let's see. You write your own grub.cfg or edit the existing one. You
> > want to preserve your file from being changed so you use a *one line
> > command* to ensure that. But this one line command is a lot of trouble.
> > A one line command is onerous?
> > 
> > It is much easier to edit the unspecified "correct files" to stop any
> > changes to grub.cfg at a Debian upgrade which attempts to regenerate
> > it? One lives and learns.
> 
> I *think* I've worked out what this rant is all about: the replacement
> of /boot/grub/menu.lst in old Grub by /boot/grub/grub.cfg in Grub2.

Was that a rant? If so, It has nothing whatsoever to do with GRUB
legacy.

If you want GRUB to do what you want you write your own grub,cfg.

Stop moaning. Do it or file file a bug, Then stop moaning and do it.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Fri 08 Jul 2016 at 15:08:21 -0400, Gary Dale wrote:

> On 08/07/16 02:19 PM, Brian wrote:
> >On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> >
> >>On 07/07/16 05:12 PM, Brian wrote:
> >>>On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> >>>
> >>>>On 07/07/16 02:55 PM, David Wright wrote:
> >>>>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> >>>>>>The big selling feature of Grub over Lilo was that it didn't need to
> >>>>>>updated each time you changed something. That fell by the wayside
> >>>>>>with Grub 2. Now the big selling feature is that it works with more
> >>>>>>than just Linux.
> >>>>>I guess I don't know what you mean by "update".
> >>>>>If I change the contents of grub.cfg, the effect is immediate:
> >>>>>the changes will be seen at the next boot. I don't do anything more.
> >>>>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you 
> >>>>do
> >>>>edit it, the changes will be overwritten the next time a debian upgrade
> >>>>automatically regenerates it. The only method for preserving your changes 
> >>>>is
> >>>>to update the grub templates then run update-grub.
> >>>No it's not. dpkg-divert. That's sufficient to search the list archives
> >>>for something which has been mentioned a few times but has passed you by.
> >>A lot of trouble for something that can be avoided if you just edit the
> >>correct files in the first place.
> >Let's see. You write your own grub.cfg or edit the existing one. You
> >want to preserve your file from being changed so you use a *one line
> >command* to ensure that. But this one line command is a lot of trouble.
> >A one line command is onerous?
> >
> >It is much easier to edit the unspecified "correct files" to stop any
> >changes to grub.cfg at a Debian upgrade which attempts to regenerate
> >it? One lives and learns.
> >
> Let's see then. You can edit a grub template file or grub.cfg. You make the

No. You edit or devise a grub,cfg. GRUB template files are not involved.
They are irrelevant. You can ignore them because you are doing you own
thing. You have decided what *you* want, not what /etc/grub.d wants to
give you.

If you have some way of easily adjusting files in /etc/grub.d to the
needs of a user I wish you would say.

> same change either way but the grub template file won't get clobbered so
> there is no need to run dpkg-divert.

It's not the same change. ("grub template file". What is that? There
isn't one as far as I can see).

> Moreover, you don't need to update a system manual to note that you are
> diverting a package. You just need to note that a single file is not the
> package maintainers default - something you have to do either way.

Diverting is a Debian thing. The GRUB manual would never mention it.

Re: reasons to ditch LILO before upgrading to jessie?

[David Wright]

On Fri 08 Jul 2016 at 19:19:00 (+0100), Brian wrote:
> On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:
> > On 07/07/16 05:12 PM, Brian wrote:
> > >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> > >>On 07/07/16 02:55 PM, David Wright wrote:
> > >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> > >>>>The big selling feature of Grub over Lilo was that it didn't need to
> > >>>>updated each time you changed something. That fell by the wayside
> > >>>>with Grub 2. Now the big selling feature is that it works with more
> > >>>>than just Linux.
> > >>>I guess I don't know what you mean by "update".
> > >>>If I change the contents of grub.cfg, the effect is immediate:
> > >>>the changes will be seen at the next boot. I don't do anything more.
> > >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you 
> > >>do
> > >>edit it, the changes will be overwritten the next time a debian upgrade
> > >>automatically regenerates it. The only method for preserving your changes 
> > >>is
> > >>to update the grub templates then run update-grub.
> > >No it's not. dpkg-divert. That's sufficient to search the list archives
> > >for something which has been mentioned a few times but has passed you by.
> > 
> > A lot of trouble for something that can be avoided if you just edit the
> > correct files in the first place.
> 
> Let's see. You write your own grub.cfg or edit the existing one. You
> want to preserve your file from being changed so you use a *one line
> command* to ensure that. But this one line command is a lot of trouble.
> A one line command is onerous?
> 
> It is much easier to edit the unspecified "correct files" to stop any
> changes to grub.cfg at a Debian upgrade which attempts to regenerate
> it? One lives and learns.

I *think* I've worked out what this rant is all about: the replacement
of /boot/grub/menu.lst in old Grub by /boot/grub/grub.cfg in Grub2.
So under the old system, you generated or wrote menu.lst and then you
could edit it to your heart's content. Under the new system, grub.cfg
is always (re)built from a set of scripts and some preference data in
/etc/default/grub, unless you've protected it with your one-line
command. In case of the latter, it behaves just like menu.lst did:
if you edit it, the effect is immediate (and unlike lilo).

Somebody else then chimed in about how the partition numbering scheme
has been screwed (more like corrected IMHO) which meant people were
scratching their heads over "Is it (hd1,0) or (hd0,1)" when the world
has moved on to using UUID/LABELs instead if worrying about whether
the kernel happened to discover their disks in the right order.

Cheers,
David.

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 08/07/16 02:19 PM, Brian wrote:

On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:


On 07/07/16 05:12 PM, Brian wrote:

On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:


On 07/07/16 02:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

The big selling feature of Grub over Lilo was that it didn't need to
updated each time you changed something. That fell by the wayside
with Grub 2. Now the big selling feature is that it works with more
than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.

However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
edit it, the changes will be overwritten the next time a debian upgrade
automatically regenerates it. The only method for preserving your changes is
to update the grub templates then run update-grub.

No it's not. dpkg-divert. That's sufficient to search the list archives
for something which has been mentioned a few times but has passed you by.

A lot of trouble for something that can be avoided if you just edit the
correct files in the first place.

Let's see. You write your own grub.cfg or edit the existing one. You
want to preserve your file from being changed so you use a *one line
command* to ensure that. But this one line command is a lot of trouble.
A one line command is onerous?

It is much easier to edit the unspecified "correct files" to stop any
changes to grub.cfg at a Debian upgrade which attempts to regenerate
it? One lives and learns.

Let's see then. You can edit a grub template file or grub.cfg. You make 
the same change either way but the grub template file won't get 
clobbered so there is no need to run dpkg-divert.


Moreover, you don't need to update a system manual to note that you are 
diverting a package. You just need to note that a single file is not the 
package maintainers default - something you have to do either way.

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote:

> On 07/07/16 05:12 PM, Brian wrote:
> >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:
> >
> >>On 07/07/16 02:55 PM, David Wright wrote:
> >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> >>>>The big selling feature of Grub over Lilo was that it didn't need to
> >>>>updated each time you changed something. That fell by the wayside
> >>>>with Grub 2. Now the big selling feature is that it works with more
> >>>>than just Linux.
> >>>I guess I don't know what you mean by "update".
> >>>If I change the contents of grub.cfg, the effect is immediate:
> >>>the changes will be seen at the next boot. I don't do anything more.
> >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
> >>edit it, the changes will be overwritten the next time a debian upgrade
> >>automatically regenerates it. The only method for preserving your changes is
> >>to update the grub templates then run update-grub.
> >No it's not. dpkg-divert. That's sufficient to search the list archives
> >for something which has been mentioned a few times but has passed you by.
> 
> A lot of trouble for something that can be avoided if you just edit the
> correct files in the first place.

Let's see. You write your own grub.cfg or edit the existing one. You
want to preserve your file from being changed so you use a *one line
command* to ensure that. But this one line command is a lot of trouble.
A one line command is onerous?

It is much easier to edit the unspecified "correct files" to stop any
changes to grub.cfg at a Debian upgrade which attempts to regenerate
it? One lives and learns.

Re: reasons to ditch LILO before upgrading to jessie?

[Felix Miata]

Gary Dale composed on 2016-07-07 14:39 (UTC-0400):


It also has a "rescue shell" that I've never been able to do anything
useful with. When grub fails, I boot from a rescue cd instead. That way
I get a real working environment.


The Grub shell works the same whether in boot rescue mode or run from a 
normal boot, a lot like more familiar shells. A little practice under a 
normal boot should make it easy to understand what to do in rescue mode so 
that it shouldn't be too intimidating under the pressure of being in actual 
rescue mode. I find Grub's rescue mode nearly always easier to work through 
to a normal boot than to locate and boot appropriate rescue media, whose 
purpose often as not is just to work past a broken boot menu.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 07/07/16 05:12 PM, Brian wrote:

On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:


On 07/07/16 02:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

The big selling feature of Grub over Lilo was that it didn't need to
updated each time you changed something. That fell by the wayside
with Grub 2. Now the big selling feature is that it works with more
than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.

However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
edit it, the changes will be overwritten the next time a debian upgrade
automatically regenerates it. The only method for preserving your changes is
to update the grub templates then run update-grub.

No it's not. dpkg-divert. That's sufficient to search the list archives
for something which has been mentioned a few times but has passed you by.



A lot of trouble for something that can be avoided if you just edit the 
correct files in the first place.

Re: enumerating with Grub* (was: reasons to ditch LILO before...)

[rhkramer]

On Thursday, July 07, 2016 09:03:38 PM David Wright wrote:
> The most modern fdisk program I have is gdisk (for GPT disks) and it
> counts partitions from 1. Is there some newfangled disk subsystem
> that's passed me by which starts counting at zero?

I guess it still confuses me, but maybe I have the 0 and 1 reversed...

Re: enumerating with Grub* (was: reasons to ditch LILO before...)

[David Wright]

> rhkra...@gmail.com composed on 2016-07-07 18:47 (UTC-0400):
> >The thing that always frustrated me about grub is that, iirc, they counted
> >disks / partitions different than lilo and the rest of Linux--they start
> >counting at 1 (like Windows, iirc), and lilo and Linux start counting at 
> >0--is
> >that still the case?

I'm sorry that this causes perpetual frustration to you, particularly
as you say you really don't have an issue with grub. I'm not sure
whether the answer below will please you or not...

On Thu 07 Jul 2016 at 20:03:46 (-0400), Felix Miata wrote:
> Grub and Grub2 count drives starting with 0 (as a BIOS does).
> 
> Grub also counts partitions starting with 0.
> 
> Grub2 inexplicably counts partitions starting with 1.

I'm afraid I can't go back further than 1996 with Debian (but that was
the first release, 1.1 or buzz). At that time, Debian counted
partitions from 1, as did lilo. The old Grub definitely stood out
in starting from 0, which is why they spelled it out so carefully
in the docs, eg:
https://www.gnu.org/software/grub/manual/legacy/Naming-convention.html#Naming-convention

Now they have fallen into line, the Grub manual has to make sure you
realise it has been changed, eg
https://www.gnu.org/software/grub/manual/grub.html#Naming-convention

The most modern fdisk program I have is gdisk (for GPT disks) and it
counts partitions from 1. Is there some newfangled disk subsystem
that's passed me by which starts counting at zero?

Cheers,
David.

Re: reasons to ditch LILO before upgrading to jessie?

[Felix Miata]

Stephen Powell composed on 2016-07-07 20:30 (UTC-0400):


If your system has a BIOS and a traditional DOS-style partition table,
there's no reason not to use LILO, unless you just don't want to.


Or, if you like to be able to boot without hunting down rescue media even 
though you forgot to "rerun" some configuration utility after a kernel 
upgrade. Once you understand how Grub's shell works, which includes command 
history and tab completion much the same as *ash, it is simple (maybe not so 
much in Grub2, which I don't use, as in Grub, which accounts for about 97% of 
my bootloader installations). Grub's shell has built-in help. With Grub, 
there's no reason to be scared when an expected boot menu doesn't show up.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: reasons to ditch LILO before upgrading to jessie?

[Stephen Powell]

On Thu, Jul 7, 2016, at 10:57, Giovanni Gigante wrote:
> 
> At the end, I decided to try the upgrade to jessie with LiLo (24.1) in 
> place. I thought that the probability of hitting some bug caused by the 
> interaction between LiLo and the upgraded distribution was less than the 
> probabily of causing some damage by switching the bootloader (for 
> example, by messing up the RAID configuration) since I've never 
> configured Grub before. Also, the golden heuristic of "if it ain't 
> broke, don't fix it", and the fact that this particular Debian upgrade 
> is also switching from the init scripts to systemd, so I did not want to 
> introduce even more changes in the boot process for the moment.
> 
> Apparently, it worked.
> 

I never doubted that it would.  I still use LILO with the latest jessie
kernels.

I maintain a web page for Debian users who use LILO, or who are thinking
of switching from GRUB to LILO:

   http://www.stevesdebianstuff.org/lilo.htm

I don't address the issue of software RAID though.  I've never tried it.
I have used LILO with hardware RAID.  It works just fine.  I'm using it
right now as I write this.

As far as LILO being unmaintained is concerned, I wouldn't be too concerned
about that.  I've been thinking about offering to maintain it myself.  I haven't
heard from Joachim lately.  Maybe I'll drop him another line.

The three main things I like about LILO are (1) I understand how it works,
(2) it is easy to configure, and (3) it doesn't use any unallocated sectors.

The main limitations to LILO's future viability, as I see it, are UEFI
and GPT.  LILO is heavily dependent on the traditional BIOS.  Most UEFI
systems have a CSM to provide a BIOS for forward compatibility, though it
is often disabled by default.  But some of the newest systems are starting
to ship with no CSM.  I won't buy one of those as long as I have a choice.
And GPT is needed to break the 2 TiB disk size limit.  But none of my disks
are anywhere near that big.

If your system has a BIOS and a traditional DOS-style partition table,
there's no reason not to use LILO, unless you just don't want to.
 
-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: enumerating with Grub* (was: reasons to ditch LILO before...)

[Felix Miata]

rhkra...@gmail.com composed on 2016-07-07 18:47 (UTC-0400):


The thing that always frustrated me about grub is that, iirc, they counted
disks / partitions different than lilo and the rest of Linux--they start
counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is
that still the case?


Grub and Grub2 count drives starting with 0 (as a BIOS does).

Grub also counts partitions starting with 0.

Grub2 inexplicably counts partitions starting with 1.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: reasons to ditch LILO before upgrading to jessie?

[Michael Milliman]

On 07/07/2016 05:47 PM, rhkra...@gmail.com wrote:

I'll take advantage of this thread to ask a question / express my frustration
with grub:

The thing that always frustrated me about grub is that, iirc, they counted
disks / partitions different than lilo and the rest of Linux--they start
counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is
that still the case?

OTOH, I haven't touched either lilo or grub in a long time--I don't even know
which I'm using--I installed whatever Debian 7 offered, and, since it is a
single boot system, (and I haven't booted in ~85 days), I don't really have an
issue.
Yes, the partitions are counted differently, and that can be a little 
frustrating.  However, with Grub, you can refer to the partitions by 
label or by UUID (Grub usually defaults to using UUID) rather than 
drive/partition numbers, which makes it a little easier.  Lilo cannot 
refer to the partitions in this way, so you must know what 
drive/partition you are referring to.  This is not a big deal in many 
installations, however, in situations where the drive/partition number 
may change (e.g. usb sticks that on one boot may be /dev/sdb on one boot 
and /dev/sdc on another depending on how/when the bios enumerates them) 
this comes in very handy, as you don't have to know which 
drive/partition will be the root partition, you only have to know either 
the UUID of the partition or a label you have assigned to it, and these 
things don't change regardless of how/where a usb device is enumerated.


On Thursday, July 07, 2016 03:37:12 PM Michael Milliman wrote:

On 07/07/2016 01:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:


--
73's
Mike, WB5VQX

Re: reasons to ditch LILO before upgrading to jessie?

[Michael Milliman]

On 07/07/2016 05:47 PM, rhkra...@gmail.com wrote:

I'll take advantage of this thread to ask a question / express my frustration
with grub:

The thing that always frustrated me about grub is that, iirc, they counted
disks / partitions different than lilo and the rest of Linux--they start
counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is
that still the case?

OTOH, I haven't touched either lilo or grub in a long time--I don't even know
which I'm using--I installed whatever Debian 7 offered, and, since it is a
single boot system, (and I haven't booted in ~85 days), I don't really have an
issue.
Yes, the partitions are counted differently, and that can be a little 
frustrating.  However, with Grub, you can refer to the partitions by 
label or by UUID (Grub usually defaults to using UUID) rather than 
drive/partition numbers, which makes it a little easier.  Lilo cannot 
refer to the partitions in this way, so you must know what 
drive/partition you are referring to.  This is not a big deal in many 
installations, however, in situations where the drive/partition number 
may change (e.g. usb sticks that on one boot may be /dev/sdb on one boot 
and /dev/sdc on another depending on how/when the bios enumerates them) 
this comes in very handy, as you don't have to know which 
drive/partition will be the root partition, you only have to know either 
the UUID of the partition or a label you have assigned to it, and these 
things don't change regardless of how/where a usb device is enumerated.


On Thursday, July 07, 2016 03:37:12 PM Michael Milliman wrote:

On 07/07/2016 01:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:


--
73's
Mike, WB5VQX

Re: reasons to ditch LILO before upgrading to jessie?

[rhkramer]

I'll take advantage of this thread to ask a question / express my frustration 
with grub:

The thing that always frustrated me about grub is that, iirc, they counted 
disks / partitions different than lilo and the rest of Linux--they start 
counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is 
that still the case?

OTOH, I haven't touched either lilo or grub in a long time--I don't even know 
which I'm using--I installed whatever Debian 7 offered, and, since it is a 
single boot system, (and I haven't booted in ~85 days), I don't really have an 
issue.


On Thursday, July 07, 2016 03:37:12 PM Michael Milliman wrote:
> On 07/07/2016 01:55 PM, David Wright wrote:
> > On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote:

> On 07/07/16 02:55 PM, David Wright wrote:
> >On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> >>The big selling feature of Grub over Lilo was that it didn't need to
> >>updated each time you changed something. That fell by the wayside
> >>with Grub 2. Now the big selling feature is that it works with more
> >>than just Linux.
> >I guess I don't know what you mean by "update".
> >If I change the contents of grub.cfg, the effect is immediate:
> >the changes will be seen at the next boot. I don't do anything more.
> However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you do
> edit it, the changes will be overwritten the next time a debian upgrade
> automatically regenerates it. The only method for preserving your changes is
> to update the grub templates then run update-grub.

No it's not. dpkg-divert. That's sufficient to search the list archives
for something which has been mentioned a few times but has passed you by.

Re: reasons to ditch LILO before upgrading to jessie?

[Michael Milliman]

On 07/07/2016 01:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

The big selling feature of Grub over Lilo was that it didn't need to
updated each time you changed something. That fell by the wayside
with Grub 2. Now the big selling feature is that it works with more
than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.
With LILO any time you change the configuration, you have to re-install 
the LILO boot loader for those changes to take effect. With Grub, you 
make a change to the configuration file and it is immediately available 
on the next boot without having to re-install the Grub boot loader.  
Grub understands the file systems and so can read the configuration 
directly, whereas LILO does not understand the file system, and so the 
configuration must be provided as data directly in the loader itself 
(hence the re-install step).



It also has a "rescue shell" that I've never been able to do
anything useful with. When grub fails, I boot from a rescue cd
instead. That way I get a real working environment.

Horses for courses.

Cheers,
David.



--
73's
Mike, WB5VQX

Re: reasons to ditch LILO before upgrading to jessie?

[David Wright]

On Thu 07 Jul 2016 at 15:18:05 (-0400), Gary Dale wrote:
> On 07/07/16 02:55 PM, David Wright wrote:
> >On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> >>The big selling feature of Grub over Lilo was that it didn't need to
> >>updated each time you changed something. That fell by the wayside
> >>with Grub 2. Now the big selling feature is that it works with more
> >>than just Linux.
> >I guess I don't know what you mean by "update".
> >If I change the contents of grub.cfg, the effect is immediate:
> >the changes will be seen at the next boot. I don't do anything more.
> However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If
> you do edit it, the changes will be overwritten the next time a
> debian upgrade automatically regenerates it. The only method for
> preserving your changes is to update the grub templates then run
> update-grub.

Well, if you want to use templates to build your grub.cfg,
then you have to build it with update-grub. That's hardly
surprising. If you roll your own, you don't.

The reason I wrote 'I don't know what you mean by "update"'
is because AIUI if you changed /etc/lilo.conf, you had/have to
remember to run /sbin/lilo to reinstall the loader again.
With grub, you don't. AFAICT that's the big selling feature
you mentioned above, was it not? If not, what was it, and what
has changed between grub 1 and 2?

Cheers,
David.

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 07/07/16 02:55 PM, David Wright wrote:

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:

The big selling feature of Grub over Lilo was that it didn't need to
updated each time you changed something. That fell by the wayside
with Grub 2. Now the big selling feature is that it works with more
than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.
However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you 
do edit it, the changes will be overwritten the next time a debian 
upgrade automatically regenerates it. The only method for preserving 
your changes is to update the grub templates then run update-grub.





It also has a "rescue shell" that I've never been able to do
anything useful with. When grub fails, I boot from a rescue cd
instead. That way I get a real working environment.

Horses for courses.

Cheers,
David.

Glad you find the grub shell useful. I've yet to encounter a boot error 
that it could fix.

Re: reasons to ditch LILO before upgrading to jessie?

[David Wright]

On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
> The big selling feature of Grub over Lilo was that it didn't need to
> updated each time you changed something. That fell by the wayside
> with Grub 2. Now the big selling feature is that it works with more
> than just Linux.

I guess I don't know what you mean by "update".
If I change the contents of grub.cfg, the effect is immediate:
the changes will be seen at the next boot. I don't do anything more.

> It also has a "rescue shell" that I've never been able to do
> anything useful with. When grub fails, I boot from a rescue cd
> instead. That way I get a real working environment.

Horses for courses.

Cheers,
David.

Re: reasons to ditch LILO before upgrading to jessie?

[Gary Dale]

On 05/07/16 09:38 AM, Giovanni Gigante wrote:


Hello,
I am preparing my system for the upgrade from wheezy to jessie.
Since ancient ages, this system has been using LILO as the bootloader, 
because, long ago, it was the only bootloader that was recommended for 
my setup: this machine has two SATA disks in a software RAID 1 & LVM; 
that is, in /etc/lilo.conf I have:


boot=/dev/md0
root=/dev/mapper/vg00-rootlv
raid-extra-boot = mbr

My doubt is that I have read that LILO, besides being very old, is now 
unmantained. However, I see that the jessie installation manual still 
mentions it, so it does not seem deprecated yet.
So the question is: is there any serious reason to switch the system 
to GRUB before upgrading, or can I just keep my current setup and 
proceed to jessie?


Thanks
Giovanni

The big selling feature of Grub over Lilo was that it didn't need to 
updated each time you changed something. That fell by the wayside with 
Grub 2. Now the big selling feature is that it works with more than just 
Linux.


It also has a "rescue shell" that I've never been able to do anything 
useful with. When grub fails, I boot from a rescue cd instead. That way 
I get a real working environment.

Re: reasons to ditch LILO before upgrading to jessie?

[David Wright]

On Thu 07 Jul 2016 at 08:33:57 (+0200), to...@tuxteam.de wrote:
> On Wed, Jul 06, 2016 at 02:23:39PM -0500, Don Armstrong wrote:
> > On Wed, 06 Jul 2016, Jonathan Dowland wrote:
> > > YMMV, I find it impenetrable.
> > 
> > I'm assuming you mean the generated configuration? It's literally just
> > some boilerplate [...]
> 
> Let's make it impenetrable boilerplate, then.
> 
> FWIW, I concur with Jonathan. While I actively worked on my lilo.conf,
> since grub (espeecially -2), I try to avoid touching the conf.
> 
> Wonderfully general, but (for me) wonderfully unusable.
> 
> Now don't get me wrong: without Grub, my box wouldn't boot, and chances
> are that the "legacy" emulation of whatever monster bios is in there
> is so buggy that Lilo wouldn't cope: therefore I am still full of thanks
> and praise for the Grub authors for their hard work.
> 
> Still I do disagree on many of its design principles.

Well, I think it's a shame that there isn't a
GRUB_ENABLE_LINUX_LABEL=true
along with the GRUB_DISABLE_LINUX_UUID parameter.
I did take a look at the scripts with a view to hacking one into
shape, but it struck me that it would be harder to maintain it
unless it got incorporated upstream than what I eventually did.
Even if I succeeded in writing it.

So I took the easier course of writing a python script to read
/run/udev/data/b* and replace the --fs-uuid UUIDs in /boot/grub/grub.cfg
with --label LABELs. Along the way, it also prettifies the menu
strings and adds an fsck entry which I can call with
grub-reboot 'fsck>fsck'
(Again, I don't know why the scripts don't do this themselves.)
I keep a before/after copy so that, whenever grub or a kernel is
updated, I can copy the 'after' file if the 'before' compares equal.

I don't think the scripts are much harder to understand than those
in /etc/init.d/ which regularly come up here when people try to
hack their own.

Cheers,
David.

Re: reasons to ditch LILO before upgrading to jessie?

[Giovanni Gigante]

Brian wrote:
Giovanni Gigante seems happy enough with LiLo and there appears to be 
no definite indication that it would fail to boot an upgraded machine. 
He could consider leaving it in place, reading the bug reports and 
having a plan to install GRUB should something go wrong afterwards.


At the end, I decided to try the upgrade to jessie with LiLo (24.1) in 
place. I thought that the probability of hitting some bug caused by the 
interaction between LiLo and the upgraded distribution was less than the 
probabily of causing some damage by switching the bootloader (for 
example, by messing up the RAID configuration) since I've never 
configured Grub before. Also, the golden heuristic of "if it ain't 
broke, don't fix it", and the fact that this particular Debian upgrade 
is also switching from the init scripts to systemd, so I did not want to 
introduce even more changes in the boot process for the moment.


Apparently, it worked.

Perhaps, in the future, I'll also upgrade the bootloader, one rainy 
afternoon :-)


gg

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Thu 07 Jul 2016 at 12:44:40 +0200, to...@tuxteam.de wrote:

> On Thu, Jul 07, 2016 at 11:32:42AM +0100, Brian wrote:
> > On Thu 07 Jul 2016 at 10:35:47 +0100, Lisi Reisz wrote:
> > 
> > > On Thursday 07 July 2016 07:33:57 to...@tuxteam.de wrote:
> > > > Let's make it (GRUB2) impenetrable boilerplate, then.
> > > 
> > > :-)  +1!
> 
> :-)
> 
> > It doesn't need to be penetrable, does it?
> 
> De gustibus non est disputandum.
> 
> To me, one of the attractions of the whole Free Software thing is its
> "penetrability". I see that there's a force field among many poles,
> functionality and "getting things done NOW" being two very valid ones
> which sometimes are at odds with simplicity. And I readily admit that
> preferences are extremely individual.
> 
> > The generated grub.cfg just needs to boot the machine. In any case,
> > it can easily be replaced by a more readable five or six line version
> > if desired.
> 
> Things get more complicated when you're in the position of "fixing"
> it :-)

Admittedly, a generated grub.cfg or most of the files in /etc/grub.d
are not something I would recommend for bedtime reading. 

> And please, again: the fact that I disagree with some Grub design
> decisions shouldn't detract from the fact that I have utmost
> respect for the Grub developers and packagers. Their hard work,
> their decisions.

Giovanni Gigante seems happy enough with LiLo and there appears to be
no definite indication that it would fail to boot an upgraded machine.
He could consider leaving it in place, reading the bug reports and
having a plan to install GRUB should something go wrong afterwards.

Re: reasons to ditch LILO before upgrading to jessie?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jul 07, 2016 at 11:32:42AM +0100, Brian wrote:
> On Thu 07 Jul 2016 at 10:35:47 +0100, Lisi Reisz wrote:
> 
> > On Thursday 07 July 2016 07:33:57 to...@tuxteam.de wrote:
> > > Let's make it (GRUB2) impenetrable boilerplate, then.
> > 
> > :-)  +1!

:-)

> It doesn't need to be penetrable, does it?

De gustibus non est disputandum.

To me, one of the attractions of the whole Free Software thing is its
"penetrability". I see that there's a force field among many poles,
functionality and "getting things done NOW" being two very valid ones
which sometimes are at odds with simplicity. And I readily admit that
preferences are extremely individual.

> The generated grub.cfg just needs to boot the machine. In any case,
> it can easily be replaced by a more readable five or six line version
> if desired.

Things get more complicated when you're in the position of "fixing"
it :-)

And please, again: the fact that I disagree with some Grub design
decisions shouldn't detract from the fact that I have utmost
respect for the Grub developers and packagers. Their hard work,
their decisions.

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAld+MpgACgkQBcgs9XrR2kYYXwCdELtvb8dcQ1Zwgy/FO/mbmjRJ
riAAljXe1c+7A3aKL2crpeDQBot9hkw=
=LS3G
-END PGP SIGNATURE-

Re: reasons to ditch LILO before upgrading to jessie?

[Brian]

On Thu 07 Jul 2016 at 10:35:47 +0100, Lisi Reisz wrote:

> On Thursday 07 July 2016 07:33:57 to...@tuxteam.de wrote:
> > Let's make it (GRUB2) impenetrable boilerplate, then.
> 
> :-)  +1!

It doesn't need to be penetrable, does it? The generated grub.cfg just
needs to boot the machine. In any case, it can easily be replaced by a
more readable five or six line version if desired.

Re: reasons to ditch LILO before upgrading to jessie?

[Lisi Reisz]

On Thursday 07 July 2016 07:33:57 to...@tuxteam.de wrote:
> Let's make it (GRUB2) impenetrable boilerplate, then.

:-)  +1!

Lisi

Re: reasons to ditch LILO before upgrading to jessie?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jul 06, 2016 at 02:23:39PM -0500, Don Armstrong wrote:
> On Wed, 06 Jul 2016, Jonathan Dowland wrote:
> > YMMV, I find it impenetrable.
> 
> I'm assuming you mean the generated configuration? It's literally just
> some boilerplate [...]

Let's make it impenetrable boilerplate, then.

FWIW, I concur with Jonathan. While I actively worked on my lilo.conf,
since grub (espeecially -2), I try to avoid touching the conf.

Wonderfully general, but (for me) wonderfully unusable.

Now don't get me wrong: without Grub, my box wouldn't boot, and chances
are that the "legacy" emulation of whatever monster bios is in there
is so buggy that Lilo wouldn't cope: therefore I am still full of thanks
and praise for the Grub authors for their hard work.

Still I do disagree on many of its design principles.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAld999QACgkQBcgs9XrR2ka/RQCeP8ml0YqrsOKn6vbbBcj4e0A/
jcQAn1y3dODdJ1u4uPDOm+zOp3MEA4wb
=pS2e
-END PGP SIGNATURE-

Re: reasons to ditch LILO before upgrading to jessie?

[Don Armstrong]

On Wed, 06 Jul 2016, Jonathan Dowland wrote:
> YMMV, I find it impenetrable.

I'm assuming you mean the generated configuration? It's literally just
some boilerplate for fancy splash screens, and then menu entries. Each
entry containing appropriate module loading, root configuration, kernel
and initrd loading, and then boot commands. All of which is generated
directly from /etc/grub.d/ and is pretty well documented[1].

It's the same set of commands you can use to load almost any kernel from
almost any device almost anywhere on a system (or even the network), so
it's pretty useful to learn if you maintain machines which occasionally
need to do weird things.

1: https://www.gnu.org/software/grub/manual/html_node/Configuration.html
-- 
Don Armstrong  https://www.donarmstrong.com

A Bill of Rights that means what the majority wants it to mean is worthless. 
 -- U.S. Supreme Court Justice Antonin Scalia

Re: reasons to ditch LILO before upgrading to jessie?

[Jonathan Dowland]

On Tue, Jul 05, 2016 at 04:46:32PM -0500, Don Armstrong wrote:
> On Tue, 05 Jul 2016, Marc Shapiro wrote:
> > I finally switched to Jessie (but still using SysV Init) a few months
> > ago. This box and its predecessors have uses lilo (and SysV Init)
> > since Bo was a pup. I have yet to see any real reason to switch from
> > lilo to grub. I have never had a problem with lilo and I like having a
> > config that I can directly control and understand.
> 
> Grub's configuration is pretty simple; /etc/default/grub is pretty
> straight forward, and the resultant configuration is also pretty easy to
> understand as well.

YMMV, I find it impenetrable.

> There's a reason why no one is interested in maintaining lilo anymore.

And another why some look for alternatives to Grub :)


signature.asc
Description: Digital signature

Re: reasons to ditch LILO before upgrading to jessie?

[Don Armstrong]

On Tue, 05 Jul 2016, Marc Shapiro wrote:
> I finally switched to Jessie (but still using SysV Init) a few months
> ago. This box and its predecessors have uses lilo (and SysV Init)
> since Bo was a pup. I have yet to see any real reason to switch from
> lilo to grub. I have never had a problem with lilo and I like having a
> config that I can directly control and understand.

Grub's configuration is pretty simple; /etc/default/grub is pretty
straight forward, and the resultant configuration is also pretty easy to
understand as well.

Grub also has a lot more features than lilo has, including the ability
to boot from cd images (useful for updating bios), proper serial
support, the ability to boot any kernel even if it isn't listed in the
config, the ability to handle raid5 and raid6 filesystems, lvm, support
for UEFI, encrypted /boot, network booting, fallback support, etc.

There's a reason why no one is interested in maintaining lilo anymore.

-- 
Don Armstrong  https://www.donarmstrong.com

He no longer wished to be dead. At the same time, it cannot be said
that he was glad to be alive. But at least he did not resent it. He
was alive, and the stubbornness of this fact had little by little
begun to fascinate him -- as if he had managed to outlive himself, as
if he were somehow living a posthumous life.
 -- Paul Auster _City of Glass_

Re: reasons to ditch LILO before upgrading to jessie?

[Marc Shapiro]

On 07/05/2016 10:10 AM, Don Armstrong wrote:

On Tue, 05 Jul 2016, Giovanni Gigante wrote:

I am preparing my system for the upgrade from wheezy to jessie.
Since ancient ages, this system has been using LILO as the bootloader,
because, long ago, it was the only bootloader that was recommended for my
setup: this machine has two SATA disks in a software RAID 1 & LVM; that is,
in /etc/lilo.conf I have:

boot=/dev/md0
root=/dev/mapper/vg00-rootlv
raid-extra-boot = mbr

My doubt is that I have read that LILO, besides being very old, is now
unmantained. However, I see that the jessie installation manual still
mentions it, so it does not seem deprecated yet. So the question is:
is there any serious reason to switch the system to GRUB before
upgrading, or can I just keep my current setup and proceed to jessie?

There's always the possibility that you'll discover a new bug with lilo
and newer kernels which no one else has seen, but that's probably fairly
unlikely.

In my experience, grub now works way more reliably than lilo ever did,
and it's worth switching. [I switched over *years* ago for precisely
this reason.] But your experience may vary.


I finally switched to Jessie (but still using SysV Init) a few months 
ago.  This box and its predecessors have uses lilo (and SysV Init) since 
Bo was a pup.  I have yet to see any real reason to switch from lilo to 
grub.  I have never had a problem with lilo and I like having a config 
that I can directly control and understand.  As Giovanni says, however, 
YMMV.


Marc

Re: reasons to ditch LILO before upgrading to jessie?

[Don Armstrong]

On Tue, 05 Jul 2016, Giovanni Gigante wrote:
> I am preparing my system for the upgrade from wheezy to jessie.
> Since ancient ages, this system has been using LILO as the bootloader,
> because, long ago, it was the only bootloader that was recommended for my
> setup: this machine has two SATA disks in a software RAID 1 & LVM; that is,
> in /etc/lilo.conf I have:
> 
> boot=/dev/md0
> root=/dev/mapper/vg00-rootlv
> raid-extra-boot = mbr
> 
> My doubt is that I have read that LILO, besides being very old, is now
> unmantained. However, I see that the jessie installation manual still
> mentions it, so it does not seem deprecated yet. So the question is:
> is there any serious reason to switch the system to GRUB before
> upgrading, or can I just keep my current setup and proceed to jessie?

There's always the possibility that you'll discover a new bug with lilo
and newer kernels which no one else has seen, but that's probably fairly
unlikely.

In my experience, grub now works way more reliably than lilo ever did,
and it's worth switching. [I switched over *years* ago for precisely
this reason.] But your experience may vary.


-- 
Don Armstrong  https://www.donarmstrong.com

6: If we are one, then we can defeat 2.
  -- "The Prisoner (2009 Miniseries)" _Schizoid_

reasons to ditch LILO before upgrading to jessie?

[Giovanni Gigante]

Hello,
I am preparing my system for the upgrade from wheezy to jessie.
Since ancient ages, this system has been using LILO as the bootloader, 
because, long ago, it was the only bootloader that was recommended for 
my setup: this machine has two SATA disks in a software RAID 1 & LVM; 
that is, in /etc/lilo.conf I have:


boot=/dev/md0
root=/dev/mapper/vg00-rootlv
raid-extra-boot = mbr

My doubt is that I have read that LILO, besides being very old, is now 
unmantained. However, I see that the jessie installation manual still 
mentions it, so it does not seem deprecated yet.
So the question is: is there any serious reason to switch the system to 
GRUB before upgrading, or can I just keep my current setup and proceed 
to jessie?


Thanks
Giovanni

Re: [OT] El desarrollo de LILO se detiene

[Camaleón]

El 2016-01-08 a las 15:44 -0300, alparkom . escribió:

(rescato y corrijo)

> El día 8 de enero de 2016, 15:41, Camaleón <noela...@gmail.com> escribió:
> > Hola,
> >
> > Pues eso, parece que el desarrollador de LILO deja de hacerse cargo del
> > mantenimiento del gestor de arranque¹.

(...)

> Que es LILO? Y GRUB? Recuerdo que en la instalación de Debian te
> pregunta si quieres que GRUB sea predeterminado...

¿Google...?

https://www.google.com/webhp?complete=0=en_rd=cr,ssl#complete=0=en=que+es+lilo
https://www.google.com/webhp?complete=0=en_rd=cr,ssl#complete=0=en=que+es+grub

Saludos,

-- 
Camaleón 

[OT] El desarrollo de LILO se detiene

[Camaleón]

Hola,

Pues eso, parece que el desarrollador de LILO deja de hacerse cargo del 
mantenimiento del gestor de arranque¹.

La verdad es que se trata de uno de esos programas que nunca me he 
planteado cambiar, primero porque cuando se es novato lo último que se te 
pasa por la cabeza es ponerte a jugar con los gestores de arranque (las 
distribuciones que he instalado siempre ponían GRUB de manera 
predeterminada) y después, cuando eres perro viejo te das cuenta de que 
GRUB hace todo lo que quieres y un poquito más, así que no lo tocas.

Pero bueno, da un poquillo de pena ver cómo unos proyectos fagocitan a 
otros, da cuenta del paso del tiempo, de lo que fue y no puedo ser... en 
fin... ley de vida, supongo.

¹https://lists.alioth.debian.org/pipermail/lilo-devel/2015-December/83.html

Saludos,

-- 
Camaleón

Re: Alternatives to grub and lilo? was grub2 menu problems

[Jonathan Dowland]

 On 23 Apr 2014, at 17:33, Ralf Mardorf ralf.mard...@rocketmail.com wrote:
 
 However, a lot of
 experienced Linux users prefer Syslinux.

I'd like to revisit syslinux at some point. It works well on boot USBs etc. Add 
my voice to the chorus of folks not happy with grub2. 

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/f83ab7de-02fb-4a41-b3f0-db78c5482...@debian.org

Re: Alternatives to grub and lilo? was grub2 menu problems

[Kruppt]

On 2014-04-23, Steve Litt sl...@troubleshooters.com wrote:
 On Wed, 23 Apr 2014 17:54:22 +0600
 Muntasim Ul Haque tranjees...@inventati.org wrote:

 When I press Enter then it boots into Windows 8 without any problem.
 So I don't have any big issue here except Windows 8 is detected as
 Windows Vista and that occurrence of error message. So what's the
 remedy?

 Grub used to be good software. Predictable, non-surprising, one config
 file you edited with an editor. Those days are gone.

 Now, with grub 2, I need to be an expert on seven or so files that get
 processed into one big one, which acts as the config. I don't mind
 acquiring expertise for something important like LaTeX for writing
 books or Python for making my computer do my bidding, but I don't want
 to spend hours or days gaining expertise just for a program telling the
 computer the kernel and initrd locations, and a few other things. With
 gui, splash screens, frame-buffers, and all sorts of other gobblty-gook.

 I considered going back to LILO, but it still has no understanding of
 filesystems: It's easy to bork and hard to fix. Not as hard as Grub 2
 though.

 Is there a simpler bootloader that works with Linux? I don't want GUI.
 I don't want a framebuffer. I don't want a splash screen. And I don't
 want to wade through seven files to turn those things off. Basically,
 I'd like something like LILO that understands ext4.

 Thanks,

 SteveT

 Steve Litt*  http://www.troubleshooters.com/
 Troubleshooting Training  *  Human Performance



There are patched versions of Grub Legacy out there that
*understand* ext4 and the use of UUID's. I know that a LiveCD
Debian varient called Mepis, the latest of the 8.5 versions
has this patched version of GRUB Legacy. If you downloaded 
their latest 8.5 LiveCD you could install this patched version 
of Legacy Grub from the LiveCD. (Without having to install OS)
Also the LiveCD version of ArchBang pre systemd 
had a patched version of Grub Legacy also.
Sorry don't remember the version, just remember that it
was the version pre systemd, as they changed to GRUB2 after
that point in time. I'm sure there are other places to
find this patched version of Grub-Legacy, I just don't remember them
at this point in time. I use both Grub2 and Grub Legacy myself.
I have not messed yet with any UEFI or EFI systems, so can not
comment on that. In my case I use Grub Legacy (installed MBR 
and first ext partition on HDD's) and install all GRUB2 to the 
root partition of all other GNU/Linux installs on drives. 
I can boot directly to any of the other Linux installs 
from Grub-Legacy or chainload to GRUB2 
for it's added features if need be. 
(boot directly from ISO's etc.)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140424034325.730@0.0.0

Re: Alternatives to grub and lilo? was grub2 menu problems

[maderios]

On 04/23/2014 06:18 PM, Steve Litt wrote:


Now, with grub 2, I need to be an expert on seven or so files that get
processed into one big one, which acts as the config. I don't mind


Hi
You need to edit only one file: /etc/default/grub
Then
update-grub
and it works...
--
Maderios



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/53591316.5060...@gmail.com