Since practically every other major distro decided to use Systemd I have finally made the long overdue switch to Slackware.

I am having a problem that I have not been able to solve, though.
Here is my setup:
- Encrypted root fs on /dev/sda1 (internal ssd, full disk encryption)
- boot partition on /dev/sdb1 (external memory card)
- LILO on MBR of /dev/sdb

The memory card can be write-protected by a physical switch. The system boots up fine if write protection is not enabled. However, if I enable write protection (physically) on the memory card then the system will hang after 'BIOS data check'. I have two questions:

- What exactly is BIOS data check doing?
- What needs to be written to the boot partition on the memory card at start-up and can I prevent it so that the system won't hang?

Early mounts are read only as a rule. Is something messing with execute permissions? Is EFI involved?

Well, then enabling write-protection should not be a problem. Is there any chance that maybe the status of the /boot partition (writeable vs read-only) is stored somewhere when LILO installs itself?
Maybe this status is checked again during 'BIOS data check' and is therefore expected to be writeable during boot. Just a thought but I do not know how to verify that.

No EFI involved. I mounted the card on a booted system with and without write-protection. There were no changes in execute permissions. During boot process there are also no messages that would indicate otherwise. Just the dots during the check and the message

BIOS data check

appears at the end. The 'successful' part never shows.

From a default lilo.conf
Booting from a memory card is possibly similar to booting from a floppy, have you tried adding/uncommenting the "compact" setting and seeing if that changes the boot behaviour?

Yes, I had already read somewhere that using compact in lilo.conf will skip the BIOS data check. If skipped, then the system starts with physical write-protection enabled. I would prefer, however, to not skip the test and still be able to boot with write protection enabled.
Update: It has nothing to do with the compact option. More info in the post http://www.linuxquestions.org/questi...1/#post5732334 further down.

So the question remains, why does 'BIOS data check'
need a writeable boot partition and is it possible to change that behaviour?

Some bois data is written to the reserved portion of the MBR of the first storage device that is bootable.
Lilo used to use this data during boot to verify the system. I do not know if it still does since I long ago switched to grub and only run encrypted drives as second partitions or second drives.

I have always used compact in lilo.conf and always get the BIOS data check successful message, although perhaps it skips the test and just doesn't say so.

It is possible that your specific BIOS treats your boot drive differently when write protect is enabled, so that it might show up as /dev/sdb when write protect is disabled, but as something else when write protect is enabled. If so, and if your lilo.conf has something like:
image=/dev/sdb1/vmlinuz
then lilo may not be able to find the image.
You could try using the appropriate device from /dev/disk/by-id/ instead of /dev/sdb1/
in lilo.conf (or /dev/disk/by-label/ or /dev/disk/by-uuid).

If this is the case, I have an article on the SlackDocs Wiki explaining how to do this

3 members found this post helpful.

Indeed, I was having issues recently booting off an sdcard recently and used this article to set up UUIDs for everyting. Now the card boots correctly no matter which of several laptop hardware sdcard slots are used ( /dev/sdX or /dev/mmcblkX, etc).

OP isn't clear exactly where /dev and /proc, /var, /tmp etc are mounted. These, as I understand it, can't be on a wright-protected drive. Also, the boot process may be getting confused if it can't find initrd and/or where rootdev is. Then again, are you sure that your BIOS supports read-only booting from non-optical devices? Isn't that why we use isolinux and syslinux and not lilo/elilo on these devices?

Just thinking on this Bios check needing a writable disk.

Back in the day, Dos was vulnerable to boot record viruses - things like Form, Ping Pong, and the rather evil CIH. I'm sure you can google them. The Bios check may include validation of the boot record. If an invalid boot record was found, something would need access to correct it. CIH, for instance, overwrites the Motherboard's Bios on some random date (April 26th, IIRC).

What got me into linux was that I had small kids and one of them picked this up on irc. This was back far enough that letting 5 - 10 year old kids on IRC was not parental neglect or madness. I found 175 copies of CIH on April 23rd spread between 2 computers, and reacted by starting the linux learning curve.

You know how I arrived myself to pass from Windows 3.1.1 for Workgroups to Slackware Linux, and stay this way until today? Because of OneHalf: https://en.wikipedia.org/wiki/OneHalf

In those times, the Windows 95 was shipped on diskettes, you know, the little things of 1.44MB, and about 25 of them. I made about 15 trips in a week, every about 10Km to walk, trying to resolve the installation issues with the operating system bought from a shop. Was something cheap OEM, and they had sell on diskettes written by them.

Still, I do not managed to install Windows 95 on my computer, then a friend had a kit of Slackware (series 3.x, if I remember right). My friend installed me this Slackware, as console access, then on several weeks I managed to start the X server and to have a desktop on TWM or something...

To be on topic, I do not recommend the compact option in the problematic motherboards/systems.

Also, talking about the write-protection switch on that SDCARD for boot, I guess that the kernel is just confused about its boot context.

And I have a suggestion: how about to try use SYSLINUX, which is know as booting from read-only devices, and going up from a FAT32 partition, which is native for SDCARDs?

1 members found this post helpful.

I reinstalled Slackware 14.2 ( same setup ) and this time I used the 'compact' option in /etc/lilo.conf directly after the installation finished, ie, while still booted from the installation USB stick. The 'BIOS data check' was skipped but the system would still hang just as before when physical write-protection was enabled. As it appears, the error is not related to the 'compact' option. If I install LILO from the installation USB thumbdrive then the system will not boot if physical write-protection is enabled. If, however, I reinstall LILO from the booted, installed system then it will start whether write-protection is enabled or not.

I noticed a few strange things during installation which I will try to recite from memory as accurate as possible. The USB stick with the Slackware installation ISO is /dev/sdb1. There is only one partition on it. The SDCARD has two partitions on it, /dev/sdc1 (this is the boot partition) and /dev/sdc2 (unrelated data, plays no role in the install). The encrypted root filesystem will be installed on /dev/sda1. The root partition is the only partition and takes up the entire SSD drive (I do not think this plays any role in the later boot behaviour; just being thorough). However, at some point during the installation - cannot remember exactly when - the installation USB stick was identified as /dev/sdc3, which is weird because not only was it the wrong device but there even was no device plugged into the system that had three partitions. Anyway, the installation finished nonetheless, seemingly without errors and without corrupting any devices.

Another thing I noticed is that when I try to identify the boot device via /dev/disk/by-id/ in /etc/lilo.conf then LILO throws an error:
Neither do I know why this option was removed nor am I sure if it factors into the observed behaviour.

The installation is the 64bit edition on a real machine, ie, not VirtualBox or any other virtual machine.
If anyone is going to make a similar install then maybe he/she can give some feedback if the same behaviour can be observed.

I verified the downloaded ISO prior installation via md5sum and gpg signature. Both were good. The downloaded ISO was verified with the following gpg-key:

Is LILO using some "hidden" default configuration during installation which I am not aware of and that makes it want to write on the boot device/partition?

Thanks to everyone who is willing to look into this erratic behaviour.

Does this mean your original problem is solved?

Then, your original problem is resolved and that's good...

Look, in my opinion, after all, I do not consider you are doing the things right.

Firstly, I do not consider a SDCARD, write protected or not, as a reliable boot source for an operating system. They just wasn't made for this, but to temporary transport of data, i.e. images and short movies.

Secondly, my eyebrow is raising while reading about your custom partitioning of this SDCARD. Because I know well that this partitioning is critical for a long term life of a SDCARD, and it is a proprietary art of cylinders, sectors and so on, long story short: a SDCARD is supposed to use its FAT32 or FATX, and to be formatted with a special tool. This one: https://www.sdcard.org/downloads/formatter_4/

Thirdly, what you do is just a huge complication, with a short term life, and with no perceivable gain. Please, enlighten me, what advantage you get using for boot a (write protected) SDCARD, compared with just having a small UN-encrypted partition (for boot) on your glorious SSD, then in the second partition to have your encrypted Linux root; solution which, after all, would be magnitude grades more reliable?

Fourthly, looks like your SDCARD is not plugged in a real hardware for, BUT your computer use a USB bridge for, that's WHY the SDCARD appears as /dev/sdb instead of some /dev/mmcblkX, then it would behave just like a USB memory stick, but with a much shorter life span (specially after your shiny formatting). Long story short, same results you will obtain using a USB stick instead, and even it would be more reliable than your SDCARD.

Unfortunately, it is not that easy. I cannot think of a reason why the system would need write access to the boot disk in any scenario. When I observe behaviour like this then I cannot rule out the possibility of malware involved. The goal of this thread is to get an explanation for the observed behaviour - which is hopefully just a bug - and not just some kind of workaround that makes it somehow work. Since the Slackware homepage suggests this forum for help and I know that there are Slackware maintainers reading this forum, I started this thread here.

1 members found this post helpful.