Re: i386 debian to 64bit intel

[john doe]

On 12/5/2020 7:32 PM, Jerry Mellon wrote:

Thanks John.
I’m not brave enough to try that yet. I will just backup. Do I need to re 
format or will the install take care of that?



No, the Debian installer (d-i) will per default take care of that for you.

Here's what I would suggest:
- Backup what you need as you will loos everything that is on the disk
that will be reinstalled
- Execute the below commands in a terminal to download the proper iso file:

$ mkdir debian-amd64-10.7
$ cd debian-amd64-10.7
$ wget
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.7.0-amd64-netinst.iso
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/SHA512SUMS.sign 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/SHA512SUMS
|| echo "Something went rong when checksumming."
$ sha512sum -c SHA512SUMS --strict --ignore-missing || echo "Something
went rong while verifying."
$ gpg --keyserver hkps://keyring.debian.org --keyserver-options
auto-key-retrieve --verify *.sign


Note that if you requires non-free firmware during installation you
might want the below URL instead:

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.7.0+nonfree/amd64/iso-cd/

If you want non-free firmware you can simply substitute the URLs in the
wget line above.


- If the above commands are successfull
- Install as you have already done but with the correct architecture
- When prompted on how to format the disk select the line that resemble
"Install home directories in a separate partition"


P.S.

Please post through the list so others can chime in when needed or  when
I'm rong! :)

--
John Doe

Re: Replying. [was Re: AMD GPU Sea Islands Problem]

[Brad Rogers]

On Sat, 5 Dec 2020 23:08:14 +0200
Andrei POPESCU  wrote:

Hello Andrei,

> 2. A Reply-To is set, either by the list[1] or by the Sender

Even with one set, many ppl /still/ manage to not honour it.

I've lost count of the number of time replies have come to me only,
despite setting a list address for the Reply-To which survived any list
software processing.   :-(

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Keep your drink just give 'em the money
U & Ur Hand - P!nk


pgpofhT_zg81m.pgp
Description: OpenPGP digital signature

Re: Installation instructions.

[peter]

From: David 
Date: Fri, 4 Dec 2020 22:56:41 +1100
> 1) grub needs a partition table on the target device so it can do
> embedding, so the target device can't be an entire block device (eg
> sdx) it must be a partition[*] (eg sdxN where N is some natural number)
> 
> 2) And you probably need at least N=2 on an older machine.
> If there is sufficient RAM, the installer offers to load itself
> into RAM which frees up the partition where the iso is, so that it can
> be overwritten by the new install. 

My first step was to plan the partition layout and create it with 
gparted. ROOT, HOME & INSTLLR were formatted ext4.

(hd0,mdos1)  unused
(hd0,mdos2)  unused
(hd0,mdos3)  ROOT  /
(hd0,mdos4)  extended
(hd0,mdos5)  SWAP  swap
(hd0,mdos6)  HOME  /home
(hd0,mdos7)  INSTLLR

(iso, initrd, vmlinuz) are in INSTLLR.  There is no need to overwrite 
INSTLLR during the installation. INSTLLR can be joined onto /home 
later.

From: David 
Date: Sun, 6 Dec 2020 07:29:37 +1100
> > Thanks.  Well, the iso file simply wasn't present.
> 
> I don't understand this sentence. Do you mean you made a
> human error? Or something else?

Yes, my human error.  I omitted putting the iso in the folder before 
the last trial run yesterday.

> I suggest the use of priority=medium which allows you to
> choose which [*]partitions are searched for the iso, which might help.

That definitely helps.

The installer then gives the option to search for USB devices.  It 
gives no evidence of a hdd although it's running from one. (?)  In the 
snapshot of console 4, the last line reports "devices found: ''".  
Meaning "no devices found".
http://easthope.ca/FailedBootVrtConsole4.jpg

Then I put the iso on a SD card in a USB adapter.

The installer finds that iso.  Ie. boot from (iso, initrd, vmlinuz) in 
INSTLLR and let the installer search USB devices.  The iso in a USB 
connected device is found.  

Preliminary conclusion. The installer can be started from (hd0,msdos7) 
but the iso search fails to acknowledge existence of (hd0) and fails 
to find the iso in (hd0,msdos7).

Does the installer search algorithm work in the msdos extension? Not 
always.

Does it ever work on the extension?  Don't know yet. 

Regards,   ... P.

-- 
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Error apt

[latincom]

Pase Buster a Bullseye y tengo este error, probe lo recomendado, mas
desinstalar e instalar los paquetes mencionados, y no se corrige; alguien
sabe la solucion, para este tipo de errores?

You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 guile-2.2-libs : Depends: libgc1 (>= 1:7.4.2) but it is not installed
 gvfs-fuse : Depends: gvfs (= 1.46.1-1) but 1.38.1-5 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or
specify a solution).

Re: gestionnaire de fenêtres X11 pour grands écrans pour Debian

[Vincent Lefevre]

Salut,

C'est un peu vieux, mais je rattrape petit à petit...

On 2020-10-13 06:11:56 +0200, Basile Starynkevitch wrote:
> J'utilise Linux depuis 1993 et préfère la ligne de commandes. J'ai deux
> grand écrans sous Debian/Sid. La commande xdpyinfo | grep -i -4 screen donne
> notamment
> 
> > screen #0:
> >dimensions:5360x1440 pixels (1418x381 millimeters)

Moi:

screen #0:
  dimensions:7680x2160 pixels (814x229 millimeters)

(La taille en mm est complètement fausse, mais bon, c'est le nombre
de pixels qui compte.)

> Je cherche un gestionnaire de fenêtres X11 (X11 window manager) - ou
> probablement une configuration d'un tel gestionnaire de fenêtres (par
> exemple icewm, fvwm, ) qui:

J'utilise fvwm depuis 1995, et je n'ai pas changé avec ma nouvelle
config.

> 1. démarre aisément une commande que je tape, si possible via zsh et la
> complétion associée.

Euh... je ne vois pas le rapport avec le gestionnaire de fenêtres.

> 2. gère les touches volume son de mon clavier Corsair Gaming K66 (AZERTY)

Avec fvwm, on peut associer une commande à une touche. Par exemple,
j'ai ceci pour la luminosité de l'écran de mon portable (qui est
en fait éteint quand j'utilise mes 2 écrans 4K, mais peu importe,
c'est un exemple):

Key XF86MonBrightnessDown   A   A   Exec brightnessctl set 10-
Key XF86MonBrightnessUp A   A   Exec brightnessctl set +10

Évidemment, il faut que les touches soient supportées par le driver.
Mais cela n'a pas de rapport avec le gestionnaire de fenêtres.

> 3. limite dans tous les cas la taille maximale des fenêtres X11 à 3072x1024
> pixels.

Pourquoi?

En tout cas, fvwm semble pouvoir le faire:

  MaxWindowSize [ width [ p ] height [ p ] ] Tells fvwm the
  maximum width and height of a window. [...]

Mais je n'ai jamais testé (pas vraiment besoin en pratique, je crois
qu'il n'y a que xpdf qui a ouvert des fenêtres trop grandes sur certains
documents, peut-être à cause de ma config "Xpdf.initialZoom: 200").

