Discussion:
Boot up FLASH media creation?
(too old to reply)
Tuxedo
2018-09-07 08:31:18 UTC
Permalink
Hello,

Within Slackware's setup and right after the slackware install procedure
from USB to HD was completed, the option to MAKE USB FLASH BOOT step was
returned and done.

Now the system is installed on the HD, and booting from LILO via MBR and
/boot sector works, but when testing the Flash USB, the system does not boot
from for some reason. The Flash boot begins and stops or simply hangs midway
with some non-descriptive messages, maybe because the USB was created before
the subsequent mkinitrd procedure of the Slackware HD installation?

Booting from USB will be needed next to reinstall LILO after having
installed Windows on another partition, as of course the Windows installer
will then overwrite the MBR.

Having completed the Slackware installation, can the same Flash USB creation
utility that is available via the setup program on a Slackware installation
USB be launched from within the now ready installed Slackware on the HD? If
so, what is the command?

Or is it necessary to start the setup program via the Slackware install USB
and re-run CONFIGURE, discarding various other steps until reaching the USB
Flash creation step again?

Currently, elilo.conf on the Flash USB appears as follows:

chooser=simple
message=message.txt
delay=300
timeout=300
#
image=/vmlinuz
label=huge.s
read-only
append="root=/dev/cryptvg/root vga=normal ro"


While the current and working /etc/lilo.conf on the installed Slackware
appears as follows:

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
lba32 # Allow booting past 1024th cylinder with a recent BIOS
boot = /dev/nvme0n1

#compact # faster, but won't work on all systems.

# Append any additional kernel parameters:
append=" "
prompt
timeout = 50
vga = normal

# Linux bootable partition config begins
image = /boot/vmlinuz-generic-4.14.67
initrd = /boot/initrd.gz
root = /dev/cryptvg/root
label = Linux
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends

Many thanks for any ideas!
Tuxedo
Tuxedo
2018-09-08 08:08:56 UTC
Permalink
Hello again,

I will need to log into the existing Slackware installation after the MBR
will have been swiped by a subseqent Windows intllation, but as the Flash-
boot creation during Slackware's installation failed, or in fact created a
USB-stick which results in a kernel error when booting from it, I'm not sure
how get into the system after.

Not having installed Windows yet and while still being logged in to the
Slackware system, can the procedure at /var/log/setup/setup.80.make-bootdisk
be used to create a USB-stick that can later enter the installed Slackware?
Or is this application only usable via the setup installer program on an
installation media?

I tried running the script on the system that will need the temporary boot
media, but NO NEW DEVICE was detected, although I added and mounted a new
USB-stick beforehand. On a different Slackware system, however, the
application detected a new USB but failed to install the booting utilities
on it for some reason.

Alternatively, what other ways to reinstall LILO for an already installed
Slackware after having lost the MBR to Windows exist?

Is there for example some live distro that can be used to redirect to the
/boot sector?

Whatever Slackware installed onto the MBR during setup will simply need to
be repeated, but after adding Windows to LILO's menu options.

Many thanks,
Tuxedo
Ars Ivci
2018-09-08 08:34:41 UTC
Permalink
Post by Tuxedo
Hello again,
I will need to log into the existing Slackware installation after the MBR
will have been swiped by a subseqent Windows intllation, but as the Flash-
boot creation during Slackware's installation failed, or in fact created a
USB-stick which results in a kernel error when booting from it, I'm not sure
how get into the system after.
Not having installed Windows yet and while still being logged in to the
Slackware system, can the procedure at /var/log/setup/setup.80.make-bootdisk
be used to create a USB-stick that can later enter the installed Slackware?
Or is this application only usable via the setup installer program on an
installation media?
If I remember correctly, you can run "pkgtool" as root from a terminal
and it will allow you to run any of the install scripts again (should be
the "setup" option in the menu of pkgtool in your case).

peace,
t.
Tuxedo
2018-09-08 20:45:30 UTC
Permalink
Ars Ivci wrote:

[...]
Post by Ars Ivci
If I remember correctly, you can run "pkgtool" as root from a terminal
and it will allow you to run any of the install scripts again (should be
the "setup" option in the menu of pkgtool in your case).
pkgtool -> Setup -> make-bootdisk is indeed there.

Maybe it's the same as running /var/log/setup/setup.80.make-bootdisk as
root.

In either case, no new USB devices is detected, although there is a USB
media plugged in. I tried several new medias with and without mounting them
first.

Maybe I need run the Slackware installer from scratch or try and patch the
existing USB startup media somehow, which uses the huge.s kernel to
initially boot but then there is some kind of kernel panic in the beginning.

In any case, pkgtool is useful to know.

Thanks for the tip.

Tuxedo
Ars Ivci
2018-09-08 21:28:10 UTC
Permalink
Post by Tuxedo
[...]
Post by Ars Ivci
If I remember correctly, you can run "pkgtool" as root from a terminal
and it will allow you to run any of the install scripts again (should be
the "setup" option in the menu of pkgtool in your case).
pkgtool -> Setup -> make-bootdisk is indeed there.
Maybe it's the same as running /var/log/setup/setup.80.make-bootdisk as
root.
It should be the same. There must be a direct command as well, like
"makebootdisk" but am not sure, try running makebootdisk as root (doubt
it will change anything, though).
Post by Tuxedo
In either case, no new USB devices is detected, although there is a USB
media plugged in. I tried several new medias with and without mounting them
first.
You should insert it after the system asks for it, not before. Sorry, I
do not have access to a Slackware system so I cannot try beforehand.

t.
Tuxedo
2018-09-09 06:39:11 UTC
Permalink
Ars Ivci wrote:

[...]
Post by Ars Ivci
You should insert it after the system asks for it, not before. Sorry, I
do not have access to a Slackware system so I cannot try beforehand.
Thanks for this vital bit of infomration! Indeed, it works to create a USB
boot stick.

Unfortunately the new stick has the same boot error as the previous, in that
there's a kernel panic: "RIP: 0010:panic-0x107/0x228" followed by a
screenfull of characters and numbers and ending with ---[end trace
988c6a1ca11768ex]---

elilo.conf on the newly created startup USB appears as follows:


------------ USBSLACK/EFI/BOOT/elilo.conf -----------
chooser=simple
message=message.txt
delay=300
timeout=300

image=/vmlinuz
label=huge.s
read-only
append="root=/dev/cryptvg/root vga=normal ro"

-----------------------------------------------------


/etc/lilo.conf on the installed Slackware which boots fine,
appears as follows:

---------

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
lba32 # Allow booting past 1024th cylinder with a recent BIOS
boot = /dev/nvme0n1

#compact # faster, but won't work on all systems.

# Append any additional kernel parameters:
append=" "
prompt
timeout = 50
vga = normal

# Linux bootable partition config begins
image = /boot/vmlinuz-generic-4.14.67
initrd = /boot/initrd.gz
root = /dev/cryptvg/root
label = Linux
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends

---------

I have a different and older Slackware 14.2 installation on another laptop
which I just tested to create a startup stick with according to the same
procedure and the stick thereafter works fine to boot with on that system.

This same stick does not work to boot the new installation however (as can
be expected). I guess there are different versions kernels.

Maybe I should re-run the whole Slackware installation in case something
went wrong with the setup which causes the error with the startup USB into
new installation.

Does anyone here know the steps to manually create a startup media?

