三星S10 5G设备中pstore无法工作的问题排查求助

Alright, let's tackle your bootloop and pstore issue on the Samsung S10 5G. I've dealt with similar problems on Samsung devices before, so here's a structured approach to diagnose the pstore failure and alternative ways to grab kernel logs:

Since pstore works on your OnePlus 6T but not the S10 5G, the issue is likely device-specific kernel/bootloader interference. Try these steps:

• Verify Ramoops Kernel Parameters Are Actually Applied
  Samsung's bootloader often overrides kernel cmdline parameters, even if you set them in init.rc. Check the active cmdline with cat /proc/cmdline (while in a working rooted ROM). If you don't see ramoops.mem_address=0xC1000000 (your decimal 3241148416 converted to hex) and ramoops.mem_size=0x100000, manually add these to your boot.img's cmdline. You can do this with tools like magiskboot (part of Magisk) to unpack the boot.img, edit the cmdline, then repack it.

• Adjust PStore Mount Timing
  Your init.rc mounts pstore early in the boot process—before the kernel may have fully initialized the ramoops module. Move the pstore mount commands to init.post_boot.rc or late_init.rc instead, to ensure the kernel is ready to handle the filesystem.

• Check for Memory Address Conflicts
  The mem_address you're using for ramoops might be reserved for other hardware components on the S10 5G. Run cat /proc/iomem in a working ROM to check if the range 0xC1000000 to 0xC1FFFFFF (your 1MB mem_size) is already allocated to another device. If it is, pick an unused region (look for "System RAM" sections marked as free) and update your ramoops parameters.

• Test Without Compression
  Your kernel has CONFIG_PSTORE_ZLIB_COMPRESS enabled—sometimes compression can cause issues on certain devices. Try disabling it temporarily: either recompile the kernel with CONFIG_PSTORE_ZLIB_COMPRESS=n, or add pstore.uncompress=0 to the kernel cmdline to bypass decompression and see if logs appear.

• Trigger a Manual Kernel Oops
  To test if pstore is capable of writing logs at all, trigger a controlled kernel oops with root access:

  echo 1 > /proc/sys/kernel/sysrq
  echo c > /proc/sysrq-trigger
  

  This should crash the kernel and force a write to pstore. If no logs show up after reboot, your pstore/ramoops implementation is fundamentally broken on this device's kernel.

If pstore isn't working, here are other ways to get the bootloop-causing logs:

• UART Serial Debugging
  Samsung flagships (including the S10 5G) have exposed UART pins on the motherboard. You'll need to open the device, solder or connect a USB-to-TTL adapter to the correct pins, then use a tool like minicom or screen to capture real-time kernel boot logs. This is the most reliable method for bootloop issues, as it shows exactly where the kernel hangs.

• Check Recovery-Mounted Logs
  If you can boot into a custom recovery like TWRP:

  • Mount the /data partition and check /data/log/kernel/ or /data/dontpanic/ for any cached kernel logs.
  • Mount /proc and run cat /proc/kmsg to dump any remaining kernel buffer content (note: this only works if the kernel hasn't fully crashed and the recovery can access the kernel's memory).

• Magisk Logs
  If you can boot a rooted ROM after the failed flash, mount /data and check /data/adb/magisk.log. Magisk logs often capture early boot issues, including SELinux policy violations that might be causing your bootloop.

• Compare SELinux Policy Differences
  Since your issue stems from modifying the SELinux policy in the AP file, use a tool like cil_diff or just diff to compare the policy files (e.g., /system/etc/selinux/plat_sepolicy.cil) from your working ROM and the modified one. Look for changes that affect critical system processes (like init, zygote, or servicemanager)—a misconfigured policy can immediately trigger a bootloop.

• Modify Boot.img to Increase Log Buffer
  Edit your boot.img's cmdline to add log_buf_len=32M (increase the kernel log buffer size) and console=tty0 to force log output to the framebuffer. While you won't see it during bootloop, you might be able to dump the buffer from recovery if the kernel hasn't overwritten it.

内容的提问来源于stack exchange，提问作者Vatish Sharma