search

stevleibelt / arch-linux-live-cd-iso-with-zfs

archiso with zfs embedded
GNU General Public License v3.0
57 stars 15 forks source link

Update build.sh #6

Closed derzahla closed 2 years ago

derzahla commented 2 years ago

Best workaround I could think of. Since mkarchiso takes over options are limited and you cant have two repo's named the same. Another option is to add this only if mkarchiso fails on version dependency, then rerun

stevleibelt commented 2 years ago

Thanks for the pull request @derzahla

Do I get your intention right? You want to prevent that a building fails by dating back the repository for one week?

Would this workaround just move the build error one week in the future? Because when the building is possible by the current repository, the "one week dated back" repository would have the state that a build is not possible?

derzahla commented 2 years ago

Correct, archzfs always seems to be behind so their zfs module does not match the upstream kernel and fails installation. As far as if it would cause a failure in the situation where archzfs's kmod was for a newer version than last week's current Arch kernel...i dont know. I did not remove the current arch repo for the pacman.conf, I just added the archive repo in front of it. So it might still check the current repo if it doesnt find a match. But if not, I think that situation wouldbe much less likely to occur and cause a failure. Unfortuantly there isnt much flexibility for creating a better fix without modifying mkarchiso itself, it seems.

stevleibelt commented 2 years ago

Hello @derzahla thank you very much for answering my questions and extending your explenation.

I think I got the idea now good enough and I like it. But I need to have some time testing it out before merging your change. So I have to ask you for patience.

stevleibelt commented 2 years ago

@derzahla, I found a solution for this problem. Since the release of 2.3.0, the build.sh is able to handle flags.

So my simple solution is to merge your change and only enable this setting a flag. I will try to investigate what flag would be the best and if we maybe want to provide an optional argument to set the amounts of weeks we want to go back.

Working drafts are the flags -l|--last-week or -w|--weel-older. Any suggestion?

derzahla commented 2 years ago

@stevleibelt it's been awhile since I looked at the code but you can do that if you like. Sounds like you don't encounter the version mismatch errors frequently? I've only tried to build the iso a handful of times in the last couple months but would almost always fail for that reason.

So based on my observed results I would just keep the archive repo as the default. Have you encountered any failures that way?

If I was also seeing frequent failure using the 1-week-old archive core repo, and switching back to current resolved it - I would write a function to parse the kernel versions from each repo and choose the one that matches archzfs.

stevleibelt commented 2 years ago

@derzahla You are right, I don't see that errors often. Just give me a few days and I am done with the changes. I am thinking of a configuration file so you could just configure the flag used by default and that is it :-).

stevleibelt commented 2 years ago

I've released version 2.5.0 with your changes @derzahla

You can now just call build.sh -r to get your desired effect.

Right now (20220418T21:46:11), calling build.sh -r, we get the following error message.

warning: cannot resolve "libicuuc.so=71-64", a dependency of "brltty"
:: The following package cannot be upgraded due to unresolvable dependencies:
      brltty

I will try to investigate that within this week. Maybe we have to adapt the others repositories too, when modifying [core]. Do you have any experience with it? Would you be so kind and have a look on my implementation?

Oh and "by the way", build.sh now supports an optional configuration/build.sh configuration where you can define you preferred way of calling build.sh.

stevleibelt commented 2 years ago

Reopened this pr to give @derzahla the chance to comment in here.

derzahla commented 2 years ago

Thanks Steve. You're right, what you are seeing is a possible problem that can occur while only setting the core repo back 1 week. It worked at the time for me and was a quick and dirty hack that got the image to build. I thought I would share incase you or others were having the same problem but you dont have to merge it if you dont hit the same problem. Setting all repos (core/exta/community) to the the 1 week old archive should stop this partitcular problem from happening.

If I had more time, a more complete solution would be to use the default repos, pull the version of zfs-linux and compare it to the version of linux that is available. Then only set the repos back 1 week if there is a mismatch.

stevleibelt commented 2 years ago

@derzahla, I will close this pr. Thanks for your response, I've created a milestone and an issue ticket to solve the newly created issue.

Feel free to join :-).