Fun with GRUB2, BLS and Multiboot USB
by Philip Rhoades
People,
LILO and SysLinux were simple and GRUB1 was straightforward - but by the
time GRUB2 came around I was long past configuring my own kernels and
hacking around at a lower level . . now I think, finally, I need to know
more about how GRUB2 - works specifically with Fedoras 38+.
This current interest was prompted when I upgraded my WS from F37
KDE(->Sway) via a beta F38 LiveSway and found that /boot/grub2/grub.cfg
did not contain a menuentry for the latest F38!? - much hacking and
experimenting followed . .
Now I have a WS with two USB sticks (8G and 32G) and have booted the
latest F38 Live Sway (on the 8G) and successfully installed it to the
32G and now my mild OCD is less offended when I boot on the 32G USB I
see ALL the old Fedora systems on drives /dev/sd[a-d] ! - I am happy!
So, I have git cloned the grub2 stuff and had a look at it but I am too
old now to be digging around in that stuff just at the moment - so, has
any Fedora Guru produced a diagram or at least a point list, of what
Grub does from turning on the power to the display of the Grub menu on a
Fedora machine? - that would be nice as a more-detailed overview than I
have been able to find so far - but not so low-down I am amongst the
weeds . . that might come later . .
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
1 year
colm update breaking ragel
by Michel Alexandre Salim
Hi,
I noticed when rebuilding mcrouter that it failed because ragel is not
installable, because colm was updated:
DEBUG util.py:443: Error:
DEBUG util.py:443: Problem: conflicting requests
DEBUG util.py:443: - nothing provides libcolm-0.13.0.7.so()(64bit) needed by ragel-7.0.0.12-9.fc38.x86_64
Looks like the latest version of ragel (7.0.4) expects the new colm
version, so I'll build it and resolve the breakage - only for Rawhide (both colm and ragel
are maintained by the same upstream).
CC:ing the colm and ragel maintainers so they can coordinate any update
for other branches.
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
1 year
DNF Sytem Upgrade requirements for an F37 → F38 upgrade
by Alexander Ploumistos
Hello,
TL;DR:
DNF memory usage during upgrades from F37 to F38 on a couple of Fedora
Cloud images (with 2 GB of RAM each) led to oomd kicking in and
killing the upgrade process. It might be worth looking into before the
final (also beta?) release.
The longer story:
I have a couple of hosted VMs, which started their lives as Fedora
Cloud 27 and which I have been upgrading to the next Fedora release
via dnf-plugin-system-upgrade. These VMs run very few things, mainly
some PHP applications on Apache and a good chunk of the PHP stack,
some scheduled network scripts, a private rpm repository, OpenVPN and
Wireguard nodes and when I am far from my main computer and koji or
copr happen to be busy, I test things in mock on them. These VMs are
near clones of each other, so usually only one of them is up at any
moment.
I've never had an issue with memory use up to now and when the systems
aren't building packages, they seldom require more than 200 MB of RAM.
What's more, there's the default swap-on-zram, so they should be more
than happy memory-wise with 2 GB of RAM.
I tried to upgrade one VM to F38, to see what problems I might face
and after the packages had been downloaded, I lost the ssh connection
as DNF was running the transaction test, right after a successful
transaction check. I repeated the whole thing a couple more times,
until I remembered that oomd is there and sure enough, DNF had been
consuming 1-1.3 GB until oomd decided to kill it. Well, actually it
killed my entire session and not just DNF. I tried running the upgrade
inside a screen (the GNU one) session and I came back to an empty
session. The transaction involved the upgrade of 1620 packages, with
a total size of 1.2 GB. I think the difference between that and the
previous upgrade F36 to F37) is around 100 MB and 30 or 40 packages.
In each of the failed attempts, the memory pressure was 55 to 78% for
more than 20 seconds, according to systemd-oomd. The exact same issues
appeared when upgrading the second VM.
Eventually I did the upgrade by doubling the available RAM to 4 GB
(and then set it back to 2), but perhaps this could be a problem for
others, especially those who pay for cloud-based resources. Is DNF
supposed to be a legitimate target for systemd-oomd? Conversely, is
DNF supposed to use up so much memory?
1 year
mingw sysroot paths (and generalizing them)
by Florian Weimer
Looking at
Information for RPM mingw64-zlib-1.2.13-2.fc38.noarch.rpm
<https://koji.fedoraproject.org/koji/rpminfo?rpmID=33118048>
sysroot paths look like this:
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll
/usr/x86_64-w64-mingw32/sys-root/mingw/include/zconf.h
/usr/x86_64-w64-mingw32/sys-root/mingw/include/zlib.h
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.dll.a
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc
Is the /mingw/ part of the sysroot path, or is it within the sysroot?
Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or
--sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the
sysroot?
I assumed the latter, but now I wonder if /mingw in the sysroot is the
analogue of /usr in GNU/Linux sysroots.
Eventually, we want to produce some GNU/Linux sysroots. I picked
/usr/%{_arch}-redhat-linux/sys-root/fc%{fedora}
or (depending on the operating system)
/usr/%{_arch}-redhat-linux/sys-root/el%{rhel}
or (as the fallback)
/usr/%{_arch}-redhat-linux/sys-root/root
and we have /usr inside the sysroot, e.g. <stdio.h> is
/usr/x86_64-redhat-linux/sys-root/fc35/usr/include/stdio.h
in a Fedora 35 sysroot on x86-64 (although the Fedora 35 update with
this never actually went out). We essentially use the /mingw/ part as
an OS ABI version indicator, to make the different versions
co-installable.
I want to pick this up again and would like to solicit comments if that
OS ABI variant thing is the right approach, or if we should drop it.
Sysroot packages are by nature relocatable, and do not have to be
installed in /, so it's perhaps not a great loss if their version
variants are not co-installable.
We need something like this before we can drop i686 on ELN; it's only
way to enable -m32 in GCC in a sustainable fashion. But we don't need
OS ABI variants for that.
Thanks,
Florian
1 year
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
1 year
Looking for new xfig package-maintainer
by Hans de Goede
Hi All,
I have been keeping the Fedora xfig package alive all these years
because I know that there are still users using xfig and xfig
actually still has an active upstream.
Lately I have not been able to spend any time on this, as can
be seen from the currently open / unfixed CVE against xfig:
https://bugz.fedoraproject.org/xfig
Upstream has a patch available fixing this, so fixing this
is easy. I just have not been able to make the time for this.
As such I think the time has come to ask for help for
maintaining xfig. If you can help by taking over or
co-maintaining xfig, please let me know.
Regards,
Hans
1 year
Koji: Could the initial side tag repo be copied from parent (to avoid
worflow delays)?
by Miro Hrončok
Hello,
When using custom side tags like this:
$ fedpkg request-side-tag
$ fedpkg chain-build --target f38-build-side-... ...
One of the obstacles is that the initial waitrepo for the job takes a lot of
time, (e.g. 10+ minutes). That is not comfortable for the package maintainer --
it's faster to use buildroot overrides.
I wonder if the initial createrepo could be skipped entirely by symlinking /
copying / using the already available repository from the base (parent) tag.
That could make this workflow more attractive.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year
nodejs broken?
by Iñaki Ucar
Hi,
RStudio (which depends on nodejs-devel) is FTBFS since the latest
nodejs update. I see this in F37 and F38:
Error: Transaction test error:
file /usr/lib64/libv8.so.10 conflicts between attempted installs of
nodejs-libs-1:18.14.2-5.fc37.x86_64 and
nodejs20-libs-1:19.7.0-13.fc37.x86_64
file /usr/lib64/libv8_libbase.so.10 conflicts between attempted
installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and
nodejs20-libs-1:19.7.0-13.fc37.x86_64
file /usr/lib64/libv8_libplatform.so.10 conflicts between attempted
installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and
nodejs20-libs-1:19.7.0-13.fc37.x86_64
Best,
--
Iñaki Úcar
1 year
