My son taught me an easy way to rebuild the boot
sector when it has been wiped (always because my error).

Using another system, such as LiveSlack, load the
drive with the damaged sector into, say, mountpoint.

cd mountpoint
mount --bind /sys sys
mount --bind /proc proc
mount --bind /dev dev
chroot mountpoint
lilo

or grub-install, whatever.

I added the three mount lines to live slack usb.

On Wed, 13 Dec 2023 21:16:49 +0000, root wrote:

> My son taught me an easy way to rebuild the boot
> sector when it has been wiped (always because my error).
>
> Using another system, such as LiveSlack, load the
> drive with the damaged sector into, say, mountpoint.
>
> cd mountpoint
> mount --bind /sys sys
> mount --bind /proc proc
> mount --bind /dev dev
> chroot mountpoint
> lilo

That seems a bit overly complicated.

I've used a similar, but trimmed down, procedure
1) live boot
2) mount your host directories under the live boot /mnt directory
3) cd /mnt && chroot .
4) lilo

You don't need the bind mounts.

--
Lew Pitcher
"In Skills We Trust"

On Wed, 13 Dec 2023 23:25:07 +0000, Lew Pitcher wrote:

> On Wed, 13 Dec 2023 21:16:49 +0000, root wrote:
>
>> My son taught me an easy way to rebuild the boot sector when it has
>> been wiped (always because my error).
>>
>> Using another system, such as LiveSlack, load the drive with the
>> damaged sector into, say, mountpoint.
>>
>> cd mountpoint
>> mount --bind /sys sys
>> mount --bind /proc proc
>> mount --bind /dev dev
>> chroot mountpoint
>> lilo
>
> That seems a bit overly complicated.
>
> I've used a similar, but trimmed down, procedure
> 1) live boot
> 2) mount your host directories under the live boot /mnt directory
> 3) cd /mnt && chroot .
> 4) lilo
>
> You don't need the bind mounts.

Or even easier:

1) live boot
2) below /mnt mount / partition and possibly any /boot partition
3) lilo -r /mnt

Now, looking at the manual page of lilo it seems as if the dev directory
also would be needed, but I don't have any memory of doing a bind mount
of dev in such situations. However it might have been some years since I
did this the last time.

regards Henrik

On 12/14/23 00:51, Henrik Carlqvist wrote:
> Now, looking at the manual page of lilo it seems as if the dev directory
> also would be needed,

That's been my experience.

But it's been a long time and the need for /dev may be handled by if
Slackware is using devfs or static dev files.

If the static dev files exist in the /dev directory of the root file
system, they would become available under /mnt/dev and probably suffice
for what lilo wants.

chrooting probably also needs /proc.

I'm not sure how GRUB changes any of this.

--
Grant. . . .

On Thu, 14 Dec 2023 08:42:45 -0600, Grant Taylor wrote:

> On 12/14/23 00:51, Henrik Carlqvist wrote:
>> Now, looking at the manual page of lilo it seems as if the dev directory
>> also would be needed,
>
> That's been my experience.
>
> But it's been a long time and the need for /dev may be handled by if
> Slackware is using devfs or static dev files.
>
> If the static dev files exist in the /dev directory of the root file
> system, they would become available under /mnt/dev and probably suffice
> for what lilo wants.
>
> chrooting probably also needs /proc.

You may be right, but then again....

Long ago, I settled on a system recovery process that involved booting
from a Slackware "live" install disk, and using chroot to gain root fs
access to my hard disks. I've used this on and off over the last 20
years. It never occurred to me that such a chroot()ed environment might
also require bind mounts to fix up /proc, /sys, and especially /dev.
In my experience, I've never needed to do so.

/proc and /sys are simple: for most things, you don't need them in the
chrooted environment. Or, perhaps, you only need them when something
/explicitly/ references /proc or /sys; implicit references, such as
mount() calls, work because the overall system still supplies a
referencible source, under the covers.

