Slackware 14.2 hangs after 'BIOS data check'
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?
|
Quote:
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. Quote:
BIOS data check appears at the end. The 'successful' part never shows. |
From a default lilo.conf
Code:
# Enable map compaction: |
Quote:
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). |
Quote:
|
Quote:
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. |
Quote:
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? |
It is not the 'compact' option
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: Code:
Warning: /dev/disk/by-id/usb-Multi_Flash_Reader_xxx-0:BIOS syntax is no longer supported. 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: Code:
pub 1024D/40102233 2003-02-26 Slackware Linux Project <security@slackware.com> Thanks to everyone who is willing to look into this erratic behaviour. |
Quote:
|
Quote:
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. |
Quote:
|
All times are GMT -5. The time now is 09:13 AM. |