search

WhitewaterFoundry / Fedora-Remix-for-WSL

Fedora Remix for Windows Subsystem for Linux.
Other
710 stars 51 forks source link

DNF fix #19

Closed ghost closed 5 years ago

ghost commented 5 years ago

There were issues regarding unmet dependencies, which are fixed by the replaced os-release file (see #18 for issue explanation).

Then there were issues with dnf unable to install anything down to being unable to make a transaction lock (even without the lock file existent and attempting numerous other fixes). This was occuring regardless of the os-release fix, so I'm not sure how this didn't appear until now. Removing the --releasever argument seems to fix it.

ghost commented 5 years ago

Don't merge yet! It passed the chroot test, but building for WLinux resulted in seg-faults. I'm going to pursue some further fixes

ghost commented 5 years ago

Okay I might have figured this out. The --forcearch is required for the first dnf --installroot, but after that it seems to cause issues. And it shouldn't be needed after this point anyway as the config files will be set by the first call to --installroot / mock.

The odd dependency issues I mentioned above (down to /etc/os-release) seem to be down to the generic-release package (which I do realise is required by terms of Fedora Remix). So we need to write our own custom os-release file. I've started to write one (can be found as part of this PR) but I'm sure it probably needs more changes.

ghost commented 5 years ago

And finally, the segmentation faults only occur with multiple calls to 'dnf --installroot'. Using it once for the main group install, then using chroot for further dnf commands fixes this issue. I have a feeling it might be down to --installroot not behaving as if just calling dnf within the rootfs, but instead either using some of it's own config files each time, or regenerating some files. The description here sounds like that might be the case: https://dnf.readthedocs.io/en/latest/command_ref.html

I've run a chroot test, and a WSLFedoraRemix test build and this seems to be working now. But before pushing from development --> master I'd like to do a lot more testing. Also, for the future, I'm not sure this method will work for arm64 based systems when building from x86_64, as attempting to chroot in and running the dnf binary will fail.

ghost commented 5 years ago

I've created a rootfs build with these fixes applied and all seems to work-out. But to ensure this isn't a single-usecase-fix type situation, especially given the severity of the bugs, someone else to rebuild WSLFedoraRemix and confirm this would be much appreciated :+1:. I'll post a link to the new rootfs development build in the Teams chat you can all use

sirredbeard commented 5 years ago

I will test this weekend.

ghost commented 5 years ago

Pushed one last small change (which I'll now need to do a rootfs rebuild for :stuck_out_tongue:), basically modifying the /etc/os-release file to be more WSLFedoraRemix specific, while also referencing that we're based on Fedora so as not to break any dependencies.

ghost commented 5 years ago

I ran another fresh build with it, installed some test packages and all seemed to be fine so going to merge with development for now. We can perform further testing in development before moving to master. @sirredbeard the main thing that needs checking is whether the /etc/os-release file changes I've made are alright :+1: