LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-11-2019, 08:59 PM   #1
ernie young
LQ Newbie
 
Registered: Feb 2016
Distribution: Slackware 14.2
Posts: 25

Rep: Reputation: Disabled
Kernel 4.19.72 Setup length exceeds 63 maximum; kernel setup will overwrite boot loader


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.

This is what /etc/lilo.conf looks like:
Code:
image = /boot/vmlinuz-generic-4.19.72
  initrd = /boot/initrd.gz
  root = /dev/sda2
  label = 4.19.72
  read-only
image = /boot/vmlinuz-generic-4.19.72
  initrd = /boot/initrd.gz
  root = /dev/sda2
  label = 4.19.59
  read-only
Thank you for any help provided.
 
Old 09-11-2019, 09:07 PM   #2
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,117

Rep: Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595
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.
 
Old 09-12-2019, 01:33 PM   #3
slacktroll
Member
 
Registered: May 2011
Distribution: Slackware 14.2
Posts: 125

Rep: Reputation: 21
you entered image = /boot/vmlinuz-generic-4.19.72 twice.. is this intentional or just a typo?

:-)
(oops the guy over me wrote the same thing?)

Last edited by slacktroll; 09-12-2019 at 01:34 PM. Reason: typo
 
Old 09-12-2019, 02:20 PM   #4
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 465

Rep: Reputation: 269Reputation: 269Reputation: 269
Quote:
Originally Posted by abga View Post
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.
 
1 members found this post helpful.
Old 09-12-2019, 02:33 PM   #5
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,117

Rep: Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595
@LuckyCyborg

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.

There was also a recent thread in which the purpose of huge/generic was discussed:
https://www.linuxquestions.org/quest...el-4175659853/

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.
 
4 members found this post helpful.
Old 09-12-2019, 09:27 PM   #6
ernie young
LQ Newbie
 
Registered: Feb 2016
Distribution: Slackware 14.2
Posts: 25

Original Poster
Rep: Reputation: Disabled
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:
Quote:
image = /boot/vmlinuz-generic-4.19.72
initrd = /boot/initrd.gz
root = /dev/sda2
label = 4.19.72
read-only
image = /boot/vmlinuz-generic-4.19.59
initrd = /boot/initrd.gz
root = /dev/sda2
label = 4.19.59
read-only
image = /boot/vmlinuz
initrd = /boot/initrd.gz
root = /dev/sda2
label = Linux
read-only
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:
Code:
mkinitrd -c -k 4.19.72 -m ext4 -o /boot/initrd-4.19.72.gz
Edited the new stanza of /etc/lilo.conf to this:
Code:
initrd = /boot/initrd-4.19.72.gz
  root = /dev/sda2
  label = 4.19.72
  read-only
Thank you for the patience.
 
Old 09-12-2019, 10:03 PM   #7
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,117

Rep: Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595
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):
Code:
mkinitrd -c -k 4.19.72 -m ext4 -f ext4 -r /dev/sdb3
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
 
Old 09-12-2019, 11:26 PM   #8
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,117

Rep: Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595
- 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 -
 
Old 09-13-2019, 10:15 AM   #9
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 326

Rep: Reputation: 285Reputation: 285Reputation: 285
Those LILO issues has nothing to do with the initrd, in my opinion.

In fact, it is about partitioning. An old version of (c)fdisk will preserve 63 sectors at the beginning of the disk. Like
Code:
[root@centos ~]# fdisk -ul

Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      417689      208813+  83  Linux
/dev/sda2         2522205    13799834     5638815   83  Linux
/dev/sda3        13799835    16771859     1486012+  8e  Linux LVM
/dev/sda4          417690     2522204     1052257+   5  Extended
/dev/sda5          417753     2522204     1052226   82  Linux swap /     Solaris
Those first 63 sectors are used by LILO for its setup.

