Future of BIOS RAID support in the installer
by Vojtech Trefny
Hi, I am planning to change how we support BIOS RAID (sometimes also
called Firmware or Fake RAID) in the installer in the future. I plan
to go through the official Fedora change process for Fedora 38, but
I'd like to get some feedback first.
We are currently using dmraid to support these types of RAIDs in
blivet[1] (storage library the Anaconda installer uses) and we would
like to replace it with mdadm. The main reason is that dmraid is no
longer actively maintained, but it will also mean one less dependency
for the installer (we use mdadm for the software RAID support) and one
less service running during boot (dmraid-activation.service).
The potential issue here is that mdadm doesn't support all BIOS RAID
types. mdadm supports only Common RAID Disk Data Format standard[2]
(DDF) and Intel Matrix Storage Technology (IMSM) so by switching to
mdadm we would remove support for some of the older formats that
existed before DDF was standardized. I am not sure how many people are
still using these older RAIDs and the main reason for sending this
email is to find out. So if you are using a BIOS RAID on your system,
can you check what kind? You can find out simply by checking the
filesystem type on the underlying disk(s) reported by for example
`lsblk -f`. Types supported by mdadm are "ddf_raid_member" and
"isw_raid_member". Types supported only by dmraid are
"adaptec_raid_member", "hpt***_raid_member", "jmicron_raid_member",
"lsi_mega_raid_member", "nvidia_raid_member",
"silicon_medley_raid_member" and "via_raid_member". So if you have one
of the latter ones and you'd be impacted by this change, please let me
know so we can reconsider this change. Note that this would affect
only the installation process, I know some external and NAS drives use
BIOS RAID and these won't be affected, dmraid is not being removed
from the repositories (at least I am not aware of this right now, some
distributions are already planning to remove dmraid completely).
[1] https://github.com/storaged-project/blivet
[2] https://www.snia.org/tech_activities/standards/curr_standards/ddf
Regards
Vojtech Trefny
vtrefny(a)redhat.com
10 months, 1 week
RISC-V -- are we ready for more, and what do we need to do it?
by Matthew Miller
Hi all! I just got back from Open Source Summit, several of the talks I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
* see http://fedora.riscv.rocks/koji/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10 months, 2 weeks
Self Introduction: Andreas Vögele
by Andreas Vögele
Hello Fedora developers,
I'm Andreas from Stuttgart in Germany. I'm a system administrator and
software developer, who moved his computers to Fedora about a year ago.
I've written a handful of Perl modules that I package at the Open Build
Service and Copr. I'd like to maintain some of these modules directly in
Fedora. In the past, I maintained ports of other software at
SlackBuilds.org and OpenBSD. Occasionally, I contribute patches to free
software projects. I enjoy programming in C, Perl and recently Kotlin.
Kind regards,
Andreas
10 months, 3 weeks
memtest86plus v6.00
by Richard W.M. Jones
Earlier discussion:
https://www.mail-archive.com/devel@lists.fedoraproject.org/msg169800.html
Current memtest86+ 5.x requires non-UEFI, which makes it increasingly
irrelevant to modern hardware. memtest86 forked into a proprietary
product some time ago. However there is hope because upstream
memtest86+ 6.00 is (a) open source and (b) seems to work despite the
large warnings on the website:
https://memtest.org/
Note this new version is derived from pcmemtest mentioned in the
thread above which is only indirectly derived from memtest86+ 5.x and
removes some features.
So my question is are we planning to move to v6.00 in future?
I did attempt to build a Fedora RPM, but it basically involves
removing large sections of the existing RPM (eg. the downstream script
we add seems unnecessary now and the downstream README would need to
be completely rewritten). It's probably only necessary to have
memtest.efi be installed as /boot/memtest.efi and although it won't
appear automatically in the grub menu, it can be accessed by a trivial
two line command.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
11 months, 2 weeks
Conflicting build-ids in nekovm and haxe
by Andy Li
Hi list,
Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901
Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c".
The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib".
Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode).
I'm not sure how to resolve it.
Please advice.
Best regards,
Andy
11 months, 3 weeks
can't install package pipewire-jack-audio-connection-kit
by Martin Gansser
Hi,
when trying to install pipewire-jack-audio-connection-kit i get this error message:
# dnf -y install pipewire-jack-audio-connection-kit
Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020.
Error:
Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- conflicting requests
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
How can i fix this ?
Regards
Martin
1 year, 1 month
Planning to start unifying native and mingw packages
by Sandro Mani
Hi
Following recent discussions and to reduce the maintenance burden, I'm
planning to start merging native and mingw packages. Initially, I'll be
looking at these packages where I maintain both variants:
eigen3 mingw-eigen3
enchant2 mingw-enchant2
freeimage mingw-freeimage
gdal mingw-gdal
GeographicLib mingw-GeographicLib
geos mingw-geos
giflib mingw-giflib
gtkspell3 mingw-gtkspell3
gtkspellmm30 mingw-gtkspellmm30
jxrlib mingw-jxrlib
leptonica mingw-leptonica
libgeotiff mingw-libgeotiff
libimagequant mingw-libimagequant
libkml mingw-libkml
librttopo mingw-librttopo
libspatialite mingw-libspatialite
libwebp mingw-libwebp
openjpeg2 mingw-openjpeg2
OpenSceneGraph mingw-OpenSceneGraph
osgearth mingw-osgearth
podofo mingw-podofo
proj mingw-proj
python-pillow mingw-python-pillow
qtspell mingw-qtspell
shapelib mingw-shapelib
svg2svgt mingw-svg2svgt
tesseract mingw-tesseract
uriparser mingw-uriparser
I'm performing test builds here [1]. Once I've got them all building
there, if there are no objections, I plan to push to F37 and retire all
the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
1 year, 1 month