Tuxedo
Pascal Hambourg
2018-09-09 10:58:56 UTC
Permalink
Post by Tuxedo
Unfortunately the new stick has the same boot error as the previous, in that
there's a kernel panic: "RIP: 0010:panic-0x107/0x228" followed by a
screenfull of characters and numbers and ending with ---[end trace
988c6a1ca11768ex]---
May I ask why you set up the USB drive for EFI boot with elilo whereas
you set up the main drive for legacy boot with lilo ?
Post by Tuxedo
------------ USBSLACK/EFI/BOOT/elilo.conf -----------
chooser=simple
message=message.txt
delay=300
timeout=300
image=/vmlinuz
label=huge.s
read-only
append="root=/dev/cryptvg/root vga=normal ro"
-----------------------------------------------------
As already explained, an initrd is mandatory when the root device is
based on software RAID, LVM and/or LUKS. Otherwise you will get a kernel
panic because the root device does not exist.
Pascal Hambourg
2018-09-09 14:14:20 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
------------ USBSLACK/EFI/BOOT/elilo.conf -----------
chooser=simple
message=message.txt
delay=300
timeout=300
image=/vmlinuz
         label=huge.s
         read-only
         append="root=/dev/cryptvg/root vga=normal ro"
-----------------------------------------------------
As already explained, an initrd is mandatory when the root device is
based on software RAID, LVM and/or LUKS. Otherwise you will get a kernel
panic because the root device does not exist.
One precision :
An initrd may be embedded into the kernel image so it is not necessary
to load a separate initrd file, but it must be generic enough to open
the LUKS container and activate the root LV.
Tuxedo
2018-09-09 15:32:56 UTC
Permalink
Pascal Hambourg wrote:

[...]
Post by Pascal Hambourg
Post by Pascal Hambourg
Post by Tuxedo
-----------------------------------------------------
As already explained, an initrd is mandatory when the root device is
based on software RAID, LVM and/or LUKS. Otherwise you will get a kernel
panic because the root device does not exist.
An initrd may be embedded into the kernel image so it is not necessary
to load a separate initrd file, but it must be generic enough to open
the LUKS container and activate the root LV.
I'm not sure why the boot stick is created in the way it is so the current
Slackware installation doesn't start from it, or why EFI booting is used.

The previous Slackware (14.2/64 bit) system, where booting from USB works
fine, has the following files on the stick:

A directory named USBSLACK

drwx------ 3 tuxedo users 2048 Sep 8 23:27 EFI
-rw-r--r-- 1 tuxedo users 653 Sep 8 23:27 f1.txt
-r--r--r-- 1 tuxedo users 37888 Sep 8 23:27 ldlinux.sys
-rw-r--r-- 1 tuxedo users 685 Sep 8 23:27 message.txt
-rw-r--r-- 1 tuxedo users 234 Sep 8 23:27 syslinux.cfg
-rw-r--r-- 1 tuxedo users 7635952 Sep 8 23:27 vmlinuz

The EFI directory contains a BOOT directory:

drwx------ 2 tuxedo users 2048 Sep 8 23:27 BOOT

The BOOT directorry contains the following files:
-rw-r--r-- 1 tuxedo users 239720 Sep 8 23:27 BOOTX64.EFI
-rw-r--r-- 1 tuxedo users 159 Sep 8 23:27 elilo.conf
-rw-r--r-- 1 tuxedo users 618 Sep 8 23:27 message.txt

The bios of the harware is set to UEFI/Legacy Boot, with Legacy first.

The elilo.conf above contains:

chooser=simple
message=message.txt
delay=300
timeout=300
#
image=/vmlinuz
label=huge.s
read-only
append="root=/dev/sda2 vga=normal ro"

It appears similar to the newer laptop which fails to boot from USB, the
main difference being that the older system does not have an SSD, it has an
older but very similar BIOS version and not the most up-to-date kernel. It's
also Slackware 14.2 and 64 bit.

Also, the older system does not have a separate boot partition as the root
file system does not need it, since the Slackware installation is
unencrypted and only the home partiton is encrypted. And there's no LVM
setup.

Relevant parts in /etc/lilo.conf on the old system are:

boot = /dev/sda
image = /boot/vmlinuz
root = /dev/sda2


The USBSLACK stick created on the new system includes a same file structure:

drwx------ 3 tuxedo users 2048 Sep 9 08:04 EFI
-rw-r--r-- 1 tuxedo users 652 Sep 9 08:04 f1.txt
-r--r--r-- 1 tuxedo users 37888 Sep 9 08:04 ldlinux.sys
-rw-r--r-- 1 tuxedo users 696 Sep 9 08:04 message.txt
-rw-r--r-- 1 tuxedo users 264 Sep 9 08:04 syslinux.cfg
-rw-r--r-- 1 tuxedo users 8853264 Sep 9 08:04 vmlinuz


With the EFI directory containing a BOOT directory containing these files:
-rw-r--r-- 1 tuxedo users 238531 Sep 9 08:04 BOOTX64.EFI
-rw-r--r-- 1 tuxedo users 174 Sep 9 08:04 elilo.conf
-rw-r--r-- 1 tuxedo users 630 Sep 9 08:04 message.txt

And with elilo.conf on the stick containing the following:

chooser=simple
message=message.txt
delay=300
timeout=300
#
image=/vmlinuz
label=huge.s
read-only
append="root=/dev/mapper/cryptvg-root vga=normal ro"


On the new system /etc/lilo.conf contains:

lba32 # Allow booting past 1024th cylinder with recent BIOS
boot = /dev/nvm0n1
image = /boot/vmlinuz-generic-4.14.67
initrd = /boot/initrd.gz
root = /dev/cryptvg/root

The newer system is fully encrypted with the LVM setup and starts fine
except when trying to boot via USB startup media.

Tuxedo
Tuxedo
2018-09-09 15:51:43 UTC
Permalink
Tuxedo wrote:

[...]
The bios of the hardware is set to UEFI/Legacy Boot, with Legacy first.
Both systems are configured in the bios the same way. But maybe UEFI is what
takes effect, I'm not sure.

Tuxedo
Pascal Hambourg
2018-09-09 21:07:52 UTC
Permalink
Post by Tuxedo
The previous Slackware (14.2/64 bit) system, where booting from USB works
fine
(...)
(...)
Post by Tuxedo
image=/vmlinuz
label=huge.s
read-only
append="root=/dev/sda2 vga=normal ro"
(...)
Post by Tuxedo
Also, the older system does not have a separate boot partition as the root
file system does not need it, since the Slackware installation is
unencrypted and only the home partiton is encrypted. And there's no LVM
setup.
The root filesystem is in a plain partition, so mounting it does not
require an initrd if the root= parameter is set with the device name or
the partition UUID (PARTUUID). This explains why booting works fine
without an initrd.

Note however that setting root=/dev/sd* is not reliable because /dev/sd*
device names are not persistent across reboots when there are more than
one drive. A USB stick counts as one. By default the kernel delays the
detection of USB mass storage devices in order to give precedence to ATA
or SCSI devices, but sometimes it happens that the USB device is
detected first anyway and gets /dev/sda instead of the internal drive.

This is why many distributions use filesystem UUIDs in the root=
parameter. But the kernel does not know anything about filesystem UUIDs,
so an initrd must be used to search and mount the root filesystem by UUID.
Tuxedo
2018-09-09 21:53:36 UTC
Permalink
Pascal Hambourg wrote:

[...]
Post by Pascal Hambourg
The root filesystem is in a plain partition, so mounting it does not
require an initrd if the root= parameter is set with the device name or
the partition UUID (PARTUUID). This explains why booting works fine
without an initrd.
Note however that setting root=/dev/sd* is not reliable because /dev/sd*
device names are not persistent across reboots when there are more than
one drive. A USB stick counts as one. By default the kernel delays the
detection of USB mass storage devices in order to give precedence to ATA
or SCSI devices, but sometimes it happens that the USB device is
detected first anyway and gets /dev/sda instead of the internal drive.
This is why many distributions use filesystem UUIDs in the root=
parameter. But the kernel does not know anything about filesystem UUIDs,
so an initrd must be used to search and mount the root filesystem by UUID.
So the root=/dev/sd2 setting may not be ideal. However, the old system is a
single drive system and having used it for over a year I've so far not had
any issues in booting it even while external USB/SD media were attached.

It's good to know however in case boot failures may happen.

Thanks for the info.

