Adelie on QEMU PPC
by BALATON Zoltan
Hello,
I'm not subscribed here (hope this still gets through), please cc me on
any reply. I'm also not sure this is the right place to send this but I
guess you may be more interested than the general QEMU crowd and could
help more with debugging the Adelie Linux side so I'm sending it here.
I'm trying to run adelie-live-ppc-1.0-beta2-20181218.iso on QEMU (mainly
to have something that's known to work on real hardware to test with).
Actually I eventually could boot it and it seems to work but I've found
some strange problems during this that I'm not sure if bug in QEMU or
guest code and how to debug it. Hope you have some idea. Here are the
details. I'm using this command with QEMU from git master as of today:
qemu-system-ppc -M mac99,via=pmu -m 1024 -boot d \
-cdrom adelie-live-ppc-1.0-beta2-20181218.iso \
-d unimp,guest_errors -serial stdio
on an x86_64 host. (This approximately emulates a PowerMac3,1 but not
exactly. I've also enabled some debug to get more details on what's
happening: #define DEBUG_EXCEPTIONS in target/ppc/excp_helper.c)
I get the grub boot menu after some errors in OF console (not sure what
are these and if could be related to the problem) then pressing enter
starts to load kernel but ends in an unexpected exception around loading
initrd that jumps off to a non-existent handler so I think this should not
happen. This is what I could find out about this:
DSI exception: DSISR=42000000 DAR=02e8d000
DSI exception: DSISR=42000000 DAR=02e8e000
^ These are last lines of loading /bzImage I think
ISI exception: msr=00003030, nip=0480afc0
ISI exception: msr=00003030, nip=0480c294
DSI exception: DSISR=40000000 DAR=04861650
^ Some grub code running?
DSI exception: DSISR=40000000 DAR=3fc5b1f4
DSI exception: DSISR=42000000 DAR=3fcc05fc
DSI exception: DSISR=40000000 DAR=3fcbed2c
DSI exception: DSISR=40000000 DAR=3fcbc974
DSI exception: DSISR=40000000 DAR=3fcba84c
DSI exception: DSISR=40000000 DAR=3fcb8f94
DSI exception: DSISR=40000000 DAR=3fcb7c78
DSI exception: DSISR=40000000 DAR=3fcb6be4
DSI exception: DSISR=40000000 DAR=3fcb5b64
DSI exception: DSISR=40000000 DAR=3fcb3a50
DSI exception: DSISR=40000000 DAR=3fcb2ffc
DSI exception: DSISR=40000000 DAR=3fca8890
DSI exception: DSISR=40000000 DAR=3fc9bffc
DSI exception: DSISR=40000000 DAR=3fcacc1c
DSI exception: DSISR=40000000 DAR=3fc5dfe0
^ Not sure what are these
ISI exception: msr=00003030, nip=048a903c
ISI exception: msr=00003030, nip=048b8fe4
ISI exception: msr=00003030, nip=048ada7c
^ More grub code
DSI exception: DSISR=42000000 DAR=00002000
ISI exception: msr=00003030, nip=048abfa4
invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00002428 0
Invalid instruction at 00002428
and ends with the exception that should not happen and hangs here. The
interesting part is that this seems to depend on what's in the memory or
layout or positions so it may be a problem in guest code (like using an
unitialised pointer which may work if it luckily points to some data that
does not cause big harm but fails otherwise) or could also be problem in
QEMU or OpenBIOS if it does not provide something that grub expects and
this causes problem (or anything else really as I'm only guessing here).
What I've found is that when I press 'c' at the boot menu to get to grub>
prompt and then manually do:
linux /bzImage
initrd /initrd
then I get exception slightly differently, such as:
DSI exception: DSISR=42000000 DAR=02e8d000
DSI exception: DSISR=42000000 DAR=02e8e000
DSI exception: DSISR=40000000 DAR=3fde7cdc
DSI exception: DSISR=40000000 DAR=04861650
DSI exception: DSISR=42000000 DAR=3fcbaaec
DSI exception: DSISR=40000000 DAR=3fcbb2f8
DSI exception: DSISR=40000000 DAR=3fcb3a50
DSI exception: DSISR=40000000 DAR=3fcad7f8
DSI exception: DSISR=40000000 DAR=3fcae01c
DSI exception: DSISR=40000000 DAR=3fcacc1c
ISI exception: msr=00003030, nip=048a903c
ISI exception: msr=00003030, nip=048b8fe4
DSI exception: DSISR=40000000 DAR=048b0b28
ISI exception: msr=00003030, nip=048a78d8
ISI exception: msr=00003030, nip=048971e4
ISI exception: msr=00003030, nip=048981b8
DSI exception: DSISR=40000000 DAR=048afc90
ISI exception: msr=00003030, nip=048a1750
DSI exception: DSISR=40000000 DAR=8115d380
ISI exception: msr=00003030, nip=0489fc74
DSI exception: DSISR=40000000 DAR=04830520
ISI exception: msr=00003030, nip=04837e88
DSI exception: DSISR=40000000 DAR=81165080
ISI exception: msr=00003030, nip=048ada7c
DSI exception: DSISR=42000000 DAR=00002000
DSI exception: DSISR=42000000 DAR=00003000
invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000238c 0
Invalid instruction at 0000238c
So there seems to be something non-deterministic in this. I guess my first
question would be what does grub do here at nip=048ada7c? Is there a way
to guess this from the above (it's somewhere around loading initrd) or can
you make an iso with unstripped grub and if that reproduces the problem
then maybe we can get something from grub source? Where are the sources of
grub that's on the iso?
Then I've tried with my pathched OpenBIOS from here (at Known problems 1.):
http://zero.eik.bme.hu/~balaton/qemu/amiga/#morphos
which fixes a device tree problem I know about. Add
'-bios openbios-qemu.elf' to qemu command above to use it.
With that it does not get the above problem and starts to boot but seems
to get a panic (based on where it hangs) but I could not make it print
this on serial or anywhere to get more info. Do you know what options
could make the kernel log to serial during boot? I've tried earlyprintk
console=ttyPZ0 console=ttyS0 and similar but could not get output with any
of these.
But during experimenting with this sometimes I managed to boot it. Finally
I've found that if I do exactly this:
1. Use -bios openbios-qemu.elf
2. press c at boot menu to get grub> prompt
3. Type these (issue 'set' 2 times!)
grub> ls
grub> set
grub> set
grub> linux /bzImage
grub> initrd /initrd
grub> boot
then it boots. Strange! So I wonder if you have an idea how this could be
debugged and identify if it's a QEMU, OpenBIOS or guest code problem. I
think most likely could be something is missing from OpenBIOS which then
leads to using uninitialised data but without getting some debug output
from the kernel panic at least or finding out where the crash in grub is
happening I have no idea how to find what could cause this.
Thank you,
BALATON Zoltan
1 year, 10 months
Upcoming changes to 1.0-BETA3 and packager notes
by A. Wilcox
Hi all,
We will be conducting a test build of all packages using gcc8 on all
builders, beginning this morning UTC (approximately four hours after
this email is sent).
This mass-rebuild may take up to four days. During this time, no
changes will be possible. Package bumps, security fixes, and new
packages will not be merged.
If no issues are identified with GCC 8, we will move ahead with moving
our system toolchain to GCC 8. This will allow us to ship 1.0 with full
C++17 support, in addition to opening up the possibility of a future
RISC-V port.
Regards,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 2 months
"What happened to the weekly status reports?" and other questions answered
by A. Wilcox
Hello all,
The past few weeks have been very trying on the Adélie Linux project.
You may have noticed that the weekly status reports stopped with the
week ending 2019-01-20.
Usually, I'm able to send the weekly status report emails on Monday or
Tuesday of the following week. Both of those days were spent attempting
to secure more funding so that the project could continue.
Wednesday, 30th January 2019, at approximately 16:40 Central Standard
Time, the dedicated server that powers the following Adélie Linux (and
other) infrastructure was disconnected from the Internet:
- code.foxkit.us (GitLab)
- enfys.foxkit.us (PostgreSQL database serving GitLab and IMAP/SMTP)
- IRC bouncer used by awilfox, Elizafox, rwg (IRC operator), and others
- other systems including our backup Bugzilla server
During the week of January 14th, the Systems Administration team,
consisting of Aerdan, djt, and myself, had migrated the contents of a
dedicated server hosted at Rack911 containing mirrormaster and rarity
(the mailing list system) to other systems. We were told in early
January that this dedicated server was being powered off at the end of
the month. We were then notified at 18:21 CST on the 30th of January
that the information we were provided was incorrect, and that the other
dedicated server that was hosted there was also being powered off.
We had less than 36 hours to move over a terabyte of information to
other systems. Some of this infrastructure is still not available
(notably, my IRC bouncer, which allowed me to communicate with many of
our upstreams, is still down and needs to be reinstalled). From all of
us, I would like to extend an extreme debt of gratitude to Zach van Rijn
(Thalheim on IRC, who hosts us2-distfiles) for managing to bring up an
image I took of our GitLab server on the same infrastructure as us2.
This allowed us to recover much quicker.
Since GitLab requires Node.js, Go, and a few other packages that we had
not yet stabilised, we were unable to reinstall GitLab on our new
dedicated system at Integricloud. This most likely will not be able to
take place until after the 1.0 release cycle is completed.
Immediately after this emergency migration, my office had an insect
issue that required me to abandon it for six days. This also required
me to leave my laptops behind. I was only able to use my mobile phone
during this time, and as such, was unable to do much of the work of
managing the Adélie Linux project.
Since then, our team has been working tirelessly to try and regain our
momentum and continue to release 1.0-BETA3 at the time that we promised.
At this time, it appears that although we had no ability to work on
Adélie Linux from the 30th of January until the 6th of February, we had
managed to complete things sooner than anticipated. This means that we
are only currently four days behind schedule, with an anticipated
release date of 18th April at our current pace.
Thanks to Bobby Bingham (koorogi on IRC)'s efforts of rewriting
libucontext, we now have a functional Go on 64-bit PowerPC. More on
this and other developments will be included in the next weekly status
report, which I will write this evening. It will be primarily focused
on the week of 18th through 24th February, but it will also include
information about what happened before the 18th of February.
Rest assured that even through adversity, we remain dedicated to
creating the best libre operating environment possible.
Thank you for your continued support. We could not exist without our
amazing community.
All of my best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 2 months
[adelie-devel]The future of BusyBox in Adélie
by A. Wilcox
Hi all,
Now that we are tightening up all our loose ends and trying to make this
a really solid 1.0 release, I was wondering what we want to do with
BusyBox. This is by far the worst package we ship in the entire distro:
packages$ find . -name '*.patch' | cut -d'/' -f3 | sort | uniq -c
[ ... ]
12 binutils
12 openssl
17 firefox-esr
17 qemu
33 busybox
The way I see it, there are a few options for it:
== Move to user/ ==
There is no reason for it to be in system/; it is not used by any system
dependency, nor is it essential to build or run the Adélie Core system.
Things would basically stay the same. We would continue to be at the
mercy of Alpine's patching, unless someone here really wants to take on
the worst package in packages.git. However, seeing as nobody should be
using it, I don't know that such a thing would be bad.
== Remove ==
Considering the brokenness[1][2][3] of BusyBox, we could remove it from
the repositories entirely. We may be able to compile a static coreutils
for recovery.
== Replace with Toybox ==
Since BusyBox is only packaged for static tools for recovery, we could
replace it with Toybox. While it is missing some functionality, it is
much closer to the standards and what a reasonable user would expect
from a recovery environment.
I'd like to resolve this before BETA2 if possible. Let's discuss!
Best,
--arw
[1]: https://www.mail-archive.com/busybox@busybox.net/msg25157.html
[2]: https://bugs.alpinelinux.org/issues/9279
[3]: https://da.gd/buggybox
--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 2 months