Liveslak vs USBinstall and lost boot sector

[root]

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?

[Mike Small]

Post by root
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

...

Post by root
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.

...

Post by root
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.

[root]

Post by Mike Small
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.

Post by Mike Small
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).

Post by Mike Small
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.

Post by Mike Small
There's also grub-mkrescue.
- Mike Sm.

Thanks for responding Mike.

[Rich]

Post by root

Post by Mike Small
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.

Post by root
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.

[Henrik Carlqvist]

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
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

[root]

Post by Henrik Carlqvist
I guess that you did mount /sda2 before copying its kernel to /boot?

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.

Post by Henrik Carlqvist
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.

Post by Henrik Carlqvist

Post by root
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
-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.

Post by Henrik Carlqvist
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.

[Henrik Carlqvist]

Post by root

Post by root
/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

Post by root
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

[noel]

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.

[root]

Post by noel

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.

Post by noel
Dunno what you're doing to poor lilo.

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

[root]

Post by root

Post by noel

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.

[Jim Diamond]

Post by root

Post by noel

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?

[Joseph Rosevear]

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