[gentoo-user] new genkernel problem

[gentoo-user] new genkernel problem

[Jack]

I'm currently running a 5.6.10 kernel, compiled with genkernel along  
with an initramfs.  That was compiled with gcc-9.3.0.  Since then,  
using gcc-10.1.0, I have not successfully run genkernel.  Initially it  
was kernel compile failures due to the -fnocommon bug.  With a patch,  
the kernel compile completed fine, and the patch is no longer needed  
for 5.6.16 or 5.7.0.  However, all recent attempts at running genkernel  
fail during creation of initramfs.  (This is genkernel-9999, re-emerged  
yesterday.)

* Gentoo Linux Genkernel; Version 4.0.7-4-g06acd6f-git
* Using genkernel configuration from '/etc/genkernel.conf' ...
* Running with options: --lvm --firmware --microcode  
--kernel-append-localversion=-gcc-10 all

* Working with Linux kernel 5.7.0-gentoo-x86_64-gcc-10-01 for x86_64
* Using kernel config file  
'/etc/kernels/kernel-config-5.7.0-gentoo-x86_64-gcc-10-01' ...
*
* Note: The version above is subject to change (depends on config and  
status of kernel sources).

* kernel: >> Initializing ...
*         >> Running 'make clean' ...
*         >> --no-mrproper is set; Skipping 'make mrproper' ...
*         >> --no-oldconfig is set; Skipping 'make oldconfig' ...
*         >> Running 'make olddefconfig' due to changed kernel options  
...
*         >> Kernel version has changed (probably due to config change)  
since genkernel start:
*            We are now building Linux kernel  
5.7.0-gentoo-x86_64-gcc-10 for x86_64 ...
*         >> Compiling 5.7.0-gentoo-x86_64-gcc-10 bzImage ...
*         >> Compiling 5.7.0-gentoo-x86_64-gcc-10 modules ...
*         >> Installing 5.7.0-gentoo-x86_64-gcc-10 modules (and  
stripping) ...
*         >> Generating module dependency data ...
*         >> Compiling out-of-tree module(s) ...
*         >> Saving config of successful build to  
'/etc/kernels/kernel-config-5.7.0-gentoo-x86_64-gcc-10' ...

* initramfs: >> Initializing ...
*         >> Appending devices cpio data ...
*         >> Appending base_layout cpio data ...
*         >> Appending auxilary cpio data ...
*         >> Appending busybox cpio data ...
*         >> Appending blkid cpio data ...
*         >> Appending gpg cpio data ...
* ERROR: Command 'nice -n10 make -j8 --load-average 10 V=1' failed!
* ERROR: create_initramfs(): append_data(): append_gpg():  
populate_binpkg(): gkbuild(): Failed to create binpkg of gnupg-1.4.23!

and, of course, I wouldn't really expect gcc-10 to be able to compile  
gnupg-1.4.23.  (The detailed log does show the multiple definition  
errors.)  That version of gnupg  is coded in the ebuild, so hopefully  
there is SOME reason for selecting it.  Also - I now see that I can  
give --no-gpg to genkernel to omit gnupg from the initramfs - that's  
running now.

I'd be surprised if I am really the only one facing this, but I haven't  
found any other reports.  (It's quite possible my search-fu isn't.)  I  
don't know exactly when this started showing up, since I THOUGHT I had  
run genkernel successfully since then, but although there are several  
vmlinuz and sysmap files in /boot, there is only the single initramfs  
which I currently boot with.

Thanks for any thoughts or suggestions.

Jack

Re: [gentoo-user] new genkernel problem

[Andrew Udvare]

On Fri, 5 Jun 2020 at 15:02, Jack <ostroffjh@users.sourceforge.net> wrote:
> Thanks for any thoughts or suggestions.
>
> Jack

I would keep GCC 9 for now. I've run into a few issues with GCC 10
compiling various packages so I have kept GCC 9 on my system. There's
not some serious detriment to not using GCC 10 for 99% of people. Most
distros still use an older version.

Also, have you considered trying Dracut for initramfs generation? I
don't know how well it works with genkernel as I don't use that (I
manually configure my kernels).

Re: [gentoo-user] new genkernel problem

[Jack]

