marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
Dcow_ has joined #asahi
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow_ has joined #asahi
jeffmiw has quit [Ping timeout: 480 seconds]
jeffmiw has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
wCPO has quit [Remote host closed the connection]
wCPO has joined #asahi
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<amw>
Glanzmann: I did find my MBA got very hot when I left it shut in my bag under Linux - even though it is barely warm at one with the lid open
<amw>
So you were right
Dcow_ has joined #asahi
artemist0 has quit [Quit: artemist0]
artemist has joined #asahi
DarkShadow4444 has joined #asahi
DarkShadow4444 has quit []
DarkShadow4444 has joined #asahi
DarkShadow4444 has quit []
DarkShadow44 has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
DarkShadow44 has joined #asahi
darkapex1 has joined #asahi
darkapex has quit [Ping timeout: 480 seconds]
darkapex2 has joined #asahi
darkapex1 has quit [Ping timeout: 480 seconds]
<marcan>
I would not recommend using Linux in a "portable" scenario without shutting down the full system every time you store it, yet
<marcan>
making that work acceptably well needs more power management stuff that isn't done yet (CPU deep sleep, whole system sleep, both of which depend on the PSCI stuff)
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
jmr2 has joined #asahi
<jmr2>
Be especially cautious if you're using a tree that include the October DCP code. On shutdown, it does turns off the display, but the laptop isn't powered down, since shutdown isn't implemented yet.
jmr2 has quit []
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
burlmancer[m] has joined #asahi
i509vcb[m] is now known as i509VCB
i509VCB has quit [Quit: Reconnecting]
i509VCB has joined #asahi
i509VCB has quit []
i509VCB has joined #asahi
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow_ has joined #asahi
vnogueira has quit [Ping timeout: 480 seconds]
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
the_lanetly_052__ has joined #asahi
the_lanetly_052__ has quit [Remote host closed the connection]
ewrvvvvvvvvvvvd has joined #asahi
n1c has joined #asahi
jeffmiw has quit [Remote host closed the connection]
jeffmiw has joined #asahi
ewrvvvvvvvvvvvd has quit [Remote host closed the connection]
aleasto has joined #asahi
os0 has joined #asahi
os has quit [Read error: Connection reset by peer]
<landscape15[m]>
marcan: Could it be possible to run Linux only with Icestorm cores as a power saving feature?
<amw>
Perhaps there's a magic register to toggle speed up or down - but I guess it's way more complex...
<j`ey>
amw: CPU freq is already worked out
<j`ey>
turning cores off, would require the PSCI thing, mwhich needs some figuring out
<amw>
j`ey: So it is a simple register write ... :-)
<j`ey>
well.. ish :P
<jannau>
landscape15[m]: right now or when support has progressed more. dynamically or just during boot until it is powered down?
<amw>
I think if you turn cores off they lose all register / cache values and need to be re-started correctly - but perhaps changing frequency might be simpler
<landscape15[m]>
jannau: I mean dynamically. But it would also be good to support this with a “power saving” mode (as in macOS).
<amw>
It's always simpler when you don't know what you are talking about :-D
<j`ey>
you can turn cores of in linux with: echo 0 > /sys/devices/system/cpu/cpuN/online
<j`ey>
(wont work yet though)
<landscape15[m]>
j`ey: ok thanks. So it only needs power management optimization.
<amw>
Anything in /sys/devices/system/cpu/cpu0/power do anything yet ? wifi take5 code
<marcan>
we actually don't know how to turn cores off, but we know how to put them into deep sleep, which should be the ~same
<marcan>
they lose GPR register state except pc, sp, which means you need a little push/pop deal around the sleep
<marcan>
m1n1 already implements this
<marcan>
I don't think macOS attempts to actually power cores off at any time except when going into whole system sleep
<marcan>
maybe not even then, logically speaking
<amw>
Is this done in m1n1/proxyclient/experiments/cpu_pstates.py ?
<marcan>
once the PSCI stuff is implemented linux will call m1n1 (which will remain resident in RAM) to implement this, as well as full system sleep
<marcan>
so linux will never actually have this code itself
<amw>
ok - like a bios or UEFI routine?
<marcan>
yes, similar mechanism to UEFI runtime services
<marcan>
but unrelated, we will also have UEFI runtime services via u-boot
<marcan>
the problem is this is normally done by a supervisor or hypervisor, but we don't have either of those on M1 (normally), so we need to invent/standardize a new method for doing it without crossing privilege levels
<amw>
Why is it bad to just call that code directly in Linux - if it is so small
<marcan>
because every other ARM platform does it via PSCI and we don't want to make a mess of things
<j`ey>
amw: upstream wont accept it
<amw>
ok - PSCI = Power State Coordination Interface (according google)
<marcan>
yes
<marcan>
as a bonus, this gives us even *more* chances of things like sleep modes magically working on newer Apple CPUs without any kernel changes
<marcan>
pushing low level stuff into m1n1 is always a win from that point of view
<amw>
OK - but it does sound a little complex if we have m1n1 + u-boot remaining whilst also booting through grub - perhaps just go u-boot => linux?
darkapex3 has joined #asahi
<mps>
amw: you mean u-boot numeric menu
<mps>
and extlinux.conf?
<amw>
mps: Just worried about how everyone doesn't step on the previous layer's code?
<mps>
iiuc uboot and grub are removed from memory when they finish their job
<amw>
mps: In the boards I've worked I think so - but perhaps there is firmware routines that can be implemented by m1n1 + u-boot in a special reserved area denoted in the dtb that the kernel reads (from u-boot)
<maz>
it could, if you were to port grub to m1n1. but the amount of work required for that is absolutely silly, and that's exactly why we have an EFI layer in u-boot...
<mps>
I tried with picocom attached to ttyACM1 on second machine but didn't get anything on it during boot
<mps>
kettenis: ^
<landscape15[m]>
maz: thanks. this means that you can install grub directly into the rootFS right?
<maz>
landscape15[m]: grub needs to live somewhere where the EFI loader will find it, and that's in the EFI partition.
<mps>
grub on my usb disk is in rootFS partition
<mps>
on nvme, even if I put it in efi sys partition it can't be found
<maz>
mps: are you sure? you should have a file called bootaa64.efi in the EFI partition.
<mps>
ok, it is found but doesn't start for unknown to me reason, just puts 'me' in grub cli prompt, image is few msgs above
<mps>
maz: I have it
<maz>
mps: that's grub.
<landscape15[m]>
Well, running grub on USB seems easier (you can make an EFI partition or load the .efi from an EFI folder)
<mps>
maz: ok, that is one part of grub, rest is on rootFS
<maz>
mps: well, everything else is a module that can live anywhere wher grub can load it. the core grub has to live in the EFI partition.
<j`ey>
mps: does your 'u-boot.cfg' has CONFIG_FS_FAT?
<mps>
j`ey: I think so because it works fine from same setup on usb disk
<landscape15[m]>
maz: this means that you need an APFS Container, an ext4 partition, a FAT32 EFI partition. To me it seems a lot
<j`ey>
oh right, hm
<maz>
landscape15[m]: a lot? have you ever seen an Android install, or a ChromeOS install?
<mps>
if I break u-boot and set boot_order usb0 it works and boots from usb
<maz>
landscape15[m]: and you want to consider some swap as well.
<j`ey>
landscape15[m]: having a EFI partition is normal
os0 has quit [Ping timeout: 480 seconds]
os has joined #asahi
<j`ey>
and an APFS container is a level higher than the partitions
<landscape15[m]>
Ok, but what if you have two or more Linux distributions installed…
<maz>
and it's not like partitioning is wasting much space either...
<j`ey>
same as with any other computer
<j`ey>
you'd have more paritions
<mps>
j`ey: APFS container look like it is ZFS, am I right?
<mps>
j`ey: also I didn't but that is what I concluded looking at it
<landscape15[m]>
amw: yes, but the EFI partition is not needed if Linux is loaded by a m1n1 > kernel payload
<j`ey>
landscape15[m]: m1n1+kernel payload is not easy to upgrade
<j`ey>
that's why you want m1n1+uboot, so the kernel can be upgraded without having to go through 1TR+kmutil
<amw>
j`ey: Can't we do m1n1+u-boot payload => ext4 / linux?
<j`ey>
amw: yes, but the point is to use the "normal" boot path from whatever distro, which probably involves grub
<j`ey>
the idea is to integrate with other distros, not make a new one!
<landscape15[m]>
j`ey: So the “standard” way will be m1n1 > uboot payload, which then search for grub, right?
<j`ey>
landscape15[m]: yes
<amw>
ok - so debian et al won't support u-boot?
<j`ey>
well debian packages u-boot, but the intended path is to be more UEFI like
<maz>
amw: the standard way to use u-boot from a distro these days is to use u-boot's EFI interface. it makes things a lot easier for Debian (and everyone else), as nobody has to care about the various versions of u-boot and their level of brokenness across 2000 different platforms.
<landscape15[m]>
j`ey: thanks. Also Linux kernel updates will be easier and not dependent on the boot chain.
<mps>
amw: I don't know grub cli commands, have to read some docs first (mostly use syslinux and u-boot on my machines for years)
<amw>
Try "set" and see what variables it sets?
<kettenis>
landscape15[m]: I don't know why grub is upset (and I don't really use grub as OpenBSD has its own EFI bootloader)
<kettenis>
could be misconfiguration, or maybe it gets confused by the presence of the apple-specific partitions
<amw>
Does "ls" see anything - perhaps it is defaulting to the wrong partition?
<mps>
looks like it scans first 3 partitions (o, 1, 2) and then give up
<maz>
it looks like grub doesn't find its configuration file, or that the fonfig file doesn't match the system that grub sees (UUIDs, partition layout and such)
<amw>
grub has a clunky (hdX,Y) syntax for partitions
<mps>
and rootFS with grub config and modules are on partition 5
<amw>
Does your grub support nvme devices? Can you do ls (hd0,5) or (hd1,5)
<mps>
I have to boot chromebook and try again
<mps>
amw: give me 5 minutes
<kettenis>
grub doesn't need to care about if this is an nvme device or not
<amw>
It kind of sounds like u-boot can see the device, loads grub which can't read any partitions and drops into rescue shell
<maz>
there are *two* grub config files in most installs: one that is colocated with bootaa64.efi (used to botstrap the environment), and another one with the full config. obviously, the first has to know how to find the second one.
<kettenis>
but even without a config file, grub should be able to recognize the partitions
<kettenis>
fun fact: the nvme uses 4k sectors
<maz>
yes, absolutely. it may not be able to use the FS though.
<amw>
Under Linux my USB device is /dev/sda but my nvme is nvme0n1 - quite different driver?
<mps>
amw: ls in grub shell shows all partitions
<amw>
Then you should be able to manual load the kernel / initrd
<mps>
set shows this 'prefix=(hd1,gpt2)/boot/grub'
<amw>
Does ls (hd1,gpt2)/boot/grub work?
<mps>
amw: no
<kettenis>
gpt2 is almost certainly the APFS partition
<amw>
I think that is where grub will look for it's files (and kernel)
<amw>
Perhaps try changing to the ext4 or what ever linux partition?
<amw>
e.g. set prefix=(hdX,Y)/boot/grub sort of command
<mps>
amw: what is grub command to try boot after changing prefix
<amw>
There's alot of other stuff there that looks useful too
<mps>
hmm, uncrecognized
<amw>
Did the "ls /" show anything?
<amw>
In particular those notes say "set prefix=(hdX,Y)/boot/grub => se the actual location of the grub folder"
<mps>
amw: yes, 'unknown filesysystem'
<amw>
*Use
<mps>
oh, there is root variable
<amw>
Try ls (hd1,gpt5) - if your linux on 5th partition?
<mps>
got 'filesystem is ext2'
<mps>
something is missing with grub, help and boot are unrecognized
<amw>
mps: That's better than unknown filesystem :-}
<amw>
If your grub is on the EFI - shouldn't the partition it wants be FAT32 ?
<amw>
Is that (hd1,gpt1) ?
<kettenis>
(hd1,gpt4) would be my guess
<mps>
amw: no, grub is gpt5
<mps>
efi is gpt4
<kettenis>
anyway, you should be able to list files on those partitions with
<mps>
kettenis: I tried to put complete grub on efi partition (gpt4) but still didn't worked
<kettenis>
ls (h1,gpt4)/
<kettenis>
and
<kettenis>
ls (hd1,gtp5)/
<amw>
I'm afraid I have to go to bed - those notes say grub rescue> => grub can't find the grub folder
<mps>
ls (hd1,gpt4) => filesystem unknown
<mps>
ls (hd1,gpt5) => ext2
<mps>
ok, good night
<kettenis>
well, if (hd1,gpt4) really is your efi filesystem, grub doesn't recognize it as such
<kettenis>
so either the partition type is wrong, or the fat32 filesystem on there is busted
<kettenis>
or you have a grub that doesn't include fat32 support, which would be silly
<mps>
hm, I tried to copy all this to usb and it works fine
eroux has joined #asahi
<mps>
and opposite, copied all from usb disk and it doesn't find /boot/grub on gpt5
eroux has quit [Ping timeout: 480 seconds]
<marcan>
landscape15[m]: GPT can handle up to 128 partitions, so I'm really not worried about typical users running out of partitions by doing multiple linux installs
<marcan>
besides, "traditional" linux is at least root, boot, swap; here we'd have stub, EFI, root, maybe swap (no need for root these days) so it's not that different
<marcan>
*for boot
<marcan>
amw: subsequent stages do not step over each other if they shouldn't; there are multiple reserved memory mechanisms depending on how you're booting
<marcan>
m1n1 is actually *required* to stay in RAM for us to implement sleep, due to how the CPU RVBAR gets locked down
<marcan>
it is a hard requirement of the platform as it exists today that the computer will wake up at m1n1's base address, the way I have addresses aligned right now
<marcan>
so there has to be *something* there if nothing else
<marcan>
that doesn't mean m1n1 needs to stay entirely resident; I'll probably constrain the PSCI code to not use any dynamic memory, so we can throw away the heap; that would keep the memory wastage to under a couple MBs max, and we could shrink it further if we really want to with some section trickery
<kettenis>
fwiw, u-boot does section trickery and has a PSCI implementation for some boards that don't have TF-A that fits in a few pages
<kettenis>
peanuts compared to what apple already steals for some of the firmware blobs ;)
<kettenis>
(that PSCI implementation wouldn't be very useful to us though)
<marcan>
makes sense, yeah
<kettenis>
the efi runtime in u-boot uses a similar mechanism
<marcan>
and we certainly could fit the PSCI code in a few kBs if we want, though that would involve forgoing all the m1n1 infra and mostly making it a separate codebase, which may or may not be what we want
<marcan>
(e.g. leaving the UART iodev active, at least if debug was active, is quite legitimate for debugging suspend/resume and will largely play fine with the kernel driver)
<kettenis>
making it a separate codebase would probably be what I'd do
<marcan>
depends on how much machinery ends up going in there
<kettenis>
true
<kettenis>
but it would make it easier to audit the code
<marcan>
yeah, but it's not like there's much of an attack surface here, and m1n1 is the root of trust for our ecosystem anyway
<marcan>
e.g. there's a chance we end up having to talk to SPMI or something for sleep, and if it comes to that I'm not sure I want to start over without our usual scaffolding :p
<marcan>
but either way, this is all relatively easy to refactor post facto; m1n1 is small enough it's easy to do major surgery on it
<marcan>
so unless it turns out the PSCI code will be basically freestanding once we figure out what needs to go there (i.e. one C file), I'll probably just start by leaving all of m1n1 resident
<marcan>
and then if we want to slim it down in the future we certainly can
<NightRaven[m]>
is there any easy way to get a wifi dongle working ?
<mps>
NightRaven[m]: which dongle, do you know its usb id
<Glanzmann>
NightRaven[m]: wifi already works.
<NightRaven[m]>
i have a realtek 811
<Glanzmann>
NightRaven[m]: And USB works, too. So you probably only have to plug it in and compile in the right modules into the kernel.
<Glanzmann>
NightRaven[m]: Why don't you use the wifi from marcan?
<NightRaven[m]>
i don't have a second machine
<NightRaven[m]>
to enable the firmware stuff
<Glanzmann>
NightRaven[m]: Oh, I see.
<mps>
NightRaven[m]: type 'lsusb' and look at ID column
<Glanzmann>
NightRaven[m]: THan I would use mps kernel config and than add the kernel module for you wifi stick.
<NightRaven[m]>
Glanzmann: but how would you add a kernel module ?
<Glanzmann>
NightRaven[m]: Do you have a usb ethernet card?
<NightRaven[m]>
Glanzmann: i don't
<NightRaven[m]>
only a wifi dongle
<Glanzmann>
NightRaven[m]: Buy one, makes your life easier.
<NightRaven[m]>
hmm i will but for now i want try to get the dongle working so i build the kernel using mps's config
<mps>
NightRaven[m]: tell me what lsusb says for your dongle and I will which module you need
<mps>
NightRaven[m]: hmm, kernel have only RTL8192U but not RTL8192EU
<mps>
NightRaven[m]: ah, you are lucky 'drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: * The RTL8723BU/RTL8192EU vendor driver use coexistence table type'
<NightRaven[m]>
oh ok
<NightRaven[m]>
so i will build the kernel with your config is this your config wget https://tg.st/u/.config
<NightRaven[m]>
s/wget//
eroux has joined #asahi
___nick___ has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
<Glanzmann>
NightRaven[m]: Yes, that is mps config. And than you have to add the additional module.
<Glanzmann>
Also don't forget about the firmware.
<Glanzmann>
NightRaven[m]: What Linux Distribution do you use?
<NightRaven[m]>
i want to use arch
<mps>
NightRaven[m]: I think it is CONFIG_RTL8XXXU in kernel config, you have to enable this
<NightRaven[m]>
mps: there is not CONFIG_RTL8XXXU in the .config file
<NightRaven[m]>
or do i have to add it ?
<mps>
NightRaven[m]: run 'make nconfig' or 'make menuconfig' and go to drivers/networking menu and look there
<NightRaven[m]>
oh ok thx i willl post any problems i have i will try it now
<landscape15[m]>
<mps> "NightRaven: type 'lsusb' and..." <- Do you need to do that also for a usb-c to Ethernet dongle? So that I can enable (if present) that card in my config.
<landscape15[m]>
mps: thanks. I didn’t try it yet. But I’m also considering to build mine, to get basic Wi-Fi stuff working.
<kettenis>
reworked the keyboard mapping in u-boot a bit to make the arrow keys work
<mps>
kettenis: thanks
<kettenis>
tested with grub from the debian installer
<mps>
kettenis: it is OT question, but do you know how to increase character size in u-boot
<kettenis>
booted from usb, but it does recognize my efi and openbsd partitions just fine
<mps>
I tried with setting ttf font but got only blank screen (always used u-boot with serial consoles till now)
<NightRaven[m]>
<mps> "NightRaven: landscape15[m..." <- ok i will use that let me just payload that and boot from the .bin file
<kettenis>
mps: no I have no idea
<mps>
NightRaven[m]: you have kernel and dtbs (and config) in boot dir when you unpack tar file
<mps>
I hope you have m1n1.macho already
<mps>
kettenis: np, will try to find on the net
<NightRaven[m]>
mps: wait so i have the .bin file
<NightRaven[m]>
but where do i put the stuff inside the tar file ?
riker77 has quit [Quit: Quitting IRC - gone for good...]
<mps>
NightRaven[m]: best is to mount you target rootFS somewhere (/mnt for example) and do 'tar xf linux-5.16.0-rc5-a15.tar.gz -C /mnt'
<NightRaven[m]>
oh ok
<kettenis>
fwiw, I just chainloaded the OpenBSD EFI bootloader from the grub that is part of the debian installer ISO
<tpw_rules>
mps: that looks like grub's fault. u-boot loaded it fine
<mps>
tpw_rules: yes
<mps>
tpw_rules: only strange thing is it works fine from usb disk
<tpw_rules>
is the USB disk plugged in at this point?
<tpw_rules>
did you compile grub yourself? mine has a whole bunch of modules.
<mps>
doesn't matter, same happens with it plugged or not
<tpw_rules>
ok, i've had weird problems before when i have a usb with the same filesystem UUIDs as the nvme plugged in
<mps>
looks like i need to look at grub build options
<kettenis>
tpw_rules: UUIDs that aren't quite unique? ;)
<tpw_rules>
also also nixos keeps its kernel and initrd on the ESP so it doesn't technically need to access ext4. not sure how your distro does it
<tpw_rules>
kettenis: blame the abhorrent practice of SD card images!
<kettenis>
I'll gladly do that!
<kettenis>
oh, interesting
<kettenis>
Debian actually uses SHIM on aarch64
<tpw_rules>
btw random arcana: when i made my ESP, i had to pass `-s 1` to mkfs.vfat to stop it complaining about the data structure size on a 512MiB ESP. maybe if you don't it creates a not quite standard partition grub isn't happy with. the nvme is 4k hard sectored and your USB presumably isn't
<tpw_rules>
mps: ^
<mps>
tpw_rules: I created both partitions with 'mkfs.fat -F 32'
<mps>
s/created/made FS/
<j`ey>
kettenis: not anymore
<mps>
(time for lunch, will be afk)
riker77 has joined #asahi
<NightRaven[m]>
Mps I have done the tar xf on the /mnt but now I get this
<landscape15[m]>
NightRaven: I used rsync to copy the rootFS onto the nvme partition. It worked but you may need to repair it with e2fsck
<kettenis>
tpw_rules: applied the usb timer thingy to my branch
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
<NightRaven[m]>
<landscape15[m]> "NightRaven: I used rsync to copy..." <- Hmm I have formatted multiple times I have done mkfs.ext4 /dev/sda then I tar -xf in a folder with the rootFS the sudo cp -r * /mnt Then I did mp's command
os5 has joined #asahi
os has quit [Ping timeout: 480 seconds]
bradfier has quit [Quit: Leaving...]
bradfier has joined #asahi
<NightRaven[m]>
Ok I get the same problem with my other HDD could it be the image.gz ?
<landscape15[m]>
NightRaven: why don’t you simply cp -r from the extracted rootFS to the root USB device?
<NightRaven[m]>
That's what I do
<NightRaven[m]>
Oops I missed a sentence
<NightRaven[m]>
I am on my phone sorry I am not the best at typing at it
<NightRaven[m]>
But I have tried my different HDD and same problem so I am going to try a different image.gz
<landscape15[m]>
NightRaven: yeah it could be the kernel broken
<NightRaven[m]>
Yep
<NightRaven[m]>
Same message
<landscape15[m]>
With my config I get keyboard and nvme working, but USB doesn’t work. Which options should I enable?
<NightRaven[m]>
I used Glanzmann's one
<NightRaven[m]>
I am not sure
<NightRaven[m]>
<NightRaven[m]> "so i will build the kernel..." <- Try
<NightRaven[m]>
That . config
<landscape15[m]>
NightRaven[m]: mmh, try to build it yourself with debootstrap. In my case it worked.
<NightRaven[m]>
With debootstrap ?
<landscape15[m]>
NightRaven: yeah it’s a tool that let you build a Linux rootFS with basic tools. Then under chroot you can install everything you want.
<NightRaven[m]>
Oh ok I will try that
<landscape15[m]>
NightRaven: ok let me know
<NightRaven[m]>
If it does not work I am just going to post a picture and wait for mps or someone
<landscape15[m]>
<landscape15[m]> "With my config I get keyboard..." <- I’m comparing my config with mps’s one to find why USB doesn’t work. I enabled all APPLE configs, but still doesn’t work.
zimsneexh has quit [Read error: Connection reset by peer]
<tpw_rules>
mps: maybe try with mkfs.vfat -F 32 -s 1 . how big is your ESP?
<tpw_rules>
kettenis: cool. i saw your review email too, thank you! ( i received it twice though? )
<kettenis>
yeah I mistyped one of the addresses in the CC's a added
<kettenis>
so I sent it again
<tpw_rules>
i assume you've made the internal keyboard poll not take 40ms
<kettenis>
something around 1ms I think
<tpw_rules>
ok. i still think the 5us poll timer is kind of absurd but 1ms should only delay for a second or so i imagine.
___nick___ has quit []
___nick___ has joined #asahi
<mps>
tpw_rules: not sure this will help, looks like grub stop scanning partitions on number 2, i.e. scans 0, 1 and 2 and then stops
<tpw_rules>
mps: well partition 3 might be a not quite valid FAT
<tpw_rules>
if it's the ESP
<tpw_rules>
it should be a simple matter to copy files off the ESP then reformat it right
<landscape15[m]>
NightRaven: try to keep the default mount point for your USB and cp -rf directly to it.
<NightRaven[m]>
so ```sudo cp -rf * /mnt/debian```
os has joined #asahi
<NightRaven[m]>
* is the rootFS
<NightRaven[m]>
```*```
<mps>
tpw_rules: right, it is simple task, I can try this
os5 has quit [Read error: Connection reset by peer]
<landscape15[m]>
NightRaven: so yes. But you should add the entire rootFS path, not only `*`
<NightRaven[m]>
See what i do is i put all the rootFS into a folder at home and then i cd into the folder and do ```sudo cp -rf * /mnt/debian``` i do ```*``` for everything in that folder
<NightRaven[m]>
so the rootFS
<landscape15[m]>
NightRaven: ok then. It should work. But have you moved the rootFS files with cp to that folder? Permissions could be broken.
<NightRaven[m]>
but i use sudo should i go to root
<NightRaven[m]>
?
<mps>
NightRaven[m]: from your image above looks like your root FS is broken
<landscape15[m]>
NightRaven: if you used sudo then no
<NightRaven[m]>
mps: but i do ```sudo mkfs.ext4 /dev/sda```
<NightRaven[m]>
i am cleaning the hdd
<NightRaven[m]>
then mounting it and putting the rootFS on too it
<NightRaven[m]>
<mps> "NightRaven: you have kernel..." <- and then your files
<mps>
why didn't you created partition tables and partitions on your disk
<NightRaven[m]>
i mean this worked before so i thought it will work
<NightRaven[m]>
i did not know you need it but it worked without it
<NightRaven[m]>
before
<mps>
it could work but is unusual
<mps>
if you could 'follow' shell script I created to install alpine I can post it to use it as hints for your distro
<NightRaven[m]>
i am going to try landscape's sudo cp -rf
<NightRaven[m]>
instead of -r
<NightRaven[m]>
mps: sure i will try to change some stuff
<tpw_rules>
are there two people here with the same favorite distro? :)
<mps>
tpw_rules: :)
<kettenis>
and they make jokes about the BSDs...
<mps>
kettenis: I like BSD but don't use on workstations
<NightRaven[m]>
tpw_rules: lol i will take a look at it and try some stuff
os has quit [Read error: Connection reset by peer]
<tpw_rules>
if you like, you don't have to use that to install to the internal nvme. you can load the nixos installer to ram then reformat your usb flash drive
<NightRaven[m]>
Hmm yeah I might try nix os but never heard of it
<NightRaven[m]>
Btw mps I am not sure if it is the rootFS, Image.gz or .bin file but I am going to try something
<mps>
NightRaven[m]: from your image it is seen that kernel trying to run /sbin/init but can't to run it for unknown reason
<mps>
sorry, /etc/init
<mps>
it clearly says that it mounted sda as root fs
<NightRaven[m]>
Yea I think the linux.tar.gz corrupted it
<NightRaven[m]>
But wait
<mps>
no, it can't find init
<NightRaven[m]>
I FOUND THE ISSUE
<NightRaven[m]>
<mps> "NightRaven: best is to mount you..." <- it was your tar.gz when I did tar xf linux.tar.gz to my mount point