[gentoo-user] Gentoo-sources 5.7.x

[gentoo-user] Gentoo-sources 5.7.x

[Peter Humphrey]

Afternoon all,

Is there something special for me to set in the kernel config to enable it to 
find the root partition? I copied the config from 5.4.38, ran oldconfig and 
followed most of the suggested answers; but it won't boot.

# cat /boot/loader/entries/30-gentoo-5.7.1.conf
title Gentoo Linux 5.7.1
linux /vmlinuz-5.7.1-gentoo
options root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0 
raid=noautodetect

That file hasn't changed, other than the kernel version.

On booting with that setup, I got an error immediately (from the UEFI BIOS, I 
assume) complaining of an invalid parameter. A few seconds later the kernel 
panicked because it couldn't find the root device.

So I chopped off everything after the 1p4 and booted again. No invalid-
parameter error this time, but still it couldn't find the boot device.

Something has changed, and I can't see what it is.

I've tried compiling the kernel (and @system) with gcc-9.3.0 and with 
gcc-10.1.0, but I saw no difference.

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x

[Andrew Udvare]

[-- Attachment #1.1: Type: text/plain, Size: 932 bytes --]

On 08/06/2020 11:06, Peter Humphrey wrote:
> Afternoon all,
> 
> Is there something special for me to set in the kernel config to enable it to 
> find the root partition? I copied the config from 5.4.38, ran oldconfig and 
> followed most of the suggested answers; but it won't boot.

Sounds like missing drivers. oldconfig didn't do everything it was
supposed to. Moving across multiple major versions, this is to be
expected. A lot of names of things have changed.

Do a comparison of your configuration between old and new.

diff -uN old-config-file /usr/src/linux/.config

Make sure to at least enable NVME with CONFIG_BLK_DEV_NVME=y and try
booting 5.7 again. Other than that, the naming scheme may have changed
but I don't know about this. For better future-proofing, use a UUID of
your root partition rather than a device name.

root=UUID=...

You can get this UUID with the blkid command.

Andrew


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

Re: [gentoo-user] Gentoo-sources 5.7.x

[Peter Humphrey]

On Monday, 8 June 2020 16:32:07 BST Andrew Udvare wrote:

> Sounds like missing drivers. oldconfig didn't do everything it was
> supposed to. Moving across multiple major versions, this is to be
> expected. A lot of names of things have changed.
> 
> Do a comparison of your configuration between old and new.
> 
> diff -uN old-config-file /usr/src/linux/.config

Hmm. 4570 lines, but much of it can be discounted.

> Make sure to at least enable NVME with CONFIG_BLK_DEV_NVME=y and try
> booting 5.7 again.

Yes, they were both set already - I couldn't have booted 5.4.38 without them.

> Other than that, the naming scheme may have changed but I don't know about
> this. For better future-proofing, use a UUID of your root partition rather
> than a device name.
> 
> root=UUID=...
> 
> You can get this UUID with the blkid command.

I'll try this in a minute - thanks for the idea. I've stuck with device names 
so far because (i) I can read them, and (ii) I can't ever have more than one 
NVMe device in this box.

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x

[Peter Humphrey]

On Tuesday, 9 June 2020 15:46:43 BST Peter Humphrey wrote:

> > Other than that, the naming scheme may have changed but I don't know about
> > this. For better future-proofing, use a UUID of your root partition rather
> > than a device name.
> > 
> > root=UUID=...
> > 
> > You can get this UUID with the blkid command.
> 
> I'll try this in a minute - thanks for the idea. I've stuck with device
> names so far because (i) I can read them, and (ii) I can't ever have more
> than one NVMe device in this box.

Nope. Didn't help. All I have now is dredging through the kernel config yet 
again, or possibly even trying an initrd. I hope I'm not being forced down 
that road after all these years.

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Peter Humphrey]

On Tuesday, 9 June 2020 15:56:52 BST Peter Humphrey wrote:
> On Tuesday, 9 June 2020 15:46:43 BST Peter Humphrey wrote:
> > > Other than that, the naming scheme may have changed but I don't know
> > > about
> > > this. For better future-proofing, use a UUID of your root partition
> > > rather
> > > than a device name.
> > > 
> > > root=UUID=...
> > > 
> > > You can get this UUID with the blkid command.
> > 
> > I'll try this in a minute - thanks for the idea. I've stuck with device
> > names so far because (i) I can read them, and (ii) I can't ever have more
> > than one NVMe device in this box.
> 
> Nope. Didn't help. All I have now is dredging through the kernel config yet
> again, or possibly even trying an initrd. I hope I'm not being forced down
> that road after all these years.

It was so simple, and the clue was in an earlier message.

