| 1 |
On 04/06 03:35, Andrea Conti wrote: |
| 2 |
> > Then there was something mentioned about namespaces, which should |
| 3 |
> > be allocated smaller than the physical drive |
| 4 |
> > Is this really needed - just to boot from this SSD? |
| 5 |
> |
| 6 |
> NVMe namespaces are an abstraction layer that allows a controller to present |
| 7 |
> its connected storage as a number of independent volumes. |
| 8 |
> Think LVM LVs, or the way a hardware RAID card presents volumes as multiple |
| 9 |
> SCSI LUNs. |
| 10 |
> |
| 11 |
> Your run-of-the-mill NVMe "gumstick" SSD by default will expose all of its |
| 12 |
> capacity in a single namespace (and I don't even think it can be configured |
| 13 |
> any other way), so you don't have to worry. |
| 14 |
> |
| 15 |
> Just remember that NVMe storage is always accessed through a namespace, so |
| 16 |
> the equivalent of good old /dev/sda is not /dev/nvme0 (the controller) but |
| 17 |
> /dev/nvme0n1 (the first namespace on the controller) |
| 18 |
> |
| 19 |
> > Or is it sufficient (and harmless for the SSD) to just |
| 20 |
> > partitioning and format the drive? |
| 21 |
> |
| 22 |
> It's not only harmless, it's the way it's supposed to be used. |
| 23 |
> |
| 24 |
> Remember that you will need to boot in UEFI mode, so you will need a system |
| 25 |
> partition (and you really, really want to use GPT). The gentoo handbook has |
| 26 |
> a good section on UEFI booting. |
| 27 |
> |
| 28 |
> > I found some hints regarding page sizes and erase block sizes |
| 29 |
> > when partitioning the drive. |
| 30 |
> |
| 31 |
> I wouldn't bother with that, but you're free to experiment :) |
| 32 |
> |
| 33 |
> andrea |
| 34 |
> |
| 35 |
|
| 36 |
Hi Andrea, |
| 37 |
|
| 38 |
yes...as long as other would take the risk I would suggest, they are |
| 39 |
free to experiment. ;) |
| 40 |
|
| 41 |
I encountered the next problem...and I will invite you to experiment |
| 42 |
together with me.... |
| 43 |
|
| 44 |
For my new system I choosed GPT/UEFI. |
| 45 |
|
| 46 |
I have a MSI Tomahawk MAX motherboard. This offers two boot modes: |
| 47 |
UEFI |
| 48 |
UEFI and Legacy |
| 49 |
|
| 50 |
Since my current system, from which I chroot into my new system is |
| 51 |
Legacu bootable I choosed the latter as boot mode. |
| 52 |
|
| 53 |
First (minor) trap: |
| 54 |
Despite being on a AMD64 system (and grub is installed accordingly) |
| 55 |
grub-install tries to access /usr/lib/grub/i386-pc/, which |
| 56 |
does not exist. I fixed that quick and dirty with a symlink |
| 57 |
lrwxrwxrwx 1 root root 10 Apr 6 15:16 i386-pc -> x86_64-efi |
| 58 |
drwxr-xr-x 2 root root 24576 Apr 6 15:09 x86_64-efi |
| 59 |
|
| 60 |
Next: |
| 61 |
Calling |
| 62 |
grub-install --target=x86_64-efi --efi-directory=/boot |
| 63 |
results in: |
| 64 |
Installing for x86_64-efi platform. |
| 65 |
EFI variables are not supported on this system. |
| 66 |
EFI variables are not supported on this system. |
| 67 |
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory. |
| 68 |
|
| 69 |
The config of the runnig kernel has set: |
| 70 |
CONFIG_EFI=y |
| 71 |
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y |
| 72 |
CONFIG_EFI_VARS=y |
| 73 |
CONFIG_EFI_ESRT=y |
| 74 |
CONFIG_EFI_RUNTIME_MAP=y |
| 75 |
CONFIG_EFI_RUNTIME_WRAPPERS=y |
| 76 |
CONFIG_EFI_TEST=y |
| 77 |
CONFIG_EFI_PARTITION=y |
| 78 |
CONFIG_EFIVAR_FS=y |
| 79 |
|
| 80 |
Do I miss something here? |
| 81 |
|
| 82 |
ls -l /sys/firmware |
| 83 |
gaves me: |
| 84 |
drwxr-xr-x 5 root root 0 2020-04-06 16:25 acpi |
| 85 |
drwxr-xr-x 3 root root 0 2020-04-06 16:25 dmi |
| 86 |
drwxr-xr-x 21 root root 0 2020-04-06 16:25 memmap |
| 87 |
|
| 88 |
Do I really need an image on an USBstick to boot into UEFI mode |
| 89 |
just to setup a system to boot into UEFI mode? |
| 90 |
|
| 91 |
Is there any way around that? |
| 92 |
|
| 93 |
Cheers! |
| 94 |
Meino |
Archives