On 2020.06.05 16:24, Andrew Udvare wrote:
> On Fri, 5 Jun 2020 at 15:02, Jack <ostroffjh@users.sourceforge.net>  
> wrote:
> > Thanks for any thoughts or suggestions.
> >
> > Jack
> 
> I would keep GCC 9 for now. I've run into a few issues with GCC 10  
> compiling various packages so I have kept GCC 9 on my system. There's  
> not some serious detriment to not using GCC 10 for 99% of people.  
> Most distros still use an older version.
> 
> Also, have you considered trying Dracut for initramfs generation? I  
> don't know how well it works with genkernel as I don't use that (I  
> manually configure my kernels).

Thanks for the suggestion, and I do still have gcc-9.3 installed.   
However, when gcc-10 was marked stable, I worked on recompiling almost  
my entire system with it.  I have very few packages that simply can't  
deal with it yet, and I suspect a few of those are not sufficiently  
supported at all that they have a good chance of getting tree-cleaned.   
Sort of parallel to getting rid of python-2.

I used to do all my kernel configuration and setup manually on my old  
box (with legacy grub).  When I upgraded to my new PC with a Ryzen 5  
2600 and started using lvm, I ended up needing an initramfs, and  
managed to get genkernel working for me, without TOO much of an  
effort.  Right now, it's run genkernel, and when I'm happy, run  
grub-mkconfig, and it works.  If I ever go to a manually crafted  
grub.cfg, I might consider a different way of creating my intramfs, but  
I'd rather not introduce yet another moving part if I don't really need  
to.

Anyway, I'm writing this running my shiny new 5.7 kernel,  having run  
genkernel with --no-gpg.  I had not explicitly turned that on; I  
suppose it's just the default, unless I missed something in the config  
file.

Re: [gentoo-user] new genkernel problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Fri, 05 Jun 2020 16:48:30 -0400, Jack wrote:

> I used to do all my kernel configuration and setup manually on my old  
> box (with legacy grub).  When I upgraded to my new PC with a Ryzen 5  
> 2600 and started using lvm, I ended up needing an initramfs, and  
> managed to get genkernel working for me, without TOO much of an  
> effort.  Right now, it's run genkernel, and when I'm happy, run  
> grub-mkconfig, and it works.  If I ever go to a manually crafted  
> grub.cfg, I might consider a different way of creating my intramfs, but
> I'd rather not introduce yet another moving part if I don't really need
> to.

dracut uses an initramfs naming convention recognised by grub-mkconfig.


-- 
Neil Bothwick

Use Colgate toothpaste or end up with teeth like a Ferengi.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] new genkernel problem

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

Andrew Udvare wrote:
> On Fri, 5 Jun 2020 at 15:02, Jack <ostroffjh@users.sourceforge.net> wrote:
>> Thanks for any thoughts or suggestions.
>>
>> Jack
> I would keep GCC 9 for now. I've run into a few issues with GCC 10
> compiling various packages so I have kept GCC 9 on my system. There's
> not some serious detriment to not using GCC 10 for 99% of people. Most
> distros still use an older version.
>
> Also, have you considered trying Dracut for initramfs generation? I
> don't know how well it works with genkernel as I don't use that (I
> manually configure my kernels).
>
>


When you install your kernel, do you use make install or do you copy the
kernel to /boot manually?  I do mine manually but also copy it manually
as well.  That makes it hard for me to recall how to use the dracut
command.  It requires a kernel version etc etc. 

If you do copy yours manually to /boot, what command do you use for
dracut?  Maybe I'm doing it a hard way or something and you have a
easier method. 

Thanks.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: [gentoo-user] new genkernel problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Fri, 5 Jun 2020 15:57:07 -0500, Dale wrote:

> When you install your kernel, do you use make install or do you copy the
> kernel to /boot manually?  I do mine manually but also copy it manually
> as well.  That makes it hard for me to recall how to use the dracut
> command.  It requires a kernel version etc etc. 

I use make install. If I trust the makefile to build the kernel and it's
module tree, and copy the modules to the correct location, why wouldn't I
trust it to copy a single file to /boot at the same time?
 
> If you do copy yours manually to /boot, what command do you use for
> dracut?  Maybe I'm doing it a hard way or something and you have a
> easier method. 

cd /usr/src/linux
make all modules_install install
dracut --kver=$(cat include/config/kernel.release)