Tuxedo
Tuxedo
2018-09-09 21:21:26 UTC
Permalink
Post by Pascal Hambourg
Post by Pascal Hambourg
Post by Tuxedo
------------ USBSLACK/EFI/BOOT/elilo.conf -----------
chooser=simple
message=message.txt
delay=300
timeout=300
image=/vmlinuz
label=huge.s
read-only
append="root=/dev/cryptvg/root vga=normal ro"
-----------------------------------------------------
As already explained, an initrd is mandatory when the root device is
based on software RAID, LVM and/or LUKS. Otherwise you will get a kernel
panic because the root device does not exist.
An initrd may be embedded into the kernel image so it is not necessary
to load a separate initrd file, but it must be generic enough to open
the LUKS container and activate the root LV.
Sorry, I wasn't paying attention in my earlier reply to the above points in
your message.

As far as I understand, the reason the boot stick creation and use of the
resulting stick on the previous system with an unencrypted Slackware works
is that on that system the initrd can load, but not so on the fully
encrypted system, so it has to be reconfigured on the new system with LVM
and LUKS.

I guess Slackware's boot disk creation tool does take this type of
configuration into account automatically.

The initrd.gz and initrd-tree was created to make regular booting work on
the new system, so I guess it's not needed to create new such files to be
placed directly on USB boot media?

The files that already exist on the installed system in the unecrypted /boot
partition (/dev/nvme0n1p2) are:

lrwxrwxrwx 1 root root 23 Sep 5 23:32 System.map -> System.map-
huge-4.14.67
-rw-r--r-- 1 root root 3318666 Aug 24 23:03 System.map-generic-4.14.67
-rw-r--r-- 1 root root 4651340 Aug 24 23:02 System.map-huge-4.14.67
-rw-r--r-- 1 root root 512 Sep 6 01:02 boot.10300
-rw-r--r-- 1 root root 136 Sep 5 12:36 boot_message.txt
-rw-r--r-- 1 root root 426 Apr 13 15:08 coffee.dat
lrwxrwxrwx 1 root root 19 Sep 5 23:32 config -> config-huge-4.14.67
-rw-r--r-- 1 root root 180604 Aug 24 23:02 config-generic-4.14.67.x64
-rw-r--r-- 1 root root 180604 Aug 24 22:59 config-huge-4.14.67.x64
-rwxr-xr-x 1 root root 216219 Jun 12 20:49 elilo-ia32.efi
-rwxr-xr-x 1 root root 238531 Jun 12 21:01 elilo-x86_64.efi
drwxr-xr-x 2 root root 1024 Apr 13 15:09 grub
drwxr-xr-x 14 root root 1024 Sep 6 00:20 initrd-tree
-rw-r--r-- 1 root root 10613264 Sep 6 00:40 initrd.gz
-rw-r--r-- 1 root root 22578 Apr 13 15:08 inside.bmp
-rw-r--r-- 1 root root 432 Apr 13 15:08 inside.dat
drwx------ 2 root root 12288 Sep 5 11:35 lost+found
-rw------- 1 root root 175104 Sep 6 23:26 map
-rw-r--r-- 1 root root 6878 Apr 13 15:08 onlyblue.bmp
-rw-r--r-- 1 root root 424 Apr 13 15:08 onlyblue.dat
-rw-r--r-- 1 root root 15634 Mar 27 2011 slack.bmp
-rw-r--r-- 1 root root 33192 Apr 13 15:08 tuxlogo.bmp
-rw-r--r-- 1 root root 423 Apr 13 15:08 tuxlogo.dat
lrwxrwxrwx 1 root root 20 Sep 5 23:32 vmlinuz -> vmlinuz-
huge-4.14.67
lrwxrwxrwx 1 root root 23 Sep 5 12:17 vmlinuz-generic -> vmlinuz-
generic-4.14.67
-rw-r--r-- 1 root root 5625616 Aug 24 23:03 vmlinuz-generic-4.14.67
lrwxrwxrwx 1 root root 20 Sep 5 12:17 vmlinuz-huge -> vmlinuz-
huge-4.14.67
-rw-r--r-- 1 root root 8853264 Aug 24 23:02 vmlinuz-huge-4.14.67

Does the contents on boot stick need to be changed to boot from it or would
only elilo.conf on the boot stick need to reference initrd.gz on the /boot
partition, maybe just by adding:

initrd = /boot/initrd.gz

I'm not sure how to embed an initrd into the kernel image? If it's only
useful in the odd sitiation where a USB start-up media is needed, I guess
it's not important to keep it in the kernel, so a separate initrd file could
be fine?

Thanks for any suggestions.

Tuxedo
Pascal Hambourg
2018-09-09 22:12:35 UTC
Permalink
Post by Tuxedo
As far as I understand, the reason the boot stick creation and use of the
resulting stick on the previous system with an unencrypted Slackware works
is that on that system the initrd can load
No. Booting the previous system does not require an initrd because the
kernel can mount the root filesystem itself.

Booting the new system does require an initrd because the kernel cannot
open a LUKS device and activate an LVM logical volume itself. The boot
loader is responsible for loading the kernel and the initrd, but the USB
stick boot loader configuration does not specify an initrd.
Post by Tuxedo
Does the contents on boot stick need to be changed to boot from it or would
only elilo.conf on the boot stick need to reference initrd.gz on the /boot
initrd = /boot/initrd.gz
Either. In any case you must indicate the right path in the initrd
option. However I think that it is safer to copy the initrd file to the
actual boot drive.
Post by Tuxedo
I'm not sure how to embed an initrd into the kernel image?
This can only be done at kernel build time.
I was just mentioning the possibility that Slackware may provide a stock
kernel embedding a generic initrd with LUKS and LVM support, so that
loading an additional initrd would not be required.
Tuxedo
2018-09-09 22:51:32 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
As far as I understand, the reason the boot stick creation and use of the
resulting stick on the previous system with an unencrypted Slackware
works is that on that system the initrd can load
No. Booting the previous system does not require an initrd because the
kernel can mount the root filesystem itself.
Thanks for clarifying. I got it :-)
Post by Pascal Hambourg
Booting the new system does require an initrd because the kernel cannot
open a LUKS device and activate an LVM logical volume itself. The boot
loader is responsible for loading the kernel and the initrd, but the USB
stick boot loader configuration does not specify an initrd.
Post by Tuxedo
Does the contents on boot stick need to be changed to boot from it or
would only elilo.conf on the boot stick need to reference initrd.gz on
initrd = /boot/initrd.gz
Either. In any case you must indicate the right path in the initrd
option. However I think that it is safer to copy the initrd file to the
actual boot drive.
It sounds like a good way, so I copy the initrd.gz from the /boot directory
of the installed system onto the USBSLACKS media (while mounted as
/run/media/root/USBSLACKS).

Then in elilo.conf on the USBSLACKS stick I think the correct path will be
/initrd.gz

That's how /vmlinuz is referenced in the same path on the USB.

So the elilo.conf on the stick can contain:

chooser=simple
message=message.txt
#
image=/vmlinuz
initrd=/initrd.gz
label=huge.s
read-only
append="root=/dev/mapper/cryptvg-root vga=normal ro"

However, the stick only has 7MB left while initrd.gz is 10.6MB. I don't
understand. The size in /dev/sdc1 shows up as 16M with only 7.7M available
but the stick is supposed to be 16GB. At least that's what's printed on it.
I must try another USB.
Post by Pascal Hambourg
Post by Tuxedo
I'm not sure how to embed an initrd into the kernel image?
This can only be done at kernel build time.
I was just mentioning the possibility that Slackware may provide a stock
kernel embedding a generic initrd with LUKS and LVM support, so that
loading an additional initrd would not be required.
I'm hoping for this to happen in the next release :-)

Tuxedo
Tuxedo
2018-09-09 23:14:41 UTC
Permalink
Tuxedo wrote:

