Re: After update, just a black screen

[John Paul Adrian Glaubitz]

On 5/20/20 2:06 PM, Mick Bert wrote:
> Very bad!

Not unexpected when you are missing firmware packages.

> After the complete update, since long time (see, the other email), I got from 
> my iBookG4 just a black screen.

You need to install the firmware-amd-graphics package.

You need to add the following to your sources.list:

# contrib and non-free arch:all packages (i.e. firmware)
deb [arch=all] http://ftp.debian.org/debian/ unstable contrib non-free

> I can see the boot logging until the graphic card initialization, then I have 
> no way to
> interact. I also tried to load the old kernel (from yaboot menu), but the 
> result is the same.

Try booting with "nomodeset" or "init=/bin/bash".

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: [Regression 5.7-rc1] Random hangs on 32-bit PowerPC (PowerBook6,7)

[Aneesh Kumar K.V]

On 5/20/20 7:23 PM, Christophe Leroy wrote:



Le 20/05/2020 à 15:43, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


Le 18/05/2020 à 17:19, Rui Salvaterra a écrit :

Hi again, Christophe,

On Mon, 18 May 2020 at 15:03, Christophe Leroy
 wrote:


Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It 
may

have broken swap.


Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a definitive patch!



Yeah I discovered recently that the way swap is implemented on powerpc
expects RW and other important bits not be one of the 3 least
significant bits (see __pte_to_swp_entry() )


The last 3 bits are there to track the _PAGE_PRESENT right? What is the
RW dependency there? Are you suggesting of read/write migration entry?
A swap entry should not retain the pte rw bits right?

A swap entry is built using swap type + offset. And it should not have a
dependency on pte RW bits. Along with type and offset we also should
have the ability to mark it as a pte entry and also set not present
bits. With that understanding what am I missing here?


That's probably me who is missing something, I have not digged into the 
swap functionning yet indeed, so that was only my first feeling.


By the way, the problems is definitely due to the order changes in the 
PTE bits, whether that's because _PAGE_RW was moved to the last 3 bits 
or whether that's because _PAGE_PRESENT was moved out of the last 3 
bits, I don't know yet.


My (bad) understanding is from the fact that  __pte_to_swp_entry() is a 
right shift by 3 bits, so it looses the last 3 bits, and therefore 
__swp_entry_to_pte(__pte_to_swp_entry(pte)) looses the last 3 bits of a 
PTE.


Is there somewhere a description of how swap works exactly ?



Looking at  __set_pte_at(), I am wondering whether this was due to 
_PAGE_HASHPTE? . This would mean we end up wrongly updating some swap 
entry details. We call set_pte_at() on swap pte entries.


-aneesh

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Rui Salvaterra]

Hi, Christian,

On Wed, 20 May 2020 at 16:00, Christian König
 wrote:
>
> So I've used an ancient system (32bit) to setup a test box for this.
>
>
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.

Oh, I have one of those in box somewhere, but no AGP machine to
install it (yet).

> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
>
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
>
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.

I agree, correctness before performance, always.

> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
>
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
>
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.

I usually test with my distro's (Debian or Ubuntu, in my case) games.
For example, I used Nexuiz when wiring up the shader cache on r300g.

> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
>
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.
>
> So if anybody wants to get his hands dirty and squeeze a bit more
> performance out of the old hardware, porting USWC from amdgpu to radeon
> shouldn't be to much of a problem.

Well, FWIW, I would argue that a regression in performance, if
avoidable, should be avoided. I have not nearly enough knowledge of
the driver to do it myself, but I'll glady test any patches, on both
x86-64 (Radeon Xpress 1250) and ppc32 (Mobility Radeon 9550).

Cheers,
Rui

Re: iBook G4 - Wireless

[Rui Salvaterra]

Hi, Mick,

On Wed, 20 May 2020 at 16:05, Mick Bert  wrote:
>
> But when I type the command iwlist, it give me:*|

iwlist is for very old WEXT-based drivers, IIRC. For modern
mac80211-based drivers (like b43) using the nl80211 configuration
interface, you need to use iw.

Cheers,
Rui

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Alex Deucher]

