Menu

Strange Behavior

Mikhail
2019-03-12
2019-03-25
  • Mikhail

    Mikhail - 2019-03-12

    Hi!
    Gentoo x86_64, m/b MSI 970a-g43, GeForce 1050
    Dualboot with Windows 10 (earlier 8.1)
    refind-11.3 and earlier versions.

    SSD with Gentoo and separate ESP partition with grubx64.efi, windows efi loader and refind. And another HDD with installed Widnows 10, but without ESP.

    Sometimes refind start normally and then start any OS: Windows or Gentoo. Sometimes after BIOS POST messages I got black screen and 100% CPU load and nothing more.

    In BIOS and in Windows I turned off the fast boot. I deleted hibernate mode in Windows. I’m trying to load refind in text mode, but with the same statistic.

    This happens after reloading Gentoo or Windows, ater reloading from Windows in Gentoo and inversely. A normal loading chance of approximately 60% - in other time – black screen, reset and manually start grubx64.efi.

    How can I enable debug and see the logs of the refind?

     
  • Roderick W. Smith

    I'm afraid that rEFInd has no debug mode or ability to save logs. I saw this type of problem on one system in the past, and it was the motherboard that was failing. I ultimately had to retire that system, since it got to the point where it took several reboots before it would boot. I do have some suggestions for further debugging or workarounds/fixes:

    • Check your firmware's version, and check the manufacturer's (MSI's) Web page to see what versions are available. If there's an update, try installing it. If the problem is a bug in the firmware, an update might fix it.
    • Try installing another boot manager, like gummiboot/systemd-boot, or GRUB as a test. Set it up to boot first and either configure it to launch Linux and Windows or to chainload to rEFInd If gummiboot or GRUB has problems loading, too, then you can be pretty confident that the motherboard or its firmware is at fault. If not, then it's more likely something about rEFInd that's failing sporadically.
    • If you have unnecessary EFI filesystem drivers installed, uninstall them. If that doesn't help, try temporarily uninstalling the necessary filesystem drivers, too. Drivers are very low-level, and if they fail, they're likely to hang the machine, so a bad driver (or filesystem damage that's causing a driver to hang) is a plausible culprit. If this seems to be the problem, you could try running a filesystem check on the partition(s) that the driver reads, switching /boot to another filesystem, using dont_scan_volumes in refind.conf to hide an offending partition (if it doesn't hold your kernels), or switching to another driver (like Pete Batard's drivers).
    • Simplify your setup as much as possible. Unplug any external disks (including USB flash drives -- they sometimes prevent a system from booting), unplug PCI cards you don't absolutely need, etc. You might even consider deleting or consolidating partitions, although that's likely only a possibility if you were planning such changes in the near future anyhow.
     
  • Mikhail

    Mikhail - 2019-03-12

    This computer configuration I have 2.5 years. Moreover, one motherboard burned down and was replaced under the warranty for exactly the same. Always installed the latest BIOS.
    GRUB - is my default boot manager all this time.
    ESP partition formatted with FAT32.
    I have no external disks.
    Trying dont_scan_volumes and exluding support ext2 and iso9660 from build of the refind.

    P.S. No success. After black screen rebooted with GRUB and checked ESP partition, which not auto mounted in fstab. All is OK:

    fsck.vfat -tv /dev/sda1
    
    fsck.fat 4.1 (2017-01-24)
    Checking we can access the last sector of the filesystem
    Boot sector contents:
    System ID "mkfs.fat"
    Media byte 0xf8 (hard disk)
           512 bytes per logical sector
           512 bytes per cluster
            32 reserved sectors
    First FAT starts at byte 16384 (sector 32)
             2 FATs, 32 bit entries
       2081280 bytes per FAT (= 4065 sectors)
    Root directory start at cluster 2 (arbitrary size)
    Data area starts at byte 4178944 (sector 8162)
        520222 data clusters (266353664 bytes)
    63 sectors/track, 255 heads
          6144 hidden sectors
        528384 sectors total
    Checking for bad clusters.
    Checking for unused clusters.
    Checking free cluster summary.
    /dev/sda1: 428 files, 64987/520222 clusters
    

    But:

    dumpe2fs /dev/sda1
    dumpe2fs 1.44.5 (15-Dec-2018)
    dumpe2fs: Bad magic number in super-block while trying to open /dev/sda1
    Couldn't find valid filesystem superblock.
    /dev/sda1 contains a vfat file system
    
     

    Last edit: Mikhail 2019-03-12
  • Roderick W. Smith

    Try doing a file-level backup of the ESP (using cp, zip, or similar tools). You can then create a fresh FAT filesystem on the ESP and restore the backup. You might need to adjust your /etc/fstab entry in Linux, but it should otherwise work without changes.

     
    • Mikhail

      Mikhail - 2019-03-25

      I have already done this at different times at least twice. Does not help.

       
  • Roderick W. Smith

    As I said, the only time I've seen this, it was a sign of a failing computer (or perhaps firmware), and I've had to retire the computer. Trying to resolve the problem is worth doing, of course, but if your situation is like mine, the computer simply is not long for this world as a useful device, I'm afraid.

     

Log in to post a comment.