It doesn't get much easier ;-)


-- 
Neil Bothwick

DCE seeks DTE for mutual exchange of data.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] new genkernel problem

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

Neil Bothwick wrote:
> On Fri, 5 Jun 2020 15:57:07 -0500, Dale wrote:
>
>> When you install your kernel, do you use make install or do you copy the
>> kernel to /boot manually?  I do mine manually but also copy it manually
>> as well.  That makes it hard for me to recall how to use the dracut
>> command.  It requires a kernel version etc etc. 
> I use make install. If I trust the makefile to build the kernel and it's
> module tree, and copy the modules to the correct location, why wouldn't I
> trust it to copy a single file to /boot at the same time?
>  
>> If you do copy yours manually to /boot, what command do you use for
>> dracut?  Maybe I'm doing it a hard way or something and you have a
>> easier method. 
> cd /usr/src/linux
> make all modules_install install
> dracut --kver=$(cat include/config/kernel.release)
>
> It doesn't get much easier ;-)
>
>


From what I've read, I like my way better.  I did have to change the
names from bzimage* to kernel* but other than that, I can use the naming
method I've used for years and keep the good kernels I want.  On
occasion I remove outdated ones I no longer plan to use.  I still wish I
didn't need the init thingy but still. 

My biggest problem, getting the dracut command options right.  If I
didn't need dracut, I'd be in heaven. 

Dale

:-)  :-)

[-- Attachment #2: Type: text/html, Size: 1925 bytes --]

Re: [gentoo-user] new genkernel problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Sat, 6 Jun 2020 10:13:56 -0500, Dale wrote:

> >> If you do copy yours manually to /boot, what command do you use for
> >> dracut?  Maybe I'm doing it a hard way or something and you have a
> >> easier method.   
> > cd /usr/src/linux
> > make all modules_install install
> > dracut --kver=$(cat include/config/kernel.release)
> >
> > It doesn't get much easier ;-)


> From what I've read, I like my way better.  I did have to change the
> names from bzimage* to kernel* but other than that, I can use the naming
> method I've used for years and keep the good kernels I want.

make install names the kernels vmlinuz-$VERSION, and updates a symlink to
vmlinuz if one exists.

> On
> occasion I remove outdated ones I no longer plan to use.  I still wish I
> didn't need the init thingy but still.

make install doesn't remove anything, that's your job!
 
> My biggest problem, getting the dracut command options right.  If I
> didn't need dracut, I'd be in heaven. 

If you have a plain setup, dracut shouldn't need any options.


-- 
Neil Bothwick

Two rights don't make a wrong, they make an airplane.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] new genkernel problem

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]

Neil Bothwick wrote:
> On Sat, 6 Jun 2020 10:13:56 -0500, Dale wrote:
>
>>>> If you do copy yours manually to /boot, what command do you use for
>>>> dracut?  Maybe I'm doing it a hard way or something and you have a
>>>> easier method.   
>>> cd /usr/src/linux
>>> make all modules_install install
>>> dracut --kver=$(cat include/config/kernel.release)
>>>
>>> It doesn't get much easier ;-)
>
>> From what I've read, I like my way better.  I did have to change the
>> names from bzimage* to kernel* but other than that, I can use the naming
>> method I've used for years and keep the good kernels I want.
> make install names the kernels vmlinuz-$VERSION, and updates a symlink to
> vmlinuz if one exists.

But sometimes I have more than one of the same version.  I add a -1, -2,
-3 etc to them as I go.  From my understanding, make install doesn't do
that.  I do and with good reason. It seems make install won't accomplish
what I do by hand.


>> On
>> occasion I remove outdated ones I no longer plan to use.  I still wish I
>> didn't need the init thingy but still.
> make install doesn't remove anything, that's your job!

Neither does my method.  When /boot starts getting fullish, I use
uprecords to help determine what kernels to keep along with what kernels
would still be compatible with system changes.  In my opinion, the admin
should do those manually. 


>  
>> My biggest problem, getting the dracut command options right.  If I
>> didn't need dracut, I'd be in heaven. 
> If you have a plain setup, dracut shouldn't need any options.
>
>