On Wed, May 20, 2020 at 10:43 AM Christian König
 wrote:
>
> Am 13.05.20 um 13:03 schrieb Christian König:
> > Unfortunately AGP is still to widely used as we could just drop support for 
> > using its GART.
> >
> > Not using the AGP GART also doesn't mean a loss in functionality since 
> > drivers will just fallback to the driver specific PCI GART.
> >
> > For now just deprecate the code and don't enable the AGP GART in TTM even 
> > when general AGP support is available.
>
> So I've used an ancient system (32bit) to setup a test box for this.
>
>
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.
>
> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
>
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
>
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.
>
>
> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
>
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
>
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.
>
> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
>
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.
>
>
> So if anybody wants to get his hands dirty and squeeze a bit more
> performance out of the old hardware, porting USWC from amdgpu to radeon
> shouldn't be to much of a problem.

We do support USWC on radeon, although I think we had separate flags
for cached and WC.  That said we had a lot of problems with WC on 32
bit (see radeon_bo_create()).  The other problem is that, at least on
the really old radeons, the PCI gart didn't support snooped and
unsnooped.  It was always snooped.  It wasn't until pcie that the gart
hw got support for both.  For AGP, the expectation was that AGP
provided the uncached memory.

>
>
> Summing it up I'm still leaning towards disabling AGP completely by
> default for radeon and deprecate it in TTM as well.
>
> Thoughts? Especially Alex what do you think.

Works for me.

Alex

Re: iBook G4 - Wireless

[John Paul Adrian Glaubitz]

On 5/20/20 6:58 PM, Rui Salvaterra wrote:
> On Wed, 20 May 2020 at 17:56, John Paul Adrian Glaubitz
>  wrote:
>>
>> I recommend using nmcli for network configuration on the command line, it's
>> convenient and supports everything that network-manager supports.
> 
> Nah… nmtui. ;)

Ah, I haven't tried that yet, to be honest. I will give it a try next time
I'm using network-manager on the command line.

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: iBook G4 - Wireless

[Rui Salvaterra]

On Wed, 20 May 2020 at 17:56, John Paul Adrian Glaubitz
 wrote:
>
> I recommend using nmcli for network configuration on the command line, it's
> convenient and supports everything that network-manager supports.

Nah… nmtui. ;)

Re: iBook G4 - Wireless

[Jeroen Diederen]

https://wireless.wiki.kernel.org/en/users/drivers/b43


Mick Bert schreef op 2020-05-20 17:05:

Il 01/02/19 16:59, John Paul Adrian Glaubitz ha scritto:

See: http://snapshot.debian.org/package/b43-fwcutter/1%3A019-3/


Hello

I downloaded and installed b43-fwcutter
 and
|*firmware-b43-installer_019-3with dpkg -i, and it looks to work fine.
But when I type the command iwlist, it give me:*|


|*lo Interface doesn't support scanning.
enP2p32s15f0  Interface doesn't support scanning.
wlan0 Interface doesn't support scanning : Network is down
*|


|*dmesg|grep b43:
*|


|*[    7.081207] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 
0006)

[    7.241650] b43-pci-bridge 0001:10:12.0: Sonics Silicon Backplane
found on PCI device 0001:10:12.0
[   22.025427] b43-phy0: Broadcom 4306 WLAN found (core revision 5)
[   22.123551] b43-phy0: Found PHY: Analog 2, Type 2 (G), Revision 2
[   22.128124] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision
2, Version 0
[   22.264280] b43 ssb0:0: firmware: direct-loading firmware 
b43/ucode5.fw
[   22.412649] b43 ssb0:0: firmware: direct-loading firmware 
b43/pcm5.fw

[   22.541911] b43 ssb0:0: firmware: direct-loading firmware
b43/b0g0initvals5.fw
[   22.658153] b43 ssb0:0: firmware: direct-loading firmware
b43/b0g0bsinitvals5.fw
*|

|*While lspci:*|

|*0001:10:12.0 Network controller: Broadcom Inc. and subsidiaries
BCM4306 802.11b/g Wireless LAN Controller (rev 03)

*|

|**|What can I check?

|**|