# cat /boot/loader/entries/30-gentoo-5.7.1.conf
title Gentoo Linux 5.7.1initrd=/intel-uc.img
linux /vmlinuz-5.7.1-gentoo
options root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0 raid=noautodetect

All I had to do was to remove the slash from initrd=/intel-uc.img. I did that
in all the .../entries files and 5.4.38 also still boots happily.

Thanks to those who offered help.

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Neil Bothwick]

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

On Tue, 09 Jun 2020 17:07:40 +0100, Peter Humphrey wrote:

> > Nope. Didn't help. All I have now is dredging through the kernel
> > config yet again, or possibly even trying an initrd. I hope I'm not
> > being forced down that road after all these years.  
> 
> It was so simple, and the clue was in an earlier message.
> 
> # cat /boot/loader/entries/30-gentoo-5.7.1.conf
> title Gentoo Linux 5.7.1initrd=/intel-uc.img
> linux /vmlinuz-5.7.1-gentoo
> options root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0
> raid=noautodetect
> 
> All I had to do was to remove the slash from initrd=/intel-uc.img. I
> did that in all the .../entries files and 5.4.38 also still boots
> happily.

Did you also remove the leading slash from the kernel? I'm still running
5.4 but I tried removing the slashes from the kernel and initrds and it
booted fine. Thanks for the heads up, I'll be ready when 5.7+ goes
longterm.


-- 
Neil Bothwick

WinErr 008: Broken window - Watch out for glass fragments

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

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Peter Humphrey]

On Tuesday, 9 June 2020 18:29:50 BST Neil Bothwick wrote:
> On Tue, 09 Jun 2020 17:07:40 +0100, Peter Humphrey wrote:
> > > Nope. Didn't help. All I have now is dredging through the kernel
> > > config yet again, or possibly even trying an initrd. I hope I'm not
> > > being forced down that road after all these years.
> > 
> > It was so simple, and the clue was in an earlier message.
> > 
> > # cat /boot/loader/entries/30-gentoo-5.7.1.conf
> > title Gentoo Linux 5.7.1initrd=/intel-uc.img
> > linux /vmlinuz-5.7.1-gentoo
> > options root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0
> > raid=noautodetect

That's got corrupted somehow. My first post had it right, but the first line of 
the file above is not.

> > All I had to do was to remove the slash from initrd=/intel-uc.img. I
> > did that in all the .../entries files and 5.4.38 also still boots
> > happily.
> 
> Did you also remove the leading slash from the kernel? I'm still running
> 5.4 but I tried removing the slashes from the kernel and initrds and it
> booted fine. Thanks for the heads up, I'll be ready when 5.7+ goes
> longterm.

I didn't, no, but I'll try it.

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Peter Humphrey]

On Wednesday, 10 June 2020 09:57:18 BST Peter Humphrey wrote:
> On Tuesday, 9 June 2020 18:29:50 BST Neil Bothwick wrote:

> > Did you also remove the leading slash from the kernel? I'm still running
> > 5.4 but I tried removing the slashes from the kernel and initrds and it
> > booted fine. Thanks for the heads up, I'll be ready when 5.7+ goes
> > longterm.
> 
> I didn't, no, but I'll try it.

This is the new default boot entry:

# cat /boot/loader/entries/30-gentoo-5.7.1.conf
title Gentoo Linux 5.7.1
linux vmlinuz-5.7.1-gentoo
options root=/dev/nvme0n1p4 initrd=intel-uc.img net.ifnames=0 
raid=noautodetect

I've just booted from it.

I assume I wouldn't be able to if I removed the leading slash from root=

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Neil Bothwick]

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

On Wed, 10 Jun 2020 11:01:45 +0100, Peter Humphrey wrote:

> > > Did you also remove the leading slash from the kernel? I'm still
> > > running 5.4 but I tried removing the slashes from the kernel and
> > > initrds and it booted fine. Thanks for the heads up, I'll be ready
> > > when 5.7+ goes longterm.  
> > 
> > I didn't, no, but I'll try it.  
> 
> This is the new default boot entry:
> 
> # cat /boot/loader/entries/30-gentoo-5.7.1.conf
> title Gentoo Linux 5.7.1
> linux vmlinuz-5.7.1-gentoo
> options root=/dev/nvme0n1p4 initrd=intel-uc.img net.ifnames=0 
> raid=noautodetect
> 
> I've just booted from it.
> 
> I assume I wouldn't be able to if I removed the leading slash from root=

I /think/ you're right there.

Any reason you bury the iniitrd in the options list rather that having it
on a separate line? This is what I'm now using:

title	Desktop
version	5.4.38-gentoo
linux	vmlinuz-5.4.38-gentoo
options	root=LABEL=yooden rd.luks.uuid=luks-...
initrd	intel-uc.img
initrd	initramfs-5.4.38-gentoo.img


