From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Separate /usr partition
Date: Thu, 15 Sep 2022 05:00:25 -0500 [thread overview]
Message-ID: <bc3d9f4e-5b95-666a-d14b-6735e69f1acb@gmail.com> (raw)
In-Reply-To: <12071369.O9o76ZdvQC@wstn>
Peter Humphrey wrote:
> On Wednesday, 14 September 2022 23:09:59 BST Neil Bothwick wrote:
>> On Wed, 14 Sep 2022 16:50:45 +0100, Peter Humphrey wrote:
>>> I'm thinking of separating /usr onto its own partition so that I can
>>> have it mounted read-only except while updating it. I'd prefer not to
>>> have to make an init thingy, not having needed one up to now. Besides,
>>> some machines have things like early-ucode or amd-uc.
>> Most of this has already been answered, except for your final point. You
>> can load more than one initrd at boot, so you can still apply microcode
>> updates. For example, with systemd-boot
>>
>> title Desktop
>> version 5.15.59-gentoo
>> linux /vmlinuz-5.15.59-gentoo
>> options root=LABEL=blah blah
>> initrd /amd-uc.img
>> initrd /initramfs-5.15.59-gentoo.img
>>
>> I use dracut to create the initrd, which is so straighforward even Dale
>> can't break it ;-)
> :)
>
> That seems to be the way to go then - even dinosaurs die out in the end.
> Perhaps Dale will show us the command he referred to.
>
> Thank you all for your help.
>
As I said, I do all mine by hand. I don't use make install etc. After
I build my kernel, I copy it and name it something like this, from /boot.
root@fireball / # ls -al /boot/kernel*
-rw-r--r-- 1 root root 11638944 Nov 30 2021 /boot/kernel-5.10.46-2
-rw-r--r-- 1 root root 11863664 Feb 18 2022 /boot/kernel-5.14.15-2
-rw-r--r-- 1 root root 11881040 Aug 6 18:00 /boot/kernel-5.14.15-3
-rw-r--r-- 1 root root 12128016 Jun 30 20:00 /boot/kernel-5.18.7-1
-rw-r--r-- 1 root root 11167744 Nov 30 2021 /boot/kernel-5.6.7-1
root@fireball / #
I basically put the version and at times a dash number on the end.
Sometimes "-1" may work but I add a driver or something and the next is
-2, the next -3 etc. For -3 above, I added a driver for a new network
card as a example. Sometimes I clean out older dashed versions. Point
is, it needs to start with kernel and go from there. You may have a
different way of naming them. I think grub just looks for it to start
with kernel.
Once I get that done, I then build the init thingy. This is Neil's
command that he posted. From my understanding, the kernel symlink needs
to point to the correct kernel version.
dracut --kver=$(cat include/config/kernel.release)
That gives a init thingy with a somewhat generic name. I then rename it
to match the kernel, looks something like this from /boot.
root@fireball / # ls -al /boot/initramfs*
-rw------- 1 root root 9310818 Nov 30 2021 /boot/initramfs-5.10.46-2.img
-rw------- 1 root root 9093386 Nov 13 2021 /boot/initramfs-5.14.15-2.img
-rw------- 1 root root 9485412 Aug 6 18:01 /boot/initramfs-5.14.15-3.img
-rw------- 1 root root 9117155 Jun 30 22:57 /boot/initramfs-5.18.7-1.img
-rw------- 1 root root 9310789 Nov 30 2021 /boot/initramfs-5.6.7-1.img
root@fireball / #
Once you get the two things to match, kernel and initramfs, then when
you update grub, it will match them together and create the needed
entries. I think at one point, I had one init for each kernel version
without the dash part. I can't recall how I did that tho. To update
grub, I use this command.
grub-mkconfig -o /boot/grub2/grub.cfg
I actually put it in a file in /root and just run it. I just named it
grub-update. That way I don't have to remember the option part. ;-)
When it runs, just make sure it sees the kernel and a matching
initramfs. It usually lists them in order.
I don't update kernels that often. If you do it more often, others will
have more automated ways to do things. They may use make install and
other things that makes it a lot faster. I do it this way because it is
not something I have to do often and I always get a good result. Plus,
I keep the ones I know work well.
It's been a while but I think Neil may have a more automated process.
Heck, if he shares his step by step, I may convert. LOL
I don't think I left anything out. :/
Dale
:-) :-)
next prev parent reply other threads:[~2022-09-15 10:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-14 15:50 [gentoo-user] Separate /usr partition Peter Humphrey
2022-09-14 16:12 ` karl
2022-09-14 16:17 ` Laurence Perkins
2022-09-14 16:30 ` Rich Freeman
2022-09-14 17:04 ` Dale
2022-09-14 20:38 ` karl
2022-09-14 22:09 ` Neil Bothwick
2022-09-15 8:57 ` Peter Humphrey
2022-09-15 10:00 ` Dale [this message]
2022-09-15 10:48 ` Peter Humphrey
2022-09-15 11:15 ` Dale
2022-09-15 17:32 ` Neil Bothwick
2022-09-15 17:35 ` Neil Bothwick
2022-09-15 18:15 ` Laurence Perkins
2022-09-15 19:54 ` Neil Bothwick
2022-09-16 15:16 ` Peter Humphrey
2022-09-16 15:25 ` Dale
2022-09-16 15:49 ` Peter Humphrey
2022-09-16 17:57 ` Rich Freeman
2022-09-17 7:54 ` Peter Humphrey
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=bc3d9f4e-5b95-666a-d14b-6735e69f1acb@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