Re: iBook G4 - Wireless

[John Paul Adrian Glaubitz]

On 5/20/20 6:17 PM, Rui Salvaterra wrote:
> On Wed, 20 May 2020 at 16:05, Mick Bert  wrote:
>>
>> But when I type the command iwlist, it give me:*|
> 
> iwlist is for very old WEXT-based drivers, IIRC. For modern
> mac80211-based drivers (like b43) using the nl80211 configuration
> interface, you need to use iw.

Indeed. The last release of wireless-tools happened more than 10 years ago,
like net-tools, it's deprecated and should no longer be used.

I recommend using nmcli for network configuration on the command line, it's
convenient and supports everything that network-manager supports.

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: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Michel Dänzer]

On 2020-05-20 4:43 p.m., Christian König wrote:
> Am 13.05.20 um 13:03 schrieb Christian König:
>> Unfortunately AGP is still to widely used as we could just drop
>> support for using its GART.
>>
>> Not using the AGP GART also doesn't mean a loss in functionality since
>> drivers will just fallback to the driver specific PCI GART.
>>
>> For now just deprecate the code and don't enable the AGP GART in TTM
>> even when general AGP support is available.
> 
> So I've used an ancient system (32bit) to setup a test box for this.
> 
> 
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.
> 
> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
> 
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
> 
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.
> 
> 
> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
> 
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
> 
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.
> 
> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
> 
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.

I suspect the main reason it's only 5% is that PCIe GART page tables are
stored in VRAM, so they don't need to be fetched across the PCIe link
(and presumably it has more than one TLB entry as well). The difference
is much bigger with native AGP ASICs with PCI GART.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer

Re: iBook G4 - Wireless

[Rui Salvaterra]

On Wed, 20 May 2020 at 18:00, John Paul Adrian Glaubitz
 wrote:
>
> On 5/20/20 6:58 PM, Rui Salvaterra wrote:
> > On Wed, 20 May 2020 at 17:56, John Paul Adrian Glaubitz
> >  wrote:
> >>
> >> I recommend using nmcli for network configuration on the command line, it's
> >> convenient and supports everything that network-manager supports.
> >
> > Nah… nmtui. ;)
>
> Ah, I haven't tried that yet, to be honest. I will give it a try next time
> I'm using network-manager on the command line.

I used to use nmcli too, but a couple of months ago a friend of mine
showed me the light. :)

Re: After update, just a black screen

[Mick Bert]

Il 20/05/20 14:30, John Paul Adrian Glaubitz ha scritto:

"init=/bin/bash".


What the hell - in this mode, it does not recognise keystroke ^C, or ^Z. 
I started a ping, and I do not know how to interrupt it!


--
Mick

Re: After update, just a black screen

[jjhdiederen]

What you could also do is to boot from a Debian installer medium and do 
"Recovery". You can then enter the system and issue the command as given 
by Adrian.

Re: After update, just a black screen

[Mick Bert]

Il 20/05/20 14:30, John Paul Adrian Glaubitz ha scritto:

You need to install the firmware-amd-graphics package.

You need to add the following to your sources.list:

# contrib and non-free arch:all packages (i.e. firmware)
deb [arch=all]http://ftp.debian.org/debian/  unstable contrib non-free


I can see the boot logging until the graphic card initialization, then I have 
no way to
interact. I also tried to load the old kernel (from yaboot menu), but the 
result is the same.

Try booting with "nomodeset".


The good news is that this way works fine. And the suggestion above, 
fixed the issue.


Then I am going to work on the wireless adapter...

--
Mick

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Christian König]

Am 13.05.20 um 13:03 schrieb Christian König:

Unfortunately AGP is still to widely used as we could just drop support for 
using its GART.

Not using the AGP GART also doesn't mean a loss in functionality since drivers 
will just fallback to the driver specific PCI GART.

For now just deprecate the code and don't enable the AGP GART in TTM even when 
general AGP support is available.


So I've used an ancient system (32bit) to setup a test box for this.


The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily 
15 years old.


What happens in AGP mode is that glxgears shows artifacts during 
rendering on this system.


In PCI mode those rendering artifacts are gone and glxgears seems to 
draw everything correctly now.


