Over the years I could not count the number of times that one of
my machines which uses lilo has lost its boot sector. I use grub now
in my main machine, but I have a number of machines for which I
am responsible which still run lilo. Yesterday a friend's machine
lost its boot sector and I want to tell how I solved the problem
and ask if there was a better way.

The machine with the lost boot sector had been running 14.2
for several years. The owner who lives over 100 miles from
me brought the machine to me. I booted the machine with
a liveslak drive. The operational partition on the drive was
sda2. I followed these steps:

mkdir /sda2

cp /sda2/boot/vmlinuz /boot

mount /dev/sda2 /sda2
mount --bind /dev /sda2/dev
/dev/sda2/sbin/lilo -r /sda2
sync
umount /sda2

and the affected machine was able to boot.

This process could be simplified if liveslak
or an install usb could track slackpkg updates.
If, over time, slackpkg updates the kernel the
original install disk cannot be used to get
into the system. Similarly, the liveslak kernel
would not match the kernel on the affected system.

What would you have done apart from switching to grub?

root <NoEMail@home.org> writes:

> Over the years I could not count the number of times that one of
> my machines which uses lilo has lost its boot sector. I use grub now
....
> sda2. I followed these steps:
>
> mkdir /sda2
>
> cp /sda2/boot/vmlinuz /boot
>
> mount /dev/sda2 /sda2
> mount --bind /dev /sda2/dev
> /dev/sda2/sbin/lilo -r /sda2
> sync
> umount /sda2
>
>
> and the affected machine was able to boot.
....
>
> What would you have done apart from switching to grub?

Backing up the boot sector (mental note, back up my boot sectors) to a
filesystem -- I prefer / to make it easy to find -- each time it changes
would reduce your recovery to...

dd if=/boot.sector.backup of=/dev/sda bs=512 count=1

I would back it up only to a filesystem on the hard drive where it
exists. The usual considerations for backups motivating a separate drive
or off site copy don't apply. You want only the most recent (non-corrupt
-- a gotcha there?) bytes. If the drive goes, the root file system
corrupts or is wiped, or if your apartment burns down then the sector is
no longer useful.

Using grub the backup is slightly more complicated. Its first stage
lives where exactly? Somewhere between the MBR boot sector and the
first sector of the first partition? So dd out some number of the first
N sectors up to but not including the beginning of the first partition?
Or up to and including its PBR if you use and want to preserve that?
Off by one errors here could be really annoying.

One thing I've been doing is to make each operating system on my disk
boot from its PBR if possible. So Slackware 14.2 (I have 15.0 on
another machine with no multibooting and a GPT partition table) boots
with lilo from its PBR. Grub is set up from Debian using all the gunk
they have to detect everything and create boot entries, these being
bootable directly from the Grub installed in the MBR + early sectors.
My custom Grub configuration includes chain loaders to Slackware and
NetBSD's PBR bootloaders. I also have an inactive Grub configuration on
the Slackware partition that is, I hope, more or less up to date, in
case I erased Debian. The Slackware PBR would be bootable with a simple
fdisk /mbr and active flag if needed. Once into the Slackware area (via
lilo on the PBR) I could run grub-mkconfig to get the other things
booting again. So there's some redundancy but probably too much
complexity.

There's also grub-mkrescue.

- Mike Sm.

Mike Small <smallm@panix.com> wrote:
> root <NoEMail@home.org> writes:
>
> Backing up the boot sector (mental note, back up my boot sectors) to a
> filesystem -- I prefer / to make it easy to find -- each time it changes
> would reduce your recovery to...
>
> dd if=/boot.sector.backup of=/dev/sda bs=512 count=1
>
> I would back it up only to a filesystem on the hard drive where it
> exists. The usual considerations for backups motivating a separate drive
> or off site copy don't apply. You want only the most recent (non-corrupt
> -- a gotcha there?) bytes. If the drive goes, the root file system
> corrupts or is wiped, or if your apartment burns down then the sector is
> no longer useful.

I can't be sure to make such a backup when I am doing something that
involves the boot sector indirectly. Moreover, I would still have to
use Liveslak or something else to mount the drive and perform
the dd restoration.