[...]
Post by Tuxedo
However, the stick only has 7MB left while initrd.gz is 10.6MB. I don't
understand. The size in /dev/sdc1 shows up as 16M with only 7.7M available
but the stick is supposed to be 16GB. At least that's what's printed on
it. I must try another USB.
I tested another 16GB USB stick but after running pkgtool to make it
Slackware bootable, it appears that it shrunk. It's not possible to have the
'vmlinuz' kernel and 'initrd.gz' files on the media (3MB short of space).

So I tried referencing the path on the SSD as in 'initrd=/boot/initrd.gz'
but then the same kernel panic as before happened.

This is how elilo.conf appears on the stick:

chooser=simple
message=message.txt
#
image=/vmlinuz
label=huge.s
initrd=/boot/initrd.gz
read-only
append="root=/dev/mapper/cryptvg-root vga=normal ro"

Is the initrd.gz file perhaps requested before /boot has mounted?

Any ideas what to try?

Tuxedo
Pascal Hambourg
2018-09-10 05:55:13 UTC
Permalink
Post by Tuxedo
Post by Tuxedo
However, the stick only has 7MB left while initrd.gz is 10.6MB. I don't
understand. The size in /dev/sdc1 shows up as 16M with only 7.7M available
but the stick is supposed to be 16GB.
Can't you extend the partition and its filesystem ?
Post by Tuxedo
So I tried referencing the path on the SSD as in 'initrd=/boot/initrd.gz'
but then the same kernel panic as before happened.
chooser=simple
message=message.txt
#
image=/vmlinuz
label=huge.s
initrd=/boot/initrd.gz
read-only
append="root=/dev/mapper/cryptvg-root vga=normal ro"
Is the initrd.gz file perhaps requested before /boot has mounted?
Yes it is. The bootloader does not mount anything.
Boot loader boots.
Boot loader loads kernel and initrd
Boot loader starts kernel
Kernel mounts extracts and mounts initrd
Kernel+initrd mount /
Kernel+initrd mount /boot and other filesystems