> 4. démarre quelques logiciels au click droit menu (lxterminal, firefox,
> thunderbird)

On peut affecter un menu entièrement configurable à chacun des
boutons.

En fait, fvwm est bien configurable, avec une page man de 9000 lignes,
sans compter les 18 modules qui viennent avec.

> Je n'ai généralement pas besoin d'icônes desktop sur mon bureau. Je
> prefère très largement la ligne de commande.

Idem, surtout avec la puissance de zsh.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation instructions.

[David]

On Sun, 6 Dec 2020 at 11:18, Brian  wrote:
> On Sun 06 Dec 2020 at 08:07:30 +1100, David wrote:
> > On Sun, 6 Dec 2020 at 07:54, Brian  wrote:
> > > On Sun 06 Dec 2020 at 07:29:37 +1100, David wrote:
> > > > On Sun, 6 Dec 2020 at 06:57,  wrote:

> > > > > > I give their md5sums below so you can check we are using the same
> > > > > > files.

> > > > > Thanks.  Well, the iso file simply wasn't present.

> > > > I don't understand this sentence. Do you mean you made a
> > > > human error? Or something else?

> > > The OP is using an i386 version. We expect you are on amd64.

> > Err sorry, I'm still baffled by what is being said here.

> Inconsequential, and probably better left unsaid.

I hope so :)

I'm not arguing with you, just expressing wry amusement
at the random hints of information being supplied ...

Peter is complaining that he sees
["Failed to find an installer image"]

so if he writes "the iso file simply wasn't present" then that
would explain the complaint, case closed. Perhaps.

Re: Installation instructions.

[Brian]

On Sun 06 Dec 2020 at 08:07:30 +1100, David wrote:

> On Sun, 6 Dec 2020 at 07:54, Brian  wrote:
> > On Sun 06 Dec 2020 at 07:29:37 +1100, David wrote:
> > > On Sun, 6 Dec 2020 at 06:57,  wrote:
> 
> > > > > I give their md5sums below so you can check we are using the same
> > > > > files.
> 
> > > > Thanks.  Well, the iso file simply wasn't present.
> 
> > > I don't understand this sentence. Do you mean you made a
> > > human error? Or something else?
> 
> > The OP is using an i386 version. We expect you are on amd64.
> 
> Err sorry, I'm still baffled by what is being said here.

It was a data point for those following this thread. I noted the md5sum
of the ISO file: As I said:

  > That's not the problem, of course.

Inconsequential, and probably better left unsaid.

-- 
Brian.

Re: Installation instructions.

[David]

On Sun, 6 Dec 2020 at 08:35, John Boxall  wrote:
> On 2020-12-05 4:07 p.m., David wrote:

> > I have both i386 and amd64 machines available to test, and I'm
> > using i386 when trying to assist Peter.

> In your testing have you been able to cleanly boot and run the installer
> through to completion, whether i386 or amd64? I have some results from a
> buster amd64 VirtualBox guest, but it isn't clean (kernel mismatch), but
> the install does progress. I will be testing on bare metal soon-ish.

Hi John,

Yes these days stable always works for me on actual hardware i386 and
amd64.

Due to lack of playtime I haven't done much with testing/unstable
releases or the testing versions of debian-installer, but that's where
I'm headed (if I wasn't too busy with too many projects).

With those development suites I guess mismatches between
installer/vmlinuz/initrd might be more likely. But stable should work
unless there are occasional bugs, it can happen when kernels change.

When I first tried this years ago I experienced the same problem as
Peter. Which was irritating, because on old hardware, removable media
installs can be very slow. I like fast installs, so I wanted to find a
better way.

My approach now is to create a very flexible setup on each machine,
disks these days are so huge that there's plenty of space. I use 4
primary partitions with an msdos partition table. Three of them are 12
GB and the fourth is much bigger consuming the rest of the drive using
LUKS and LVM.

The 12GB boot partition is big enough to hold the boot files of many
different installs regardless if outside or inside the LUKS/LVM, plus
however many different installation iso images that I want to play
with.

I do each install without a separate boot, and then move the boot images
to the boot partition and symlink to them. This keeps all the kernels
and initrds and installation ISOs on their own partition. Sometimes
an initrd from one install can be helpful to use to fix another. Another
benefit of this is that the grub of every install can do whatever stupid things
it wants to its grub.cfg without corrupting my actual grub.cfg that
boots the system, which I manage manually and keep simple without all
the overcomplicated default stuff makes the default grub.cfg hard to read.

The other two 12GB primary partitions are just throwaway play spaces
which are sometimes helpful if convincing the installer to install
into LUKS/LVM gets tricky, I can just do it outside and then move it
inside afterward if I want to keep it.

I also use 'approx' on another machine on my LAN as a repo cache which
speeds things up too.

All this gives me the ability to easily test these things on actual
hardware. I'm not claiming my way is "best" just sharing how I do it
and why.

So these days I expect hd-media install to work every time. And when
it doesn't then I'm curious to understand why. So my interest here is
purely academic curiosity to better understand something that I didn't
know how to troubleshoot when it was happening to me years ago. I
haven't tried VM's for a while but if I did I would use kvm not
VirtualBox.

Re: [Emc-users] buster warning

[Gene Heskett]

On Saturday 05 December 2020 15:47:02 Felix Miata wrote:

> Gene Heskett composed on 2020-12-05 11:52 (UTC-0500):
> > On Saturday 05 December 2020 11:11:40 Tixy wrote:
> >> On Sat, 2020-12-05 at 10:35 -0500, Gene Heskett wrote:
> >> > And while it is working, there still is not a /dev/enp1s0
> >> > to be found except in an "ip a" output.
> >>
> >> I'm sure "ip a" mentions 'enp1s0' not '/dev/enp1s0'.
> >
> > Correct, my short term memory isn't that error free any more.
>
> Do you remember eth0? Would you like it back? I always have it (lots
> of PCs). To get it I use option #3 from the bottom of:
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkIn
>terfaceNames/

That might be handy Felix, but is unrelated to the problem at hand.

What I found when this occurred at buster install time, and it took this 
to remind me of a day wasted when I installed buster, was what appears 
to be a race condition between avahi assigning an absolutely bogus 
routing table in the 169.xx.xx.xx range, and ifup trying to read the 
interfaces file to get the proper route. Or something along those lines.

So The fix is brute force by rm'ing the avahi-daemon which stops all that 
BS and does not generate a logable error when whatever cals it can't 
find it.