>
> Using grub the backup is slightly more complicated. Its first stage
> lives where exactly? Somewhere between the MBR boot sector and the
> first sector of the first partition? So dd out some number of the first
> N sectors up to but not including the beginning of the first partition?
> Or up to and including its PBR if you use and want to preserve that?
> Off by one errors here could be really annoying.

When I lose the grub boot sector I fall back to a fixed set of
commands which I keep on a file card under my monitor (which I
can't seem to find now so I can't reveal the commands).
>
> One thing I've been doing is to make each operating system on my disk
> boot from its PBR if possible. So Slackware 14.2 (I have 15.0 on
> another machine with no multibooting and a GPT partition table) boots
> with lilo from its PBR. Grub is set up from Debian using all the gunk
> they have to detect everything and create boot entries, these being
> bootable directly from the Grub installed in the MBR + early sectors.
> My custom Grub configuration includes chain loaders to Slackware and
> NetBSD's PBR bootloaders. I also have an inactive Grub configuration on
> the Slackware partition that is, I hope, more or less up to date, in
> case I erased Debian. The Slackware PBR would be bootable with a simple
> fdisk /mbr and active flag if needed. Once into the Slackware area (via
> lilo on the PBR) I could run grub-mkconfig to get the other things
> booting again. So there's some redundancy but probably too much
> complexity.

I don't understand most of the previous paragraph.
>
> There's also grub-mkrescue.
>
> - Mike Sm.

Thanks for responding Mike.

root <NoEMail@home.org> wrote:
> Mike Small <smallm@panix.com> wrote:
>> root <NoEMail@home.org> writes:
>>
>> Backing up the boot sector (mental note, back up my boot sectors) to
>> a filesystem -- I prefer / to make it easy to find -- each time it
>> changes would reduce your recovery to...
>>
>> dd if=/boot.sector.backup of=/dev/sda bs=512 count=1
>>
>> I would back it up only to a filesystem on the hard drive where it
>> exists. The usual considerations for backups motivating a separate
>> drive or off site copy don't apply. You want only the most recent
>> (non-corrupt -- a gotcha there?) bytes. If the drive goes, the root
>> file system corrupts or is wiped, or if your apartment burns down
>> then the sector is no longer useful.
>
> I can't be sure to make such a backup when I am doing something that
> involves the boot sector indirectly.

But you can, if you want, setup a cron job to periodically do the dd
copy of the boot sector to a file every X units of time. You can even
choose to store the last Y copies (date/time stamped) or all copies
ever made (again, date/time stamped). Then you don't have to
'remember' to make the backup, it just happens for you automatically.

> Moreover, I would still have to use Liveslak or something else to
> mount the drive and perform the dd restoration.

True. But you have to do that to recover from a lost boot sector
anyway, so no different there.

On Wed, 08 Mar 2023 15:29:43 +0000, root wrote:

> Over the years I could not count the number of times that one of my
> machines which uses lilo has lost its boot sector.

Even if the boot sector is OK, the position it points to where the kernel
should be might no longer be valid.

> The machine with the lost boot sector had been running 14.2 for several
> years. The owner who lives over 100 miles from me brought the machine to
> me. I booted the machine with a liveslak drive. The operational
> partition on the drive was sda2. I followed these steps:
>
> mkdir /sda2
>
> cp /sda2/boot/vmlinuz /boot
>
> mount /dev/sda2 /sda2
> mount --bind /dev /sda2/dev
> /dev/sda2/sbin/lilo -r /sda2
> sync
> umount /sda2
>
>
> and the affected machine was able to boot.

I guess that you did mount /sda2 before copying its kernel to /boot?
However, I don't see any need to copy the kernel. Simply do:

mkdir /sda2
mount /dev/sda2 /sda2
/dev/sda2/sbin/lilo -r /sda2

> This process could be simplified if liveslak or an install usb could
> track slackpkg updates.
> If, over time, slackpkg updates the kernel the original install disk
> cannot be used to get into the system. Similarly, the liveslak kernel
> would not match the kernel on the affected system.

It does not matter if you choose some rescue media like syslinux, knoppix
or the Slackware installation media with a completely different kernel.
Lilo does not care if the running kernel differs from the kernel lilo is
supposed to boot. You can even write lilo configuration files which allow
you to choose between many different kernels.
> What would you have done apart from switching to grub?

