| 7 Jun 2024 |
 erahhal | ok | 16:56:46 |
 atemu12 | This smells like there should be even more log here | 16:57:37 |
| erahhal | I wonder if it's because it's not pulling down the right kernel branch | 16:57:40 |
| erahhal | What I was talking about above. It's currently using main | 16:57:57 |
| erahhal | which is not right | 16:57:59 |
| atemu12 | The avbtool might be a red herring | 16:58:01 |
| atemu12 | This is clearly concerning the kernel build | 16:58:52 |
| atemu12 | It's odd because I think it's only triggered from within the AOSP build? | 16:59:13 |
| erahhal | Here's the rest of that last line: | 16:59:16 |
| erahhal | robotnix-lineage_cheetah> avbtool add_hash_footer: error: argument --image: can't open 'out/soong/.intermediates/packages/modules/Virtualization/microdroid/microdroid_kernel_signed/android_arm64_armv8-2a_cortex-a55/4b56b5210baead69529bad02297ac604/microdroid_kernel': [Errno 13] Permission denied: 'out/soong/.intermediates/packages/modules/Virtualization/microdroid/microdroid_kernel_signed/android_arm64_armv8-2a_cortex-a55/4b56b5210baead69529bad02297ac604/microdroid_kernel' | 16:59:28 |
| erahhal | The kernel is pulled from AOSP for the pixel 7 pro | 17:00:02 |
| erahhal | It's just using the wrong branch at the moment | 17:00:14 |
| atemu12 | That looks like a different issue | 17:01:17 |
| atemu12 | You shouldn't be getting permission denied on the build dir | 17:01:31 |
| atemu12 | That smells like an issue we patch around where the build system copies the permissions of the src which in our case is in the nix store | 17:02:07 |
| erahhal | Ok, I could have messed up the patches | 17:02:29 |
| erahhal | it's one of the first things I did when I started this. I'll review those | 17:02:40 |
| erahhal | I'll get the right branch of the kernel while I'm at it | 17:03:03 |
| atemu12 | It could also simply be that there's now more places you need to patch | 17:03:21 |
| atemu12 | I had to do that for android 13 too | 17:03:26 |
| atemu12 | You need to dig into the makefile of that step to figure out what function it uses | 17:05:46 |
| atemu12 | Had an idea on that patch just now; we could perhaps try to fool the build system into thinking that the our bind-mounts are rw | 17:06:34 |
| atemu12 | Then we wouldn't need to patch it in all the places where it tries to copyu | 17:06:51 |
| atemu12 | * Then we wouldn't need to patch it in all the places where it tries to copy | 17:06:53 |
| erahhal | that sounds like it would be great if it could be made to work | 17:07:07 |
 jaen | Kind of out there, but maybe overlayfs could work (though not sure how reliable ZFS' support is)? | 17:13:09 |
| 8 Jun 2024 |
| atemu12 | I'm just not sure whether the nix store mounts are actually considered ro which is a necessary condition for overlayfs I think? | 08:44:50 |
| jaen |
The lower filesystem can be any filesystem supported by Linux and does not need to be writable.
Is what kernel docs say, so I guess it doesn't have to be r/o.
| 13:52:29 |
| jaen | *
The lower filesystem can be any filesystem supported by Linux and does not need to be writable.
Is what kernel docs say, so I guess it doesn't have to be r/o.
| 13:52:40 |
| jaen | *
The lower filesystem can be any filesystem supported by Linux and does not need to be writable.
Is what kernel docs say, so I guess it doesn't have to be r/o.
| 13:52:43 |