Performance is obviously not comparable, cause in AGP we don't render 
all triangles correctly.



The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP) 
which is more than 10 years old.


As far as I can tell this one works in both AGP and PCIe mode perfectly 
fine.


Since this is only a 32bit system I couldn't really test any OpenGL game 
that well.


But for glxgears switching from AGP to PCIe mode seems to result in a 
roughly 5% performance drop.


The surprising reason for this is not the better TLB performance, but 
the lack of USWC support for the PCIe GART in radeon.



So if anybody wants to get his hands dirty and squeeze a bit more 
performance out of the old hardware, porting USWC from amdgpu to radeon 
shouldn't be to much of a problem.



Summing it up I'm still leaning towards disabling AGP completely by 
default for radeon and deprecate it in TTM as well.


Thoughts? Especially Alex what do you think.

Regards,
Christian.

After update, just a black screen

[Mick Bert]

Very bad!

After the complete update, since long time (see, the other email), I got 
from my iBookG4 just a black screen.


I can see the boot logging until the graphic card initialization, then I 
have no way to interact. I also tried to load the old kernel (from 
yaboot menu), but the result is the same.


Apart from suggestions on how to fix the whole issue, the first 
information I need is how can I boot the system in a text console, 
without loading xorg, which I suppose is the point.


--
Mick

Re: [Regression 5.7-rc1] Random hangs on 32-bit PowerPC (PowerBook6,7)

[Christophe Leroy]

Le 20/05/2020 à 15:43, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


Le 18/05/2020 à 17:19, Rui Salvaterra a écrit :

Hi again, Christophe,

On Mon, 18 May 2020 at 15:03, Christophe Leroy
 wrote:


Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
have broken swap.


Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a definitive patch!



Yeah I discovered recently that the way swap is implemented on powerpc
expects RW and other important bits not be one of the 3 least
significant bits (see __pte_to_swp_entry() )


The last 3 bits are there to track the _PAGE_PRESENT right? What is the
RW dependency there? Are you suggesting of read/write migration entry?
A swap entry should not retain the pte rw bits right?

A swap entry is built using swap type + offset. And it should not have a
dependency on pte RW bits. Along with type and offset we also should
have the ability to mark it as a pte entry and also set not present
bits. With that understanding what am I missing here?


That's probably me who is missing something, I have not digged into the 
swap functionning yet indeed, so that was only my first feeling.


By the way, the problems is definitely due to the order changes in the 
PTE bits, whether that's because _PAGE_RW was moved to the last 3 bits 
or whether that's because _PAGE_PRESENT was moved out of the last 3 
bits, I don't know yet.


My (bad) understanding is from the fact that  __pte_to_swp_entry() is a 
right shift by 3 bits, so it looses the last 3 bits, and therefore 
__swp_entry_to_pte(__pte_to_swp_entry(pte)) looses the last 3 bits of a PTE.


Is there somewhere a description of how swap works exactly ?

Christophe

Re: [Regression 5.7-rc1] Random hangs on 32-bit PowerPC (PowerBook6,7)

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> Le 18/05/2020 à 17:19, Rui Salvaterra a écrit :
>> Hi again, Christophe,
>> 
>> On Mon, 18 May 2020 at 15:03, Christophe Leroy
>>  wrote:
>>>
>>> Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
>>> have broken swap.
>> 
>> Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
>> survives the beating. I'll be happy to test a definitive patch!
>> 
>
> Yeah I discovered recently that the way swap is implemented on powerpc 
> expects RW and other important bits not be one of the 3 least 
> significant bits (see __pte_to_swp_entry() )

The last 3 bits are there to track the _PAGE_PRESENT right? What is the
RW dependency there? Are you suggesting of read/write migration entry?
A swap entry should not retain the pte rw bits right? 

A swap entry is built using swap type + offset. And it should not have a
dependency on pte RW bits. Along with type and offset we also should
have the ability to mark it as a pte entry and also set not present
bits. With that understanding what am I missing here?

>
> I guess the easiest for the time being is to revert the commit with a 
> proper explanation of the issue, then one day we'll modify the way 
> powerpc manages swap.
>

-aneesh

Re: iBook G4 - Wireless

[Mick Bert]

Il 01/02/19 16:59, John Paul Adrian Glaubitz ha scritto:

See: http://snapshot.debian.org/package/b43-fwcutter/1%3A019-3/


Hello

I downloaded and installed b43-fwcutter 
 and 
|*firmware-b43-installer_019-3with dpkg -i, and it looks to work fine. 
But when I type the command iwlist, it give me:*| 



|*lo Interface doesn't support scanning.
enP2p32s15f0  Interface doesn't support scanning.
wlan0 Interface doesn't support scanning : Network is down
*| 



|*dmesg|grep b43:
*| 



|*[    7.081207] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
[    7.241650] b43-pci-bridge 0001:10:12.0: Sonics Silicon Backplane 
found on PCI device 0001:10:12.0

[   22.025427] b43-phy0: Broadcom 4306 WLAN found (core revision 5)
[   22.123551] b43-phy0: Found PHY: Analog 2, Type 2 (G), Revision 2
[   22.128124] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 
2, Version 0

[   22.264280] b43 ssb0:0: firmware: direct-loading firmware b43/ucode5.fw
[   22.412649] b43 ssb0:0: firmware: direct-loading firmware b43/pcm5.fw
[   22.541911] b43 ssb0:0: firmware: direct-loading firmware 
b43/b0g0initvals5.fw
[   22.658153] b43 ssb0:0: firmware: direct-loading firmware 
b43/b0g0bsinitvals5.fw

*|

|*While lspci:*|

|*0001:10:12.0 Network controller: Broadcom Inc. and subsidiaries 
BCM4306 802.11b/g Wireless LAN Controller (rev 03)


*|

|**|What can I check?

|**| 



--
Mick

Re: After update, just a black screen

[Rui Salvaterra]

Hi, Mick,

On Wed, 20 May 2020 at 15:00, Mick Bert  wrote:
>
> Then I am going to work on the wireless adapter...

To get Wi-Fi working, you probably only need to apt-get the
firmware-b43-installer package, assuming you already added the line
Adrian told you to your sources.list. I'm trying to get WPA3 Personal
to work, but that will require patching the b43 driver (and will only
ever be possible with software crypto).

Cheers,
Rui

Re: PB G4 Installation

[John Paul Adrian Glaubitz]

On 5/20/20 10:12 PM, user...@yahoo.com wrote:
> I installed Debian SID from the 4/19/2020 installation CD to a PowerBook
> G4, 1.5 GHz, 1.25 GB memory.  It seems to have installed well -- thanks
> to everyone who is working to maintain Debian for PowerPC!

Great to hear!

> This system has valid installations of Mac OS X Tiger and Mac OS X
> Leopard.  During installation, these operating systems were detected:
>   Mac OS X (32-bit) (on /dev/sda3) <-- This should be Mac OS X Tiger
>   Mac OS X (64-bit) (on /dev/sda3)
>   Mac OS X (32-bit) (on /dev/sda4) <-- This should be Mac OS X Leopard
>   Mac OS X (64-bit) (on /dev/sda4)
> 
> After installation, if I select either the first or third choice, I see:
> error: can't find command `xnu_kernel'.
> error: can't find command `xnu_mkext'.
> Press any key to continue...
> 
> I'm not sure why the second and fourth choices exist at all on this system.
> 
> Does anyone have any suggestions on how to fix the GRUB configuration to
> allow booting of Mac OS X partitions?  I'll study the man pages, but if
> I can't get it to work, I'll need to install yaboot instead.

Someone on this mailing list explained how to fix that. I think that was
last month or so. Or maybe the mailing list member in question will read
your mail.

> And I have these additional comments and suggestions (some of these may
> be out of scope of the Debian PPC unsupported port):
> 
> 1) I know Debian has opted to use systemd instead of sysvinit; however,
> there are valid reasons (mostly resource related) to opt for sysvinit on
> some systems.  For example, on a PowerBook G3 Wallstreet, 266 MHz, 384
> MB memory, sysvinit runs better than systemd.  This is not an invitation
> to re-open (or start a new) systemd discussion, it is a request to allow
> installation of packages that shouldn't require systemd, such as
> synaptic, to be installed without also installing systemd.  Fortunately,
> Xfce can still be installed without systemd.

This isn't really something I can change, sorry. You can just install sysvinit
and it will work. Whether certain desktops work without systemd is basically
a decision that has been made upstream.

> 2) Is there a way to change the Ethernet interface from "enP2p32s15f0"
> back to "eth0"?  I'm sure there are many very good reasons to have the
> longer names on modern systems, but on the PB G4 I'm not likely to
> change out the Ethernet interface, and it would be easier to manage it
> as "eth0".  Again, I'm not inviting discussion about why the choice of
> the longer names is better, I'm just trying to determine whether there
> is a user-configurable option for switching it back to "eth0" (as it was
> in Debian 7.8).

See: https://wiki.debian.org/NetworkInterfaceNames#How_to_get_it_back

Apparently, it's enough to pass "net.ifnames=0" on the kernel command line.

> 3) The trackpad on the PB G4 is a little slow and unpredictable in
> Debian SID, especially when the system is doing other things (like an
> apt-get update or apt-get upgrade).  The problems go away if I use a USB
> mouse, but I'm wondering if there is any way to tune the trackpad
> performance (or if not to just disable it altogether).

Did you try asking on the corresponding Linux kernel mailing list?

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: PB G4 Installation

[userm57]

On 5/20/20 5:59 PM, John Paul Adrian Glaubitz wrote:
> On 5/20/20 10:32 PM, John Paul Adrian Glaubitz wrote:
>>> Does anyone have any suggestions on how to fix the GRUB configuration to
>>> allow booting of Mac OS X partitions?  I'll study the man pages, but if
>>> I can't get it to work, I'll need to install yaboot instead.
>>
>> Someone on this mailing list explained how to fix that. I think that was
>> last month or so. Or maybe the mailing list member in question will read
>> your mail.
> 
> Btw, contributors to fix this issue are welcome.

Thanks.  Google found some articles related to this; I will take a look
at those and see if there is anything helpful.  Meanwhile, yaboot works
on the PB G4 in Debian SID to boot Mac OS Tiger, Mac OS Leopard, Debian
7.8, Debian SID and Gentoo.  The Debian 7.8 version did not work, likely
because that version's ofpath was somewhat buggy.

> 
>>> And I have these additional comments and suggestions (some of these may
>>> be out of scope of the Debian PPC unsupported port):
>>>
>>> 1) I know Debian has opted to use systemd instead of sysvinit; however,
>>> there are valid reasons (mostly resource related) to opt for sysvinit on
>>> some systems.  For example, on a PowerBook G3 Wallstreet, 266 MHz, 384
>>> MB memory, sysvinit runs better than systemd.  This is not an invitation
>>> to re-open (or start a new) systemd discussion, it is a request to allow
>>> installation of packages that shouldn't require systemd, such as
>>> synaptic, to be installed without also installing systemd.  Fortunately,
>>> Xfce can still be installed without systemd.
>>
>> This isn't really something I can change, sorry. You can just install 
>> sysvinit
>> and it will work. Whether certain desktops work without systemd is basically
>> a decision that has been made upstream.
> And I would like to add here: Not a single Debian Developer is opposed to
> such changes, it's just that the majority doesn't care which is why the
> people who want such flexibility will have to help with that work.
> 
> I think there is still the debian-init-diversity team [1] which certainly
> is always looking for new contributors.
> 
> Adrian
> 
>> [1] https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity
> 

ok, thanks.  I'll see whether I'm able to contribute anything to that
team.  Strictly speaking, though, I'm just asking for non-systemd
versions of packages when possible, such as synaptic.  I think there's
also a non-systemd version of Gnome.  I can always download these myself
from their respective authors and compile without systemd options, or
use versions from Gentoo.

Re: PB G4 Installation

[John Paul Adrian Glaubitz]