I don't have a plain setup tho nor do I really want that setup.  I like
having backup kernels and my own numbering system.  It has worked for me
for decades, ever since I started using Gentoo and building my own
kernels.  I don't see any point in changing what works unless I can
streamline what I'm already getting with the results I expect.  If I
could get rid of the init thingy, I would have zero issues with my
method.  It's dracut that causes the issues. We all know how much I
dislike init thingys tho.  ;-)  That said, dracut hasn't failed me in a
while.  If it can't build correctly, it does spit out it failed.  It's
been a while since the init thingy it creates has failed as well.  So,
at least there is that. 

Dale

:-)  :-) 

P. S. Second drive passed the long selftest.  Copying files over as I
type.  I think this one might live.  I suspect at least one of them was
broken.  I just got the two mixed up.  They are identical in brand and
size.  Now to go rebuild the mineral site for the deer.  Picked up 150
lbs of goodness yesterday. :-D

[-- Attachment #2: Type: text/html, Size: 3952 bytes --]

Re: [gentoo-user] new genkernel problem

[Jack]

On 2020.06.06 12:34, Dale wrote:
> Neil Bothwick wrote:
> > On Sat, 6 Jun 2020 10:13:56 -0500, Dale wrote:
> >
> >>>> If you do copy yours manually to /boot, what command do you use  
> for
> >>>> dracut?  Maybe I'm doing it a hard way or something and you have  
> a
> >>>> easier method. 
> >>> cd /usr/src/linux
> >>> make all modules_install install
> >>> dracut --kver=$(cat include/config/kernel.release)
> >>>
> >>> It doesn't get much easier ;-)
> >
> >> From what I've read, I like my way better.  I did have to change  
> the
> >> names from bzimage* to kernel* but other than that, I can use the  
> naming
> >> method I've used for years and keep the good kernels I want.
> > make install names the kernels vmlinuz-$VERSION, and updates a  
> symlink to
> > vmlinuz if one exists.
> 
> But sometimes I have more than one of the same version.  I add a -1,  
> -2,
> -3 etc to them as I go.  From my understanding, make install doesn't  
> do
> that.  I do and with good reason. It seems make install won't  
> accomplish
> what I do by hand.
That's what to use  CONFIG_LOCALVERSION for.  It gets appended to the  
kernel file name, and to the /usr/lib directory created by  
modules_install.  The hardest part of my figuring out how to use  
genkernel was that it overrides that value in .config, so I had to rig  
up a wrapper script so I could set that on the command line.  That's  
actually better for me, since I don't need to edit .config to rerun  
genkernel if something else changed.
> 
> >> On
> >> occasion I remove outdated ones I no longer plan to use.  I still  
> wish I
> >> didn't need the init thingy but still.
> > make install doesn't remove anything, that's your job!
> 
> Neither does my method.  When /boot starts getting fullish, I use
> uprecords to help determine what kernels to keep along with what  
> kernels
> would still be compatible with system changes.  In my opinion, the  
> admin
> should do those manually. 
> 
> 
> >  
> >> My biggest problem, getting the dracut command options right.  If I
> >> didn't need dracut, I'd be in heaven. 
> > If you have a plain setup, dracut shouldn't need any options.
> >
> >
> 
> I don't have a plain setup tho nor do I really want that setup.  I  
> like
> having backup kernels and my own numbering system.  It has worked for  
> me
> for decades, ever since I started using Gentoo and building my own
> kernels.  I don't see any point in changing what works unless I can
> streamline what I'm already getting with the results I expect.  If I
> could get rid of the init thingy, I would have zero issues with my
> method.  It's dracut that causes the issues. We all know how much I
> dislike init thingys tho.  ;-)  That said, dracut hasn't failed me in  
> a
> while.  If it can't build correctly, it does spit out it failed.  It's
> been a while since the init thingy it creates has failed as well.  So,
> at least there is that. 
Once I did get genkernel fully configured to my liking (especially  
getting it to append a string of my choosing to the names of all the  
files it creates in /boot and to the /lib/modules directory) it hasn't  
failed, unless the actual kernel compile failed (as for gcc-10, not  
fixed) or the failure to compile something to go into the initramfs  
that started this thread.  I imagine dracut will produce a very similar  
initramfs, and maybe it wont try to pull in an outdated package, but.  
like you, I prefer to stick with what works, unless I have a good  
reason to change, such as simplifying my process, even if it does take  
some effort to get there.
> 
> Dale
> 
> :-)  :-) 
> 
> P. S. Second drive passed the long selftest.  Copying files over as I
> type.  I think this one might live.  I suspect at least one of them  
> was
> broken.  I just got the two mixed up.  They are identical in brand and
> size.  Now to go rebuild the mineral site for the deer.  Picked up 150
> lbs of goodness yesterday. :-D
> 

