TC cannot see /dev/mmcblk0 despite having been booted from there

[yoroce]

I've installed Tiny Core Linux to my hard drive. I can boot into it, by I end up at a command prompt, and the system can't find my hard drive (despite having booted off of it). When I look around in /dev, the relevant devices aren't there (so of course X can't start, etc., since the relevant extensions can't be loaded). This is odd because when I run TC live off a USB key the devices show up fine. I've looked through dmesg, and I don't see any obvious errors, but I don't really know what to look for.

A few weeks ago I had a superficially similar error that was solved by using the waitusb bootcode, but the problem here is different. In the former case the devices would show up, just not in time for the boot process. Now they're never showing up. I'm running with waitusb=90 and it's not helping. Of course I changed things, and that's what broke Tiny Core in the first place: I put Windows back on my computer, which entailed moving TC to a different partition. That's when this problem started. I reinstalled, but that didn't change anything. I'm trying to think what else has changed. I'm using UEFI now, and I wasn't before (but I'm not using SecureBoot).

Here's my GRUB entry. The top is a bunch of verbiage I found, on these forums and elsewhere, that didn't seem to help except making the boot process marginally prettier. What can I do to get Tiny Core working again?

recordfail
loadfont unicode
insmod gzio
set gfxterm=auto
terminal_output gfxterm
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
insmod efi_gop
insmod efi_uga
insmod font
insmod gfxterm


search --no-floppy --fs-uuid --set=root e927b1d7-a342-45a7-a283-d1ef7d9aa2f5
linux /tce/boot/vmlinuz waitusb=90:UUID="e927b1d7-a342-45a7-a283-d1ef7d9aa2f5" home=UUID="e927b1d7-a342-45a7-a283-d1ef7d9aa2f5" opt=UUID="e927b1d7-a342-45a7-a283-d1ef7d9aa2f5" tce=UUID="e927b1d7-a342-45a7-a283-d1ef7d9aa2f5" nozswap norestore tz=EST5EDT,M3.2.0,M11.1.0
initrd /tce/boot/core.gz

[Juanito]

I guess you've double-checked that UUID="e927b1d7-a342-45a7-a283-d1ef7d9aa2f5" is correct for /dev/mmcblk0?

Did you install 64-bit grub (most uefi devices require a 64-bit bootloader)?

[yoroce]

I guess you've double-checked that UUID="e927b1d7-a342-45a7-a283-d1ef7d9aa2f5" is correct for /dev/mmcblk0?

Did you install 64-bit grub (most uefi devices require a 64-bit bootloader)?

Yes, that UUID is correct for /dev/mmcblk0p5, the partition where Tiny Core Linux's files reside (but it's the UUID, not the PARTUUID). When Tiny Core boots I don't see devices for any of the partitions or for the drive itself (/dev/mmcblk0).

I believe I have 64-bit grub installed. I say this because I have a package installed called grub-efi-amd64, and also I'm able to get grub to boot another Linux distribution as well as Windows 10, so whatever version of grub I have, it's compatible with my hardware.

[Juanito]

This might be helpful:

http://forum.tinycorelinux.net/index.php/topic,19364.msg119228.html#msg119228

[curaga]

Look into dmesg for any clues. Or try changing the BIOS values back, unless you need Windows and Windows needs them.

[yoroce]

This might be helpful:

http://forum.tinycorelinux.net/index.php/topic,19364.msg119228.html#msg119228

Juanito, I see that you wrote on this other thread, "Note that you will need to use corepure64 as most efi/uefi are 64-bit." I just want to be explicit here: I'm going to need to switch to corepure64 if I want things to work with UEFI/64 bit GRUB?

Thanks.

[Juanito]

Once the 64-bit uefi files have been written by grub using corepure64, it can be used to boot both 32-bit core and 64-bit corepure64.

As you say you seem to already have 64-bit grub installed you should be able to boot 32-bit core without problems.

[yoroce]

Look into dmesg for any clues.

Oh, have I ever. A lot of it is beyond my understanding, even with the help of search engines. Here are some interesting-looking lines in case anyone sees anything in it that I can't and wants to advise (the whole thing is here):

Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
...
efi: No EFI runtime due to 32/64-bit mismatch with kernel
...
efi: Setup done, disabling due to 32/64-bit mismatch
...
apm: BIOS not found.
...
GHES: HEST is not enabled!
...
ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
ACPI: AC Adapter [ADP0] (off-line)
ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared

[yoroce]

OK, I thought of another way to look at dmesg output. Since everything works when I boot from a live USB, I went ahead and did that and save the dmesg output, then diff-ed the two. There are a lot of little differences when I look at the diffs, but the thing that stands out to me is this:

