| 7 Jun 2024 |
 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 |
| jaen | But either way it doesn't seem to help, when I modify the unpack script to use overlayfs, the files remain unwritable. I even tried to use something called bindfs (apparently it's a FUSE bind mount) to map user/permission before mounting so the file permissions "look" like they are writable hoping that would be enough (since writes will go to the upper layer anyway), but that didn't seem to help. I didn't use overlayfs much previously (so I might be doing something wrong), but at least the obvious things don't seem to work, so maybe it was a bad idea after all. | 13:52:45 |
| atemu12 | The way you'd do it is to overlay and then chmod | 19:26:41 |