Re: [gentoo-user] new genkernel problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

On Sat, 6 Jun 2020 11:34:28 -0500, Dale wrote:

> >> From what I've read, I like my way better.  I did have to change the
> >> names from bzimage* to kernel* but other than that, I can use the
> >> naming method I've used for years and keep the good kernels I want.  
> > make install names the kernels vmlinuz-$VERSION, and updates a
> > symlink to vmlinuz if one exists.  
> 
> But sometimes I have more than one of the same version.  I add a -1, -2,
> -3 etc to them as I go.  From my understanding, make install doesn't do
> that.  I do and with good reason. It seems make install won't accomplish
> what I do by hand.

There's a kernel option that does that automatically, LOCALVERSION I
think, but it's years since I've needed to touch it.

> >> My biggest problem, getting the dracut command options right.  If I
> >> didn't need dracut, I'd be in heaven.   

> > If you have a plain setup, dracut shouldn't need any options.

> I don't have a plain setup tho nor do I really want that setup.

You don't boot from an encrypted drive (yet) or use unusual hardware,
that's what I meant by a plain system. Dracut handles booting from a a
btrfs root on a LUKS encrypted block device here with no fancy
configuration. It really is impressive the way it figures so much out for
itself.

> I like
> having backup kernels and my own numbering system.  It has worked for me
> for decades, ever since I started using Gentoo and building my own
> kernels.  I don't see any point in changing what works unless I can
> streamline what I'm already getting with the results I expect.  If I
> could get rid of the init thingy, I would have zero issues with my
> method.  It's dracut that causes the issues. We all know how much I
> dislike init thingys tho.  ;-)  That said, dracut hasn't failed me in a
> while.  If it can't build correctly, it does spit out it failed.  It's
> been a while since the init thingy it creates has failed as well.  So,
> at least there is that. 

I use a shell script to compile and install the kernel, build the
initramfs and then update the bootloader. It means the process is always
executed consistently and I only have to remember one command :)


-- 
Neil Bothwick

WinErr 002: No Error - Yet

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] new genkernel problem

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]

Neil Bothwick wrote:
> On Sat, 6 Jun 2020 11:34:28 -0500, Dale wrote:
>
>>>> From what I've read, I like my way better.  I did have to change the
>>>> names from bzimage* to kernel* but other than that, I can use the
>>>> naming method I've used for years and keep the good kernels I want.  
>>> make install names the kernels vmlinuz-$VERSION, and updates a
>>> symlink to vmlinuz if one exists.  
>> But sometimes I have more than one of the same version.  I add a -1, -2,
>> -3 etc to them as I go.  From my understanding, make install doesn't do
>> that.  I do and with good reason. It seems make install won't accomplish
>> what I do by hand.
> There's a kernel option that does that automatically, LOCALVERSION I
> think, but it's years since I've needed to touch it.

But if it changes how it works and I don't know it, that could cause
problems.  It could even remove something I don't want removed.  If I do
it myself, I know what is done and don't remove anything I don't want to
lose. Even the make commands change between kernels at times.  I suspect
make install has changes too.  I don't want to have to track kernel
changes just to know if I can use make install and still get what I have
now. 


>
>>>> My biggest problem, getting the dracut command options right.  If I
>>>> didn't need dracut, I'd be in heaven.   
>>> If you have a plain setup, dracut shouldn't need any options.
>> I don't have a plain setup tho nor do I really want that setup.
> You don't boot from an encrypted drive (yet) or use unusual hardware,
> that's what I meant by a plain system. Dracut handles booting from a a
> btrfs root on a LUKS encrypted block device here with no fancy
> configuration. It really is impressive the way it figures so much out for
> itself.
>

What I meant was, I don't use make install because I do things
differently than make install does.  It's not "plain" in that regard. 