Works until the next reboot after the avahi-daemon has been replaced by 
the package manager, in this case synaptic. So this time I got brave and 
had synaptic remove that piece crap again, which also removed a dns 
related library.  But since all that is specced in the /e/n/i file, and 
I use a hosts file for local address resolution, so for me its a total 
never mind. Since cups does its own thing anyway, I have never figured 
out ANY justification for wasting drive space with any of the many avahi 
related bits and pieces.  They are a headache waiting in the wings, and 
I fail to see the justification for jamming that crap down the users 
throats. Simply put, if it gets a chance to run, it gets it WRONG. And 
not even root can reassign a good route, I've literally spent days 
trying. It goes thru the motions, but look 5 seconds later and the wrong 
address is back in the routing table.

This may not be 100% correct, may not even be the right theory, but it 
sure fixes the problem it has created. And its been a headache here 
since Jessie.

And while you haven't been abusive about it, I am plumb put out by the 
denigrating and downright insulting remarks aimed at me for using a 
hosts file for local dns. For me, setting up a dhcp daemon for local 
address resolution is just more system bloat, wasted cpu cycles etc.

Thanks Felix, stay safe and well now.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Apt dependencies

[Ángel]

On 2020-12-05 at 18:48 +, Joe wrote:
> What does the >= sign mean as regards dependencies? I took it to mean
> 'this version or later', but apparently not.

It does.

> 
> I've had a logjam on sid for a while now, so I thought I'd
> investigate.
> 
> debfoster cannot be upgraded because of a dependency on guile-2.0-
> libs.
> 
> guile-2.0-libs depends on libgc1c2 (>= 1:7.2d) but it is not
> installable.
> 
> Currently installed version of libgc1c2 is 1:7.6.4-0.4.
> 
> Why does this not satisfy '>= 1:7.2d'?

It does:

$ dpkg --compare-versions 1:7.6.4-0.4 '>=' 1:7.2d
$ echo $?
0


The issue seem to lie in that there are two different packages
involved:
guile-2.0-libs depends on libgc1c2 (>= 1:7.2d)
debfoster depends on libgc1 (>= 1:7.2d)
libgc1 conflicts and replaces libgc1c2

I think guile-2.0-libs would need to be changed to depend on libgc1,
but that will probably also require a rebuild, to link with the new
library.

Fwd: Upcoming stable point release (10.7)

[Juan Lavieri]

Para conocimiento público.

 Mensaje reenviado 
Asunto: Upcoming stable point release (10.7)
Resent-Date: Mon,  2 Nov 2020 21:08:28 + (UTC)
Resent-From: debian-secur...@lists.debian.org
Fecha: Mon, 02 Nov 2020 21:07:27 +
De: Adam D. Barratt 
Para: debian-rele...@lists.debian.org

Hi,

The next point release for "buster" (10.7) is scheduled for Saturday
December 5th. Processing of new uploads into buster-proposed-updates
will be frozen during the preceding weekend.

Regards,

Adam


--
Errar es de humanos, pero es mas humano culpar a los demás

Re: Replying. [was Re: AMD GPU Sea Islands Problem]

[rhkramer]

On Saturday, December 05, 2020 04:08:14 PM Andrei POPESCU wrote:
> In general 'Reply' defaults to Sender, with a few exceptions:
> 
>  1. A smart mailer that detects the message is from a mailing list, most
>  likely configurable (e.g. Claws Mail already mentioned, probably
>  Sylpheed as well)

and kmail (at least in the version in Wheezy ;-)

Re: Installation instructions.

[John Boxall]

On 2020-12-05 4:07 p.m., David wrote:


I have both i386 and amd64 machines available to test, and I'm
using i386 when trying to assist Peter.


David,

In your testing have you been able to cleanly boot and run the installer 
through to completion, whether i386 or amd64? I have some results from a 
buster amd64 VirtualBox guest, but it isn't clean (kernel mismatch), but 
the install does progress. I will be testing on bare metal soon-ish.


--
Regards,

John Boxall

Re: AMD GPU Sea Islands Problem

[Felix Miata]

Guyenne Tsui composed on 2020-12-05 14:11 (UTC):

> Whenever I try to do any form rendering using the dGPU, the software 
> just hangs and become inresponsive. My kernel based on `uname -v` is '#1 
> SMP Debian 5.9.9-1 (2020-11-19)'.

What is "form rendering"? Which Sea Islands do you have? Which Debian are you
using? Which DDX driver are you using? Do you have in your grub stanzas
radeon.cik_support=0 amdgpu.cik_support=1 ???