-- 
Neil Bothwick

Don't let your mind wander, it's too little to be let out alone.

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

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Peter Humphrey]

On Wednesday, 10 June 2020 15:49:30 BST Neil Bothwick wrote:

> Any reason you bury the iniitrd in the options list rather that having it
> on a separate line?

None in particular. Perhaps I was following an example. I don't think it 
matters much, especially as I rarely need to change it.

> This is what I'm now using:
> 
> title	Desktop
> version	5.4.38-gentoo
> linux	vmlinuz-5.4.38-gentoo
> options	root=LABEL=yooden rd.luks.uuid=luks-...
> initrd	intel-uc.img
> initrd	initramfs-5.4.38-gentoo.img

Maybe I'll take some ideas from that - thanks.

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Andrew Udvare]

[-- Attachment #1.1: Type: text/plain, Size: 2207 bytes --]

On 09/06/2020 12:07, Peter Humphrey wrote:
> On Tuesday, 9 June 2020 15:56:52 BST Peter Humphrey wrote:
> # cat /boot/loader/entries/30-gentoo-5.7.1.conf
> title Gentoo Linux 5.7.1initrd=/intel-uc.img
> linux /vmlinuz-5.7.1-gentoo
> options root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0 raid=noautodetect

Since you are using systemd-boot or something that fulfils that
specification[1], you can also build your kernel with EFI stub enabled
(CONFIG_EFI_STUB) and then simply put the binary in:

${ESP}/EFI/Linux/vmlinuz-5.7.1-gentoo.efi

You can then run `bootctl set-default vmlinuz-5.7.1-gentoo.efi` or on
the menu, select it and press d to set it within systemd-boot.

(My ASUS motherboard for some reason never lets me write EFI variables
from within Linux so I have to do it from within systemd-boot.)

You can specify the options in the kernel configuration as well:

CONFIG_CMDLINE="root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0
raid=noautodetect"

To add the /intel-uc.img to this configuration you either have to
include that in kernel configuration or you can use Dracut to build an
EFI image.

Kernel config:

CONFIG_INITRAMFS_SOURCE="/boot/intel_uc.img"

Or with Dracut:

dracut --force --uefi --uefi-stub
'/usr/lib/systemd/boot/efi/linuxx64.efi.stub' ...

Dracut will automatically pick up your kernel installed to /boot (from
kernel `make install`) and /boot/intel-uc.img (and other similar
things). It will also automatically place the file into

In both cases, you have to remember to update the EFI image/rebuild and
reinstall the kernel whenever you update intel-microcode.

The benefit to this is you don't have to maintain entries files, and you
keep configuration generally in one place: the kernel config. Then you
just drop in EFI binaries into the correct place and they will appear in
the menu. You could have always keep two Linux EFI binaries in
${ESP}/EFI/Linux/ in case the newest one fails.

If you want to do this semi-automatically as part of updates and with
UEFI secure boot signing, use my project: https://github.com/tatsh/upkeep

[1] https://systemd.io/BOOT_LOADER_SPECIFICATION/

--
Andrew



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

Re: [gentoo-user] Gentoo-sources 5.7.x [FIXED]

[Peter Humphrey]

On Tuesday, 9 June 2020 19:32:23 BST Andrew Udvare wrote:

[Snip much interesting stuff]

My motherboard is also Asus: an X99-A. I haven't overwritten the UEFI BIOS 
kernel image for quite a while; not since I arrived at a stable layout of 
/boot.

This is my /boot layout:

# tree /boot                                                
/boot
├── config-5.4.38-gentoo
├── config-5.4.38-gentoo-rescue
├── config-5.7.1-gentoo
├── early_ucode.cpio
├── EFI
│   ├── Boot
│   │   └── bootx64.efi
│   └── systemd
│       └── systemd-bootx64.efi
├── intel-uc.img
├── loader
│   ├── entries
│   │   ├── 08-gentoo-5.4.38-rescue.conf
│   │   ├── 09-gentoo-5.4.38-rescue.nonet.conf
│   │   ├── 30-gentoo-5.7.1.conf
│   │   ├── 32-gentoo-5.7.1.nox.conf
│   │   ├── 34-gentoo-5.7.1.nonet.conf
│   │   ├── 40-gentoo-5.4.38.conf
│   │   ├── 42-gentoo-5.4.38.nox.conf
│   │   └── 44-gentoo-5.4.38.nonet.conf
│   ├── loader.conf
│   └── random-seed
├── System.map-5.4.38-gentoo
├── System.map-5.4.38-gentoo-rescue
├── System.map-5.7.1-gentoo
├── vmlinuz-5.4.38-gentoo
├── vmlinuz-5.4.38-gentoo-rescue
└── vmlinuz-5.7.1-gentoo

It's the outcome of a good deal of effort to find a working structure, and I'd 
need some persuasion to change it again.  :)

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x