On 5/20/20 10:32 PM, John Paul Adrian Glaubitz wrote:
>> Does anyone have any suggestions on how to fix the GRUB configuration to
>> allow booting of Mac OS X partitions?  I'll study the man pages, but if
>> I can't get it to work, I'll need to install yaboot instead.
> 
> Someone on this mailing list explained how to fix that. I think that was
> last month or so. Or maybe the mailing list member in question will read
> your mail.

Btw, contributors to fix this issue are welcome.

>> And I have these additional comments and suggestions (some of these may
>> be out of scope of the Debian PPC unsupported port):
>>
>> 1) I know Debian has opted to use systemd instead of sysvinit; however,
>> there are valid reasons (mostly resource related) to opt for sysvinit on
>> some systems.  For example, on a PowerBook G3 Wallstreet, 266 MHz, 384
>> MB memory, sysvinit runs better than systemd.  This is not an invitation
>> to re-open (or start a new) systemd discussion, it is a request to allow
>> installation of packages that shouldn't require systemd, such as
>> synaptic, to be installed without also installing systemd.  Fortunately,
>> Xfce can still be installed without systemd.
> 
> This isn't really something I can change, sorry. You can just install sysvinit
> and it will work. Whether certain desktops work without systemd is basically
> a decision that has been made upstream.
And I would like to add here: Not a single Debian Developer is opposed to
such changes, it's just that the majority doesn't care which is why the
people who want such flexibility will have to help with that work.

I think there is still the debian-init-diversity team [1] which certainly
is always looking for new contributors.

Adrian

> [1] https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity

-- 
 .''`.  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

PB G4 Installation

[userm57]

Hello,

I installed Debian SID from the 4/19/2020 installation CD to a PowerBook
G4, 1.5 GHz, 1.25 GB memory.  It seems to have installed well -- thanks
to everyone who is working to maintain Debian for PowerPC!

This system has valid installations of Mac OS X Tiger and Mac OS X
Leopard.  During installation, these operating systems were detected:
  Mac OS X (32-bit) (on /dev/sda3) <-- This should be Mac OS X Tiger
  Mac OS X (64-bit) (on /dev/sda3)
  Mac OS X (32-bit) (on /dev/sda4) <-- This should be Mac OS X Leopard
  Mac OS X (64-bit) (on /dev/sda4)

After installation, if I select either the first or third choice, I see:
error: can't find command `xnu_kernel'.
error: can't find command `xnu_mkext'.
Press any key to continue...

I'm not sure why the second and fourth choices exist at all on this system.

Does anyone have any suggestions on how to fix the GRUB configuration to
allow booting of Mac OS X partitions?  I'll study the man pages, but if
I can't get it to work, I'll need to install yaboot instead.

And I have these additional comments and suggestions (some of these may
be out of scope of the Debian PPC unsupported port):

1) I know Debian has opted to use systemd instead of sysvinit; however,
there are valid reasons (mostly resource related) to opt for sysvinit on
some systems.  For example, on a PowerBook G3 Wallstreet, 266 MHz, 384
MB memory, sysvinit runs better than systemd.  This is not an invitation
to re-open (or start a new) systemd discussion, it is a request to allow
installation of packages that shouldn't require systemd, such as
synaptic, to be installed without also installing systemd.  Fortunately,
Xfce can still be installed without systemd.

2) Is there a way to change the Ethernet interface from "enP2p32s15f0"
back to "eth0"?  I'm sure there are many very good reasons to have the
longer names on modern systems, but on the PB G4 I'm not likely to
change out the Ethernet interface, and it would be easier to manage it
as "eth0".  Again, I'm not inviting discussion about why the choice of
the longer names is better, I'm just trying to determine whether there
is a user-configurable option for switching it back to "eth0" (as it was
in Debian 7.8).

3) The trackpad on the PB G4 is a little slow and unpredictable in
Debian SID, especially when the system is doing other things (like an
apt-get update or apt-get upgrade).  The problems go away if I use a USB
mouse, but I'm wondering if there is any way to tune the trackpad
performance (or if not to just disable it altogether).

thanks!

-Stan Johnson

Re: Update fails due to NO_PUBKEY

[John Paul Adrian Glaubitz]

Hi Mick!

On 5/20/20 9:52 AM, Mick Bert wrote:
> I am trying to update debian in my iBook G4 since a very long time, but the
> "apt update" command fails due to mising public key for signature checking.

