I’ve reinstalled EndeavourOS (along with Windows 10) and at first startup RAM is not detected correctly. Instead of 16GB only 1.59GB is detected and used (My laptop is laggy and a few browser tabs freeze it).
This situation is also accompanied by inability to access BIOS menu. It hangs when I want to boot into BIOS menu.
In the end I learned how to fix it. I use efibootmgr to delete some junk boot entries which are always there (that means that they reappear after reboot). After deleting them I can access BIOS menu and RAM is correctly detected.
I know I created those boot entries manually in the past trying to solve some boot issue with another system (I don’t remember well). Anyway, I don’t have enough knowledge to understand what’s happening. I just discovered an “algorithm” to fix this issue that appears (almost or not) any time i install a fresh system. Maybe it’s a very specific problem caused by those boot entries which happens only on my laptop. However, I thought it’s worth posting it, maybe somebody more experienced sees something I can’t see.
Check it with memtest from EndeabourOS live-USB (if it will give errors or dead - sadly you’ll have to change whole laptop / motherboard, since it’s soldered RAM)
btw it’s not advisable to dual-boot with Windows 10, it’s not safe anymore:
So at least know your risks
P.S. @ricklinux yep and installed as UEFI, he already said in other thread
Other thread? Just wondered because people call it Bios which is not correct if it’s UEFI. Bios is legacy and UEFI is a firmware not a BIOS. It confuses the issue.
I hope you saw my second comment after post. I could not say if UEFI (BIOS) [I’m a bit confused here, sorry @ricklinux ] sees full RAM as long as I couldn’t get into it. Now, after everything seems working, RAM is detected correctly (16GB). (I even took a photo
Well, for that 100% I think I will have to make a fresh reinstall, reproduce the thing and boot to Windows to check for sure. But I don’t remember to affect windows in any way in the past…so…
Return that command, perhaps it will help those who’ll come here to help you as well:
sudo dmidecode -t memory
@anon31687413 maybe there was something funky you recall in Kernel, about this fairly new CPU (Intel Core i7-1065G7) / soldered RAM?
Also usual suspect would be Kingston nvme, that is very bad manufacturer, see this and that…
That could be very well a reason, given how random sometimes those failures are, but i don’t think it’s that this time, at least yet. Because if it was - drive would be most likely already dead and you wouldn’t be able to boot.
Well, for the moment I’m happy that it’s working and unless I will do a fresh reinstall I (probably) won’t be affected by this. Even then, I think I have the recipe to solve it fast (as I described in the 2nd comment after post).
Here is the output you asked:
$ sudo dmidecode -t memory
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Handle 0x000F, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 16 GB
Error Information Handle: No Error
Number Of Devices: 2
Handle 0x0010, DMI type 17, 84 bytes
Memory Device
Array Handle: 0x000F
Error Information Handle: No Error
Total Width: 32 bits
Data Width: 32 bits
Size: 8192 MB
Form Factor: Row Of Chips
Set: None
Locator: ChannelA-DIMM0
Bank Locator: BANK 0
Type: LPDDR4
Type Detail: Synchronous
Speed: 3200 MT/s
Manufacturer: Samsung
Serial Number: 20000000
Asset Tag: 9876543210
Part Number: K4UBE3D4AA-MGCH
Rank: 2
Configured Memory Speed: 2667 MT/s
Minimum Voltage: 1.5 V
Maximum Voltage: 1.5 V
Configured Voltage: 0.6 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Not Specified
Module Manufacturer ID: Bank 1, Hex 0xCE
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 8 GB
Cache Size: None
Logical Size: None
Handle 0x0011, DMI type 17, 84 bytes
Memory Device
Array Handle: 0x000F
Error Information Handle: No Error
Total Width: 32 bits
Data Width: 32 bits
Size: 8192 MB
Form Factor: Row Of Chips
Set: None
Locator: ChannelB-DIMM0
Bank Locator: BANK 2
Type: LPDDR4
Type Detail: Synchronous
Speed: 3200 MT/s
Manufacturer: Samsung
Serial Number: 20000000
Asset Tag: 9876543210
Part Number: K4UBE3D4AA-MGCH
Rank: 2
Configured Memory Speed: 2667 MT/s
Minimum Voltage: 1.5 V
Maximum Voltage: 1.5 V
Configured Voltage: 0.6 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Not Specified
Module Manufacturer ID: Bank 1, Hex 0xCE
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 8 GB
Cache Size: None
Logical Size: None
That is undoubtedly true - but I am not sure it is avoidable! Many manufacturers use the term BIOS for the UEFI firmware, often visibly - and lots of us (that know better) misuse the term too. Perhaps we can call it UEFI BIOS
I might have done some terrible things there (if possible) when I struggled with another problem some time ago. I know I look very stupid saying that and I should have more knowledge in this area .
BTW, while am at this, I feel the need to show what’s in my boot manager (got in this by stressing on F12) and UEFI > Boot section (F2).
So in Boot Manager the options are clearly displayed, although only 1 and 3 are needed. I cannot get rid of the rest.
In UEFI > Boot the first 2 options are displayed so wrong (EndeavourOS is the first and it’s displayed as empty, and the second seems to be a very long binary). From 3…6 are displayed ok (even though I didn’t scroll to make another print screen).
In /boot/efi (where is mounted the 100MB-fat32-partition from which initially only Windows10 was booting) I have the following:
➜ sudo ls /boot/efi
a9ba2b5e37794e03b8baccad6ee26e8b boot-repair EFI loader
~
➜ sudo ls /boot/efi/EFI
Boot EndeavourOS GRUB Insyde Linux Microsoft OEM systemd tools UpdateCapsule
~
➜ sudo ls /boot/efi/EFI/Boot
BOOT.CSV bootx64.efi bootx64.efi-1587024234.bak drivers_x64 fbx64.efi grub.cfg grubx64.efi icons icons-backup keys refind.conf refind.conf-sample
~
➜ sudo ls /boot/efi/EFI/EndeavourOS
grubx64.efi
~
➜ sudo ls /boot/efi/EFI/GRUB
grubx64.efi
~
➜ sudo ls /boot/efi/EFI/Insyde
~
➜ sudo ls /boot/efi/EFI/Linux
grubx64.efi
~
➜ sudo ls /boot/efi/EFI/Microsoft
Boot Recovery
~
➜ sudo ls /boot/efi/EFI/systemd
systemd-bootx64.efi
~
➜ sudo ls /boot/efi/EFI/tools
~
➜ sudo ls /boot/efi/EFI/OEM
Boot Recovery
I pasted below the output of efibootmgr. As I previously mentioned, even if I remove them with efibootmgr -B -b XXXX, after restart they are displayed again - so they are not actually removed. But, removing them this way it’s essential to solve the issue I opened this post for (I also describe this in the second comment after the post):
its not -B -b xxx the correct way is sudo efibootmgr -b xxxxx -B I know as i used efibootmgr yesterday with 100% success
The lowercase b is the command to modify the entry, the uppercase B then deletes the entry
.