BUT, the modern Linux kernels will need more space. Not a problem if you partition a drive with a modern (c)fdisk which preserves 2048 sectors, like:
Code:
bash-5.0# fdisk -l /dev/sdb
Disk /dev/sdb: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EZEX-00B
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xc4cd6b35

Device     Boot      Start        End    Sectors  Size Id Type
/dev/sdb1  *          2048  419432447  419430400  200G  7 HPFS/NTFS/exFAT
/dev/sdb2        419432448 1935673343 1516240896  723G 83 Linux
/dev/sdb3       1935673344 1952450559   16777216    8G 82 Linux swap
So, in my humble opinion the way is partioned this particular drive is not compatible with the modern LILO and those big Linux kernels from today.

Last edited by ZhaoLin1457; 09-13-2019 at 10:36 AM.
 
3 members found this post helpful.
Old 09-13-2019, 10:20 AM   #10
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 326

Rep: Reputation: 285Reputation: 285Reputation: 285
Quote:
Originally Posted by abga View Post
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.
 
1 members found this post helpful.
Old 09-13-2019, 11:10 AM   #11
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,117

Rep: Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595
Quote:
Originally Posted by ZhaoLin1457 View Post
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
 
Old 09-13-2019, 05:21 PM   #12
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,117

Rep: Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595
@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.



@ZhaoLin1457

Got some time to test your theory, also found a discussion that you might have used as inspiration for your reply:
https://superuser.com/questions/3525...-instead-of-63
+
http://jdebp.eu./FGA/disc-partition-alignment.html

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
 
Old 09-14-2019, 05:40 PM   #13
ernie young
LQ Newbie
 
Registered: Feb 2016
Distribution: Slackware 14.2
Posts: 25

Original Poster
Rep: Reputation: Disabled
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?
 
Old 09-14-2019, 06:38 PM   #14
colorpurple21859
Senior Member
 
Registered: Jan 2008
Location: florida panhandle
Distribution: slackware64-current, arch, ubuntu, others
Posts: 3,346

Rep: Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543
If it was me I would add the generic entries to the bottom of the working lilo.config one at a time to see what happens.
 
Old 09-14-2019, 07:52 PM   #15
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,117

Rep: Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595Reputation: 595
@ernie young

liloconfig will overwrite your /etc/lilo.conf, that's why I advised you to make a backup.

I'm sorry, I have no experience with KVM and what I could find on the net regarding the disk storage implies virtio devices and lilo needs some special tuning for being able to boot from them:
https://www.cyberciti.biz/faq/how-to...virsh-command/
https://www.linux-kvm.org/page/Boot_...ting_with_lilo
But that's not your case as I understand from the naming of your storage /dev/sda* instead of /dev/vda*

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):
Code:
image = /boot/vmlinuz-generic-4.19.72
#initrd = /boot/initrd-4.19.72.gz
root = /dev/sda2
label = "4.19.72"
read-only

image = /boot/vmlinuz-generic-4.19.59
#initrd = /boot/initrd-4.19.59.gz
root = /dev/sda2
label = "4.19.59"
read-only
2. Try using GRUB instead of LILO ... for your KVM setup
https://docs.slackware.com/howtos:sl..._first_install
&
https://docs.slackware.com/howtos:sl..._from_hdd#grub
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] lilo: Setup length exceeds 63 maximum; leeeoooooo Slackware 13 05-09-2012 08:36 PM
Error 18 : Selected cylinder exceeds maximum supported by BIOS Jakepal Linux - Newbie 3 09-20-2011 03:55 PM
Error 18: Selected cylinder exceeds maximum supported by BIOS brjoon1021 Linux - General 2 04-07-2008 03:37 PM
grub error 18: selected cylinder exceeds maximum supported by bios raport Linux - General 3 05-10-2007 01:55 AM
Triple boot cylinder exceeds maximum supported by the bios wlfdgcrkz Linux - Software 1 06-15-2003 11:14 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:12 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration