initrd ?

rkelsen · 09-03-2023, 04:17 AM

Quote:

Originally Posted by Petri Kaukasoina

Even faster if you once prepare /etc/mkinitrd.conf

Thanks for the tip!

Petri Kaukasoina · 09-03-2023, 04:21 AM

Quote:

Originally Posted by rkelsen

How long does it take to go through all of the configuration options to work out precisely what is needed and what is not?

Quote:

Originally Posted by enorbet

I'm not saying anyone is silly for using a generic kernel and an initrd and messing with mklinitrd or geninitrd. If that works for you that is perfectly valid but I am going to build a custom kernel anyway...

I build my kernels, too, because I follow the latest kernels (now 6.5.1). It is not needed to go through all of the configuration options. For example, if you would only use initrd to load the ext4 module, it does not take many seconds to copy Patrick's latest config-generic-6.1.51.x64 to .config, run 'make menuconfig', and change "The Extended 4 (ext4) filesystem" setting (CONFIG_EXT4_FS) to compile ext4 built-in. And you can use the same .config next time, no need to reconfigure.

enorbet · 09-03-2023, 04:29 AM

Quote:

Originally Posted by rkelsen

The barrier is in your head. You've built it up in your mind to be bigger than it is.

Everything you need to know is in the 598 word mini-HOWTO symlinked in the /boot directory of a standard Slackware installation. This document first appeared in Slackware on 21 June 2004, and was first included in the 10.0 release... >19 years ago. It's worth reading, if only to slay the dragon in your own head.

It's my imagination because my workflow isn't the same as yours? I don't understand why you don't get it that within just a few minutes of first boot or a kernel upgrade I rebuild the kernel anyway, so why not make one step, taking mere seconds longer, to avoid complexity and further steps? I've been working this way since Slackware v7.

fourtysixandtwo · 09-03-2023, 04:41 AM

To expand on Petri's method (using /etc/mkinitrd.conf) and if you have multiple kernels installed via installpkg...

For multiple kernels, I found checking /lib/modules unreliable due to orphan directories being left behind. But obviously not a problem if you keep it clean or use it like Petri does for a single kernel.

Code:

kmod=`( cd /var/lib/pkgtools/packages/ ; ls -v kernel-modules* ) | awk -F- '{printf"%s:", $3}' |sed 's/:$//'` && echo $kmod

mkinitrd -F -k $kmod

Petri Kaukasoina · 09-03-2023, 04:49 AM

Still another variation:

Code:

KERNEL_VERSION=$(cd /boot; echo vmlinuz-generic-*|sed 's/vmlinuz-generic-//g'|sed 's/ /:/g')

It may be more reliable than looking at the module directories (third-party modules left there?)

rkelsen · 09-03-2023, 05:08 AM

Quote:

Originally Posted by enorbet

It's my imagination because my workflow isn't the same as yours?

Don't get upset. It's your system, go do whatever you like.

But don't claim that building a kernel is quicker or easier than using an initrd, because it's not... by a substantial margin.

marav · 09-03-2023, 05:20 AM

Quote:

Originally Posted by Petri Kaukasoina

Still another variation:

Code:

KERNEL_VERSION=$(cd /boot; echo vmlinuz-generic-*|sed 's/vmlinuz-generic-//g'|sed 's/ /:/g')

It may be more reliable than looking at the module directories (third-party modules left there?)

I use this one:

Code:

KERNEL_VERSION=$(grep "^VERSION = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev).$(grep "^PATCHLEVEL = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev).$(grep "^SUBLEVEL = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev)$(grep "^EXTRAVERSION = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev)

fourtysixandtwo · 09-03-2023, 05:28 AM

Quote:

Originally Posted by Petri Kaukasoina

Still another variation:

Code:

KERNEL_VERSION=$(cd /boot; echo vmlinuz-generic-*|sed 's/vmlinuz-generic-//g'|sed 's/ /:/g')

It may be more reliable than looking at the module directories (third-party modules left there?)

Indeed, and would work better with manually installed kernels.

