SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This is probably the closest thread I could find dealing with my issue: https://www.linuxquestions.org/quest...em-4175463557/, however reinstalling lilo did not work. I have lilo-24.2-x86_64-8, which looks to be the latest.
In the other thread I advised you to use the huge kernel not the generic (which requires an initial ramdisk).
And in your lilo.conf you are pointing both images at the same kernel:
Code:
image = /boot/vmlinuz-generic-4.19.72
If for whatever reason you insist on using the generic kernel, then you'll need the two separate initrd.gz files for the two separate kernels.
P.S. Using the huge kernel, the following line(s) in lilo.conf are not required anymore:
Code:
initrd = /boot/initrd.gz
Last edited by abga; 09-11-2019 at 09:21 PM.
Reason: P.S.
In the other thread I advised you to use the huge kernel not the generic (which requires an initial ramdisk).
And in your lilo.conf you are pointing both images at the same kernel:
Code:
image = /boot/vmlinuz-generic-4.19.72
If for whatever reason you insist on using the generic kernel, then you'll need the two separate initrd.gz files for the two separate kernels.
P.S. Using the huge kernel, the following line(s) in lilo.conf are not required anymore:
Code:
initrd = /boot/initrd.gz
Apparently, you believe that you known better the Slackware even than Mr. Volkerding, considering that he recommends on CHANGES_AND_HINTS.TXT
Quote:
Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock.
generic kernels. You will need to create an initrd in order to boot
the generic kernels - see /boot/README.initrd for instructions.
The huge kernels are primarily intended as "installer" and "emergency".
kernels in case you forget to make an initrd.
Please explain why and how you dare to give a recommendation which is right on contrary to Mr. Volkerding's own recommendations.
Last edited by LuckyCyborg; 09-12-2019 at 02:24 PM.
Apparently you missed the context and the previous discussion with the OP (another thread): https://www.linuxquestions.org/quest...2A-4175660632/
I advised him - by pointing to some other posts I wrote - to use the huge kernel because it's simpler for his 2 kernels scenario (no initrd), he's not that experienced with Slackware & package management (& apparently lilo too) and just to avoid the situation in which we are now.
If you ask me, I believe the generic+initrd concept is obsolete in this day&year on these modern systems and the naming should be changed. generic = tiny/light & the "scary" huge = normal.
Thanks abga, slacktroll and LuckyCyborg for the help.
The repeated kernel was a typo and I excluded the huge kernel just because I am copying from the virtual machine to this post by typing it out (I can't find a copy and paste button in the vm), sorry about this. Let me make the correction:
And the huge kernel, I am using as my backup/emergency kernel (which has saved me a few times now, lol). It took me some time to find the information https://docs.slackware.com/howtos:sl...kernelbuilding that I read before but not sure how to go about this without getting the error of "Setup length exceeds 63 maximum":
Quote:
If you are already using an initrd image with your current kernel, you can choose between two options:
Create a second initrd image using the command above but with an explicit name for the resulting initrd file (which should be different from the default in order not to overwrite the old one:
mkinitrd -c -k 2.6.37.6 -m ext3 -o /boot/initrd-custom-2.6.37.6.gz
and then change the lilo.conf section to look like this:
image = /boot/vmlinuz-custom-2.6.37.6
root = /dev/sda1
initrd = /boot/initrd-custom-2.6.37.6.gz
label = newkernel
read-only # Non-UMSDOS filesystems should be mounted read-only for checking
Add the kernel modules for your new kernel to the existing initrd file. That way, you have a single initrd image containing modules for multiple kernels. All you need to do is leave out the option “-c” which is the option to wipe the directory /boot/initrd-tree and start from scratch:
mkinitrd -k 2.6.37.6 -m ext3
Is it not working because I have cleared the existing initrd tree with "-c"? Should I run mkinitrd for 4.19.59 and save it with the kernel number (to keep it orderly)?
I tried running this but no luck:
I don't know what the generic kernel contains and I'm meaning here the support (drivers) for identifying and enabling your storage in order to be able to mount the root partition. Basically you don't need an initrd if what I mentioned previously is included in generic, you can comment out the "initrd =" from lilo.conf. And the initrd file, as described in a previous post, is kernel specific, you need one for each and every kernel (version).
I'm sorry I cannot provide you with more info about initrd, it's almost 15 years now since I used the generic+initrd combo and lost all my knowledge about it, my brain is very effective in loosing useless knowledge (one usage of initrd I find useful is for booting encrypted storage, but that is also useless by itself, the actual sensible data should be encrypted and not the OS itself).
On your try to create the initrd image with the mkinitrd, here is Patrick's official doc: https://mirror.de.leaseweb.net/slack.../README.initrd
It contains an example in which the root partition is also specified (-r switch):
In addition to that, use the -o to define the name of the initrd (you already did it) and:
Code:
-s Initrd source tree (default /boot/initrd-tree/)
to have different initrd-tree for each initrd.
Use /sbin/mkinitrd --help to learn more about it.
And do provide details about your failures - errors.
But again, you shouldn't need an initrd. Try the huge kernel and stick with it if it works, if your system is new (manufactured in the last 10-15 years) and have plenty of RAM (something over 1GB).
Last edited by abga; 09-12-2019 at 10:07 PM.
Reason: wrong URL
- side note -
In trying to check all the options /sbin/mkinitrd provides I launched it by mistake without any parameters on a Slackware -current ARM (only running current on ARM) and it blew the system. I couldn't restart it and it cannot boot anymore. I remember mkinitrd complained that my /boot directory is read-only - which it is, purposefully! (stupid FAT partition) and now, when it boots I get a flood of "cannot open /dev/x1" & "cannot open /dev/c1"
Mounted the SDCard on another system, noticed a lot of garbage in / and:
Code:
ls -al /mnt/hd/sbin/init
lrwxrwxrwx 1 root root 14 Aug 5 09:15 /mnt/hd/sbin/init -> ../bin/busybox*
I take it as a lesson, to never touch mkinitrd again Just saying. Time to restore the binary image on the SDCard. Didn't know I have busybox...
- end of side note -
If you ask me, I believe the generic+initrd concept is obsolete in this day&year on these modern systems and the naming should be changed. generic = tiny/light & the "scary" huge = normal.
In fact, looks like the concept of "huge kernels" is obsolete, and almost no one other Linux distribution beyond Slackware does use them.
Everybody out there uses initrds, so I believe this "modular design" using initrds is the modern way.
Last edited by ZhaoLin1457; 09-13-2019 at 10:34 AM.
In fact, looks like the concept of "huge kernels" is obsolete, and almost no one other Linux distribution beyond Slackware does use them.
Everybody out there uses initrds, so I believe this "modular design" using initrds is the modern way.
My point was that initrd has served its purpose and didn't care what other distros are doing. I am OK with it for certain use cases and it should remain provided. My recommendation was only to change the naming of generic & huge, not to scare people with that rather uninspired name "huge".
On your observation about the lilo issue the OP is experiencing, I started considering that the environment (partitions) could be the cause when I learned that the OP is running Slackware in a VM - see post #6, but focused first on his lilo.conf corrections.
Last edited by abga; 09-13-2019 at 02:18 PM.
Reason: second point = recommendation - there were too many points
@ernie young
How did you install lilo? Did you choose MBR for its installation? If it's only Slackware that you're using the VM instance for and don't have other boot loader installed in your MBR (multi boot scenario), then and only then contine:
If not sure, backup you actual /etc/lilo.conf file and run:
Code:
/sbin/liloconfig
In the ncurses "wizard", choose simple and then, in some further step, install it on MBR. You didn't mention, until post #6, that your Slackware setup is inside a VM, wondering what VM engine are you using? I only use(d) VMWare (both professionally & privately) and never experienced issues with it.
The "older" (c)fdisk from Slackware 14.2 creates the first partition starting from 2048:
Code:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 14682111 14680064 7G 83 Linux
....
And the "newer" (c)fdisk from Slackware -current creates a DOS partition ( DOS compatibility mode) staring at 32:
Code:
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 32 195327 195296 95.4M c W95 FAT32 (LBA)
/dev/mmcblk0p2 196608 28868607 28672000 13.7G 83 Linux
...
It looks there are two conditions here, first the alignment and the mode fdisk operates, that's if it's in DOS compatibility mode or not. Older fdsik utilities were indeed defaulting in DOS compatibility mode, but as shown above, the "old" fdisk utilities from Slackware 14.2 are not.
Last edited by abga; 09-13-2019 at 06:16 PM.
Reason: edits in bold
I did install lilo in the MBR and Slackware is the only OS in the Virtual Machine. I therefore ran your command
Code:
/sbin/liloconfig
The command deleted my generic entries I had before and only the following is in the /etc/lilo.conf
Quote:
image = /boot/vmlinuz
root = /dev/sda2
label = linux
read-only
In order for me to keep my entries next time, should I install LILO in the superblock of root or is this a result of the KVM virtual machine that I am using?
Your error "Setup length exceeds XX maximum; kernel setup will overwrite boot loader" looks to be resolved in all the references I found on the net, all of which were recorded many years ago 2012-2013, by simply patching or updating lilo to a newer version. But you have the latest lilo version already.
There are 2 other suggestions I'd like to make:
1. Try to put the label entries in your lilo.conf between quotes, like:
Code:
label = "4.19.72"
Doc: https://www.tldp.org/HOWTO/text/LILO
- you can also use the general option default =, outside the "image =" block, to tell lilo which is your default image you want to boot:
Code:
default = "4.19.72"
With your latest reply and colorpurple21859's suggestion I re-read your post #6 and noticed you have 3 image sections. Why? You only need two kernels, the last you know it's working and the new one -latest- you want to test and need a failover on the last if it fails.
That was also my suggestion in the other thread with your original problem: https://www.linuxquestions.org/quest...2/#post6035155
Comment out the entire default image block liloconfig generates and only keep your image entries (leave initrd out for the moment):
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Just saying. Time to restore the binary image on the SDCard. Didn't know I have busybox...