>> I like
>> having backup kernels and my own numbering system.  It has worked for me
>> for decades, ever since I started using Gentoo and building my own
>> kernels.  I don't see any point in changing what works unless I can
>> streamline what I'm already getting with the results I expect.  If I
>> could get rid of the init thingy, I would have zero issues with my
>> method.  It's dracut that causes the issues. We all know how much I
>> dislike init thingys tho.  ;-)  That said, dracut hasn't failed me in a
>> while.  If it can't build correctly, it does spit out it failed.  It's
>> been a while since the init thingy it creates has failed as well.  So,
>> at least there is that. 
> I use a shell script to compile and install the kernel, build the
> initramfs and then update the bootloader. It means the process is always
> executed consistently and I only have to remember one command :)
>
>


Well, we know my scripting ability isn't anywhere near that advanced. 
Claiming I can do a basic script is a stretch.  ROFL  When I do it
manually, I get consistent results to and I know what steps were taken
to get there.  My only problem is recalling the options for dracut. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 4639 bytes --]

Re: [gentoo-user] new genkernel problem

[Jack]

[-- Attachment #1: Type: text/plain, Size: 4028 bytes --]

On 6/6/20 6:34 PM, Dale wrote:
> Neil Bothwick wrote:
>> On Sat, 6 Jun 2020 11:34:28 -0500, Dale wrote:
>>>>>  From what I've read, I like my way better.  I did have to change the
>>>>> names from bzimage* to kernel* but other than that, I can use the
>>>>> naming method I've used for years and keep the good kernels I want.
>>>> make install names the kernels vmlinuz-$VERSION, and updates a
>>>> symlink to vmlinuz if one exists.
>>> But sometimes I have more than one of the same version.  I add a -1, -2,
>>> -3 etc to them as I go.  From my understanding, make install doesn't do
>>> that.  I do and with good reason. It seems make install won't accomplish
>>> what I do by hand.
>> There's a kernel option that does that automatically, LOCALVERSION I
>> think, but it's years since I've needed to touch it.
>
> But if it changes how it works and I don't know it, that could cause 
> problems.  It could even remove something I don't want removed.  If I 
> do it myself, I know what is done and don't remove anything I don't 
> want to lose. Even the make commands change between kernels at times.  
> I suspect make install has changes too.  I don't want to have to track 
> kernel changes just to know if I can use make install and still get 
> what I have now.
LOCALVERSION is a kernel setting in .config.  All the kernel make 
commands handle it consistently, and have not changed in a long time.  
They just append that string to files they create (kernel and symbolmap) 
and the /lib/modules directory.  (For the init thingy, I assume you 
would give dracut that name - the exact name of the kernel to boot in 
/boot, and it makes an init thingy with a matching name.  It was 
genkernel where I was talking about things changing - and yes, genkernel 
changed it's basic kernel naming conventions a few months back, but that 
was clearly a big change, and there was a news item about it, if I 
remember.  If you are only or mostly recompiling the kernel after 
changing config settings, it's trivial to change LOCALVERSION from -01 
to -02 at the same time.
>>>>> My biggest problem, getting the dracut command options right.  If I
>>>>> didn't need dracut, I'd be in heaven.
>>>> If you have a plain setup, dracut shouldn't need any options.
>>> I don't have a plain setup tho nor do I really want that setup.
>> You don't boot from an encrypted drive (yet) or use unusual hardware,
>> that's what I meant by a plain system. Dracut handles booting from a a
>> btrfs root on a LUKS encrypted block device here with no fancy
>> configuration. It really is impressive the way it figures so much out for
>> itself.
>
> What I meant was, I don't use make install because I do things 
> differently than make install does.  It's not "plain" in that regard.
>
>
>>> I like
>>> having backup kernels and my own numbering system.  It has worked for me
>>> for decades, ever since I started using Gentoo and building my own
>>> kernels.  I don't see any point in changing what works unless I can
>>> streamline what I'm already getting with the results I expect.  If I
>>> could get rid of the init thingy, I would have zero issues with my
>>> method.  It's dracut that causes the issues. We all know how much I
>>> dislike init thingys tho.  ;-)  That said, dracut hasn't failed me in a
>>> while.  If it can't build correctly, it does spit out it failed.  It's
>>> been a while since the init thingy it creates has failed as well.  So,
>>> at least there is that.
>> I use a shell script to compile and install the kernel, build the
>> initramfs and then update the bootloader. It means the process is always
>> executed consistently and I only have to remember one command :)
>>
>>
>
>
> Well, we know my scripting ability isn't anywhere near that advanced.  
> Claiming I can do a basic script is a stretch.  ROFL When I do it 
> manually, I get consistent results to and I know what steps were taken 
> to get there.  My only problem is recalling the options for dracut.
>
> Dale
>
> :-)  :-)

