[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Maturity of GRUB on powerpc/ppc64?

From: Frank Scheiner
Subject: Re: Maturity of GRUB on powerpc/ppc64?
Date: Mon, 2 Oct 2017 17:24:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

Hi Adrian,

On 09/26/2017 09:16 PM, John Paul Adrian Glaubitz wrote:
On 09/26/2017 08:57 PM, Frank Scheiner wrote:
Sorry, I'm a little occupied recently, but I was successful in installing and
using Grub to boot my Xserve G4 on Debian Sid this weekend. Haven't tried on 
G3 or G4 Power Macs yet, though.

Please try to perform some more testing. I'm especially interested in tests
on 32-bit hardware to make sure we don't break anything there.

To speed up things I just used the disk(s) from the Xserve G4 with working Grub installation and Debian Sid (powerpc) in the machines I tested and tried to boot them with Grub, which succeeded* for all of the following machines (in the given order):

* Power Macintosh G4 (3,3 aka Gigabit)
* Power Macintosh G3 (1,1 aka Blue&White)

* Power Macintosh G4 (3,6 aka MDD)
* Power Macintosh G4 (3,5 aka QS 2002)
* Power Macintosh G4 (3,1 aka AGP)

*) Unfortunately I had some problems during my initial testing which cost me quite some time and made it necessary to reinstall Debian on the Xserve G4 on another disk (which cost even more time and multiple tries as the OF path to the disk partition containing yaboot couldn't be determined correctly on the Xserve G4). After testing the G3 where Grub was able to boot the machine, I observed multiple problems during execution of several programs (e.g. `time 7z b -mmt1` and `time 7z b` assumed four execution threads (!) and gave a decoding error and a segfault respectively during benchmarking, `halt` also segfaulted, hitting the power button powered the machine down instantly without a proper shutdown). On the next reboot the root file system was damaged and no longer accessible. I gave up on the repair from a Debian 8 installer CD-ROM, as there were hundreds of errors and because I remembered to have read somewhere that the early G3s had a buggy ATA controller installed, which could be one reason for the FS damage. On the other hand, the Xserve G4 showed an fsck error during startup with Debian Sid, too:

Begin: Will now check root file system ... fsck from util-linux 2.29.2
[/sbin/fsck.ext4 (1) -- /dev/sda3] fsck.ext4 -a -C0 /dev/sda3
Signal (4) SIGILL si_code=ILL_ILLOPC fault addr=0x8acd8c
fsck exited with status code 8
Warning: File system check failed but did not detect errors

...but I initially did not pay that much attention to it and just assumed it could be a problem of the tools integrated in the initrd - exit code 8 is for an "operational error". But it could as well be, that the FS got corrupted on the Xserve G4 already and was fully destroyed by the G3.

After reinstalling Debian Sid on another ATA disk on the Xserve G4 - this time starting with Debian Jessie, I could finish my testing with the remaining Power Macintosh G4 types I have available. I did not observe the above mentioned FS issues with the reinstalled Debian Sid.

Despite these problems, all listed machines could be booted by Grub 2.02-2 from Debian Sid during my tests as already mentioned. I booted Grub manually via `boot hd:2,grub.img`.

The root FS was an EXT4 formatted with Debian Wheezy (for G3 and G4 (3,3)) and Debian Jessie (for G4 (3,1), G4 (3,5), G4 (3,6)). No separate partition for `/boot` was used.

As the Xserve G4 comes with an externally usable serial port by default, Grub was configured to also use this port as console. This machines (and I believe also the other listed machines) have two sets of input and output device NVRAM vars:

* `input-device`
* `output-device`


* `input-device-1`
* `output-device-1`

With the following NVRAM setting:

input-device            keyboard             keyboard
output-device           screen               screen
input-device-1          scca                 scca
output-device-1         scca                 scca

...and no keyboard connected, the OF interface falls back to the serial console, but the Grub menu is displayed only on the glass console and no interaction from the serial console is possible. With the settings reversed:

input-device            scca                 keyboard
output-device           scca                 screen
input-device-1          keyboard             scca
output-device-1         screen               scca

...and a keyboard connected, both OF interface and the Grub menu are using the serial console. No output was observed on the glass console. The embedded Grub config shown on [1] should actually configure Grub to use both glass and serial console, but it seems like the console device that is actually used depends on what is set for `input-device` and `output-device` in the NVRAM - or I'm doing something wrong.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]