How might I try to reproduce this with my Sea Islands IGP?
# inxi -GISay
System:
  Host: asa88 Kernel: 5.9.0-4-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.0
  parameters:...noresume mitigations=auto consoleblank=0
  radeon.cik_support=0 amdgpu.cik_support=1
  Desktop: Trinity R14.0.10 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM
  Distro: Debian GNU/Linux bullseye/sid
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu
  v: kernel alternate: radeon bus ID: 00:01.0 chip ID: 1002:130f
  Display: x11 server: X.Org 1.20.8 driver: modesetting display ID: :0
  screens: 1
  Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (16.0x10.0")
  s-diag: 479mm (18.9")
  Monitor-1: DP-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8")
  diag: 612mm (24.1")
  OpenGL: renderer: AMD KAVERI (DRM 3.39.0 5.9.0-4-amd64 LLVM 11.0.0)
  v: 4.6 Mesa 20.2.3 direct render: Yes
Info:...Shell: Bash v: 5.1.0-rc3 running in: konsole inxi: 3.1.0
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Installation instructions.

[David]

On Sun, 6 Dec 2020 at 08:09,  wrote:

> Added DebianInstaller FAQ 29.
> https://wiki.debian.org/DebianInstaller/FAQ#Q:_Running_the_installer_from_an_iso_file_on_a_hdd_...

> If someone improves it or a maintainer incorporates the point into the
> official instructions, I won't object.

Thanks for your contribution but one nitpick: I think that linking to
an i386 specific directory ("hd-media"directory) is a bad idea. Most
people aren't using i386. So you might want to reconsider how you've
presented that information, or not be surprised when that link gets
removed by someone.

Re: Installation instructions.

[David]

On Sun, 6 Dec 2020 at 06:41, Brian  wrote:
> On Fri 04 Dec 2020 at 22:56:41 +1100, David wrote:

> > 2) And you probably need at least N=2 on an older machine.
> > If there is sufficient RAM, the installer offers to load itself
> > into RAM which frees up the partition where the iso is, so that it can
> > be overwritten by the new install. If the RAM is insufficient this is
> > not possible, so the partition where the iso is must be specified
> > "do not use" because it is mounted and in use by the installer, so
> > the new install must be done into another partition. I would
> > deal with this by converting our installer boot partition to a /boot
> > partition manually after the install is complete and rebooted
> > into the new partition.

> I have been using the hd-media installation method with preseeding
> at priority-high for many years and never encountered this. It turns
> out it was introduced as a consequence of #868900:

>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868900

> The default for iso-scan/copy_iso_to_ram is false, which is why I
> never saw it. Thanks for drawing the option to our attention.

> Choosing "true" doesn't suit me because hd-media is then unmounted.
> All the files I use during an installation, including the critical
> preseed.cfg, then become unavailable.

Thanks again for sharing interesting info about different work
methods.

Re: Installation instructions.

[peter]

From: David 
Date: Fri, 4 Dec 2020 07:20:19 +1100
> The instructions can be modified ... 

Added DebianInstaller FAQ 29.
https://wiki.debian.org/DebianInstaller/FAQ#Q:_Running_the_installer_from_an_iso_file_on_a_hdd_...

If someone improves it or a maintainer incorporates the point into the 
official instructions, I won't object.

> ... submit a patch to their maintainer.

Editing first hand seems to work better.  A few examples.
https://en.wikibooks.org/wiki/X86_Assembly
https://en.wikibooks.org/wiki/X86_Disassembly
https://en.wikibooks.org/wiki/Shelf:Computer_software

Regards,... P.
 
-- 
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Replying. [was Re: AMD GPU Sea Islands Problem]

[Andrei POPESCU]

On Sb, 05 dec 20, 12:20:02, Kenneth Parker wrote:
> 
> I am also on Gmail.  When I click (or tap) on Reply, it invariably wants me
> to send the Reply to the individual who sent the email, as opposed to the
> Debian Users List.  So one additional task for me is to edit the "To"
> field, so that it specifically goes to the List.
> 
> Is this, generally an Issue, or is it specific to Gmail?

In general 'Reply' defaults to Sender, with a few exceptions:

 1. A smart mailer that detects the message is from a mailing list, most 
 likely configurable (e.g. Claws Mail already mentioned, probably 
 Sylpheed as well)

 2. A Reply-To is set, either by the list[1] or by the Sender

(maybe others I forgot or am not aware of)

For mailing lists one should follow the rules and conventions of the 
corresponding list, e.g. on Debian lists replies should go to the list 
only, unless explicitly requested otherwise.

If your mail client doesn't properly support mailing lists one can 
either 'Reply' and replace the Sender's address with the list address or 
use 'Reply-to-All' and delete all unnecessary addresses.

[1] also known as reply-to munging

https://unicom.crosenthal.com/pw/reply-to-harmful.html

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Installation instructions.

[David]

On Sun, 6 Dec 2020 at 07:54, Brian  wrote:
> On Sun 06 Dec 2020 at 07:29:37 +1100, David wrote:
> > On Sun, 6 Dec 2020 at 06:57,  wrote:

> > > > I give their md5sums below so you can check we are using the same
> > > > files.

> > > Thanks.  Well, the iso file simply wasn't present.

> > I don't understand this sentence. Do you mean you made a
> > human error? Or something else?

> The OP is using an i386 version. We expect you are on amd64.

Err sorry, I'm still baffled by what is being said here.

I have both i386 and amd64 machines available to test, and I'm
using i386 when trying to assist Peter.

On Fri, 4 Dec 2020 at 20:00, David  wrote:

> I give their md5sums below so you can check we are using the same
> files.

> $ md5sum *iso
> f327723426dc90a4daaf1609595d8306  debian-10.6.0-i386-netinst.iso

It's the md5sum of an i386 iso file. What's that got to do with "you are
on amd64"? Sorry if I'm being dense, it's early morning is my excuse
for today :)

Re: Installation instructions.

[Brian]

On Sun 06 Dec 2020 at 07:29:37 +1100, David wrote:

> On Sun, 6 Dec 2020 at 06:57,  wrote:
> 
> > > I give their md5sums below so you can check we are using the same
> > > files.
> >
> > Thanks.  Well, the iso file simply wasn't present.
> 
> I don't understand this sentence. Do you mean you made a
> human error? Or something else?

The OP is using an i386 version. We expect you are on amd64.

That's not the problem, of course.

-- 
Brian.

Re: [Emc-users] buster warning

[Felix Miata]

Gene Heskett composed on 2020-12-05 11:52 (UTC-0500):

> On Saturday 05 December 2020 11:11:40 Tixy wrote:
 
>> On Sat, 2020-12-05 at 10:35 -0500, Gene Heskett wrote:

>> > And while it is working, there still is not a /dev/enp1s0
>> > to be found except in an "ip a" output.

>> I'm sure "ip a" mentions 'enp1s0' not '/dev/enp1s0'.
 
> Correct, my short term memory isn't that error free any more.

Do you remember eth0? Would you like it back? I always have it (lots
of PCs). To get it I use option #3 from the bottom of:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Installation instructions.

[David]

On Sun, 6 Dec 2020 at 06:57,  wrote:

> > I give their md5sums below so you can check we are using the same
> > files.
>
> Thanks.  Well, the iso file simply wasn't present.

I don't understand this sentence. Do you mean you made a
human error? Or something else?

> Files match but the search still failed.

Please report the results of a manual search in the installer
as I suggested previously here:

On Fri, 4 Dec 2020 at 22:56, David  wrote:

> I suggest the use of priority=medium which allows you to
> choose which [*]partitions are searched for the iso, which might help.

See the rest of that message for more details.

Please report what *partitions* you see offered in the menu, and what
happens when you try them, and the logfile after doing all of that.

Re: Installation instructions.

[Brian]

On Sat 05 Dec 2020 at 11:19:17 -0800, pe...@easthope.ca wrote:

> http://easthope.ca/FailedBootVrtConsole4.jpg
> 
> Apologies for the snapshot but it serves the purpose.

It doesn't serve any purpose. It is completely useless.

-- 

Brian.

Re: Installation instructions.

[peter]

> I give their md5sums below so you can check we are using the same
> files.

Thanks.  Well, the iso file simply wasn't present.  Now I have this.

root@joule:/mnt# md5sum !$
md5sum {d*,i*,v*}
f327723426dc90a4daaf1609595d8306  debian-10.6.0-i386-netinst.iso
d3f41e1b683fa87cca189f8595b80a7c  initrd.gz
b30966bc534a606bb8dafab40e106ca9  vmlinuz

> $ md5sum *iso
> f327723426dc90a4daaf1609595d8306  debian-10.6.0-i386-netinst.iso
> $ md5sum *
> d3f41e1b683fa87cca189f8595b80a7c  initrd.gz
> b30966bc534a606bb8dafab40e106ca9  vmlinuz

Files match but the search still failed.

> I suggest to check the installer log just after the search fails.
> The method of doing that is here:
> https://www.debian.org/releases/stable/i386/ch06s03.en.html#di-miscellaneous

http://easthope.ca/FailedBootVrtConsole4.jpg

Apologies for the snapshot but it serves the purpose.

To me, the most relevant notes are "missing firmware" and "devices found: ''".
An old magnetic HDD should be detected by a driver without fancy firmware. 

That leaves "devices found: ''" while files are in (hd0,msdos7).  Does 
the search algorithm work for an extended part?  Ref. 
https://en.wikipedia.org/wiki/Disk_partitioning#Extended_partition

Depending on replies, I might try the files in (hd1,1).

Thx, ... P.



-- 
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Installation instructions.

[Brian]

On Fri 04 Dec 2020 at 22:56:41 +1100, David wrote:

> 2) And you probably need at least N=2 on an older machine.
> If there is sufficient RAM, the installer offers to load itself
> into RAM which frees up the partition where the iso is, so that it can
> be overwritten by the new install. If the RAM is insufficient this is
> not possible, so the partition where the iso is must be specified
> "do not use" because it is mounted and in use by the installer, so
> the new install must be done into another partition. I would
> deal with this by converting our installer boot partition to a /boot
> partition manually after the install is complete and rebooted
> into the new partition.