I don't know how elilo works. Does it hardcode the blocklist location of
files at install time like lilo does or does it read them at run time
(from where) ?
Ars Ivci
2018-09-10 06:08:55 UTC
Permalink
Post by Tuxedo
[...]
Post by Tuxedo
However, the stick only has 7MB left while initrd.gz is 10.6MB. I don't
understand. The size in /dev/sdc1 shows up as 16M with only 7.7M available
but the stick is supposed to be 16GB. At least that's what's printed on
it. I must try another USB.
I tested another 16GB USB stick but after running pkgtool to make it
Slackware bootable, it appears that it shrunk. It's not possible to have the
'vmlinuz' kernel and 'initrd.gz' files on the media (3MB short of space).
Think of this like burning a CD. Slackware burns an image to USB, not
copies it. So, no space remains. Although, I have not done it or heard
it before you can try something like this:
1- Mount the boot USB and copy entire tree.
2- Add initrd to tree
3- Create another ISO (mkisofs??
4- Write that image back to stick.

t.
Tuxedo
2018-09-10 06:52:32 UTC
Permalink
Ars Ivci wrote:

[...]
Post by Ars Ivci
Think of this like burning a CD. Slackware burns an image to USB, not
copies it. So, no space remains. Although, I have not done it or heard
1- Mount the boot USB and copy entire tree.
2- Add initrd to tree
3- Create another ISO (mkisofs??
4- Write that image back to stick.
Thanks for the tip. It sounds complicated, although it's good to have a
usable boot stick in case booting ever goes wrong.

Alternatively, the section "Allow the secondary OS to overwrite LILO and go
back later to manually re-install and re-configure LILO" at
http://docs.slackware.com/slackbook:booting?s[]=initrd
suggest using Slackware's install media to fix the MBR:

"To re-establish LILO after another OS has erased it, you can boot from your
Slackware install media and enter the setup stage. Do not re-partition your
drive or re-install Slackware; skip immediately to Configure."

Unless I learn how to make the magic boot stick I guess it's what I will do.

Tuxedo
Ars Ivci
2018-09-10 08:04:17 UTC
Permalink
Post by Tuxedo
[...]
Post by Ars Ivci
Think of this like burning a CD. Slackware burns an image to USB, not
copies it. So, no space remains. Although, I have not done it or heard
1- Mount the boot USB and copy entire tree.
2- Add initrd to tree
3- Create another ISO (mkisofs??
4- Write that image back to stick.
Thanks for the tip. It sounds complicated, although it's good to have a
usable boot stick in case booting ever goes wrong.
Alternatively, the section "Allow the secondary OS to overwrite LILO and go
back later to manually re-install and re-configure LILO" at
http://docs.slackware.com/slackbook:booting?s[]=initrd
"To re-establish LILO after another OS has erased it, you can boot from your
Slackware install media and enter the setup stage. Do not re-partition your
drive or re-install Slackware; skip immediately to Configure."
Unless I learn how to make the magic boot stick I guess it's what I will do.
Tuxedo
That is the simplest and by far the best option. The (e)lilo config made
no sense to me; huge.s kernel should not need an initrd which is meant
to be used with generic kernels.

t.
Tuxedo
2018-09-10 08:21:51 UTC
Permalink
Ars Ivci wrote:

[...]
Post by Ars Ivci
That is the simplest and by far the best option. The (e)lilo config made
no sense to me; huge.s kernel should not need an initrd which is meant
to be used with generic kernels.
Ok. Thanks. It sounds like the most reasonable and perhaps best way in this
particular situation. That said, Slackware's developers will ideally fix the
USB creation utility for LVM+LUKS including necessary initrd installations.

Tuxedo
Ars Ivci
2018-09-10 09:27:47 UTC
Permalink
Post by Tuxedo
[...]
Post by Ars Ivci
That is the simplest and by far the best option. The (e)lilo config made
no sense to me; huge.s kernel should not need an initrd which is meant
to be used with generic kernels.
Ok. Thanks. It sounds like the most reasonable and perhaps best way in this
particular situation. That said, Slackware's developers will ideally fix the
USB creation utility for LVM+LUKS including necessary initrd installations.
Tuxedo
Maybe huge.s kernel can provide that support built-in in the future.

Other than that, I find this whole process unproductive. It is time to
switch to an installer like Calamares like every distro out there, which
will make partitioning and encrypting a breeze.

t.
Tuxedo
2018-09-11 18:41:46 UTC
Permalink
Ars Ivci wrote:

[...]
Post by Ars Ivci
Other than that, I find this whole process unproductive. It is time to
switch to an installer like Calamares like every distro out there, which
will make partitioning and encrypting a breeze.
Having tried several distros, I prefer Slackware, not for its ease of
installation but for its overall stability. With Slackware I've not had any
conflicts caused by package managers as has often been the case with popular
distros, Debian etc.

With the exception of LVM+LUKS, Slackware's installer is not too
complicated.

Tuxedo
Pascal Hambourg
2018-09-10 20:25:56 UTC
Permalink
Post by Ars Ivci
huge.s kernel should not need an initrd which is meant
to be used with generic kernels.
Do I need to say again that an initrd is not meant only to be used with
"generic" (I guess you mean "modular") kernels but is also required when
the root filesystem is :
- identified by UUID or LABEL instead of device name
- in an LVM logical volume
- in a software RAID array
- in an encrypted volume
and may also be required when :
- using uswsusp (userspace suspend) for hibernation
- /usr is on a separate filesystem
Ars Ivci
2018-09-11 21:16:49 UTC
Permalink
Post by Pascal Hambourg
huge.s kernel should not need an initrd which is meant to be used with
generic kernels.
Do I need to say again that an initrd is not meant only to be used with
"generic" (I guess you mean "modular") kernels but is also required when
- identified by UUID or LABEL instead of device name
- in an LVM logical volume
- in a software RAID array
- in an encrypted volume
- using uswsusp (userspace suspend) for hibernation
- /usr is on a separate filesystem
I stand corrected. You are right, of course.

t.
Pascal Hambourg
2018-09-14 18:12:29 UTC
Permalink
Post by Ars Ivci
Post by Pascal Hambourg
Do I need to say again that an initrd is not meant only to be used
with "generic" (I guess you mean "modular") kernels but is also
- identified by UUID or LABEL instead of device name
- in an LVM logical volume
- in a software RAID array
- in an encrypted volume
- using uswsusp (userspace suspend) for hibernation
- /usr is on a separate filesystem
I stand corrected. You are right, of course.
I forgot to mention :
- when the mass storage or network adapter used to access the /
filesystem requires to load an external firmware.

I remember an old SUN UltraSPARC station with a QLogic SCSI adapter
which required such firmware included in the firmware-qlogic package.
root
2018-09-10 13:59:36 UTC
Permalink
Post by Tuxedo
Thanks for the tip. It sounds complicated, although it's good to have a
usable boot stick in case booting ever goes wrong.
The install disk also serves as a rescue disk.
Read the instructions when you see the original
boot prompt. You can boot into any partition from
the boot disk.

You can also do simple things like create partitions,
mount partitions, edit things with vi without
ever running setup after booting from the install
disk.
Tuxedo
2018-09-14 10:34:08 UTC
Permalink
Post by root
Post by Tuxedo
Thanks for the tip. It sounds complicated, although it's good to have a
usable boot stick in case booting ever goes wrong.
The install disk also serves as a rescue disk.
Read the instructions when you see the original
boot prompt. You can boot into any partition from
the boot disk.
OK. I start up with the install media. Then select "Detect/boot any
installed operating system" and hit enter.

Next I'm prompted to select language and keyboard layout and thereafter I
arrive at the blue "Welcome to Slackware Linux Setup" screen. However, from
here I can't find a way or information on how to log into the already
installed Slackware system existing on one of the partitions of the SSD.

I can run 'setup' which gives me the option to reinstall the system.

Tuxedo


[...]
root
2018-09-14 14:36:14 UTC
Permalink
Post by Tuxedo
Post by root
Post by Tuxedo
Thanks for the tip. It sounds complicated, although it's good to have a
usable boot stick in case booting ever goes wrong.
The install disk also serves as a rescue disk.
Read the instructions when you see the original
boot prompt. You can boot into any partition from
the boot disk.
OK. I start up with the install media. Then select "Detect/boot any
installed operating system" and hit enter.
Next I'm prompted to select language and keyboard layout and thereafter I
arrive at the blue "Welcome to Slackware Linux Setup" screen. However, from
here I can't find a way or information on how to log into the already
installed Slackware system existing on one of the partitions of the SSD.
I can run 'setup' which gives me the option to reinstall the system.
Tuxedo
[...]
At the very first prompt you should see a screen that says:

In a pinch, you can boot your system from here with a command like:

boot: huge.s root=/dev/sda1 rdinit=ro


That screen will sit there with the

boot:

prompt for a couple of minutes oruntil you do something.
In the example above, the
boot:
refers to the boot: prompt so you really only have
to type the rest of the command:

huge.s root=/dev/sdXY rdinit=ro

Where XY is whatever partition you want to boot into.

I can't remember for sure, but I think you boot into
the first partition on M.2 as something like

huge.s root=/dev/nvme0n1p1 rdinit=ro
Tuxedo
2018-09-14 17:53:18 UTC
Permalink
root wrote:

[...]
Thanks for the info. However, I don't see exactly this, maybe because of how
the install disk was initially created (using UNetbootin), or maybe because
of the version of Slackware used. Whichever the case, my initial screen is:

-----------------------------------------------
UNetbootin
Default
huge.s
kms.s
speakup.s
Slackware 15.0 huge.s kernel
Slackware 15.0 huge.s kernel (use KMS console=
Detect/booz any installed operating system

Press [ Tab ] to edit options

Automatic boot in 10 seconds...
-----------------------------------------------

I can press tab and there is an editable command line, with for example the
following:

/ubnkern initrd=/ubninit load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
nomodeset SLACK_KERNEL=huge.s

This is what is pre-inset if I hit tab in relation to the first "Default"
boot option. If for example I select the second "huge.s" option, the command
line appears different, as follows:

/kernels/huge.s/bzImage initrd=/EFI/BOOT/initrd.img load_ramdisk=1
prompt_ramdisk=0 rw printk.time=0 nomodeset SLACK_KERNEL=huge.s

So I presume this is boot command line that need to be edited to boot into
my specific setup.

The unencrypted /boot partition on my installation is at /dev/nvme0n1p2 and
as far as I understand this is accessed first before unlocking the encrypted
LVM /root partition at /dev/nvme0n1p2 (/dev/cryptvg/root), after LILO booted
into /boot via the MBR. However, the MBR is presently ovewritten by the
Windows installer, so I need to boot into the installed Slackware system in
order to run the LILO setup program.
Post by root
boot: huge.s root=/dev/sda1 rdinit=ro
There is no actual "boot:" prompt, just a ">" character at the start of the
above "/ubnkern..." line.

I'm just guessing, that instead of the above command line I type:

huge.s root=/dev/cryptvg/root rdinit=ro

... but that's not doing the trick.... Any suggestions what else I should
try?

Having done the obligatory initrd produre needed for an LVM & LUKS setup,
the relevant files should exist in /boot (boot/initrd.gz, /boot/initrd-
tree/...)

In lilo.conf I there should be the lines:

boot = /dev/nvme0n1

image = /boot/vmlinuz-generic-4.14.67
initrd = /boot/initrd.gz
root = /dev/cryptvg/root
label = Linux
read-only

That's how it appeaed when I last ran lilo and when that had written to the
MBR in a way that worked fine to boot into Slackware, but as mentioned, the
MBR has since been overwritten by the Windows installer.

Any additional suggestions would be greatly appreciated, as it would save me
from making a complete Slackware reinstallation on the encrypted volume. In
any case, it would be useful to know how to boot the system in case
something will ever go wrong with the MBR.

Many thanks,
Tuxedo
Post by root
That screen will sit there with the
prompt for a couple of minutes oruntil you do something.
In the example above, the
refers to the boot: prompt so you really only have
huge.s root=/dev/sdXY rdinit=ro
Where XY is whatever partition you want to boot into.
I can't remember for sure, but I think you boot into
the first partition on M.2 as something like
huge.s root=/dev/nvme0n1p1 rdinit=ro
Pascal Hambourg
2018-09-14 18:27:01 UTC
Permalink
Post by Tuxedo
[...]
Thanks for the info. However, I don't see exactly this, maybe because of how
the install disk was initially created (using UNetbootin), or maybe because
Unetbootin replaces the original boot loader in the image with its own
boot loader.
Post by Tuxedo
Post by root
boot: huge.s root=/dev/sda1 rdinit=ro
(...)
Post by Tuxedo
huge.s root=/dev/cryptvg/root rdinit=ro
... but that's not doing the trick.... Any suggestions what else I should
try?
I do not understand the parameter "rdinit=ro".

rdinit= expects a full pathname inside the initrd and is used to run the
specified executable instead of the default initrd /init. (like init= is
used to run the specified executable on the root filesystem instead of
/sbin/init)

"ro" does not look like a full pathname, and anyway why would you need
to run an alternate initrd init ?
root
2018-09-14 18:55:36 UTC
Permalink
Post by Pascal Hambourg
I do not understand the parameter "rdinit=ro".
As part of the command orginally specified
rdinit=ro
tells the boot loader to load the image read-only.
It is identical to a line in lilo.conf
read-only
Pascal Hambourg
2018-09-14 19:50:22 UTC
Permalink
Post by root
Post by Pascal Hambourg
I do not understand the parameter "rdinit=ro".
As part of the command orginally specified
rdinit=ro
tells the boot loader to load the image read-only.
1) rdinit is a kernel parameter, not a boot loader option.
2) This does not match the description of rdinit in
Documentation/kernel-parameters.txt :

rdinit= [KNL]
Format: <full_path>
Run specified binary instead of /init from the ramdisk,
used for early userspace startup. See initrd.

Do you have any source backing up your claim ?

Besides, the initrd filesystem is loaded and used in memory and no write
on the on-disk initrd file occurs so mounting it read-only makes no sense.
Post by root
It is identical to a line in lilo.conf
read-only
No, LILO's read-only option is identical to the "ro" kernel parameter
and affects only the final root filesystem, not the initrd. From man
lilo.conf(5) :

read-only
This specifies that the root file system should be mounted
read-only. It may be specified as a global option. Typically,
the system startup procedure re-mounts the root file system
read-write later (e.g. after fsck'ing it).
root
2018-09-14 20:30:43 UTC
Permalink
Post by Pascal Hambourg
Post by root
Post by Pascal Hambourg
I do not understand the parameter "rdinit=ro".
As part of the command orginally specified
rdinit=ro
tells the boot loader to load the image read-only.
1) rdinit is a kernel parameter, not a boot loader option.
2) This does not match the description of rdinit in
rdinit= [KNL]
Format: <full_path>
Run specified binary instead of /init from the ramdisk,
used for early userspace startup. See initrd.
Do you have any source backing up your claim ?
Besides, the initrd filesystem is loaded and used in memory and no write
on the on-disk initrd file occurs so mounting it read-only makes no sense.
Post by root
It is identical to a line in lilo.conf
read-only
No, LILO's read-only option is identical to the "ro" kernel parameter
and affects only the final root filesystem, not the initrd. From man
read-only
This specifies that the root file system should be mounted
read-only. It may be specified as a global option. Typically,
the system startup procedure re-mounts the root file system
read-write later (e.g. after fsck'ing it).
The command:
huge.s root=/dev/sdxx rdinit=ro

Is a command not to a kernel but to a program on the Slackware
install disk. The meaning of the entries on the line is
determined by the program that reads that line.

The first parameter huge.s tells the program that you
want to boot the kernel huge.s from a directory that
has that kernel and others.
Pascal Hambourg
2018-09-14 21:28:07 UTC
Permalink
Post by root
huge.s root=/dev/sdxx rdinit=ro
Is a command not to a kernel but to a program on the Slackware
install disk. The meaning of the entries on the line is
determined by the program that reads that line.
What is this program ?
In <pngh0u$1t6$***@news.albasani.net> you instructed to type the command
at a "boot:" prompt. This looks like a boot loader prompt (such as
Syslinux) which expects a kernel name followed by kernel parameters.
root
2018-09-14 22:51:36 UTC
Permalink
Post by Pascal Hambourg
Post by root
huge.s root=/dev/sdxx rdinit=ro
Is a command not to a kernel but to a program on the Slackware
install disk. The meaning of the entries on the line is
determined by the program that reads that line.
What is this program ?
at a "boot:" prompt. This looks like a boot loader prompt (such as
Syslinux) which expects a kernel name followed by kernel parameters.
I've never looked into it. It is the program that comes up
with the Slackware install disk. This is a Slackware news
group, you must have your own copy.
Pascal Hambourg
2018-09-15 07:20:35 UTC
Permalink
Post by root
Post by Pascal Hambourg
Post by root
huge.s root=/dev/sdxx rdinit=ro
Is a command not to a kernel but to a program on the Slackware
install disk. The meaning of the entries on the line is
determined by the program that reads that line.
What is this program ?
at a "boot:" prompt. This looks like a boot loader prompt (such as
Syslinux) which expects a kernel name followed by kernel parameters.
I've never looked into it. It is the program that comes up
with the Slackware install disk. This is a Slackware news
group, you must have your own copy.
If the prompt happens before the kernel is loaded, it can't be anything
but the boot loader.
Tuxedo
2018-09-14 19:03:36 UTC
Permalink
Pascal Hambourg wrote:

[...]
Post by Pascal Hambourg
I do not understand the parameter "rdinit=ro".
rdinit= expects a full pathname inside the initrd and is used to run the
specified executable instead of the default initrd /init. (like init= is
used to run the specified executable on the root filesystem instead of
/sbin/init)
"ro" does not look like a full pathname, and anyway why would you need
to run an alternate initrd init ?
What might work on Unetbootin's command line to try and get into the system
and patch the MBR?

The unencrypted nvm0n1p2 /boot partition is populated with the following
files and directories:

-rw-r--r-- boot.10300
-rw-r--r-- boot_message.txt
-rw-r--r-- coffee.dat
lrwxrwxrwx config -> config-huge-4.14.67
-rw-r--r-- config-generic-4.14.67.x64
-rw-r--r-- config-huge-4.14.67.x64
-rwxr-xr-x elilo-ia32.efi
-rwxr-xr-x elilo-x86_64.efi
drwxr-xr-x grub
-rw-r--r-- initrd.gz
drwxr-xr-x initrd-tree
-rw-r--r-- inside.bmp
-rw-r--r-- inside.dat
drwx------ lost+found
-rw------- map
-rw-r--r-- onlyblue.bmp
-rw-r--r-- onlyblue.dat
lrwxrwxrwx README.initrd -> /usr/doc/mkinitrd-1.4.11/README.initrd
-rw-r--r-- slack.bmp
lrwxrwxrwx System.map -> System.map-huge-4.14.67
-rw-r--r-- System.map-generic-4.14.67
-rw-r--r-- System.map-huge-4.14.67
-rw-r--r-- tuxlogo.bmp
-rw-r--r-- tuxlogo.dat
lrwxrwxrwx vmlinuz -> vmlinuz-huge-4.14.67
lrwxrwxrwx vmlinuz-generic -> vmlinuz-generic-4.14.67
-rw-r--r-- vmlinuz-generic-4.14.67
lrwxrwxrwx vmlinuz-huge -> vmlinuz-huge-4.14.67
-rw-r--r-- vmlinuz-huge-4.14.67

Many thanks for any ideas!

Tuxedo
root
2018-09-14 19:15:17 UTC
Permalink
Post by Tuxedo
[...]
Thanks for the info. However, I don't see exactly this, maybe because of how
the install disk was initially created (using UNetbootin), or maybe because
-----------------------------------------------
UNetbootin
Default
huge.s
kms.s
speakup.s
Slackware 15.0 huge.s kernel
Slackware 15.0 huge.s kernel (use KMS console=
Detect/booz any installed operating system
Press [ Tab ] to edit options
Automatic boot in 10 seconds...
I had assumed that your installation started from a Slackware install
disk. To my knowledge the latest "official" install disk is
Slackware 14.2, I don't know where your 15.0 comes from.

The boot options on the install disk assume that you can boot
into your partition using the generic installed kernel, in
this case huge.s

If you side loaded some packages to build your own Slackware
installation you might not have included the (now old) 14.2
huge.s kernel and that boot option will not work unless
you also side load the 14.2 kernel and modules.

I was never able to get lilo to load from the M.2 ssd.
I ended up using grub. Whatever method you use to
gain access to your operating partition, the kernel
you use has to have module support on that partition.

Let your install bot process proceed to the point where
you are told to login as root, but do not execute
setup. Instead, make some mount point and mount
your operating partition on that mount point.
Then execute

chroot /mountpoint

Do something like this after logging in as root:

mkdir /mountpoint
mount /dev/nvme0n1p2 /mountpoint
chroot /mountpoint

Don't just type what I just did, verify that the
mount command is what you want.
Tuxedo
2018-09-14 20:04:18 UTC
Permalink
root wrote:

[...]
Post by root
I had assumed that your installation started from a Slackware install
disk. To my knowledge the latest "official" install disk is
Slackware 14.2, I don't know where your 15.0 comes from.
The boot options on the install disk assume that you can boot
into your partition using the generic installed kernel, in
this case huge.s
If you side loaded some packages to build your own Slackware
installation you might not have included the (now old) 14.2
huge.s kernel and that boot option will not work unless
you also side load the 14.2 kernel and modules.
I was never able to get lilo to load from the M.2 ssd.
I ended up using grub. Whatever method you use to
gain access to your operating partition, the kernel
you use has to have module support on that partition.
Let your install bot process proceed to the point where
you are told to login as root, but do not execute
setup. Instead, make some mount point and mount
your operating partition on that mount point.
Then execute
chroot /mountpoint
mkdir /mountpoint
mount /dev/nvme0n1p2 /mountpoint
chroot /mountpoint
Don't just type what I just did, verify that the
mount command is what you want.
I don't know about the 15.0 options come from, must be the very recent
Slackware current download. As far as I can remember, I ran the installation
after having downloaded the latest version and selected the "huge.s" option.

I now fired up the install media and mount /mountpoint containing the
various files and directories in /dev/nvme0n1p2 can be accessed but chroot
doesn't work. After having mounted the partition, running:

***@slackware:/# chroot /mountpoint

... results in:

chroot: can't execute '/bin/sh': No such file or directory

Is the idea to chroot into this environment and from there run liloconfig?

There is no chroot program in /bin however.

Tuxedo
root
2018-09-14 20:21:56 UTC
Permalink
Post by Tuxedo
chroot: can't execute '/bin/sh': No such file or directory
Is the idea to chroot into this environment and from there run liloconfig?
There is no chroot program in /bin however.
Tuxedo
Before I posted my response I performed the exact procedure
and it worked from the 14.2 install disk. I can't help
because I don't have or know about your install process.

Ultimately it would be to chroot into your partition
and rerun lilo to restore a damaged boot partition.

On all the systems I run or maintain there are two
drives with at least one copy of the operating system
as a backup. There are many ways a system can fail
and damage to the boot sector is not the most frequent
in my experience.

Here is another suggestion good for other reasons.
Install LiveSlak on a thumbdrive. That way you
can carry a running Slackware everywhere you go.

Boot into the LiveSlak and then do the chroot
process.

LiveSlak is much, much more useful than other live
systems because you can add your own stuff to
LiveSlak. I use my own editor which I have been
customizing for about 40 years. I am dead in
the water without it. It is installed on my
LiveSlak.
Tuxedo
2018-09-14 20:45:28 UTC
Permalink
root wrote:

[...]
Post by root
Before I posted my response I performed the exact procedure
and it worked from the 14.2 install disk. I can't help
because I don't have or know about your install process.
Ultimately it would be to chroot into your partition
and rerun lilo to restore a damaged boot partition.
On all the systems I run or maintain there are two
drives with at least one copy of the operating system
as a backup. There are many ways a system can fail
and damage to the boot sector is not the most frequent
in my experience.
Here is another suggestion good for other reasons.
Install LiveSlak on a thumbdrive. That way you
can carry a running Slackware everywhere you go.
Boot into the LiveSlak and then do the chroot
process.
LiveSlak is much, much more useful than other live
systems because you can add your own stuff to
LiveSlak. I use my own editor which I have been
customizing for about 40 years. I am dead in
the water without it. It is installed on my
LiveSlak.
I had no idea that booting bypassing the MBR would become so complicated.
Had I known, I would have installed Windows first.

I will download LiveSlak and see if it works to run and chroot into the
existing installation and run lilo. Thanks for the tip. If it doesn't work
for some reason, I'll simply reformat and resinstall Slackware on the
current encrypted partition, which I guess I have to unlock first. In the
end it may prove the easier way as it's a fresh install without user data.

Tuxedo
Tuxedo
2018-09-15 05:10:40 UTC
Permalink
Tuxedo wrote:

[...]
Post by Tuxedo
I will download LiveSlak and see if it works to run and chroot into the
existing installation and run lilo. Thanks for the tip. If it doesn't work
for some reason, I'll simply reformat and resinstall Slackware on the
current encrypted partition, which I guess I have to unlock first. In the
end it may prove the easier way as it's a fresh install without user data.
Tuxedo
Having downloaded a 3.4GB slackware64-live-current.iso image I've tried
using Netbootin to create a bootable USB of it. However, the USBs I have
which were once 16GB had shrunk to 16MB during previous Slackware USB flash
creation processes. How can their original capacity be restored again?

Not even a reformat action in Windows brings back their original capacity.

Tuxedo
Ars Ivci
2018-09-15 06:27:25 UTC
Permalink
Post by Tuxedo
[...]
Post by Tuxedo
I will download LiveSlak and see if it works to run and chroot into the
existing installation and run lilo. Thanks for the tip. If it doesn't work
for some reason, I'll simply reformat and resinstall Slackware on the
current encrypted partition, which I guess I have to unlock first. In the
end it may prove the easier way as it's a fresh install without user data.
Tuxedo
Having downloaded a 3.4GB slackware64-live-current.iso image I've tried
using Netbootin to create a bootable USB of it. However, the USBs I have
which were once 16GB had shrunk to 16MB during previous Slackware USB flash
creation processes. How can their original capacity be restored again?
Not even a reformat action in Windows brings back their original capacity.
Tuxedo
If you can use the windows part, try Rufus: https://rufus.akeo.ie/ to
reformat and create a bootable ISO.

t.
Pascal Hambourg
2018-09-15 07:18:05 UTC
Permalink
Post by Tuxedo
Having downloaded a 3.4GB slackware64-live-current.iso image I've tried
using Netbootin to create a bootable USB of it. However, the USBs I have
which were once 16GB had shrunk to 16MB during previous Slackware USB flash
creation processes. How can their original capacity be restored again?
How do you see that they have "shrunk to 16 MB" ? What does fdisk say ?
There may be confusion between partition/filesystem size and whole
device capacity.
Tuxedo
2018-09-15 07:37:37 UTC
Permalink
[...]
Post by Pascal Hambourg
How do you see that they have "shrunk to 16 MB" ? What does fdisk say ?
There may be confusion between partition/filesystem size and whole
device capacity.
Inserting and mounting the now Windows FAT reformatted media into a system
and running fdisk -l returns:

Disk /dev/sdb: 15.4 GB, 15376318464 bytes
43 heads, 40 sectors/track, 17460 cylinders, total 30031872 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xaff12d6f

While the Thunar filemanager in Linux shows up a tooltip indicating the
media has 16.6MB.

Unetbootin will not write to it due to missing space.

Simply copying something large that goes over the 16.6MB size will not work.

ls -ld /run/media/tuxedo/SLACKLIVE/

...returns:

drwx------ 2 tuxedo 16384 Sep 15 /run/media/tuxedo/SLACKLIVE/

I have no idea why....

Tuxedo
Pascal Hambourg
2018-09-15 08:11:51 UTC
Permalink
Post by Tuxedo
Inserting and mounting the now Windows FAT reformatted media into a system
Disk /dev/sdb: 15.4 GB, 15376318464 bytes
43 heads, 40 sectors/track, 17460 cylinders, total 30031872 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xaff12d6f
As expected the media capacity is still 16 GB, and the MBR partition
table appears to be empty. If the media contains a filesystem, it was
created directly in the whole device /dev/sdb.
Post by Tuxedo
While the Thunar filemanager in Linux shows up a tooltip indicating the
media has 16.6MB.
Thunar is a *file* manager, so it show whatever *filesystems* contain.
It appears that the whatever filesystem is on the media has a 16MB size.

You can gather information about metadata with the following commands :

file -s /dev/sdb*
blkid /dev/sdb*
wipefs /dev/sdb

You can wipe existing metadata with

wipe -a /dev/sdb

(make sure you specify the right device !)
then use the media for whatever you want : create a new partition table
and partitions, write a disk image...
Pascal Hambourg
2018-09-15 08:13:34 UTC
Permalink
Post by Pascal Hambourg
You can wipe existing metadata with
wipe -a /dev/sdb
Oops typo ! please read :

wipefs -a /dev/sdb
Post by Pascal Hambourg
(make sure you specify the right device !)
Tuxedo
2018-09-15 08:38:53 UTC
Permalink
Post by Pascal Hambourg
Post by Pascal Hambourg
You can wipe existing metadata with
wipe -a /dev/sdb
wipefs -a /dev/sdb
Post by Pascal Hambourg
(make sure you specify the right device !)
Thanks for the info.

I ran wipefs -a /dev/sdb

... the output was:
2 bytes were erased at offset 0x000001fe (dos): 55aa

... indicating something happened, because if I run the same again, there is
no output.

However, the size of the media has not changed and Unetbootin will not write
SlackLive or anything else big to it because of missing space. Maybe there
is something particular with the USB sticks. I had bought two new "ScanDisk"
sticks for the purpose of creating Flash startup sticks but not only didn't
that work, I don't know how to make the sticks usable again.

Maybe some partition tool, e.g. GParted, can reformat and expand them again.

Tuxedo
Pascal Hambourg
2018-09-15 09:24:37 UTC
Permalink
Post by Tuxedo
I ran wipefs -a /dev/sdb
2 bytes were erased at offset 0x000001fe (dos): 55aa
This is a boot sector signature.
wipefs should have found a filesystem signature too.
Post by Tuxedo
However, the size of the media has not changed and Unetbootin will not write
SlackLive or anything else big to it because of missing space.
The size of the media has always been 16 GB and has never changed. What
you see is the size of the mounted filesystem. Did you unmount it before
running wipefs and did you remove the media afterwards ?

I just wonder how wipefs did not find the signature of this filesystem.
Can you post the output of these commands when you see that size of 16 MB ?

file -s /dev/sdb
blkid /dev/sdb

If any filesystem metadata remains, try this when the filesystem is not
mounted :

dd if=/dev/zero of=/dev/sdb bs=1M count=2
Tuxedo
2018-09-15 09:49:25 UTC
Permalink
[...]
Post by Pascal Hambourg
This is a boot sector signature.
wipefs should have found a filesystem signature too.
Post by Tuxedo
However, the size of the media has not changed and Unetbootin will not
write SlackLive or anything else big to it because of missing space.
The size of the media has always been 16 GB and has never changed. What
you see is the size of the mounted filesystem. Did you unmount it before
running wipefs and did you remove the media afterwards ?
I just wonder how wipefs did not find the signature of this filesystem.
Can you post the output of these commands when you see that size of 16 MB ?
file -s /dev/sdb
blkid /dev/sdb
If any filesystem metadata remains, try this when the filesystem is not
dd if=/dev/zero of=/dev/sdb bs=1M count=2
I ran the above commands. I'm not sure which did it but something erased
all. Thereafter the media didn't show in Thunar at all for some reason. I
thereafter formatted it in Windows and the original size is now back when
shown in Thunar.

Many thanks!
Tuxedo
Pascal Hambourg
2018-09-15 11:40:13 UTC
Permalink
Post by Tuxedo
Post by Pascal Hambourg
Can you post the output of these commands when you see that size of 16 MB ?
file -s /dev/sdb
blkid /dev/sdb
If any filesystem metadata remains, try this when the filesystem is not
dd if=/dev/zero of=/dev/sdb bs=1M count=2
I ran the above commands. I'm not sure which did it but something erased
all.
I expected you to post the result of the first two commands which are
only informative. The last one erased the first 2 MB of the media,
hopefully previously containing filesystem metadata.
Post by Tuxedo
Thereafter the media didn't show in Thunar at all for some reason.
The reason is that the media did not contain any filesystem any more and
Thunar being a file manager, it shows only filesystems, not raw media.
Post by Tuxedo
I
thereafter formatted it in Windows and the original size is now back when
shown in Thunar.
Why on earth did you format it in Windows ? You could just partition and
format it with fdisk (or gparted and the like) and mkfs...

I would expect any Slackware user to know how to use these programs. Am
I wrong ?
Tuxedo
2018-09-15 12:09:11 UTC
Permalink
Pascal Hambourg wrote:

[...]
Post by Pascal Hambourg
I would expect any Slackware user to know how to use these programs. Am
I wrong ?
In this case, yes :-)

Tuxedo
Chris Elvidge
2018-09-15 09:54:31 UTC
Permalink
Post by Tuxedo
Post by Pascal Hambourg
Post by Pascal Hambourg
You can wipe existing metadata with
wipe -a /dev/sdb
wipefs -a /dev/sdb
Post by Pascal Hambourg
(make sure you specify the right device !)
Thanks for the info.
I ran wipefs -a /dev/sdb
2 bytes were erased at offset 0x000001fe (dos): 55aa
... indicating something happened, because if I run the same again, there is
no output.
However, the size of the media has not changed and Unetbootin will not write
SlackLive or anything else big to it because of missing space. Maybe there
is something particular with the USB sticks. I had bought two new "ScanDisk"
sticks for the purpose of creating Flash startup sticks but not only didn't
that work, I don't know how to make the sticks usable again.
Maybe some partition tool, e.g. GParted, can reformat and expand them again.
Tuxedo
Windows has problems with USB sticks with more than 1 partition. Use
fdisk and write a new partition table on the stick. (I think it's 'o')
--
Chris Elvidge, England
root
2018-09-15 14:27:13 UTC
Permalink
Post by Tuxedo
[...]
Post by Tuxedo
I will download LiveSlak and see if it works to run and chroot into the
existing installation and run lilo. Thanks for the tip. If it doesn't work
for some reason, I'll simply reformat and resinstall Slackware on the
current encrypted partition, which I guess I have to unlock first. In the
end it may prove the easier way as it's a fresh install without user data.
Tuxedo
Having downloaded a 3.4GB slackware64-live-current.iso image I've tried
using Netbootin to create a bootable USB of it. However, the USBs I have
which were once 16GB had shrunk to 16MB during previous Slackware USB flash
creation processes. How can their original capacity be restored again?
Not even a reformat action in Windows brings back their original capacity.
Tuxedo
Wipe out the partition table and start over. Assuming fdisk -l
reveals the sd to be /dev/sdXY
then do:

dd if=/dev/zero of=/dev/sdXY bs=4000000 count=1000

then run fdisk or gdisk to create a new partition table.

Alternatively you could use parted, but the above is what
I do.

Eric Pozharski
2018-09-09 15:23:42 UTC
Permalink
This post might be inappropriate. Click to display it.
Joe Rosevear
2018-09-12 21:17:51 UTC
Permalink
Post by Tuxedo
Hello,
Within Slackware's setup and right after the slackware install procedure
from USB to HD was completed, the option to MAKE USB FLASH BOOT step was
returned and done.
Now the system is installed on the HD, and booting from LILO via MBR and
/boot sector works, but when testing the Flash USB, the system does not boot
from for some reason. The Flash boot begins and stops or simply hangs midway
with some non-descriptive messages, maybe because the USB was created before
the subsequent mkinitrd procedure of the Slackware HD installation?
Booting from USB will be needed next to reinstall LILO after having
installed Windows on another partition, as of course the Windows installer
will then overwrite the MBR.
Some thoughts:

vvv 1. I don't think you need a boot stick to reinstall LILO. As
someone above posted you can boot from the a Slackware install disk. I
think you will need to mount the root partition, then chroot to it
before re-running lilo.

2. Another way to boot is to use a Grub2 boot disk. Let me know if
you are interested and I can share my notes with you about how I did
this. Or send me a little money and your address, and I'll burn one
and put it in the mail to you.

The Grub2 boot disk works great, but I don't know if it does LVM, LUKS
or UEFI, as I haven't tried them. The nice thing about a Grub2 boot
disk is that it is generic. It uses the kernel and initrd.gz directly
from root, thus except for the lacks I mentioned above, and maybe
others, it can boot any system. I have even booted Windows with it.

You need to make a few changes though to use it, and there is a bit of
learning required. I am happy with what it can do, though. It is well
worth the trouble. The laptop which I am currently using to type this
reply was booted with a Grub2 boot disk. The root which I booted is a
partition on a Samsung USB 3.0 flash drive to which I have installed
Slackware 14.2.
^^^

I hope this helps or at least gave you something to think about.

-Joe
Loading...