You are not logged in.
I have a stick of ECC RAM that consistently produces a recoverable error at the same address:
EDAC MC0: 1 CE on mc#0csrow#3channel#1 (csrow:3 channel:1 page:0x1f75764 offset:0x9c0 grain:64 syndrome:0x2
I have seen guides (most over a decade old) that specify either passing a kernel parameter in grub, with memtest86, or memmap. I use systemd-boot. I'm also not even sure the kernel parameter they pass is still correct.
How can I blacklist that memory page? It's a 32GB stick so I don't want to remove it, and I can't afford another one now. Also, blacklisting bad ram page is something that has to be done for people with soldered RAM.
An example I read said to modify the entries in /boot/loader/entries/ that would look like:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=UUID=1234-5678 rw quiet memmap=64K$1.25G
but I don't have any files in /boot/loader/entries/ . I used archinstall and the defaults. I'd rather stick with systemd-boot and not add too much stuff.
Any help appreciated.
Offline
I used archinstall
and problems like the one you posted are why archinstall is not the noob way but rather for experienced users familiar with the manual setup and the several specifics about the options selected
if you don't understand where archinstall placed the files for systemd-boot you should rather restart by reading the manual guide https://wiki.archlinux.org/title/Installation_guide and maybe even do it actually several times with different configurations to get familiar with how archinstall does systemd-boot install and where to look for the files you're supposed to modify
sorry for being a bit sarcastic - but it's pretty much the same as with "no backup? no pity!" - or transformed to what happend to you: "not bothered to do the manual setup but thought getting away with archinstall? suffer the consequences!"
also: that ram is bad - replace it asap
Offline
I don't have any files in /boot/loader/entries/
The path will be relative to the EFI system partition so use `lsblk -f` to see where that is mounted (or share the output here).
I used archinstall
Please share the install log here. Thanks.
Para todos todo, para nosotros nada
Online
TheGreatAndyChow wrote:I don't have any files in /boot/loader/entries/
The path will be relative to the EFI system partition so use `lsblk -f` to see where that is mounted (or share the output here).
It's not in the /boot drive, that's what I was saying. I have a
nvme0n1
├─nvme0n1p1 vfat FAT32 /boot
partition which is mounted and fine. But there's nothing in the boot/loader/entries/
I'm guessing it's in the esp UEFI firmware on my motherboard, but I don't know how to mount that. It doesn't appear with lsblk.
TheGreatAndyChow wrote:I used archinstall
Please share the install log here. Thanks.
I replaced the UUIDs, and it's the chunk you likely want to see.
Offline
TheGreatAndyChow wrote:I used archinstall
and problems like the one you posted are why archinstall is not the noob way but rather for experienced users familiar with the manual setup and the several specifics about the options selected
if you don't understand where archinstall placed the files for systemd-boot you should rather restart by reading the manual guide https://wiki.archlinux.org/title/Installation_guide and maybe even do it actually several times with different configurations to get familiar with how archinstall does systemd-boot install and where to look for the files you're supposed to modifysorry for being a bit sarcastic - but it's pretty much the same as with "no backup? no pity!" - or transformed to what happend to you: "not bothered to do the manual setup but thought getting away with archinstall? suffer the consequences!"
also: that ram is bad - replace it asap
The RAM is ECC and has corrected all errors so far. Sure, there is risk that a second flip happens on the affected page, but statistically that's extremely unlikely (the cosmic ray would have to hit that page, 64k out of 32 GB). Until I figure out how to blacklist that page, it just means that that part of the stick acts like regular non-ECC RAM.
Also,
Offline
well, the fact that you replace a complete random 128-bit uuid because you may think anybody could do anything with it ... nvm
that log look somewhat short - anyway, it gives a hint where to start however - the wiki will guide you further along
Offline
there's nothing in the boot/loader/entries/
So what is on the ESP, exactly?
This will show the contents:
find /boot
I'm guessing it's in the esp UEFI firmware on my motherboard
That's not how systemd-boot works, it should need loader entries on the ESP.
The archinstall log certainly shows /boot/ mounted under the ESP and systemd-boot is used. What do you actually see when the machine starts? Is there a menu?
Para todos todo, para nosotros nada
Online
Ok, I found out where the params are with bootctl. I can also update the esp with that. However, still no ideas how to modify the options of an entry. I see no examples or commands that allow editing the entries. Same with efibootmgr. Anyone familiar with how to edit? And where are they stored? Are they in the .efi files themselves? And if so, is there a way I can add a hook so when I update the new kernel won't squish it? Preferably without going a dkms way.
UUIDs redacted to 3 characters because they are irrelevant.
bootctl list
type: Boot Loader Specification Type #2 (.efi)
title: Arch Linux (6.12.1-arch1-1) (default) (selected)
id: arch-linux.efi
source: /boot//EFI/Linux/arch-linux.efi
sort-key: arch
version: 6.12.1-arch1-1
linux: /boot//EFI/Linux/arch-linux.efi
options: root=PARTUUID=f58 zswap.enabled=0 rootflags=subvol=@ rw rootfstype=bt>type: Boot Loader Specification Type #2 (.efi)
title: Arch Linux (6.12.1-arch1-1~fallback)
id: arch-linux-fallback.efi
source: /boot//EFI/Linux/arch-linux-fallback.efi
sort-key: arch
version: 6.12.1-arch1-1~fallback
linux: /boot//EFI/Linux/arch-linux-fallback.efi
options: root=PARTUUID=f58 zswap.enabled=0 rootflags=subvol=@ rw rootfstype=bt>type: Automatic
title: Reboot Into Firmware Interface
id: auto-reboot-to-firmware-setup
source: /sys/firmware/efi/efivars/LoaderEntries-4a6
Offline
please use code-tags for posting console output
and as you already discovered bootctl just run it without any additional options
sudo bootctl
it will list the required information
Offline
Well thanks for answering my questions OP, that's very helpful of you.
Looks like you're using unified kernel images so check /etc/kernel/cmdline.
Para todos todo, para nosotros nada
Online
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=UUID=1234-5678 rw quiet memmap=64K$1.25Gbut I don't have any files in /boot/loader/entries/ . I used archinstall and the defaults. I'd rather stick with systemd-boot and not add too much stuff.
For what it's worth, what you're doing is not really blacklisting. In this context is probably is and it is long since having done something of this sort but this probably just requested the kernel not to use that region of memory.
The region, can for instance be later used by device, for instance an IOMMU for page tables.
Offline
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=UUID=1234-5678 rw quiet memmap=64K$1.25Gbut I don't have any files in /boot/loader/entries/ . I used archinstall and the defaults. I'd rather stick with systemd-boot and not add too much stuff.
For what it's worth, what you're doing is not really blacklisting. In this context it probably is and it is long since having done something of this sort but this probably just requested the kernel not to use that region of memory.
The region, can for instance be later used by device, for instance an IOMMU for page tables.
In other words, you reserved the memory?
Offline
For what it's worth, what you're doing is not really blacklisting. In this context is probably is and it is long since having done something of this sort but this probably just requested the kernel not to use that region of memory.
The region, can for instance be later used by device, for instance an IOMMU for page tables.
Are you suggesting using a different e820 type?
Offline
ReDress wrote:For what it's worth, what you're doing is not really blacklisting. In this context is probably is and it is long since having done something of this sort but this probably just requested the kernel not to use that region of memory.
The region, can for instance be later used by device, for instance an IOMMU for page tables.
Are you suggesting using a different e820 type?
Yes, this is probably what it is boiling down to.
If you look at ARM board configs in the kernel, some, if not all, have configs for memory reserving because, presumably, the devices make hard access to these regions and they cannot be otherwise used.
Offline