I have been using the hd-media installation method with preseeding
at priority-high for many years and never encountered this. It turns
out it was introduced as a consequence of #868900:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868900

The default for iso-scan/copy_iso_to_ram is false, which is why I
never saw it. Thanks for drawing the option to our attention.

Choosing "true" doesn't suit me because hd-media is then unmounted.
All the files I use during an installation, including the critical
preseed.cfg, then become unavailable.

> 3) The grub.cfg I used was
> 
> menuentry 'Debian Installer' {
>   insmod part_msdos
>   insmod ext4
>   set root='(hd0,msdos1)'
>   linux /vmlinuz priority=medium
>   initrd /initrd.gz
> }

My grub.cfg is

menuentry 'Debian Installer' {  
 
   linux /boot/vmlinuz priority=medium
   initrd /boot/initrd.gz   
   
}

I think this would make "set root='(hd0,msdos1)'" superfluous. I wonder
whether the other two directives are defaults for GRUB?

-- 
Brian.

Re: Replying. [was Re: AMD GPU Sea Islands Problem]

[Charles Curley]

On Sat, 5 Dec 2020 12:20:02 -0500
Kenneth Parker  wrote:

> I am also on Gmail.  When I click (or tap) on Reply, it invariably
> wants me to send the Reply to the individual who sent the email, as
> opposed to the Debian Users List.  So one additional task for me is
> to edit the "To" field, so that it specifically goes to the List.
>
> Is this, generally an Issue, or is it specific to Gmail?

It can be an issue on other mail readers as well. Many will let you
configure that. Claws-mail will even let you configure it on a
per-directory basis.

Claws-mail also has menu entries for reply to sender, all, and mailing
list.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Apt dependencies

[Joe]

What does the >= sign mean as regards dependencies? I took it to mean
'this version or later', but apparently not.

I've had a logjam on sid for a while now, so I thought I'd investigate.

debfoster cannot be upgraded because of a dependency on guile-2.0-libs.

guile-2.0-libs depends on libgc1c2 (>= 1:7.2d) but it is not
installable.

Currently installed version of libgc1c2 is 1:7.6.4-0.4.

Why does this not satisfy '>= 1:7.2d'?

-- 
Joe

Re: Replying. [was Re: AMD GPU Sea Islands Problem]

[Tixy]

On Sat, 2020-12-05 at 12:20 -0500, Kenneth Parker wrote:
> I am also on Gmail.  When I click (or tap) on Reply, it invariably wants me
> to send the Reply to the individual who sent the email, as opposed to the
> Debian Users List.  So one additional task for me is to edit the "To"
> field, so that it specifically goes to the List.
> 
> Is this, generally an Issue, or is it specific to Gmail?

It's probably more a general issue. But how these things are handled
will be down to the program or web interface you are using to access
your mail, not the email service. The email program I use has two
options, reply to sender (Ctrl+R) and reply to list (CTrl+L). I'm sure
that would work with Gmail if I used that for my email service, but if
you use the Gmail web interface, or another email program, they may not
have a reply-to-list option.

-- 
Tixy

Re: [Emc-users] buster warning

[Michael Stone]

On Sat, Dec 05, 2020 at 11:52:32AM -0500, Gene Heskett wrote:

On Saturday 05 December 2020 11:11:40 Tixy wrote:

Have you ever seen network interfaces appear under /dev ?
They don't appear there on my machines...

They used to, 


No, they didn't. Network interfaces have traditionally been a major 
exception to the unix "everything is a file" philosophy.

Re: Replying. [was Re: AMD GPU Sea Islands Problem]

[Kenneth Parker]

On Sat, Dec 5, 2020, 12:05 PM Charles Curley <
charlescur...@charlescurley.com> wrote:

> On Sat, 5 Dec 2020 14:11:02 +
> Guyenne Tsui  wrote:
>
> > Also, I have no idea how to reply to a thread on a mailing list so it
> > would be practical if you teach me how. I use Gmail. I even installed
> > Thunderbird as according to Debian Wiki on Mailing Lists but still no
> > idea how to reply to people.
>
> Exactly how you reply to a thread depends on your mail reader. In
> general, just reply to an appropriate email in a thread. Control-R is a
> common shortcut for the purpose. Your mail reader should pick up the
> information necessary so the rest of us will see your reply as part of
> the thread.
>
> Two thoughts on netiquette...
>
> Trim the text to which you are replying. Get rid of text not
> immediately relevant to your reply. Gmail hides that for you, so you
> don't see it. Other mail readers don't hide it. I did so above.
>
> You put two separate subjects (your GPU problem and replying) into the
> same email. This means that replies to the two separate subjects will be
> interlaced, to everyone's confusion. A partial remedy is for a
> responder to change the subject line as appropriate, but even that has
> problems. A better approach is to start with a separate email for each
> subject.
>

I am also on Gmail.  When I click (or tap) on Reply, it invariably wants me
to send the Reply to the individual who sent the email, as opposed to the
Debian Users List.  So one additional task for me is to edit the "To"
field, so that it specifically goes to the List.

Is this, generally an Issue, or is it specific to Gmail?

-- 
> Does anybody read signatures any more?
>

Occasionally.  :-)

https://charlescurley.com
> https://charlescurley.com/blog/


Thanks!

Kenneth Parker

>
>

Replying. [was Re: AMD GPU Sea Islands Problem]

[Charles Curley]

On Sat, 5 Dec 2020 14:11:02 +
Guyenne Tsui  wrote:

> Also, I have no idea how to reply to a thread on a mailing list so it 
> would be practical if you teach me how. I use Gmail. I even installed 
> Thunderbird as according to Debian Wiki on Mailing Lists but still no 
> idea how to reply to people.

Exactly how you reply to a thread depends on your mail reader. In
general, just reply to an appropriate email in a thread. Control-R is a
common shortcut for the purpose. Your mail reader should pick up the
information necessary so the rest of us will see your reply as part of
the thread.