But /dev is a different kettle of fish. You need the files in /dev
in your chroot()ed environment in order to run lilo (or any other
boot-loader setup tool).

In my recovery process, I've never had to bind mount /dev before
chrooting. And, with your post, I started to wonder why.

I've come to the conclusion that, because of my upgrade process,
I've got a pre-populated /dev that udev then mounts it's tmpfs
over top of. When I installed my first systems, a requisite
package (in 14.1, it is devs-2.3.1-noarch-25.txz) contains both
static /dev entries, and a script to recreate those entries. My
upgrade process has carried this (hidden by udev) /dev directory
forward all these years, giving me a prepopulated /static/ /dev
directory when I chroot from the "live media" boot.

And, that solves that quandry.
:-)
--
Lew Pitcher
"In Skills We Trust"

On Fri, 15 Dec 2023 14:22:40 -0000 (UTC), Lew Pitcher wrote:

> I've come to the conclusion that, because of my upgrade process,
> I've got a pre-populated /dev that udev then mounts it's tmpfs over top
> of. When I installed my first systems, a requisite package (in 14.1, it
> is devs-2.3.1-noarch-25.txz) contains both static /dev entries, and a
> script to recreate those entries. My upgrade process has carried this
> (hidden by udev) /dev directory forward all these years, giving me a
> prepopulated /static/ /dev directory when I chroot from the "live media"
> boot.

https://www.baeldung.com/linux/bind-mounts

under heading 4.1

i did this on my slackware 15 machine (i think it was a slackware 15 beta
initially not a 14.2)

mount --bind / /mnt/hd
cd /mnt/hd/dev
ls

and there are 2607 lines output from ls -al !! :)

On 12/15/23 08:22, Lew Pitcher wrote:
> Long ago, I settled on a system recovery process that involved booting
> from a Slackware "live" install disk, and using chroot to gain root fs
> access to my hard disks.

N.B. chroot isn't required to access the files on the system being
rescued from the rescue media.

Simply mounting the file system somewhere and then `cd`ing to it is
sufficient to access the files.

`chroot`ing gives a different type of access that seems much more like
the system being recovered normally has. At least from a file path
perspective.

> I've used this on and off over the last 20 years. It never occurred to
> me that such a chroot()ed environment might also require bind mounts
> to fix up /proc, /sys, and especially /dev. In my experience, I've
> never needed to do so.

It's not that chroot needs the bind mount. It is that things used
inside the chroot (and maybe the chroot process itself) need access to
specific files inside of /dev in the chroot.

Those files can easily be provided by static files or even another devfs
(like) mount.

It's just that it's often viewed as easiest to inherit the files from
the real /dev inside of the chroot via a bind mount.

> /proc and /sys are simple: for most things, you don't need them in the
> chrooted environment. Or, perhaps, you only need them when something
> /explicitly/ references /proc or /sys; implicit references, such as
> mount() calls, work because the overall system still supplies a
> referencible source, under the covers.

Yep.

I've gotten away with `chroot`ing many times without anything in /proc
or /sys in the chroot. It is highly dependent on what you are wanting
to do inside of the chroot.

> But /dev is a different kettle of fish. You need the files in /dev
> in your chroot()ed environment in order to run lilo (or any other
> boot-loader setup tool).

Yep. You need the contents. How the contents get there / are created
doesn't matter as long as things can find needed files at the dev<file>
name that they are expecting.

I'm I-remember-using-mknod-in-dev-to-get-new-hardware-to-work old.

> In my recovery process, I've never had to bind mount /dev before
> chrooting. And, with your post, I started to wonder why.

For a very long time Slackware had (enough) static files in dev to bring
a system up to single user mode. For much of it's history it was all
static files in dev. I don't know Slackware's current state about files
in dev.

> I've come to the conclusion that, because of my upgrade process,
> I've got a pre-populated /dev that udev then mounts it's tmpfs
> over top of.

That seems reasonable to me.

