Smd Ramdisk Activator Windows
Timothee Cazares
Have you checked the kernel log (dmesg) for anything suspicious in the beginning area? Maybe the kernel fights for some resources or something.
Did you check BIOS settings to disable some functions/features you don't need? It might shuffle the memory/ACPI map.
Do you really need 'splash'? Beside being just cosmetics it might be error prone.
Are you sure you need 'pci=noaer'? That's disabling 'PCI advanced error reporting'. Also that 'mitigations=auto,nosmt' could be running wild.
As you can see the GUID type of /dev/sda6 is not bc13c2ff-59e6-4262-a352-b275fd6f7172 and it is an ext4 partition.
I suppose I've to change it to fat32 and use the correct GUID. Is it correct?
If so can I simply copy file and folders which are in /boot in a tmp folder and then write them back into the newly reformatted /boot modyfing fstab accordngly?
Then I've rebooted the pc to check if grub with fat32 still was working before continuing and it has booted correclty, but once I entered the DE I've discovered that the /boot partition was completely empty!!!
So now I've executed again the commands to reinstall grub, kernels and configure grunb in boot, but before trying to reboot again I'm wondering if I've done something wrongly and why the /boot partition has been emptied.
I've still to install systemd-boot, change the XBOOTLDR partition GUID type and do all the configuration to have systemd-boot working, but before doing that I want to have a working GRUB.
Check with 'mount' if /boot is mounted at all. It could be overmounted by systemd or something. Otherwise mount /boot manually to take a look if data is there. Eventually check the efi partition for kernel and initramfs. Maybe check the logs for what happened to /boot.
EDIT: I have rebooted after having repopulated the boot directory and the file inside /boot aare still present. Is it possible that the issue was related with the errors=remount-ro option of the /boot partition (I've copied the options from the efi one and generally speaking I think that my fstab is a result of what was suggested years ago when I installed the system on this pc. Should I change something?)
What about rEFInd instead of systemd-boot?
It seems simpler to configure (with the ability to automatically create menu entries for the installed kernels, much like grub).
I'm still not so sure how to create them for systemd-boot considering that I have to use the XBOOTLDR partition because the EPS one is too small and surrounded by windows reserved partitions which I do not want to resize/move at all.
I would try to investigate why /boot was empty and it still booted. Maybe there's another bootloader on a different hdd. Or the kernel/initramfs is on ESP.
It's also possible that the SSD is corrupt playing tricks on you (files vanish, won't get stored).
Neither of the two.
The strange thing is that PC was able to boot and then the /boot partition became empty somehow.
Before booting a loading initial ramdisk happened.
So maybe the fat32 went corrupted and lost all of its contents, but in such a case it would have not been able to reboot at all.
It is one of the strangest thing which have happened to me since I use linux.
In the journactl I've seen that just after that boot a fstrim "Started Discard unused blocks once a week." was executed, but I doubt it has anything to do with that.
that is the same as mine except for the order in which partitions are written (is it important?), the tracefs which is not present in mine and the lack of data=ordered for the root
Is it better to use this instead of mine?
Below there is the refind.conf
What I do not understand is if it is all I've to do to have it working and see my three kernels (linux-zen, linux and linux-lts), their fallbacks and windows 10.
When does refind read these configurations? at runtime or I've to execute refind_install so that it use them at next boot?
Is it possible to add an entry for grub so that to use it in case refind ones do not work?
I fear I've made mistakes and to find myself stuck without being able to boot nothing
I strongly belief this is going in the wrong direction, you are technically loading the ramdisk, and if it happens to work with a specific reboot cycle then the general loading mechanism of UEFI isn't the issue but something else and I consider it unlikely to be fixed by swapping bootloaders around.
you are technically loading the ramdisk, and if it happens to work with a specific reboot cycle then the general loading mechanism of UEFI isn't the issue but something else and I consider it unlikely to be fixed by swapping bootloaders around.
As far as i know the bootloader is loading, allocating and passing over the ramdisk/memory to the kernel. That might be a critical (and maybe not always bug free) process that could be handled different on other bootloaders. GRUB2 might be much more bloated/complex (and thus more error prone) than the more slick systemd-boot.
I can confirm that with refind too the freeze still happens randomly.
So I've uninstalled refind and went back to using GRUB.
I've added the kernel parameter random.trust_cpu=on, but also with taht every 3 or 4 reboot the freeze has happened.
Then I've uninstalled intel-ucode and reinstalled linux, linux-lts and linux-zen and updated grub.cfg to avoid loading itel-ucode and then I was able to do about 20 reboots without issue.
I know that intel-ucode is important, but it seems to be the suspect.
For the sake of safety I've reinstalled intel-ucode (and after 2 reboots the freeze has happened again).
On Asus site there is no uefi update available, the last BIOS (303) is the one I already have and dates back to 2019.
Should I try to use older versions of intel-ucode?
More generally speaking Windows 10 does not have this issue and as far as I know the intel-ucode is used also in Windows (even thought in a different way) every time I use it, so it seems as if the mechanism Microsoft uses is more reliable (at least on this PC). I suppose that the code base of intel-ucode is the same for both operating systems, but then maybe it is loaded in a different way? Is there anywhere an explanation on how microcode is handled by linux and windows? Just to say that it is not an hardware/firmware issue since windows 10 do not shows the same symptom.
EDIT
I've just tried to reboot in windows more than 10 times without issue.
In windows the CPU revision (which as far as I know should be related to the ucode version installed) is reported as "cc" whereas under linux it says "microcode updated early to revision 0xe2, date = 2020-07-14".
Is there a way to know which version of intel-ucode contains the cc revision for my CPU?
EDIT3
I've tried different reboot= kernel parameters:
reboot=bios is not able to shutdown or restart the pc
reboot=efi completely turns off the pc for 5 seconds when rebooting and randomly freezes loading initial ramdisk
reboot=cold randomly freeze loading initial ramdisk and when it happens it keeps freezing so I had to change the kernel parameter from the grub editor
reboot=acpi reboot in a way very similar to what windows too (meaning the power led remains on and the keyboad light is cycled when the asus logo appears before grub, but it still randomly freezes loading initial ramdisk
the initial phase of the booting takes more time (7 seconds instead of half a second or less, but a lot of early messages are displayed and when it freezes these are the last lines:
-20210219-210353.jpg
I hope it helps understand what is happening when it freezes
Did you try systemd-boot as well? I rather think ucodes are a red herring (unless you find other ppl with same problems). Did you check general stability with memtest yet?
Those laptops are a mess indeed with all the custom proprietary embedded controllers, Ring -2 security hypervisors and so on.
Maybe try to tweak grub to load ucodes/ramdisk/kernel "different" (if that's possible). I don't know... maybe something with alternative free space enumeration, different memory allocation, etc.. Not sure what's possible here.
Or look up the BIOS itself for any features to shut down. I've seen (for example) somewhere in your logs something about EC security driver. All this business DRM security spyware crap no one wants could be a potential interfering low-level error candidate.
I was using Gavotte's edition of the Windows RAMDisk driver for a while in my windows XP installation for a while already and my results were so far really good. Using the RAMDisk driver I was able to use my full 4GB RAM in my Windows 32 Bit environment.
Answer: Depending on the used hardware and BIOS configuration the non-usable memory between 3GB and 4GB (this is a area for reserved addresses for physical devices) is remapped to the area above 4GB.
Windows XP/Vista/7 32Bit editions are limited to 4GB RAM addresses so the memory above 4GB is just "unused".
The Gavotte RAMDisk is able to set the RAMDisk in the area above 4GB memory addresses and can enable the usage of this area for other purposes. I use the RAMDisk for setting my page file to this area but you can also use it for setting the TEMP folder or other stuff there.
It is just important to know that the RAMDisk is not persistent - so don't store any important stuff there - every reboot or power cycle the content is lost - so temporary files can be stored very good at this location.
ff7609af8f