March 2019 - Adélie Development - Adelie Linux Mailing Lists

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

1
2
0 / 0

Location of reserved system user/group IDs?

by zlg

When trawling through the main repository I noticed there are spots where GID/UID is set manually when creating a user, using the `-g` flag to adduser. Do we have an up-to-date list of the reserved system user and group IDs? Those packaging server software need to be able to find this document easily so we don't run into UID conflicts. I searched the wiki and browsed the main site but could not find it. I recall we had some sort of document for this. -z -- https://zlg.space/ | gopher://zlg.space/1/ OpenPGP fpr: 8C5B 31C2 A9B0 B97C 22C7 96ED 593C 6C93 2F3F ABB7

2 years, 1 month

6
6
0 / 0

iproute2 and GNU Bison

by A. Wilcox

Hi there, I have just done an experimental build of system/ without GNU Bison available. The only package that uses Bison extensions to Yacc is iproute2. There are three ways forward I can determine: 1) Move iproute2 to user/. We still have `ifconfig` and `route` from net-tools in system/ for base installs. This allows us to continue to move GNU out of system/. 2) Port iproute2 to real Yacc. I am concerned that the upstream of iproute2 may not want this, though there has never been any public discussion that I've found on this topic. If they do not, then we would have to carry the patch for it. I will note that iproute2 only uses Yacc/Bison in one file, so it would not be a particularly large patch to carry, but it would still be a non-zero effort for every version bump of iproute2. 3) Leave Bison in system/ for now. This would seriously hamper Project De-GNU[1]. Best, --arw [1]: https://wiki.adelielinux.org/wiki/Project:De-GNU -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org

2 years, 2 months

3
2
0 / 0

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

1
1
0 / 0

Future of GNU coreutils and OpenRC

by zlg

Over the past few days, conversation in IRC has brought about talk of the s6 set of utilities becoming more strongly integrated with Adélie, with a hopeful end result of s6 powering init (once s6-linux-init is done), services (via s6-rc), and process supervision, among other things like tcp wrappers, etc. Talk of gutting GNU coreutils was also present. I'd like to ask: what does this mean for developers or users like myself who currently use GNU coreutils and OpenRC? What is Adélie's official long-term statement on the "main" software stack? (for lack of better phrasing) Thanks for your time and consideration. ~zlg -- https://zlg.space/ | gopher://zlg.space/1/ OpenPGP fpr: 8C5B 31C2 A9B0 B97C 22C7 96ED 593C 6C93 2F3F ABB7

2 years, 2 months

3
2
0 / 0

[4.14] powerpc: Always initialize input array when calling epapr_hypercall()

by A. Wilcox

Kernel 4.14 fails to build with GCC 8 on powerpc64, due to 'in' being uninitialised in epapr_hypercall*. This is fixed in commit 186b8f1587c79c2fa04bfa392fdf08 upstream, and this commit applies cleanly to the 4.14 tree. This commit is already on the 4.19 branch. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org

2 years, 2 months

2
1
0 / 0

2021

2020

2019

2018

Adélie Development March 2019