[Alan Mackenzie]

Hello, Peter.

Either an annoyance, or some potentially useful info:

On Tue, Jun 09, 2020 at 15:46:43 +0100, Peter Humphrey wrote:

> I'll try this in a minute - thanks for the idea. I've stuck with device
> names so far because (i) I can read them, and (ii) I can't ever have
> more than one NVMe device in this box.

If the reason for the "can't ever" is the lack of M2 slots on your
motherboard, you can get a PCIe board with an M2 slot on it.  This way
you can get two NVMe devices in a single box.  Provided you've got enough
PCIe lanes, and suchlike.  This is precisely my setup, where I've got two
500 Gb NVMe's in a raid-1 configuration.

> -- 
> Regards,
> Peter.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Gentoo-sources 5.7.x

[Peter Humphrey]

On Tuesday, 9 June 2020 16:45:56 BST Alan Mackenzie wrote:
> Hello, Peter.
> 
> Either an annoyance, or some potentially useful info:
> 
> On Tue, Jun 09, 2020 at 15:46:43 +0100, Peter Humphrey wrote:
> > I'll try this in a minute - thanks for the idea. I've stuck with device
> > names so far because (i) I can read them, and (ii) I can't ever have
> > more than one NVMe device in this box.
> 
> If the reason for the "can't ever" is the lack of M2 slots on your
> motherboard, you can get a PCIe board with an M2 slot on it.  This way
> you can get two NVMe devices in a single box.  Provided you've got enough
> PCIe lanes, and suchlike.  This is precisely my setup, where I've got two
> 500 Gb NVMe's in a raid-1 configuration.

I've heard of that arrangement, but I haven't looked into it because the spec 
says the M2 device occupies both PCI-x slots. There may be ways round this, 
but my 256GB drive is enough for me; I do have a couple of 1TB SATA SSDs as 
well.

-- 
Regards,
Peter.

Re: [gentoo-user] Gentoo-sources 5.7.x

[Rich Freeman]

On Mon, Jun 8, 2020 at 11:06 AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> Afternoon all,
>
> Is there something special for me to set in the kernel config to enable it to
> find the root partition? I copied the config from 5.4.38, ran oldconfig and
> followed most of the suggested answers; but it won't boot.
>
> # cat /boot/loader/entries/30-gentoo-5.7.1.conf
> title Gentoo Linux 5.7.1
> linux /vmlinuz-5.7.1-gentoo
> options root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0
> raid=noautodetect
>
> That file hasn't changed, other than the kernel version.
>
> On booting with that setup, I got an error immediately (from the UEFI BIOS, I
> assume) complaining of an invalid parameter. A few seconds later the kernel
> panicked because it couldn't find the root device.

Can you have your initrd launch a shell?  I'm not sure if the
nomenclature for the root device has changed.  It is also possible
you're missing some kernel option needed (maybe an NVME option got
renamed and you answered the new option No?).

If it is running the initrd then you probably can get it to launch a
shell and then you can poke around and see what it is doing.

Offhand though those are my two guesses:
1.  Driver config option got renamed and the new option is disabled.
2.  Some kernel change alters the naming of the root device so you're
giving it the wrong name now.

If you're using an initrd you should consider using a UUID/lable/etc
to identify the root device if possible.  That tends to be more robust
when stuff like this happens, though it won't help in #1.

-- 
Rich

Re: [gentoo-user] Gentoo-sources 5.7.x

[Neil Bothwick]

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

On Mon, 8 Jun 2020 11:38:03 -0400, Rich Freeman wrote:

> > # cat /boot/loader/entries/30-gentoo-5.7.1.conf
> > title Gentoo Linux 5.7.1
> > linux /vmlinuz-5.7.1-gentoo
> > options root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0
> > raid=noautodetect
> >
> > That file hasn't changed, other than the kernel version.
> >
> > On booting with that setup, I got an error immediately (from the UEFI
> > BIOS, I assume) complaining of an invalid parameter. A few seconds
> > later the kernel panicked because it couldn't find the root device.  
> 
> Can you have your initrd launch a shell?  I'm not sure if the
> nomenclature for the root device has changed.  It is also possible
> you're missing some kernel option needed (maybe an NVME option got
> renamed and you answered the new option No?).
> 
> If it is running the initrd then you probably can get it to launch a
> shell and then you can poke around and see what it is doing.

That's not an initrd with a shell though, it's just the intel microcode
update. You would need an additional dracut (or similar) generated initrd
to do what you suggest.


-- 
Neil Bothwick

I am McCoy of Bo...Damnit! I'm a doctor, not a collective!

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