$ grep -i sdhci dmesg.installed.txt dmesg.liveusb.txt
dmesg.installed.txt:sdhci: Secure Digital Host Controller Interface driver
dmesg.installed.txt:sdhci: Copyright(c) Pierre Ossman
dmesg.liveusb.txt:sdhci: Secure Digital Host Controller Interface driver
dmesg.liveusb.txt:sdhci: Copyright(c) Pierre Ossman
dmesg.liveusb.txt:sdhci-pci 0000:00:10.0: SDHCI controller found [8086:2294] (rev 21)
dmesg.liveusb.txt:sdhci-pci 0000:00:10.0: No vmmc regulator found
dmesg.liveusb.txt:sdhci-pci 0000:00:10.0: No vqmmc regulator found
dmesg.liveusb.txt:mmc0: SDHCI controller on PCI [0000:00:10.0] using ADMA


OK, so the installed version is failing to detect an "SDHCI controller." But why? All I could think of is that it's something PCI-related, based on the name "sdhci-pci", and when I grep out and diff all the PCI-related lines from the two dmesg files I do get some differences (see below), perhaps starting with the fact that the installed version (left file) is apparently not using mmconfig (although it's mentioned again two lines later). Can anyone advise on where to go from here?

1c1
< e820: [mem 0x7ee00000-0xe00f7fff] available for PCI devices
---
> e820: [mem 0x80000000-0xdfffffff] available for PCI devices
5,8c5
< PCI: not using MMCONFIG
< PCI: Using configuration type 1 for base access
< PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000)
< PCI: MMCONFIG at [mem 0xe0000000-0xe3ffffff] reserved in ACPI motherboard resources
---
> PCI: MMCONFIG at [mem 0xe0000000-0xe3ffffff] reserved in E820
9a7
> PCI: Using configuration type 1 for base access
29a28,30
> pci 0000:00:10.0: [8086:2294] type 00 class 0x080501
> pci 0000:00:10.0: reg 0x10: [mem 0x91321000-0x91321fff]
> pci 0000:00:10.0: PME# supported from D0 D3hot
33a35,38
> pci 0000:00:18.0: [8086:22c0] type 00 class 0x080102
> pci 0000:00:18.0: reg 0x10: [mem 0x91318000-0x9131bfff]
> pci 0000:00:18.1: [8086:22c1] type 00 class 0x0c8000
> pci 0000:00:18.1: reg 0x10: [mem 0x9131f000-0x9131ffff]
47a53,56
> pci 0000:00:1e.0: [8086:2286] type 00 class 0x080102
> pci 0000:00:1e.0: reg 0x10: [mem 0x91314000-0x91317fff]
> pci 0000:00:1e.4: [8086:228c] type 00 class 0x078000
> pci 0000:00:1e.4: reg 0x10: [mem 0x9131e000-0x9131efff]
60,66c69,75
< ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
< ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
< ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
< ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
< ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
< ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
< ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
---
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *7
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *7
107a117,120
> sdhci-pci 0000:00:10.0: SDHCI controller found [8086:2294] (rev 21)
> sdhci-pci 0000:00:10.0: No vmmc regulator found
> sdhci-pci 0000:00:10.0: No vqmmc regulator found
> mmc0: SDHCI controller on PCI [0000:00:10.0] using ADMA

[curaga]

The bios is hiding it due to the new settings somehow. I doubt there's a community around Cloudbooks like there is for Chromebooks, so you might ask on the linux-efi mailing list.

You can also try the 64-bit version, perhaps it can access it due to being the same bitness as the EFI bios.

[andyj]

This thing doesn't have TPM does it?

[yoroce]

Hi @andyj. Sorry, I didn't see your post right away. I must not have been logged in when I viewed the previous post, so I did not get notified of yours. This machine does in fact have TPM. I just turned TPM off and tried booting into Tiny Core but go the same result. Thanks for the suggestion.

[andyj]

I asked about TPM because I'm having a similar problem with a laptop with Windows 10 on it. It has Bitlocker which is protected via TPM, so when I boot into Linux using a USB drive the installed drive's SATA link is down according to dmesg and so doesn't get a device. It sounds like you have something similar, and I'm assuming that TPM is to blame in my case. I have to have TPM (my company's laptop), but so far I haven't had any success accessing the drive using the linux tpm tools. I haven't tried hammering one in using mknod. Have you tried that yet?

[yoroce]

No, I haven't tried mknod. It might be beyond my capabilities. But I'd be surprised if it worked anyway given that the SDHCI controller isn't found during boot with UEFI (unlike when I use legacy boot).