Two thoughts on netiquette...

Trim the text to which you are replying. Get rid of text not
immediately relevant to your reply. Gmail hides that for you, so you
don't see it. Other mail readers don't hide it. I did so above.

You put two separate subjects (your GPU problem and replying) into the
same email. This means that replies to the two separate subjects will be
interlaced, to everyone's confusion. A partial remedy is for a
responder to change the subject line as appropriate, but even that has
problems. A better approach is to start with a separate email for each
subject.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: [Emc-users] buster warning

[Gene Heskett]

On Saturday 05 December 2020 11:11:40 Tixy wrote:

> On Sat, 2020-12-05 at 10:35 -0500, Gene Heskett wrote:
> > And while it is working, there still is not a /dev/enp1s0
> > to be found except in an "ip a" output.
>
> I'm sure "ip a" mentions 'enp1s0' not '/dev/enp1s0'.

Correct, my short term memory isn't that error free any more.
 
> Have you ever seen network interfaces appear under /dev ?
> They don't appear there on my machines...
>
They used to, and that has always been the first place I check when the 
net doesn't come up. What I am not sure about is which version it got 
changed in. Its been a while though, as I note the one wheezy install I 
still have running on another copy of that same hardware, is using eth0 
but its not in the /dev/net tree either. So I'm the one out of date it 
seems.

The whole point is that the most recent V 2.8 LinuxCNC install hasn't 
pinned the kernel, and that it didn't work again until I had rebooted 
to -rt11 from the newer -rt13, and its now works correctly for all 
versions tried, but didn't at 8:15 local time this morning.

There should be a reason, but I've not found it.
  
> # find /dev -name enp2s0
>
> # find /sys -name enp2s0
> /sys/class/net/enp2s0
> /sys/devices/pci:00/:00:1c.3/:02:00.0/net/enp2s0
>
> # ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 Dec  5 16:06 enp2s0 -> 
> ../../devices/pci:00/:00:1c.3/:02:00.0/net/enp2s0
> lrwxrwxrwx 1 root root 0 Dec  5 16:06 lo ->
> ../../devices/virtual/net/lo lrwxrwxrwx 1 root root 0 Dec  5 16:06
> wlp1s0 ->
> ../../devices/pci:00/:00:1c.0/:01:00.0/net/wlp1s0


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: [Emc-users] buster warning

[Tixy]

On Sat, 2020-12-05 at 10:35 -0500, Gene Heskett wrote:
> And while it is working, there still is not a /dev/enp1s0
> to be found except in an "ip a" output.

I'm sure "ip a" mentions 'enp1s0' not '/dev/enp1s0'.
Have you ever seen network interfaces appear under /dev ?
They don't appear there on my machines...

# find /dev -name enp2s0

# find /sys -name enp2s0
/sys/class/net/enp2s0
/sys/devices/pci:00/:00:1c.3/:02:00.0/net/enp2s0

# ls -l /sys/class/net/
total 0
lrwxrwxrwx 1 root root 0 Dec  5 16:06 enp2s0 ->  
../../devices/pci:00/:00:1c.3/:02:00.0/net/enp2s0
lrwxrwxrwx 1 root root 0 Dec  5 16:06 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 Dec  5 16:06 wlp1s0 -> 
../../devices/pci:00/:00:1c.0/:01:00.0/net/wlp1s0

-- 
Tixy

Re: [Emc-users] buster warning

[Gene Heskett]

On Saturday 05 December 2020 09:18:06 Gene Heskett wrote:

> On Saturday 05 December 2020 08:46:06 Gene Heskett wrote:
> > Greetings all;
> >
> > I just updated my one wintel/buster install, on a D525-MW mobo in an
> > OAK box, which replaced the rt kernel with a new version of
> > 4.19.0-rt13 and when synaptic was done, issued a sudo reboot to
> > reboot to it...
> >
> > 10 minutes later it is still not pingable. I've not yet had a chance
> > to go check it physically as its up the hill in a separate building.
> >
> > But I thought you with uptodate buster installs might want to know
> > something could be wrong.
> >
> > I'll report more when I know more.
>
> When I got there and turned on the monitor, is was waiting for someone
> it knew to log in. So I logged in and checked the new linuxcnc, seemed
> to be ok. But arriving back in this chair, it has no network. CCing
> debian- user since I assume the new kernel came from there. So I'll go
> back and see whats wrong with the ifup's. More later.

Went back and rebooted it to the last 3 rt kernels, no network for -rt12.

Got normal net from -rt11, reboot back to -rt12, works, ditto -rt13 
works, and the default let it time out works.

WTH. Come back to house again, ssh now works but keys are wrong, login 
anyway.

reboot it from here, ping is back in around 40 secs, takes an ssh login a 
few seconds later. Everything seems normal.  Go back up, kill the power 
to the monitor and the lathe this machine controls, come back and reboot 
it again. Works. WTH? I am glad, but I've also made a few trips up the 
hill on 86 yo pins and wasted at least 2 hours doing it. And I did not 
touch anything with an editor.  And while it is working, there still is 
not a /dev/enp1s0 to be found except in an "ip a" output. Or 
in /e/n/interfaces.  udev makes this stuff up out of whole cloth now?

Call me bumfuzzled, this does not make sense.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Installation instructions.

[Brian]

On Fri 04 Dec 2020 at 22:56:41 +1100, David wrote:

> On Fri, 4 Dec 2020 at 20:00, David  wrote:
> 
> > Looking now, I can confirm that I did a Debian installation here on 20
> > Oct 2020 using these files. There is no doubt because they are still
> > on the hard drive.
> 
> Actually it was 14 Oct, just for the record :)
> 
> I have just now done another fresh install, this time using the same 3 files
> on a blank hard drive, it worked to completion without your complaint
> occurring.
> 
> Due to actually going through the entire procedure on a blank drive
> so as to catch any unanticipated hiccups due to the process being
> different to my usual one, I can add some more thoughts about that:
> 
> 1) grub needs a partition table on the target device so it can do
> embedding, so the target device can't be an entire block device (eg
> sdx) it must be a partition[*] (eg sdxN where N is some natural number)

Indeed.
 
> 2) And you probably need at least N=2 on an older machine.
> If there is sufficient RAM, the installer offers to load itself
> into RAM which frees up the partition where the iso is, so that it can
> be overwritten by the new install. If the RAM is insufficient this is
> not possible, so the partition where the iso is must be specified
> "do not use" because it is mounted and in use by the installer, so
> the new install must be done into another partition. I would
> deal with this by converting our installer boot partition to a /boot
> partition manually after the install is complete and rebooted
> into the new partition.

Suppose vmlinuz, initrd.gz, grub.cfg and the ISO are on a USB stick. The
stick can be booted and the installation done to a hard drive, which I
would guess is common place to put it. This avoids having to consider
the memory situation or mess with the installation afterwards.

