Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fedberry 31 #46

Open
bertusdebruin opened this issue Oct 3, 2019 · 11 comments

Comments

@bertusdebruin
Copy link

@bertusdebruin bertusdebruin commented Oct 3, 2019

Fedora 29, and so Fedberry 29 is end of life within weeks.
@agrez What is the plan with Fedberry 31?
Will there be a Fedberry 31 at all?

Final Release (GA) of next-but-one release plus four weeks.

@agrez

This comment has been minimized.

Copy link
Member

@agrez agrez commented Oct 5, 2019

Hi @bertusdebruin. Yeah, at this stage Fedberry 29 is likely the last release I will do for the foreseeable future. Fedora support for the RPi is quite reasonable now and there is not really a strong case for the continuing existence of Fedberry. I have also been working 2 jobs this year and therefore free time to work on Fedberry has drastically decreased.

I have actually been tinkering with an idea to re-base Fedberry to RHEL/Centos sources (Redberry or Centberry anyone?). This would align better for me and my current work requirements. Fedora (and hence Fedberry) development moves too quickly and support is too limited to be very useful in commercial situations.

@knight-of-ni

This comment has been minimized.

Copy link

@knight-of-ni knight-of-ni commented Oct 5, 2019

@agrez I had been meaning to ask the same question so thanks for letting us know.

If I wanted to attempt a Fedberry 29 -> Fedora 30 migration, the first thing that comes to mind would be to:

  • delete fedberry.repo files
  • remove any excludes from fedora.repo files
  • then perform dnf system-upgrade

I'm sure this isn't fool proof, but I'll likely give it a shot unless you know for certain this will blow up in my face.

The opportunity to pursue Raspberry Pi packages over at RPMFusion still exists. Doing your work over there would be a good way to spread the work load around to others, like me, for example.

@bertusdebruin

This comment has been minimized.

Copy link
Author

@bertusdebruin bertusdebruin commented Oct 6, 2019

@agrez Thanks for your reply.
Redberry or Centberry would be great.
As the new CentOS 8 ARM won't have RPI specific kernels.
This could be a gap in the market.

The next version won't have (at least initially) rpi
specific kernels so testing what you need in a generic image from 7.7
will be a good (if not exact) approximation.

I agree with you that 'Fedora support for the RPi is quite reasonable now' except for the kernel.
The Fedora generic ARM kernel is rather cumbersome and slow.
In addition, not fully supported for RPI.

For example the RPI hardware lights won't work.
Wifi does not work out of the box. (Don't know if this has been resolved.)

My idea, suggestion would be make an extra packages (EPEL kind of) repo.
With only RPI rebased kernels for EL8 and Fedora.
The only thing I use from Fedberry is the kernel.

If I have to compile it myself, it takes days. (tested)
Unfortunately I don't have more powerful ARM hardware.

Keep me informed about your plans.

@agrez

This comment has been minimized.

Copy link
Member

@agrez agrez commented Oct 7, 2019

If I wanted to attempt a Fedberry 29 -> Fedora 30 migration, the first thing that comes to mind would be to:

  • delete fedberry.repo files
  • remove any excludes from fedora.repo files
  • then perform dnf system-upgrade

I'm sure this isn't fool proof, but I'll likely give it a shot unless you know for certain this will blow up in my face.

Hmmm, it would an interesting experiment. 🤔. We might have to tinker a little and see if we can't give existing users an migration path back to Fedora. I think another main issue is that booting Fedora, as compared to Fedberry, is done very differently. Last time I looked they are were using uboot and an initramfs (along with a separate boot partition). I never felt comfortable following suit as it just slows down the whole boot process on an already under-powered device. In addition, especially in the early days, this type of boot process was fragile and just broke too often for my liking.

The opportunity to pursue Raspberry Pi packages over at RPMFusion still exists. Doing your work over there would be a good way to spread the work load around to others, like me, for example.

Yes, thank you for the reminder/invitation, its appreciated. I would have really liked to be involved with rpmfusion this year, but lifeTM just seemed to get in the way. If my schedule improves, I will try to become an active member of rpmfusion.

@agrez

This comment has been minimized.

Copy link
Member

@agrez agrez commented Oct 7, 2019

@agrez Thanks for your reply.
Redberry or Centberry would be great.
As the new CentOS 8 ARM won't have RPI specific kernels.
This could be a gap in the market.

The next version won't have (at least initially) rpi
specific kernels so testing what you need in a generic image from 7.7
will be a good (if not exact) approximation.

Thanks for letting me know, I wasn't actually aware of this. I'm a little surprised that this is the case.

My idea, suggestion would be make an extra packages (EPEL kind of) repo.
With only RPI rebased kernels for EL8 and Fedora.
The only thing I use from Fedberry is the kernel.

Yes, I was more or less thinking along the same lines. Just got to wait it out while Centos finishes up with their altarch builds. With the RPi4, I am also interested in finally doing some aarch64 kernel builds, which should hopefully actually prove useful with 4GB of RAM.

Keep me informed about your plans.

Will do 😃

@Gormartsen

This comment has been minimized.

Copy link
Member

@Gormartsen Gormartsen commented Oct 9, 2019

@agrez no matter what, you have my support!

@agrez

This comment has been minimized.

Copy link
Member

@agrez agrez commented Oct 11, 2019

Thanks Gor! 😄

@speachy

This comment has been minimized.

Copy link

@speachy speachy commented Oct 21, 2019

Does the stock Fedora kernel/boot process now handle DTS overlays, or at least provide some sort of equivalent mechanism?

(Longtime Fedberry user, btw. And I greatly appreciate all the work you've put into it over the years..)

@mavit

This comment has been minimized.

Copy link

@mavit mavit commented Nov 2, 2019

FWIW, I've tried the following to get a mixture of Fedora 31 and Fedberry 29:

sudo sh -c 'echo 31 > /etc/dnf/vars/releasever'
sudo perl -pi~ -E 's/\$releasever\b/29/g' /etc/yum.repos.d/fedberry*.repo
sudo yum update

Lots of packages were skipped, but it doesn't appear to have been an obvious disaster.

@knight-of-ni

This comment has been minimized.

Copy link

@knight-of-ni knight-of-ni commented Nov 2, 2019

I tried the following last week on a spare pi:

  • sudo dnf upgrade --refresh
  • disable fedberry repos
  • remove all excludes from fedora repo files
  • sudo dnf system-upgrade download --refresh --releasever=30 --allowerasing

This "works" but after closer inspection the fedberry fc29 kernel is still there and is the only kernel the system will boot off of. This no doubt is due to differences in how the boot process is handled.

What I plan to do next is image the root partition off my former fedberry pi, and then use that to overwrite the root partition of a standard fedora 30 system. As long as this is done after the system-upgrade is performed on the fedberry system, there is a reasonable chance this will work. The fedora uboot should look for the fc30 kernel, which should be there.

Note that it appears Fedora hasn't changed their policy of allowing the wifi driver to load on boot. So at some point during the migration, you will lose your wifi. I seem to recall a page on the Fedora site somewhere that talks about how to enable it.

@bertusdebruin

This comment has been minimized.

Copy link
Author

@bertusdebruin bertusdebruin commented Nov 5, 2019

@agrez As Fedora 31 is released.
Maybe it is a good idea to create a Fedora 31 image with just an RPI kernel and the Fedberry kind of system boot. To save time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.