[-- Attachment #2: Type: text/html, Size: 5854 bytes --]

Re: [gentoo-user] new genkernel problem

[antlists]

On 06/06/2020 23:11, Neil Bothwick wrote:
> You don't boot from an encrypted drive (yet) or use unusual hardware,
> that's what I meant by a plain system. Dracut handles booting from a a
> btrfs root on a LUKS encrypted block device here with no fancy
> configuration. It really is impressive the way it figures so much out for
> itself.

All I need is for it to figure out dm-integrity, and it'll boot my setup 
fine ... hard-drive -> dm-integrity -> md-raid -> lvm -> filesystem

I'm trying to get round the fact that a damaged disk will mess up raid, 
so I want to add just that little bit more robustness :-)

Cheers,
Wol

Re: [gentoo-user] new genkernel problem

[madscientistatlarge]

hey, when you come over bring your' sam's club card, so I can get a pallet of coke.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 11, 2020 8:18 AM, antlists <antlists@youngman.org.uk> wrote:

> On 06/06/2020 23:11, Neil Bothwick wrote:
>
> > You don't boot from an encrypted drive (yet) or use unusual hardware,
> > that's what I meant by a plain system. Dracut handles booting from a a
> > btrfs root on a LUKS encrypted block device here with no fancy
> > configuration. It really is impressive the way it figures so much out for
> > itself.
>
> All I need is for it to figure out dm-integrity, and it'll boot my setup
> fine ... hard-drive -> dm-integrity -> md-raid -> lvm -> filesystem
>
> I'm trying to get round the fact that a damaged disk will mess up raid,
> so I want to add just that little bit more robustness :-)
>
> Cheers,
> Wol

Re: [gentoo-user] new genkernel problem

[madscientistatlarge]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 11, 2020 8:18 AM, antlists <antlists@youngman.org.uk> wrote:

> On 06/06/2020 23:11, Neil Bothwick wrote:
>
> > You don't boot from an encrypted drive (yet) or use unusual hardware,
> > that's what I meant by a plain system. Dracut handles booting from a a
> > btrfs root on a LUKS encrypted block device here with no fancy
> > configuration. It really is impressive the way it figures so much out for
> > itself.
>
> All I need is for it to figure out dm-integrity, and it'll boot my setup
> fine ... hard-drive -> dm-integrity -> md-raid -> lvm -> filesystem
>
> I'm trying to get round the fact that a damaged disk will mess up raid,
> so I want to add just that little bit more robustness :-)
>
> Cheers,
> Wol

Are you just using striping?  A failed drive would be bad then, X times (where X is the number of drives) worse than a normal single drive failure.  It's important to remember that drives fail completely and suddenly sometimes in any case.  I'm building a file server for my house and plan to use raid6 to mitigate that issue, It also allows me to comfortably use refurbished drives (6 of the 4 tb htsg drives, $60 ea. on ebay).  I am keeping a spare drive just in case, and I used multiple sources so the drives will hopefully be less likely to fail in a group over a short time.  It'll still be very fast and near the limit of my Gb/s network.

Re: [gentoo-user] new genkernel problem

[antlists]

On 06/06/2020 23:11, Neil Bothwick wrote:
> You don't boot from an encrypted drive (yet) or use unusual hardware,
> that's what I meant by a plain system. Dracut handles booting from a a
> btrfs root on a LUKS encrypted block device here with no fancy
> configuration. It really is impressive the way it figures so much out for
> itself.

All I need is for it to figure out dm-integrity, and it'll boot my setup 
fine ... hard-drive -> dm-integrity -> md-raid -> lvm -> filesystem

I'm trying to get round the fact that a damaged disk will mess up raid, 
so I want to add just that little bit more robustness :-)

Cheers,
Wol