Your choice of bootloader does not matter. The important thing that
matters is the text in the changelog when a new kernel package is
released by Slackware:

-8<--------------------------------------------
Be sure to upgrade your initrd after upgrading the kernel packages.
If you use lilo to boot your machine, be sure lilo.conf points to the
correct kernel and initrd and run lilo as root to update the bootloader.
If you use elilo to boot your machine, you should run eliloconfig to copy
the kernel and initrd to the EFI System Partition.
-8<--------------------------------------------

You will need to update your bootloader, you can do it the easy way or
you can do it the hard way with some friend using a rescue media.

regards Henrik

On Wed, 08 Mar 2023 15:29:43 +0000, root wrote:

> Over the years I could not count the number of times that one of my
> machines which uses lilo has lost its boot sector. I use grub now in my

Strange, never had a lilo boot failure (that wasnt caused by operator
error in nearly 30 years)

I only use lilo, 99% of that is and has been slackware (we did have some
redhat (not rhel or clone, not fedora or clone, but the original) back in
the 90's because some software only supported it and they refused to give
out source, I'm sure they had a a floor load of laywers actively
protecting their crappy trademark software LOL, over all that/this time
thats thousands of servers, from a top 3 national ISP, to fair-sized web
hosting company

Dunno what you're doing to poor lilo.

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> On Wed, 08 Mar 2023 15:29:43 +0000, root wrote:
>
>
> I guess that you did mount /sda2 before copying its kernel to /boot?
> However, I don't see any need to copy the kernel. Simply do:

You are correct, I mounted sda2 earlier. I posted the procedure
from memory.

I copied the kernel from sda2 because lilo expected that kernel
to be in the boot directory and I wasn't sure that it wanted
it in the boot directory of sda2 or of the liveslak drive.

>
> mkdir /sda2
> mount /dev/sda2 /sda2
> /dev/sda2/sbin/lilo -r /sda2
>
>
> It does not matter if you choose some rescue media like syslinux, knoppix
> or the Slackware installation media with a completely different kernel.
> Lilo does not care if the running kernel differs from the kernel lilo is
> supposed to boot. You can even write lilo configuration files which allow
> you to choose between many different kernels.

I have seen many times that Lilo fails if it can't find the kernel
mentioned in lilo.conf, or if a partition is called for that it
can't find.

>
>> What would you have done apart from switching to grub?
>
> Your choice of bootloader does not matter. The important thing that
> matters is the text in the changelog when a new kernel package is
> released by Slackware:
>
> -8<--------------------------------------------
> Be sure to upgrade your initrd after upgrading the kernel packages.
> If you use lilo to boot your machine, be sure lilo.conf points to the
> correct kernel and initrd and run lilo as root to update the bootloader.
> If you use elilo to boot your machine, you should run eliloconfig to copy
> the kernel and initrd to the EFI System Partition.
> -8<--------------------------------------------

I do the mkinitrd when I change the kernel being used by lilo. In this
case lilo on sda2 was using a custom kernel I built and it had
not been changed.

>
> You will need to update your bootloader, you can do it the easy way or
> you can do it the hard way with some friend using a rescue media.
>
> regards Henrik

As usual, thanks much for responding Henrik.

noel <deletethis@invalid.lan> wrote:
> On Wed, 08 Mar 2023 15:29:43 +0000, root wrote:
>
>> Over the years I could not count the number of times that one of my
>> machines which uses lilo has lost its boot sector. I use grub now in my
>
>
> Strange, never had a lilo boot failure (that wasnt caused by operator
> error in nearly 30 years)

I'll confess. I'm certain almost always my incorrect use of lilo,
as it was in this case.

I have, however, had the boot sector wiped when an ssd was the
boot drive and some program I was developing crashed. Lilo
was not the cause of the boot sector damage in those cases.

>
> Dunno what you're doing to poor lilo.

I pretty much use grub on most of the machines I use now.

root <NoEMail@home.org> wrote:
> noel <deletethis@invalid.lan> wrote:
>> On Wed, 08 Mar 2023 15:29:43 +0000, root wrote:
>>
>>> Over the years I could not count the number of times that one of my
>>> machines which uses lilo has lost its boot sector. I use grub now in my
>>
>>
>> Strange, never had a lilo boot failure (that wasnt caused by operator
>> error in nearly 30 years)
>
> I'll confess. I'm certain almost always my incorrect use of lilo,
> as it was in this case.
>

It's easy enough for me to backup the boot sector without relying
on my memory:

I put the dd command in rc.local so the boot sector is backed up
after a successful boot. Thanks for the suggestion.

On Fri, 10 Mar 2023 08:01:50 +0000, root wrote:

> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> /sbin/lilo -r /sda2

> I have seen many times that Lilo fails if it can't find the kernel
> mentioned in lilo.conf, or if a partition is called for that it can't
> find.

Yes, that can happen if your /boot directory lives on another partition
than the / directory. I so, you will need to mount also the /boot
partition correctly below the directory you point out with the -r option.

In short lilo needs the file /etc/lilo.conf and any file that
configuration file points to. Usually all files pointed to by lilo.conf
resides below /boot.

So if you from your live media mount your root partition at /sda2 and you
have /boot on a separate partition you will also need to mount that
partition below /sda2/boot. When called with "lilo -r /sda2" lilo
initially expects to find:

/sda2/etc/lilo.conf

Once that file has been parsed lilo will probably expect to find kernels
and stuff below

/sda2/boot

> I do the mkinitrd when I change the kernel being used by lilo. In this
> case lilo on sda2 was using a custom kernel I built and it had not been
> changed.

Lilo is not supposed to break unless the MBR has been tampered with in
some way or the files pointed to by lilo has been removed or moved to
other blocks on the disk. Lilo in the MBR does not parse file systems, it
remembers the position on disk that the kernel resides on. Doing things
like "mv /boot/vmlinuz /tmp; mv /tmp/vmlinuz /boot" might from a users
point of view on the /boot file system look as if nothing has changed but
will most likely break lilo as the kernel might have moved to another
block on the disk.

regards Henrik

On Wed, 8 Mar 2023 15:29:43 -0000 (UTC), root wrote:

> Over the years I could not count the number of times that one of my
> machines which uses lilo has lost its boot sector. I use grub now in my
> main machine, but I have a number of machines for which I am responsible
> which still run lilo. Yesterday a friend's machine lost its boot sector
> and I want to tell how I solved the problem and ask if there was a
> better way.

> [snip]

I haven't used lilo in years. I'm wondering if yours is a lilo issue.
Yes, Grub took a little getting used to, and it has an overhead of
complexity which sours it a little. Yet it works well, and is a powerful
tool.

I can't say that I have ever "lost a boot sector". I have occasionally
been unable to boot--maybe once or twice it happened by accidentally
damaging the boot sector. Usually, however, any trouble that I had came
from the normal processes of installing and upgrading. To deal with this
I studied. I ran tests, searched the Internet for tips, and kept notes,
some of which go back sixteen years. I manage alright now, but I'm still
not confident when it comes to fixing booting problems.

Generally, my problem solving involves the use of chroot, mkinitrd and
mkinitrd_command_generator.sh. And, of course, it involves reading my
notes.

There is one more bit of wisdom I would like to pass along. Perhaps you
have Slackware on a bootable flashdrive? I couldn't manage without such
flashdrives (I have several). They are life savers when I have booting
trouble, and (true confession) my daily system *is* a bootable Slackware
flashdrive.

-Joe

On 2023-03-10 at 04:06 AST, root <NoEMail@home.org> wrote:
> noel <deletethis@invalid.lan> wrote:
>> On Wed, 08 Mar 2023 15:29:43 +0000, root wrote:
>>
>>> Over the years I could not count the number of times that one of my
>>> machines which uses lilo has lost its boot sector. I use grub now in my
>>
>>
>> Strange, never had a lilo boot failure (that wasnt caused by operator
>> error in nearly 30 years)
>
> I'll confess. I'm certain almost always my incorrect use of lilo,
> as it was in this case.
>
> I have, however, had the boot sector wiped when an ssd was the
> boot drive and some program I was developing crashed.

Logged in as root at the time, by any chance?