Those users who cannot boot from a USB stick can have vmlinuz, initrd.gz
and grub.cfg on the hard disk and the ISO on a USB stick, where it should
found.

-- 
Brian.

> 
> 3) The grub.cfg I used was
> 
> menuentry 'Debian Installer' {
>   insmod part_msdos
>   insmod ext4
>   set root='(hd0,msdos1)'
>   linux /vmlinuz priority=medium
>   initrd /initrd.gz
> }
> 
> I suggest the use of priority=medium which allows you to
> choose which [*]partitions are searched for the iso, which might help.
> Once the problem is resolved you can remove that or
> change it to what you prefer: low or high (which eg specifies
> that only a few high priority questions are asked during install).
> 

Re: [Emc-users] buster warning

[Gene Heskett]

On Saturday 05 December 2020 09:18:06 Gene Heskett wrote:

> On Saturday 05 December 2020 08:46:06 Gene Heskett wrote:
> > Greetings all;
> >
> > I just updated my one wintel/buster install, on a D525-MW mobo in an
> > OAK box, which replaced the rt kernel with a new version of
> > 4.19.0-rt13 and when synaptic was done, issued a sudo reboot to
> > reboot to it...
> >
> > 10 minutes later it is still not pingable. I've not yet had a chance
> > to go check it physically as its up the hill in a separate building.
> >
> > But I thought you with uptodate buster installs might want to know
> > something could be wrong.
> >
> > I'll report more when I know more.
>
> When I got there and turned on the monitor, is was waiting for someone
> it knew to log in. So I logged in and checked the new linuxcnc, seemed
> to be ok. But arriving back in this chair, it has no network. CCing
> debian- user since I assume the new kernel came from there. So I'll go
> back and see whats wrong with the ifup's. More later.
>
I went went back up the hill and checked /e/n/interfaces, no change 
there, supposed to be enps01, tried to restart it, failed, there is 
no /dev/enps01. or /dev/net/enps01.  systemctl says the tun descriptor 
in /dev/net "is in a bad state".

So I'm going back yet again to see if the grub menu still has the older 
rt kernel.


> > Cheers, Gene Heskett
>
> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

AMD GPU Sea Islands Problem

[Guyenne Tsui]

Hello debian-users,

Whenever I try to do any form rendering using the dGPU, the software 
just hangs and become inresponsive. My kernel based on `uname -v` is '#1 
SMP Debian 5.9.9-1 (2020-11-19)'.


Also, I have no idea how to reply to a thread on a mailing list so it 
would be practical if you teach me how. I use Gmail. I even installed 
Thunderbird as according to Debian Wiki on Mailing Lists but still no 
idea how to reply to people.


I tried using `sudo dmesg | grep -E 'radeon'` to see what is wrong and 
this is what it shows:
[ 1046.029454] radeon :01:00.0: WB enabled
[ 1046.029457] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x8c00
[ 1046.029458] radeon :01:00.0: fence driver on ring 1 use gpu addr 
0x8c04
[ 1046.029459] radeon :01:00.0: fence driver on ring 2 use gpu addr 
0x8c08
[ 1046.029460] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x8c0c
[ 1046.029461] radeon :01:00.0: fence driver on ring 4 use gpu addr 
0x8c10
[ 1056.474247] radeon :01:00.0: ring 0 stalled for more than 10096msec
[ 1056.474264] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1056.474296] radeon :01:00.0: ring 4 stalled for more than 10096msec
[ 1056.474303] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1056.986262] radeon :01:00.0: ring 4 stalled for more than 10608msec
[ 1056.986278] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1056.986310] radeon :01:00.0: ring 0 stalled for more than 10608msec
[ 1056.986318] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1057.370362] Asynchronous wait on fence radeon:radeon.gfx:10 timed out 
(hint:submit_notify [i915])
[ 1057.498258] radeon :01:00.0: ring 0 stalled for more than 11120msec
[ 1057.498272] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1057.498304] radeon :01:00.0: ring 4 stalled for more than 11120msec
[ 1057.498310] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1058.010280] radeon :01:00.0: ring 4 stalled for more than 11632msec
[ 1058.010296] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1058.010328] radeon :01:00.0: ring 0 stalled for more than 11632msec
[ 1058.010335] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1058.522291] radeon :01:00.0: ring 0 stalled for more than 12144msec
[ 1058.522307] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1058.522339] radeon :01:00.0: ring 4 stalled for more than 12144msec
[ 1058.522346] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1059.034298] radeon :01:00.0: ring 4 stalled for more than 12656msec
[ 1059.034314] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1059.034346] radeon :01:00.0: ring 0 stalled for more than 12656msec
[ 1059.034354] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1059.546317] radeon :01:00.0: ring 0 stalled for more than 13168msec
[ 1059.546333] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1059.546366] radeon :01:00.0: ring 4 stalled for more than 13168msec
[ 1059.546373] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1060.058325] radeon :01:00.0: ring 4 stalled for more than 13680msec
[ 1060.058342] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1060.058374] radeon :01:00.0: ring 0 stalled for more than 13680msec
[ 1060.058382] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1060.570345] radeon :01:00.0: ring 0 stalled for more than 14192msec
[ 1060.570364] radeon :01:00.0: GPU lockup (current fence id 
0x000e last fence id 0x0011 on ring 0)
[ 1060.570397] radeon :01:00.0: ring 4 stalled for more than 14192msec
[ 1060.570405] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 0x0013 on ring 4)
[ 1061.082329] radeon :01:00.0: ring 4 stalled for more than 14704msec
[ 1061.082343] radeon :01:00.0: GPU lockup (current fence id 
0x0011 last fence id 

Re: [Emc-users] buster warning

[Gene Heskett]

On Saturday 05 December 2020 08:46:06 Gene Heskett wrote:

> Greetings all;
>
> I just updated my one wintel/buster install, on a D525-MW mobo in an
> OAK box, which replaced the rt kernel with a new version of
> 4.19.0-rt13 and when synaptic was done, issued a sudo reboot to reboot
> to it...
>
> 10 minutes later it is still not pingable. I've not yet had a chance
> to go check it physically as its up the hill in a separate building.
>
> But I thought you with uptodate buster installs might want to know
> something could be wrong.
>
> I'll report more when I know more.
>
When I got there and turned on the monitor, is was waiting for someone it 
knew to log in. So I logged in and checked the new linuxcnc, seemed to 
be ok. But arriving back in this chair, it has no network. CCing debian- 
user since I assume the new kernel came from there. So I'll go back and 
see whats wrong with the ifup's. More later.

> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Emergency mode when root account locked

[Marco Möller]

On 04.12.20 13:00, deandre wrote:

Hi

My problem is when I try to boot up deepin(Debian 10 buster) I get the 
message “cannot open access to console, the root account is locked See 
sulogin(8) man for more details” and after I press Enter it continues to 
give me the same message, at this point I’m not really sure what to do.


Sent from Mail  for 
Windows 10




If the root account login is deactivated, then the rescue console 
(rescue.target or emergency.target) usually cannot be entered.
However, in the grub menu it can still be forced the launch o a shell as 
root, even if the root account was deactivated, by adding the following 
boot parameter:


~
init=/sbin/sulogin --force
~

Best wishes,
Marco.

Re: Añadir modulo wifi en kernel

[Josu Lazkano]

Gracias a los dos.

De momento tampoco cuesta mucho hacer esto cada vez que actualizo el kernel:

make clean
make
make install


A ver si en las últimas versiones de kernel lo añaden, la verdad que de
momento no me está dando ningún problema.

Un saludo.

-- 
Josu Lazkano

Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net

[Narcis Garcia]

El 5/12/20 a les 7:22, Àlex ha escrit:
> El 5/12/20 a les 6:59, Àlex ha escrit:
>> El 4/12/20 a les 18:00, Narcis Garcia ha escrit:
>>> Tinc un ordinador amb unitat SSD i, quan executo aquesta instrucció:
>>> $ sudo fstrim -a -v
>>>
>>> Em diu:
>>> /boot: 766,7 MiB (803893248 bytes) trimmed on /dev/sda1
>>> /: 243,1 GiB (261022449664 bytes) trimmed on /dev/mapper/sda2_crypt
>>>
>>> Algú sap quin és el problema i com resoldre'l ?
>>> Algú sap si hi ha programari per a fer anàlisi detallat d'aquest tema?
>>
>> Narcís,
>>
>> Crec que fstrim en general no augmenta gaire el rendiment del disc, però
>> pot donar problemes si s'utilitza molt freqüentment i sobretot si
>> s'utilitza sobre volums encriptats. Per exemple:
>>
>>    https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
>>
>> Si vols millorar rendiment, passa de fstrim, posa la informació
>> confidencial en una partició a banda i encripta només aquesta partició,
>> no tota l'arrel /
>>
>> Salutacions
>>
>>    Àlex
>>
> https://www.spinics.net/lists/raid/msg40916.html
> 
> https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems
> 

No vull augmentar la velocitat de la unitat, sinó recuperar-la com era
al principi.
L'arrel està encriptada perquè les dades són confidencials. Allò què fa
l'usuari és confidencial (i es revela a /tmp /var/tmp i altres
ubicacions) juntament amb còpies temporals de documents que es poden
obrir i eines que poden treballar a /opt , apart de què: Veure quines
aplicacions són instal·lades dóna pistes del format dels documents que
es treballen per tal d'escarbar en el desxifrat. I també la distinció
entre dades i programari dóna pistes entre la informació important i la
resta.

