Re: Updated installer images 2020-12-02
Hello! On 12/25/20 6:31 PM, Riccardo Mottola wrote: > I have read the threads with Dennis, but found no solution, conclusion about > it. Can > you point me to these threads? To see where is the issue and whether there is > a rescue > solution: I want to get this iMac working for these Holidays. There is no solution yet other than using an older image which has glibc_2.30 such as the image from May [1] which is supposed to work. > I have read previous threads about hfsutils, but thought they were fixed, as > per your > mail with Frank Scheiner. I cannot make any further tests to the grub-installer code at the moment since we need to fix the partman issue first. > Is there a known-good working snapshot for ppc64 macs? Yes, 2020-05-30 should work [1]. > And... Frohe Weihnachten! Same to you. Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2020-05-30/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installer images 2020-12-02
Hi Adrian On 12/27/20 11:19 AM, John Paul Adrian Glaubitz wrote: I have read previous threads about hfsutils, but thought they were fixed, as per your mail with Frank Scheiner. I cannot make any further tests to the grub-installer code at the moment since we need to fix the partman issue first. Is there a known-good working snapshot for ppc64 macs? Yes, 2020-05-30 should work [1]. Unfortunately, it does not work for me, the installation step of the bootloader fails. hfsutils is not found (package missing on the CD?) thus I suppose newfs of the grub partition fails and the step aborts, I have seen that in some other of the many images I tried. Can I fix that manually perhaps? If you don't kick out a new installer, I need to complete with this one. I imagine these steps: - enter target root with busybox (which exactly?) - download hfsutils (a compatible version with May 30) - format the grub partition using the failing command: hformat -l "NewWorld Bootblock" "/dev/sda2" - manually install grub (which command(s) ?) Maybe getting the missing commands and confirmations of these steps from a receipe would make things easier, as a temporary step. Or perhaps another image is known to work/complete? as it seems I randomly tried since late 2019 and none seems to work :( Riccardo
Re: Updated installer images 2020-12-02
On 12/27/20 2:39 PM, Riccardo Mottola wrote: > Unfortunately, it does not work for me, the installation step of the > bootloader > fails. hfsutils is not found (package missing on the CD?) thus I suppose newfs > of the grub partition fails and the step aborts, I have seen that in some > other > of the many images I tried. You are confusing hfsprogs and hfsutils. The former is actually missing on the FTP server. > - download hfsutils (a compatible version with May 30) You need to install hfsprogs manually from here: - powerpc: > http://snapshot.debian.org/archive/debian-archive/20190328T105444Z/debian/pool/main/h/hfsprogs/hfsprogs_332.25-11_powerpc.deb - ppc64: > http://snapshot.debian.org/archive/debian-ports/20131024T131048Z/pool-ppc64/main/h/hfsprogs/hfsprogs_332.25-11_ppc64.deb The package is currently not installable because Debian Ports has no support for non-free at the moment. Something that I cannot change but the Debian Ports FTP admins can change. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installer images 2020-12-02
Hi, the MintPPC project uses the images from 2020-04-19 https://cdimage.debian.org/cdimage/ports/snapshots/2020-04-19/ I guess, this should work. Karl > Am 27.12.2020 um 14:49 schrieb John Paul Adrian Glaubitz > : > > On 12/27/20 2:39 PM, Riccardo Mottola wrote: >> Unfortunately, it does not work for me, the installation step of the >> bootloader >> fails. hfsutils is not found (package missing on the CD?) thus I suppose >> newfs >> of the grub partition fails and the step aborts, I have seen that in some >> other >> of the many images I tried. > > You are confusing hfsprogs and hfsutils. The former is actually missing on > the FTP > server. > >> - download hfsutils (a compatible version with May 30) > > You need to install hfsprogs manually from here: > > - powerpc: > >> http://snapshot.debian.org/archive/debian-archive/20190328T105444Z/debian/pool/main/h/hfsprogs/hfsprogs_332.25-11_powerpc.deb > > - ppc64: > >> http://snapshot.debian.org/archive/debian-ports/20131024T131048Z/pool-ppc64/main/h/hfsprogs/hfsprogs_332.25-11_ppc64.deb > > The package is currently not installable because Debian Ports has no support > for > non-free at the moment. Something that I cannot change but the Debian Ports > FTP > admins can change. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: Updated installer images 2020-12-02
Hello! On 12/27/20 2:58 PM, Karl wrote: > the MintPPC project uses the images from 2020-04-19 > https://cdimage.debian.org/cdimage/ports/snapshots/2020-04-19/ That shouldn't make a difference as these are missing hfsprogs on the installation CD as well. Unfortunately, hfsprogs has a non-free license (APSL) which is why we had to move the package to the "non-free" section and Debian Ports currently does not include "contrib" or "non-free". When I created the installation images back then, I did not make sure the hfsprogs package was included in the CD image. So it was always downloaded over the network when GRUB was being installed. However, I actually don't see a reason why the latest images shouldn't work on 64-Bit PowerMacs. 32-Bit machines won't work due to the aforementioned partman issue which is most likely a regression in glibc 2.31 and unless someone is willing to help me debug the issue, the bug will remain until I have found the time to work on this. I am planning to do that next week. So far I have not found the glibc change that is causing the partman problem. Debugging this is not trivial as it requires injecting glibc from git into the running installer to be able to bisect the issue in glibc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ppc64 testing binutils
i reported the problem via bugzilla and it was fixed on december 25th in the upstream source. i tested the fix and successfully compiled a kernel. hopefully a new experimental package based on the updated code will be released. the bug report (with fix): https://sourceware.org/bugzilla/show_bug.cgi?id=27100 cam On Wed, Dec 16, 2020 at 12:24 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hi Cameron! > > On 12/16/20 9:10 PM, Cameron MacPherson wrote: > > after upgrading to binutils 2.35.50.20201125-1 while attempting to > compile > > kernel 5.10.1 i get this error: > > > > $ make V=1 bindeb-pkg > > CC init/main.o > > [..]scripts/genksyms/genksyms -R -r /dev/null > init/.tmp_main.ver; ld > > -EB -m elf64ppc -r -o init/.tmp_main.o init/main.o -T init/.tmp_main.ver; > > mv -f init/.tmp_main.o init/main.o; rm -f init/.tmp_main.ver; fi > > ld: final link failed: bad value > > make[4]: *** [scripts/Makefile.build:279: init/main.o] Error 1 > > This should be either reported to the binutils Bugzilla [1] or to the > linux-ppc > kernel mailing list [2]. > > Thanks, > Adrian > > > [1] https://sourceware.org/bugzilla/ > > [2] https://lists.ozlabs.org/listinfo/linuxppc-dev > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: ppc64 testing binutils
Hi Cameron! On 12/27/20 11:52 PM, Cameron MacPherson wrote: > i reported the problem via bugzilla and it was fixed on december 25th in > the upstream source. i tested the fix and successfully compiled a kernel. > hopefully a new experimental package based on the updated code will be > released. Perfect, thanks a lot for taking the time to report the issue! > the bug report (with fix): > https://sourceware.org/bugzilla/show_bug.cgi?id=27100 Could you leave the feedback that Alan's patch fixed the issue in the bug tracker? That helps anyone running into this issue and Alan also knowing it fixed your problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installer images 2020-12-02
Hi! On 12/27/20 2:49 PM, John Paul Adrian Glaubitz wrote: You are confusing hfsprogs and hfsutils. The former is actually missing on the FTP server. The confusion arises because I found this in the logs: Dec 25 15:29:46 in-target: hfsutils: not found Dec 25 15:29:46 in-target: Dec 25 15:29:47 mk-hfs-bootstrap: `hformat -l "NewWorld Bootblock" "/dev/sda2"' failed with non-zero exit value (127)! Cannot continue. Exiting. - download hfsutils (a compatible version with May 30) You need to install hfsprogs manually from here: http://snapshot.debian.org/archive/debian-ports/20131024T131048Z/pool-ppc64/main/h/hfsprogs/hfsprogs_332.25-11_ppc64.deb The package is currently not installable because Debian Ports has no support for non-free at the moment. Something that I cannot change but the Debian Ports FTP admins can change.ù Inconvenient, those hfsprogs are very old, I needed also an old version of openssl: http://snapshot.debian.org/archive/debian-ports/20131024T131048Z/pool-ppc64/main/o/openssl/libssl1.0.0_1.0.1e-3_ppc64.deb it wants multiarch support too which I could't find, so I just forced it. This way I could indeed run, when in rescuemode on chroot in the targetroot hformat -l "NewWorld Bootblock" "/dev/sda2"' but now? If I try to run "grub-installer" in a rescue shell (not in target root) it fails because grub-proble fails to get the canonical path of rootfs and /boot . Maybe it needs some options? If, instead, from the rescue menu I run the "install grub boot loader", the behaviour is quite "stupid" IMO. The installer insists running the "installing the base system" step, I let it do but on a "pre-existing" partition (since I want to rescue, not reinstall, also because I have hfsutils manually installed there). Base install will fail, since a file is existing. I cannot install from the menu. Quite braindead... the installer tries to be too smart! Frustrating, I must say. Riccardo
Re: Updated installer images 2020-12-02
On 12/28/20 1:28 AM, Riccardo Mottola wrote: > Frustrating, I must say. Well, it's broken at the moment and I will fix that within the next days. You can either use a Yaboot-based image if it's really urgent or just wait. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