In my case it's the misc dir and modules.* files that get left there.

pan64 · 09-03-2023, 05:41 AM

Quote:

Originally Posted by marav

I use this one:

Code:

KERNEL_VERSION=$(grep "^VERSION = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev).$(grep "^PATCHLEVEL = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev).$(grep "^SUBLEVEL = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev)$(grep "^EXTRAVERSION = " /usr/src/linux/Makefile | rev | cut -d' ' -f1 | rev)

what about

Code:

KERNEL_VERSION=$(make -f <makefile> -s kernelversion)

?

marav · 09-03-2023, 05:52 AM

Quote:

Originally Posted by pan64

what about

Code:

KERNEL_VERSION=$(make -f <makefile> -s kernelversion)

?

That means you must have a compiler to catch the version

pan64 · 09-03-2023, 05:59 AM

Quote:

Originally Posted by marav

That means you must have a compiler to catch the version

No, that means make should be available. No compiler required.
Otherwise a simple awk can work too:

Code:

awk '/^VERSION = / {v=$NF} 
     /^PATCHLEVEL = / {pl=$NF}
     /^SUBLEVEL = / {sl=$NF}
     /^EXTRAVERSION = / {ev=$NF}
     END { printf "%s.%s.%s%s", v, pl, sl, ev }' <makefile>

(something like this)

marav · 09-03-2023, 06:10 AM

Quote:

Originally Posted by pan64

No, that means make should be available. No compiler required.
Otherwise a simple awk can work too:

Code:

awk '/^VERSION = / {v=$NF} 
     /^PATCHLEVEL = / {pl=$NF}
     /^SUBLEVEL = / {sl=$NF}
     /^EXTRAVERSION = / {ev=$NF}
     END { printf "%s.%s.%s%s", v, pl, sl, ev }' <makefile>

(something like this)

It's just based on what Pat does:
http://ftp.slackware.com/pub/slackwa...ric.SlackBuild
There are several way to do it, I just choose one :-)

gus3 · 09-03-2023, 07:05 AM

I had this, 3 years ago:

A desktop, a server/firewall, a (normal-sized) laptop, and a netbook, all running Slackware-current. All set up to install the latest kernel with "mkinitrd -F ... && lilo" with the same command. And of course, the same "su" password (but that's because I'm just lazy). The next step? Duplicate the 4 sessions into a single input, via "multixterm". I could "upgradepkg", with symlinks for x86_64 or i686, and then go to /boot to do the installation stuff.

That setup beforehand, paid off really well, with outputs showing health and consistency

chrisretusn · 09-03-2023, 09:29 AM

We all do things a bit differently. I use symlinks in /boot to reference the kernels; vmlinuz-generic-stock, vmlinuz-generic-working and occasionally vmlinuz-generic-testing.

In my mkinitrd.conf I have the following:

Code:

KERNEL_VERSION=$(readlink vmlinuz-generic-[swt]* | cut -d- -f3 | sort | sed ':a;N;$!ba;s/\n/:/g')

This nicely formats to 'KERNEL_VERSION=6.1.50:6.1.51'

The "sort" is not really needed as mkinitrd does not care about what order the kernel versions are in the list, that "sort" is for me.

So all I need is to use is 'mkinitrd -F'

Thanks to @Petri Kaukasoina for this idea.

What I used to do was 'mkinitrd -F -k 6.1.50:6.1.51'

I always run mkinitrd from /boot/.

enorbet · 09-03-2023, 01:03 PM

Quote:

Originally Posted by rkelsen

Don't get upset. It's your system, go do whatever you like.

But don't claim that building a kernel is quicker or easier than using an initrd, because it's not... by a substantial margin.

I wasn't upset before but now I am a wee bit because you are misrepresenting what I have written. I never made the claim that an isolated instance of building a kernel is quicker or easier than generating an initrd. I won't bore everyone with what I actually wrote since it is already a matter of record. Just please stop misepresenting my words to suit your personal preference and workflow. Your way is fine and so is mine.