Porto anys donant voltes a aquest tema (amb xifrat i sense) i no acabo
d'esbrinar quin és el problema amb Linux o util-linux.

Ara per ara, per a rehabilitar una unitat SSD no veig altra sortida que
utilitzar blkdiscard per a formatejar-la tota de nou.

Salut;
Narcís.

Re: Emergency mode when root account locked

[Andrei POPESCU]

On Vi, 04 dec 20, 08:09:44, Greg Wooledge wrote:
> On Fri, Dec 04, 2020 at 12:00:14PM +, deandre wrote:
> > My problem is when I try to boot up deepin(Debian 10 buster)
> 
> Deepin is not Debian.  It's a derivative.  Your problems with Deepin
> should be asked on a Deepin support list, because the users there will
> have more knowledge about your operating system than we do.

While your guess is probably right, just for the archives, there is also 
a Deepin Desktop Environment, with several components available already 
in buster and many more to come.

https://salsa.debian.org/pkg-deepin-team
 
> I am also going to guess that Deepin, like Ubuntu, defaults to giving
> you a user account with sudo access, and no root password.  You can
> achieve that in Debian as well, by doing something special during the
> installation.  In all cases, it's a stupid idea and you shouldn't do it.

This is a pretty strong (and harsh!) statement. Care to expand on the 
reasons?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Help with install on old Mac

[didier gaumet]

Hello

Disclaimer: I am not familiar with Apple (old or new) hardware

There is the Debian Jessie installation manual for the powerpc architecture:
 https://www.debian.org/releases/jessie/powerpc/index.html.en

the 3.6.1 section could explain why you have difficulties to boot from your 
hard disk:
 
https://www.debian.org/releases/jessie/powerpc/ch03s06.html.en#invoking-openfirmware
but the link indicated to upgrade is broken

http://gnats.netbsd.org/43952 provides an updated link:
 wget 
http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/English-North_American/Macintosh/System/Mac_OS_X/System_Disk_Utility.smi.bin

On a side note, NetBSD, FreeBSD and OpenBSD all seem to have present version of 
their OS for the mac powerpc architecture:, NetBSD probably being the most 
advanced and supported (FreeBSD: WIP):
 http://wiki.netbsd.org/ports/macppc/

keep us informed if you have succeeded :-)
   

Re: swamp rat bots Q

[Andrei POPESCU]

On Vi, 04 dec 20, 18:55:22, Gene Heskett wrote:
> On Friday 04 December 2020 17:37:02 Tixy wrote:
> >
> > OK, I'll do your proofreading...

[...]

> Fat fingers syndrome, I've suffered from that for 86 years. 

Typing errors happen to everyone. Triple-checking the result when 
something is not working as expected usually catches most, but possibly 
not all of them.

When posting a question to the list it would really save a lot of time 
for all involved if one would just attach[1] the config files in 
question.  Most of them should be accepted by the list without issues.

For larger files (e.g. logs or similar) there is always gzip.

[1] copy-paste or similar can hide issues like wrong line-endings.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Help with install on old Mac

[Bob McGowan]

It is a Power PC G3 running Mac OS 9.

I've gotten CDs for Jessie 8.11, the last Debian release to support 
Power PC architecture.


I set up a second SCSI hard disk with an Adaptec controller and 
installed to it successfully.  However, upon reboot the system does not 
start immediately.  When it finally does, it boots the old Mac OS 9.


It turns out the existing disk is on an Advansys controller (?) that 
needs non-free firmware.  I figured this might be the cause of the 
reboot failure.


So I have rebooted from the CD and tried to access firmware on a USB 
stick.  I've tried several directory locations and had no success with 
the installer finding the files.  This may be due to the size of the 
stick (32G), I'll try something smaller later.


The real issue I need help with is that I can't figure out how, or even 
if it is possible, to use virtual consoles with Debian for Power PC, 
during install.  It would help if I could get a virtual console to work 
so I can take a look at what is going on behind the scenes.


Does anyone here have any experience from ages past with this 
environment?  Any suggestions for web sites with useful information for 
such old hardware?


I'm doing this for fun and learning, so I'm good with the restrictions 
all this will impose, particularly the old OS. ;)


Thanks,

Bob