On Saturday, 15 June 2024 07:53:06 BST Dale wrote:
> Peter Humphrey wrote:
> > Here's the output of parted -l on my main NVMe disk in case it helps:
> > 
> > Model: Samsung SSD 970 EVO Plus 250GB (nvme)
> > Disk /dev/nvme1n1: 250GB
> > Sector size (logical/physical): 512B/512B
> > Partition Table: gpt
> > Disk Flags:
> > 
> > Number  Start   End     Size    File system     Name      Flags
> > 
> >  1      1049kB  135MB   134MB
> >  2      135MB   4296MB  4161MB  fat32           boot      boot, esp
> >  3      4296MB  12.9GB  8590MB  linux-swap(v1)  swap1     swap
> >  4      12.9GB  34.4GB  21.5GB  ext4            rescue
> >  5      34.4GB  60.1GB  25.8GB  ext4            root
> >  6      60.1GB  112GB   51.5GB  ext4            var
> >  7      112GB   114GB   2147MB  ext4            local
> >  8      114GB   140GB   25.8GB  ext4            home
> >  9      140GB   183GB   42.9GB  ext4            common
> > 
> I'm starting the process here.  I'm trying to follow the install guide
> but this is still not clear to me and the guide is not helping.  In your
> list above, is #2 where /boot is mounted?  Is that where I put kernels,
> init thingys, memtest and other images to boot from? 

Yes, and yes ('tree -L 3 /boot' below). I've had no success with the layout 
recommended in the wiki, because I want a choice of kernels to boot; I've 
shown my boot-time screen here before. In fact, gparted shows the unformatted 
first partition as bios_grub. I don't know why parted didn't show the same (it 
does show it now) Gparted screen shot attached.

Thus, I have an unused bios_grub partition, then a FAT32 EFI system partition, 
then the rest as usual.

> My current layout for a 1TB m.2 stick, typing by hand:
> 
> 1    8GB        EFI System   
> 2    400GB    Linux file system for root or /.
> 3    180GB    Linux file system for /var.
> 
> I'll have /home and such on other drives, spinning rust. I'm just
> wanting to be sure if my #1 and your #2 is where boot files go, Grub,
> kernels, init thingys etc.  I've always had kernels and such on ext2 but
> understand efi requires fat32. 

Yes. I believe the EFI spec requires a file system that any OS can access, and 
FAT is it, FAT32 usually being recommended.

Then, when it comes to bootctl and installkernel, I ignore the Gentoo advice 
on USE flags because it results in illegible file names and impenetrable 
directories. My version is far simpler to manage, which I do by hand. I don't 
suppose anyone else would use my approach, but I started it long before the 
days of EFI, and it still works for me.

Also, as I've said here before, I dislike the all-things-to-all-men grub, so I 
don't use it.

Incidentally, do you really need so much space in root and /var? Mine are just 
40GB each, and not even half full. I don't run a lot of media apps though. 
Still, space is cheap.   :)

$ tree -L 3 /boot
/boot
├── config-6.1.67-gentoo-rescue
├── config-6.6.21-gentoo
├── config-6.6.21-gentoo-rescue
├── config-6.6.30-gentoo
├── config-6.6.30-gentoo-rescue
├── config-6.7.9-gentoo
├── config-6.8.5-gentoo-r1
├── early_ucode.cpio
├── EFI
│   ├── BOOT
│   │   └── BOOTX64.EFI
│   ├── Linux
│   └── systemd
│       └── systemd-bootx64.efi
├── intel-uc.img
├── loader
│   ├── entries
│   │   ├── 06-gentoo-rescue-6.6.30.conf
│   │   ├── 07-gentoo-rescue-6.6.30.nonet.conf
│   │   ├── 08-gentoo-rescue-6.6.21.conf
│   │   ├── 09-gentoo-rescue-6.6.21.nonet.conf
│   │   ├── 30-gentoo-6.6.30.conf
│   │   ├── 32-gentoo-6.6.30.conf
│   │   ├── 34-gentoo-6.6.30.conf
│   │   ├── 40-gentoo-6.6.21.conf
│   │   ├── 42-gentoo-6.6.21.conf
│   │   └── 44-gentoo-6.6.21.conf
│   ├── entries.srel
│   ├── loader.conf
│   └── random-seed
├── System.map-6.6.21-gentoo
├── System.map-6.6.21-gentoo-rescue
├── System.map-6.6.30-gentoo
├── System.map-6.6.30-gentoo-rescue
├── System.map-6.7.9-gentoo
├── System.map-6.8.5-gentoo-r1
├── vmlinuz-6.1.67-gentoo-rescue
├── vmlinuz-6.6.21-gentoo
├── vmlinuz-6.6.21-gentoo-rescue
├── vmlinuz-6.6.30-gentoo
├── vmlinuz-6.6.30-gentoo-rescue
├── vmlinuz-6.7.9-gentoo
└── vmlinuz-6.8.5-gentoo-r1

-- 
Regards,
Peter.

Reply via email to