> When I installed my first systems, a requisite package (in 14.1, it
> is devs-2.3.1-noarch-25.txz) contains both static /dev entries, and a
> script to recreate those entries. My upgrade process has carried this
> (hidden by udev) /dev directory forward all these years, giving me
> a prepopulated /static/ /dev directory when I chroot from the "live
> media" boot.

Yep.

> And, that solves that quandry.
> :-)

:-)

--
Grant. . . .

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> I've come to the conclusion that, because of my upgrade process,
> I've got a pre-populated /dev that udev then mounts it's tmpfs

udev no longer mounts any dev or tmp file systems, unless I'm mistaken
(quite possible). I think it has been demoted to only adjusting
permissions, renaming network interface names, and whatever else its
udev rules can do. Now there is devtmpfs, and it's only the kernel
that's involved in mounting a tmpfs and populating it with device nodes,
that done early in boot to avoid a "cold plug" or chicken and egg
between what userland udevd needs and provides:

https://lwn.net/Articles/330985/
https://lwn.net/Articles/331818/

On Wed, 13 Dec 2023 21:16:49 -0000 (UTC), root wrote:

> or grub-install, whatever.

Since I almost always use Grub, I would likely try this:

grub-install --recheck --boot-directory <path to root> <boot device>

Here's a scenario:

-You have a Slackware installation which no longer boots. You believe
this to be due to a damaged boot sector.

-You boot a different Slackware installation in such a way that you
can "see" the device of the broken Slackware. I would do this using
Slackware on a bootable flashdrive, but I imagine this could be done in
other ways.

-You find your broken Slackware installation at /dev/sda1, and you
mount it at /mnt/to.

-Wipe the boot sector. This is a precaution and may not be needed:

dd if=/dev/zero of=/dev/sda bs=512 count=1

-This will install Grub to the MBR of /dev/sda (not /dev/sda1 !):

grub-install --recheck --boot-directory /mnt/to /dev/sda

Here is some discussion:

-I'm using "--boot-directory /mnt/to" instead of
"--boot-directory=/mnt/to". I think the syntax you will find in
documentation is the latter, but it seems I have been successful in using
a different syntax.

-I think you can actually use "/dev/sda1" for <boot device>, but I'm
not sure. I don't ever do that, and I think there is a reason. I think
if you did, then your BIOS wouldn't see the boot instructions when it
boots your system. Perhaps the use of /dev/sda1 would be useful for
"boot chaining".

-For this to work in a "turn key" fashion you will need a Grub
configuration file. Grub exects to find it in the directory named by
"--boot-directory" at "boot/grub/grub.cfg". For example, in the above
scenario that would be here:

/mnt/to/boot/grub/grub.cfg

I think you can still boot without a grub.cfg file, but you will need to
know what to type at the Grub command line. That is a very interesting
and useful subject, but I will not address it here.

Here is a sample grub.cfg file with one stanza (0):

default='0'
timeout='3'
menuentry 'Slackware Linux on prodesk'{
ROOT=220506aa1Drive

search --label --set root $ROOT
echo 'Loading Linux kernel ...'
linux /boot/vmlinuz-generic ro root=LABEL=$ROOT \
rootfs=ext4 quiet
echo 'Loading initial ramdisk ...'
echo 'Starting Slackware Linux ...'
initrd /boot/initrd.gz
}

This assumes the root that you are booting has an ext4 filesystem and a
LABEL of "220506aa1Drive". And it assumes you have a suitable initrd.gz
at (per the above scenario) /mnt/to/boot/initrd.gz. Of course the use of
an initrd.gz is not always needed--this is the subject of another
discussion. If yours is not needed, just omit that line from the
corresponding stanza.

Also I recommend, although it isn't always needed, that your fstab (at /
mnt/to/etc/fstab in the above scenario) refers to the devices to mount
and use as swap by LABEL= names like this:

LABEL=220506aa1Drive / ext4 defaults,noatime,errors=panic 0 1
LABEL=220506aa2Swap swap swap defaults,noatime 0 0

Per this example, you will need to give your swap partition a label of
"220506aa2Swap", and I already mentioned above that you need to give the
root partition a LABEL also. The other details of your fstab are, of
course, up to you!

Note that the LABEL syntax is not always needed in either of the fstab
file nor the grub stanza, but I will not discuss the exceptions here.
What I have described is not always the least work to setup, but for me
it is the most robust and understandable way.

If you're going to use Grub you will beneifit from knowing:

-The above scenario defines a 3 second timeout. That means when
booting you have 3 seconds to press a key to interupt the booting.

-Once interupted you can:

-Use the up and down arrows to choose other stanzas, if any.

-Press "e" to make temporary edits to the booting instructions or
"c" to get a Grub command line. The "escape" key returns you to the Grub
menu.

-Press the "enter" key to run the selected stanza.

I hope this helps!

-Joe

On Thu, 14 Dec 2023 08:42:45 -0600, Grant Taylor wrote:

> I'm not sure how GRUB changes any of this.

Hello,

I guess I'm late to the party.

I posted a message--as a reply to the O.P.--explaining how I would use
Grub.

-Joe

On Fri, 22 Dec 2023 00:26:54 +0000, Joseph Rosevear wrote:
> dd if=/dev/zero of=/dev/sda bs=512 count=1

Be careful with that one, at least with good old MBR partition style
those first 512 bytes will not only contain the MBR code to boot but also
the partition table. However, with a GPT partition table the first 512
bytes will only contain boot code.

regards Henrik

On 12/22/23 00:24, Henrik Carlqvist wrote:
> On Fri, 22 Dec 2023 00:26:54 +0000, Joseph Rosevear wrote:
>> dd if=/dev/zero of=/dev/sda bs=512 count=1
>
> Be careful with that one, at least with good old MBR partition style
> those first 512 bytes will not only contain the MBR code to boot but also
> the partition table. However, with a GPT partition table the first 512
> bytes will only contain boot code.

I thought that:

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

was supposed to recover a borked boot sector.

Rinaldi

On Fri, 22 Dec 2023 06:24:32 -0000 (UTC), Henrik Carlqvist wrote:

> On Fri, 22 Dec 2023 00:26:54 +0000, Joseph Rosevear wrote:
>> dd if=/dev/zero of=/dev/sda bs=512 count=1
>
> Be careful with that one, at least with good old MBR partition style
> those first 512 bytes will not only contain the MBR code to boot but
> also the partition table. However, with a GPT partition table the first
> 512 bytes will only contain boot code.
>
> regards Henrik

Thank you!

I apologize for posting something that could cause someone to lose data.

On reviewing my notes I did, in fact, find words that warn of the above
deleting the partition table. Generally, I use the above when preparing
a new drive for a cloned installation of Slackware. I don't remember the
sequence of steps, but it seems I would follow the above with the making
of partitions. Now I'm curious regarding the details of my use of the
above. I'll have to examine my scripts to see what they do.

I also found in my notes a reference to having to remake my partions
after doing the above. I knew how to remake them exactly as before, and
no data was lost.

The reason I suggested the optional use of the above is that, for reasons
I don't understand, the above wipe has sometimes been needed to make a
device bootable. The grub-install command alone wasn't always
sufficient. Generally, I think this happened when I was reusing a drive
that had previously been used in some capacity, perhaps as a bootable
drive--I don't remember.

I would like to understand this better.

I did find, just now, in my notes that the partition information begins
*after* the first 446 bytes which is for the bootstrap code. And I have
in the past used a wipe like the above, but using "bs=446". It seems
that that is what I *should* have written in my post. So I'll give it
here:

dd if=/dev/zero of=/dev/sda bs=446 count=1

Understand that I provided the wiping step as precaution that "may not be
needed".

Please, any who tries this, be careful and backup your MBR first.

Also--thanks for the information, I didn't know that (as you wrote) a GPT
partition has only boot code in the first 512 bytes. So it seems that my
original instructions are OK in that case. (I didn't expect this to be
so complex!)

-Joe