Is this tested on M1 / Asahi F40?

[mattbdc]

A few errors about failure to unmount as last step in build.sh -d /dev/whatever, but then build.sh mount step doesnt works and suggests dmesg, nothing clear in dmesg, tried 3 USB sticks with same issue. I will dive in further and share logs etc if its expected to work with Asahi Fedora 40?

[leifliddy]

Thanks. I'll test that out tonight....

…

On Tue, Apr 30, 2024 at 4:24 PM Matt ***@***.***> wrote: A few errors about failure to unmount, but the build.sh mount step doesnt works and suggests dmesg, nothing clear, tried 3 USB sticks. I will dive in further and share logs etc if its expected to work with Asahi Fedora 40? — Reply to this email directly, view it on GitHub <#29>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADCOG6PYNXUQ52OIMFEZQWDY76SQLAVCNFSM6AAAAABHAMFVJOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3TCNRRGQ4DGNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[leifliddy]

I missed an update to F40. It should work now. What's odd is the the u-boot cmds no longer work -- so I removed them from the readme. It appears that usb drives now have priority in uboot and will auto-boot if inserted. I'm send Janne a msg to verify whether this is the intended behavior or not.

[mattbdc]

Still having issues, a few errors, mount fails, and the USB disk is just empty other than two partitions with just skelton lost+found folders.

‣  Running depmod for 6.8.8-400.asahi.fc40.aarch64+16k
‣  Generating system users
‣  Generating volatile files
‣  Applying presets…
Removed "/var/tmp/mkosi-workspacez3jsn9bq/root/etc/systemd/system/systemd-homed.service.wants/systemd-homed-activate.service".
Created symlink /var/tmp/mkosi-workspacez3jsn9bq/root/etc/systemd/system/systemd-homed.service.wants/systemd-homed-activate.service → /usr/lib/systemd/system/systemd-homed-activate.service.
‣  Applying first boot settings
/var/tmp/mkosi-workspacez3jsn9bq/root: /etc/passwd written.
/var/tmp/mkosi-workspacez3jsn9bq/root: /etc/shadow written.
‣  Generating hardware database
‣  Relabeling files using targeted policy
Create snapshot of '/var/tmp/mkosi-workspacez3jsn9bq/staging/image' in '/home/matt/asahi-fedora-usb/mkosi.output/image'
‣  /home/matt/asahi-fedora-usb/mkosi.output/image size is 1.7G.
### Cleaning up
rm: cannot remove 'mkosi.output/image/var/cache/dnf/copr:copr.fedorainfracloud.org:group_asahi:fedora-remix-branding-7c716826e400b621': Is a directory
rm: cannot remove 'mkosi.output/image/var/cache/dnf/copr:copr.fedorainfracloud.org:group_asahi:fedora-remix-scripts-fc41b8e210141be6': Is a directory
rm: cannot remove 'mkosi.output/image/var/cache/dnf/copr:copr.fedorainfracloud.org:group_asahi:kernel-fe6f29f8650ee02d': Is a directory
rm: cannot remove 'mkosi.output/image/var/cache/dnf/copr:copr.fedorainfracloud.org:group_asahi:u-boot-3a6f8c84bc178696': Is a directory
rm: cannot remove 'mkosi.output/image/var/cache/dnf/fedora-f7555ca695ce920e': Is a directory
rm: cannot remove 'mkosi.output/image/var/cache/dnf/updates-a18edc7e5a341f29': Is a directory
root@fedora:/home/matt/asahi-fedora-usb# ./build.sh  mount
### Mounting to /home/matt/asahi-fedora-usb/mnt_usb
mount: /home/matt/asahi-fedora-usb/mnt_usb/boot: mount point does not exist.
      dmesg(1) may have more information after failed mount system call.

[mattbdc]

Cant see anything odd in dmesg

[  351.180245] EXT4-fs (sda3): mounted filesystem d747cb2a-aff1-4e47-8a33-c4d9b7475df9 r/w with ordered data mode. Quota mode: none.
[  351.252576] EXT4-fs (sda2): mounted filesystem a1492762-3fe2-4908-a8b9-118439becd26 r/w with ordered data mode. Quota mode: none.
[  351.252661] EXT4-fs (sda2): unmounting filesystem a1492762-3fe2-4908-a8b9-118439becd26.

usb_mnt was mounted to /dev/sda3 (/dev/sda was the usb stick) it seems looking at output of mount

will try dd if=/dev/zero on the stick and try completely fresh.

Tried everything again, even reclone repo in fresh directory, still yields a USB stick with two partitions called fedora-usb-boot with nothing on (other than lost+found folders)

[AmateurECE]

Tried everything again, even reclone repo in fresh directory, still yields a USB stick with two partitions called fedora-usb-boot with nothing on (other than lost+found folders)

I'm seeing the same thing on x86_64/F40.

[leifliddy]

Can you run and post the following cmd as root?

[root@mac ~]# $(which mkosi) --version
mkosi 22

If the mkosi version is 22 then run + post the following

blkid | grep /dev/sdx``

The comment ouf set -e and the top of build.sh and replace it with set -x
Then run /build.sh -d /dev/sdx and post the output somwhere.

[mattbdc]

You probably just need the extra -r from my open pull request , but removing the -e above will probably work too as it will just skip over that line. I think very early asahi fedora installs had a lot more left over bits in that directory some of which folders.

[AmateurECE]

Removing set -e appears to have worked! I used the live USB to recover my system successfully. I didn't peer through the log to see which command was failing, but it sounds like you guys already have it figured it out. Here's the log anyways:

asahi-fedora-usb-log.txt

mkosi version was 22.

[leifliddy]

hmmm....you would need to do something like a set -ex' and see where it stopped. I'll test this out tonight. I'd like to leave set -e` in place as I don't want the script progressing in the event that it failed a critical step.