Try this as root:

# wget 
http://ftp.ports.debian.org/debian-ports/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2019.11.05_all.deb
# dpkg -i debian-ports-archive-keyring_2019.11.05_all.deb

This should fix "apt update".

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: Update fails due to NO_PUBKEY

[John Paul Adrian Glaubitz]

On 5/20/20 10:14 AM, Mick Bert wrote:
> Il 20/05/20 09:54, Steffen Grunewald ha scritto:
>> On Wed, 2020-05-20 at 09:52:51 +0200, Mick Bert wrote:
>>> I am trying to update debian in my iBook G4 since a very long time, but the
>>> "apt update" command fails due to mising public key for signature checking.
>> Extract the key ID from the error message, fetch the key (using gpg 
>> --recv-keys),
>> then a
> 
> The key ID is the following 'NO_PUBKEY 84C573CD4E1AFD6C'
> 
> but the command 'gpg --recv-key 84C573CD4E1AFD6C' fails with a "general 
> error". Anyway...

That's because this particular key has expired:

glaubitz@suse-laptop:~> gpg --fingerprint 84C573CD4E1AFD6C
gpg: checking the trustdb
gpg: key 2064C53641C25E5D: no user ID for key signature packet of class 10
gpg: key 2064C53641C25E5D: no user ID for key signature packet of class 10
gpg: key 2064C53641C25E5D: no user ID for key signature packet of class 10
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   4  signed:  88  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1  valid:  88  signed:  85  trust: 88-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2020-05-30
pub   rsa4096 2018-12-26 [SC] [expired: 2020-01-31]
  1177 213F 7B9E F1C5 280C  FEEA 84C5 73CD 4E1A FD6C
uid   [ expired] Debian Ports Archive Automatic Signing Key (2020) 


glaubitz@suse-laptop:~>

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: Update fails due to NO_PUBKEY

[Steffen Grunewald]

On Wed, 2020-05-20 at 09:52:51 +0200, Mick Bert wrote:
> I am trying to update debian in my iBook G4 since a very long time, but the
> "apt update" command fails due to mising public key for signature checking.

Extract the key ID from the error message, fetch the key (using gpg 
--recv-keys),
then add it to the keyring known to APT (apt-key add) ...

HTH, 
 Steffen

Re: Update fails due to NO_PUBKEY

[Mick Bert]

Il 20/05/20 09:54, Steffen Grunewald ha scritto:

On Wed, 2020-05-20 at 09:52:51 +0200, Mick Bert wrote:

I am trying to update debian in my iBook G4 since a very long time, but the
"apt update" command fails due to mising public key for signature checking.

Extract the key ID from the error message, fetch the key (using gpg 
--recv-keys),
then a


The key ID is the following 'NO_PUBKEY 84C573CD4E1AFD6C'

but the command 'gpg --recv-key 84C573CD4E1AFD6C' fails with a "general 
error". Anyway...


Il 20/05/20 09:54, John Paul Adrian Glaubitz ha scritto:

Try this as root:
# wget 
http://ftp.ports.debian.org/debian-ports/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2019.11.05_all.deb
# dpkg -i debian-ports-archive-keyring_2019.11.05_all.deb

This seems to work. Now the long process of "apt-get dist-upgrade" is in 
course.


Thanks all

--
Mick

Update fails due to NO_PUBKEY

[Mick Bert]

I am trying to update debian in my iBook G4 since a very long time, but 
the "apt update" command fails due to mising public key for signature 
checking.


My current sources.list is:

# binary default
deb http://ftp.ports.debian.org/debian-ports/ unstable main
deb http://ftp.ports.debian.org/debian-ports/ unreleased main
deb http://incoming.ports.debian.org/buildd/ unstable main

# source
deb-src http://ftp.debian.org/debian unstable main
deb-src http://incoming.debian.org/debian-buildd/ buildd-unstable main

and the debian-version:

buster/sid

It's not the first time I got this error (even though on other systems), 
but I never remember how to get out of it. I allready tried with 
--allow-unauthenticated, with the same result.


--
Mick