From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] What are common SSDs does and don'ts.
Date: Mon, 7 Apr 2025 13:28:10 -0500 [thread overview]
Message-ID: <af62325e-eda8-6af7-dc30-e8b2563fe85f@gmail.com> (raw)
In-Reply-To: <9430467.CDJkKcVGEf@rogueboard>
Michael wrote:
> On Wednesday, 2 April 2025 05:04:12 British Summer Time Dale wrote:
>> Michael wrote:
>>> The second page, relevant to AMD CPUs, points to the particular microcode
>>> blob you'd need to use for your CPU:
>>>
>>> https://wiki.gentoo.org/wiki/AMD_microcode
>>>
>>> It explains the hexadecimal number '19h' corresponds to your decimal '25'.
>>> Therefore your family 25 CPU requires the 'amd-ucode/microcode_amd_fam19h'
>>> blob. Whether you build this as part of your initrd, or you specify it in
>>> your kernel config so it becomes part of the kernel image, is your call.
>>>
>>>> Either way, I do have the amd-uc.img thing in /boot. I think the
> firmware package puts it there.
>>> I think the initrd builder (e.g. dracut) puts it there and GRUB loads it.
>> I was wondering where that came from. Makes sense.
> Dracut is capable of building a separate initrd image with the required
> microcode for 'early microcode loading'. This is picked up by GRUB and loaded
> first thing during boot. This is the default dracut configuration since
> version 047.
>
> It is explained here:
>
> https://wiki.gentoo.org/wiki/Microcode#Dracut
>
>
>>>> Anyway, it finds it when I update grub config so I need a init thingy.
>>> You do not need an initrd if the only reason for running an initrd image
>>> is to load your microcode. The kernel is perfectly capable of doing this
>>> on its own - see the above links.
>> I was just clarifying that with Peter. So, if I have a microcode image
>> and a kernel, it will boot, with no init thingy?
> Your system will boot regardless. These are the permutations:
>
> 1. No microcode provided by you:
>
> The MoBo will load and use whatever version of microcode has been embedded in
> the EFI firmware made available by the OEM.
>
> 2. Microcode provided - embedded within your main initrd:
>
> The microcode will load as part of the main initrd.
>
> 3. Microcode provided - as a separate initrd image:
>
> The separate microcode initrd image, e.g. amd-uc.img, will be picked up by
> GRUB and loaded early in the boot process.
>
> 4. Microcode provided - embedded in the kernel image itself:
>
> The microcode binary blob is part of the kernel and will be loaded first
> before the rest of the kernel, provided the 'Firmware loading facility'
> [CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam19h.bin ...."] is built in
> the kernel and not configured as a module.
>
> https://wiki.gentoo.org/wiki/
> AMD_microcode#Supplying_the_microcode_files_to_the_kernel
>
>
>>>> I was kinda hoping I could ditch it but I guess it is the best way to
>>>> load the microcode thing. I've read it is best to load the microcode
>>>> pretty early. It was a thought.
>>> It's a good thought and your hope can still be realised. I suggest you
>>> start with reading the above two links.
>> I been reading those, a couple times or so. Just trying to clear up the
>> mud. LOL While I would like to just include this in the kernel itself,
>> that may not be the best for my situation. I may update the kernel once
>> a year, if that. If I have a kernel as a backup that is three or four
>> years old, it will have microcode that is that old as well and lack any
>> new updates. Having it as a image means it will be updated when needed
>> and have the new code whenever I reboot. So, for my situation, having
>> older kernels as backups and such, it may be better to have the image
>> method instead of including it into the kernel.
> Yes, good point.
>
>
>> I'm still thinking on this but if I understand this correctly, having a
>> microcode image and kernel is the best way for me if I can remove the
>> init thingy from the process. It sounds like I can.
> Yes, you can have the microcode as a separate initrd image and GRUB will load
> it each time, irrespective of the kernel you boot with.
>
> It is worth mentioning though, kernel code a few years old is not the safest
> way to run your machine, given the continuous improvements and security
> patches released by the kernel devs.
>
After some thought, I think I'm just going to stick with the dracut and
init thingy way. I'd like to get rid of it but it does work. In the
past, I had nightmares with init thingys, Mandriva days. I've only ever
had one fail with dracut building it. I'm kinda leaning towards file
corruption or something myself since it did work for a while.
So, things stay as they are. For the moment anyway.
Dale
:-) :-)
next prev parent reply other threads:[~2025-04-07 18:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 18:50 [gentoo-user] What are common SSDs does and don'ts Dale
2025-03-22 19:29 ` Mark Knecht
2025-03-22 21:37 ` Michael
2025-03-23 1:48 ` Dale
2025-03-23 9:00 ` Michael
2025-03-23 21:41 ` Dale
2025-03-23 22:15 ` Nate Eldredge
2025-03-23 22:32 ` Frank Steinmetzger
2025-03-23 23:24 ` Dale
2025-03-31 21:27 ` Frank Steinmetzger
2025-04-01 0:44 ` Dale
2025-04-01 10:01 ` Peter Humphrey
2025-04-01 10:12 ` Dale
2025-04-01 10:24 ` Peter Humphrey
2025-04-01 12:56 ` Dale
2025-04-01 13:13 ` Peter Humphrey
2025-04-02 3:33 ` Dale
2025-04-02 11:13 ` Peter Humphrey
2025-04-01 11:04 ` Michael
2025-04-01 13:03 ` Dale
2025-04-01 15:44 ` Michael
2025-04-02 4:04 ` Dale
2025-04-02 8:29 ` Michael
2025-04-07 18:28 ` Dale [this message]
2025-04-01 22:46 ` Frank Steinmetzger
2025-04-01 23:08 ` Frank Steinmetzger
2025-04-02 4:03 ` Dale
2025-03-23 4:34 ` Matt Jolly
2025-03-23 6:56 ` netfab
2025-03-23 7:01 ` Dale
2025-03-23 7:03 ` netfab
2025-03-23 22:46 ` Frank Steinmetzger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af62325e-eda8-6af7-dc30-e8b2563fe85f@gmail.com \
--to=rdalek1967@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox