-
Notifications
You must be signed in to change notification settings - Fork 6
M1 Mini - Boot persistence #31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Well, first, the obligatory warning: using the NVMe disk might put your device into a state that requires DFU mode to restore. (That said, this only happened to me once, when I deliberately modified the recovery partition to see what would happen.) The most important part is not to touch the Apple partitions. That means using the Apple Disk Utility to create one (or several) MS-DOS partitions that Linux can then use (it doesn't care much about the partition type in the partition table). The second most important part is that fatfs currently is not supported: it syncs to disk in a way the Linux NVMe driver doesn't understand yet, so changes might not be written after an fsync. So, from memory:
If all goes well, you will boot to your new Debian system automatically. If things do not go well, do the following:
Btrfs does work but requires extra setup (debian defaults, when creating a btrfs root file system, to putting its stuff in a subvolume, and pearl attempts to mount the main volume, so (Edited to fix incorrect /dev/ path) |
Hello Pip, be MS-DOS partition, I presume you mean an EX-FAT partition? Regards, Ry |
I use the option called "MS-DOS (FAT32)" in Disk Utility, but ExFAT ought to work as well if you don't see the option for some reason. The partition is then reformatted as a different file system which macOS should be unable to recognize... |
Oh, and of course, do feel free to leave questions or comments. As I said, it was from memory, though I'm currently going through an install with the new kernel on the One gotcha is that it's very advisable to suggest a desktop environment; without it, you won't get network-manager, and it'll be harder to connect the machine to a network again. Just as a reminder, it is of course possible to install different distributions, as long as those distributions accept being switched to using a foreign kernel (and, alas, as long as they're okay with a 16 KB page size). Technically, of course, we're not running Debian, but the Debian userspace with our own kernel and modules. |
Hello Pip, I have tried a straight reboot and a power recycle, in both cases, your pearl script starts again. Regards Ry |
Are you saying you are selecting "final" in the boot menu, and it boots to the installer again, after the installation? Can you open a shell and (Unfortunately, there's a bug that I only fixed today which means you have to hit enter once on the pearl screen rather than just waiting for it to go away. Sorry about that). |
The message is okay, by the way. Pearl is the boot loader, the Debian installer just doesn't know it exists :-) |
"Are you saying you are selecting "final" in the boot menu, and it boots to the installer again, after the installation? Can you open a shell and cat /persist/root in it to see it's correct? - I select Install (Debian Installer) from your menu. No, after the "successful" Debian install, after a power off/on, your perl script (no4k, delay, root /dev/... etc.) starts automatically. |
cat /persist/root /dev/mapper/nvme0n1p3. This looks correct. |
I'm not sure I understand how that can happen. What should happen is that after the power on, you see the pearl 4-screen split-screen again, select "final", and it should boot to Debian. Are you saying you're seeing Recovery Mode instead? Maybe a screenshot could help me understand what you're seeing. |
Oh, you have
If you're happy with the results, you can go into the Recovery Mode terminal and run
(or whatever) to see whether it works automatically, though you'll still have to select "final" manually until tomorrow's release. |
Sorry about that mistake, by the way. Entirely my fault, should be fixed in the instructions now. |
Hello Pip, you boot persistence Debian Installer works! My compliments on the brain cells expended to get this to work. Chapeau! I also observe the (ethernet) internet speed is not what I expect, somwehat slow. Regards, Ry |
Hello Ry,
Hmm. What does
I think we're currently unpacking them automatically, so you can probably delete them; in any case, they're both necessary for WiFi but nothing else.
Yes. The way it currently is is that Debian installs a 5.10 kernel but it's never used. Uninstalling the Debian kernel package causes dependency woes, so I just left both installed for now. It's true that /lib/modules contains subdirectories for both kernels; right now, the way that happens is a bit of a hack, because I've been stuck in a system that couldn't get the network modules to get the other modules once too often :-) Anyway, apart from the wasted disk space, this shouldn't cause major issues.
Almost certainly :-)
Is this with or without the EEE firmware?
I'm afraid at this point you'll have to go back to Recovery Mode and modify the Thanks, again, for all the testing, |
Pip, EEE firmware??? Here is an excerpt from dmesg - root@magalas:~# dmesg |grep -i tg Regards, Ry |
The penny drops - |
Yes, I messed up that one :-( It's salvageable (I'm running it), but that's probably not necessary or useful. The release has been deleted, so if you reinstall it should go back to the previous, kinda-working one. |
Have done so. Unfortunately, I will have to start the no4k dance with Pearl again. |
Pip, also seeing this - @magalas:~# dmesg |grep brcmf [ 83.549685] ieee80211 phy2: brcmf_msgbuf_query_dcmd: Timeout on response for query command Any ideas? |
1 similar comment
Pip, also seeing this - @magalas:~# dmesg |grep brcmf [ 83.549685] ieee80211 phy2: brcmf_msgbuf_query_dcmd: Timeout on response for query command Any ideas? |
Github playing tricks again. I had to close and reopen this issue again. |
Problem in the wifi driver. Are you using it? Maybe it doesn't like being loaded but unused, and you could just rmmod it? |
Pip, trying to. The wifi part is proving to be a stubborn beast - Regards, Ry |
"cfg80211: loaded regulatory.db is malformed or signature is missing/invalid" is fixed. The ...FW failed to initialise stuff persists. |
GitHub is having trouble, it seems. |
...or was having trouble, this run actually looks good so far :-) |
Please let me know when I should descend to the boiler room. :) |
Okay, that took a while longer that usual, but the build has finally finished, and it boots on my mini, so I'd be very interested to know:
Note that the tg3 problems are still present, and there's copious debug output so this "release" isn't all that usable with standard logrotate settings. Thanks, as always, for all the testing efforts! Pip |
Must put on my overalls on first. Will report back. |
Pip, still the same unfortunately. lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 A lot of NVRAM diagnostics/dumping at startup. [Mon Dec 27 15:26:53 2021] brcmfmac: brcmf_pcie_register Enter Do you need any logs? Ry |
Bummer. Any idea what might have gone differently with the boot which gave you a
|
Pip, here is a short log immediately after issuing these commands - |
Pip, just rebooted. Did nothing special, just a routine restart. Tue Dec 28 13:34:12 2021] brcmfmac: brcmf_pcie_ring_mb_write_wptr W w_ptr 271 (0), ring 3 wlan0 IEEE 802.11 ESSID:"Propodopolus" enx560910d15459 no wireless extensions. This is very frustrating and as far as I know, impossible to reproduce. Ry |
Well, at least we know the hardware's working now :-) It is frustrating that I'm not seeing any failures at all, but you're seeing them (it seems) randomly, and in most cases. What I'm thinking is we need to reset the hardware more thoroughly in between attempts... It would be interesting to know whether the driver reloads if you don't do another hardware reset, just rmmod/modprobe. I'll try to see what happens if I toggle the SMC power gate after unloading the driver, but I suspect it'll just crash the mini. |
Pip, after a rmmod/modprobe the interface did not disappear, but has been very verbal in syslog - Dec 28 14:05:45 magalas kernel: [ 2820.591359] brcmfmac: brcmf_pcie_ring_mb_ring_bell RING ! |
Device is being stubborn in being brought online again - 2933.494028] brcmfmac: brcmf_pcie_ring_mb_update_rptr R r_ptr 29 (28), ring 0 |
Pip, any further ideas? Ry |
Hmm. No really good ones, at the moment. I tried with the mac address that was used on your system, to exclude that last possibility that that was the significant difference, but it just worked here. Any idea how often it happens to work or fail? Once I get back to the mini, I'll try rebooting it in a loop to see whether I can ever catch it failing to bring up the brcmfmac module... |
Pip, I have booted the machine to macos and back here (Linux) again to see if perhaps a firmware update might change things. Ry |
Pip, performed an init 0 and power off. Lo and behold, wlan0 has surfaced. |
Pip, again, another shutdown and power off/on. The device is not stable and cannot be varied online i.e. with an IP address, DHCP etc. [Wed Dec 29 13:33:47 2021] ieee80211 phy2: brcmf_msgbuf_query_dcmd: Timeout on response for query command Pip, are you also running a 5.16.0-rc6 kernel on the M1 Mini? Ry |
Just came across this - https://lore.kernel.org/all/20211226153624.162281-1-marcan@marcan.st/T/ |
Quite possibly! I'll have a look soon! |
Fascinating.. what happens behind the scenes. |
Pip, have prepared things as per instructions here https://lore.kernel.org/all/20211226153624.162281-1-marcan@marcan.st/T/. [Thu Dec 30 11:45:23 2021] brcmfmac: brcmf_pcie_register Enter Wireless works on macos, I am presuming all of the "correct" firmware is in the right place. Just wondering whether there is a mis-match/compatibility problem with the wireless firmware and the 5.16.0-rc6 kernel I am using...
Ry |
Pip, any developments from your side? Ry |
I'll try preparing a kernel using marcan's driver, but it might not work out today... |
I have tried the method outlined here https://lore.kernel.org/all/20211226153624.162281-1-marcan@marcan.st/T/ and renamed the files accordingly on the Linux side. Still the same error(s). |
The last startup log of 2021. |
Sorry, I won't be getting around to this for at least another few days. Other stuff intervening... |
Understand. |
Very quiet here.. |
Hello Pip, will there be any more updates here? Regards Ry |
Pip,
as discussed in thread/issue #29. I would like to know when boot persistance might become available on this hardware using an NVME SSD.
As I am not familiar with apple internals or this stage1/2/3 stuff, being a humble Linux soldier.
Any assistance you need, please let me know.
Regards,
Ry
PS I have booted to RAM in the past using tmpfs and initramfs, but as stated already, I am not familiar with apple's walled garden.
The text was updated successfully, but these errors were encountered: