Re: AMD Radeon 6490M

[Andrei POPESCU]

On Du, 03 ian 21, 22:24:32, Felix Miata wrote:
> 
> Start with a read of this driver primer (which applies to all distros, not 
> just
> openSUSE), to avoid potential confusion when you see the word "driver":
> .

Excelent!

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


signature.asc
Description: PGP signature

Re: recommendations for supported, affordable hardware raid controller.

[Andrei POPESCU]

On Du, 03 ian 21, 19:53:07, Michael Stone wrote:
> 
> Applications which need more data integrity
> guarantees generally implement some sort of journalling and/or use atomic
> filesystem operations. (E.g., write a temporary file, flush/sync,
> rename--that guarantees either the old file or the new file will be present,
> but not a partially written file.)

Unless I'm mistaken, this is somewhat similar to how copy-on-write works 
for every write, except that the copy-on-write is done at block level 
and with the added benefits that unchanged blocks are kept as they are 
(less writes) and may even be shared between files (using less space).


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


signature.asc
Description: PGP signature

Re: recommendations for supported, affordable hardware raid controller.

[Andrei POPESCU]

On Du, 03 ian 21, 13:43:00, David Christensen wrote:
> 
> I would postulate that copy-on-write technology could be/ is already
> included in journaling file systems to improve efficiency.

Copy-on-write (btrfs, ZFS) is different than journaling (ext4, xfs, 
etc.).

As fas as I understand copy-on-write provides the same file system 
consistency guarantees as a journal, but has other benefits in addition.

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


signature.asc
Description: PGP signature

Re: Nvidia Optimus, Debian 10, and Firefox ESR crashes

[David Wright]

On Sun 03 Jan 2021 at 15:41:26 (-0800), David Christensen wrote:
> On 2021-01-03 06:51, Alexander V. Makartsev wrote:
> > On 03.01.2021 02:52, David Christensen wrote:
> > > 
> > > Any suggestions for trouble-shooting the crashes?
> > > 
> > Have you checked the systemd journal?
> > Even after you reboot frozen system you can see last syslog
> > messages easily from previous boot with this command:
> >      $ sudo journalctl -b -1
> > 
> > Journald keeps logs from multiple previous boots.
> >      $ sudo journalctl --list-boots
> > 
> > You can select them by index. ( "0" is current boot, "-1" is
> > previous boot, etc. )
> 
> 2021-01-03 14:01:19 root@dipsy ~
> # journalctl -b -1
> Specifying boot ID or boot offset has no effect, no persistent journal
> was found.
> 
> 2021-01-03 14:01:29 root@dipsy ~
> # journalctl --list-boots
>  0 8b60854b67c243679bec112a7050f054 Sun 2021-01-03 14:01:00
> PST<80><94>Sun 2
> 
> No of much use (?).
> 
> Start Firefox, browse YouTube, play video "Relaxing Christmas Jazz
> Music 10 Hours" (not in full screen) -- crashes after ~50 minutes:
> 
> 2021-01-03 15:35:15 root@dipsy ~
> # journalctl -b -1
> Specifying boot ID or boot offset has no effect, no persistent journal
> was found.
> 
> 2021-01-03 15:35:18 root@dipsy ~
> # journalctl --list-boots
>  0 8b60854b67c243679bec112a7050f054 Sun 2021-01-03 14:01:00
> PST<80><94>Sun 2
> 
> Again, not of much use (?).  How do I get information out of the
> systemd journal?
> 
> dmesg(1) has some information, both about boot and the crash:
> 
> 2021-01-03 15:40:07 root@dipsy ~
> # dmesg | grep nouveau | head -n 30

[…]

> 2021-01-03 15:40:14 root@dipsy ~
> # dmesg | grep nouveau | wc
> 5193686   34789
> 
> Suggestions?

I don't have persistent journalling set, but I see very little in
journalctl -b   that's missing from my ordinary logs, particularly
/var/log/journal of course, but also daemon.log and syslog.

Cheers,
David.

Re: Nvidia Optimus, Debian 10, and Firefox ESR crashes

[David Christensen]

On 2021-01-01 15:51, David Christensen wrote:

2021-01-01 12:18:31 root@dipsy ~ # lspci



01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [NVS 4200M] (rev 
a1)



01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)



On 2021-01-03 17:43, Alexander V. Makartsev wrote:

It looks like "nouveau" deadlock bug. [3] Have you tried to install 
proprietary driver? Last supported driver version for your VGA is

390, so you will need to install "nvidia-legacy-390xx-driver" package
from Debian non-free repo.

$ sudo apt install nvidia-legacy-390xx-driver 
nvidia-legacy-390xx-kernel-dkms nvidia-legacy-390xx-kernel-support



[3] https://bugs.freedesktop.org/show_bug.cgi?id=81690


2021-01-03 20:06:51 root@dipsy ~
# cat /etc/debian_version
10.7

2021-01-03 20:06:57 root@dipsy ~
# uname -a
Linux dipsy 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 
GNU/Linux


2021-01-03 20:07:00 root@dipsy ~
# cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ buster main non-free contrib
deb-src http://deb.debian.org/debian/ buster main non-free contrib
deb http://deb.debian.org/debian/ buster-updates main
deb-src http://deb.debian.org/debian/ buster-updates main
deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main

2021-01-03 20:07:07 root@dipsy ~
# apt-get update
Hit:1 http://security.debian.org/debian-security buster/updates InRelease
Hit:2 http://deb.debian.org/debian buster InRelease
Hit:3 http://deb.debian.org/debian buster-updates InRelease
Reading package lists... Done

2021-01-03 20:07:14 root@dipsy ~
# apt-get install nvidia-legacy-390xx-driver
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dkms dpkg-dev glx-alternative-mesa glx-alternative-nvidia 
glx-diversions libdpkg-perl libegl-nvidia-legacy-390xx0 
libgl1-nvidia-legacy-390xx-glvnd-glx libglx-nvidia-legacy-390xx0 
libnvidia-legacy-390xx-eglcore
  libnvidia-legacy-390xx-glcore libnvidia-legacy-390xx-ml1 
nvidia-egl-common nvidia-installer-cleanup nvidia-kernel-common 
nvidia-legacy-390xx-alternative nvidia-legacy-390xx-driver-bin
  nvidia-legacy-390xx-driver-libs nvidia-legacy-390xx-egl-icd 
nvidia-legacy-390xx-kernel-dkms nvidia-legacy-390xx-kernel-support 
nvidia-legacy-390xx-vdpau-driver nvidia-modprobe nvidia-support patch 
update-glx

  xserver-xorg-video-nvidia-legacy-390xx
Suggested packages:
  python3-apport menu debian-keyring nvidia-driver git bzr ed diffutils-doc
Recommended packages:
  fakeroot linux-headers-686-pae | linux-headers-amd64 | 
linux-headers-generic | linux-headers build-essential 
libalgorithm-merge-perl libfile-fcntllock-perl nvidia-settings-legacy-390xx
  libnvidia-legacy-390xx-cfg1 nvidia-persistenced 
nvidia-legacy-390xx-driver-libs-i386 libopengl0 | 
libopengl0-glvnd-nvidia libgles-nvidia-legacy-390xx1 
libgles-nvidia-legacy-390xx2

  nvidia-legacy-390xx-vulkan-icd
The following NEW packages will be installed:
  dkms dpkg-dev glx-alternative-mesa glx-alternative-nvidia 
glx-diversions libdpkg-perl libegl-nvidia-legacy-390xx0 
libgl1-nvidia-legacy-390xx-glvnd-glx libglx-nvidia-legacy-390xx0 
libnvidia-legacy-390xx-eglcore
  libnvidia-legacy-390xx-glcore libnvidia-legacy-390xx-ml1 
nvidia-egl-common nvidia-installer-cleanup nvidia-kernel-common 
nvidia-legacy-390xx-alternative nvidia-legacy-390xx-driver
  nvidia-legacy-390xx-driver-bin nvidia-legacy-390xx-driver-libs 
nvidia-legacy-390xx-egl-icd nvidia-legacy-390xx-kernel-dkms 
nvidia-legacy-390xx-kernel-support nvidia-legacy-390xx-vdpau-driver 
nvidia-modprobe

  nvidia-support patch update-glx xserver-xorg-video-nvidia-legacy-390xx
0 upgraded, 28 newly installed, 0 to remove and 4 not upgraded.
Need to get 32.5 MB of archives.
After this operation, 123 MB of additional disk space will be used.
Do you want to continue? [Y/n]


Note pop-up dialog:

Conflicting nouveau kernel module loaded

The free nouveau kernel module is currently loaded and conflicts with 
the non-free nvidia kernel module.


The easiest way to fix this is to reboot the machine once the 
installation has finished.



Choose 'OK'.


Installation finishes with some warnings related to the removed nouveau 
driver (which is not unexpected):


Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-12-amd64
W: Possible missing firmware 
/lib/firmware/nvidia/gp100/gr/sw_method_init.bin for module nouveau
W: Possible missing firmware 
/lib/firmware/nvidia/gp100/gr/sw_bundle_init.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp100/gr/sw_nonctx.bin 
for module nouveau




Reboot -- boots okay -- login manager displayed -- login okay -- Xfce 
desktop okay -- external monitor not getting signal.



Xfce -> Settings -> Display only lists one monitor "default":

Resolution  

Re: enable journal

[David Christensen]

On 2021-01-03 15:52, Felix Miata wrote:

David Christensen composed on 2021-01-03 15:41 (UTC-0800):


Again, not of much use (?).  How do I get information out of the systemd
journal?


sudo mkdir /var/log/journal

or

turn it on in /etc/systemd/journald.conf.


STFW 'systemd journal':

https://wiki.archlinux.org/index.php/Systemd/Journal


Edit /etc/systemd/journald.conf:

Storage=persistent


Reboot.  Verify journal exists on disk:

2021-01-03 16:39:08 root@dipsy ~
# ls -l /var/log/journal/f1c6f007595c4c8c99bc5043ea75d9ac/system.journal
-rw-r-+ 1 root systemd-journal 8388608 Jan  3 16:35 
/var/log/journal/f1c6f007595c4c8c99bc5043ea75d9ac/system.journal



Look at journal:

2021-01-03 16:40:12 root@dipsy ~
# journalctl | tail
Jan 03 16:35:19 dipsy ntpd[708]: Soliciting pool server 138.68.201.49
Jan 03 16:35:20 dipsy ntpd[708]: Soliciting pool server 184.105.182.16
Jan 03 16:35:20 dipsy colord[701]: failed to get session [pid 633]: No 
data available

Jan 03 16:35:21 dipsy ntpd[708]: Soliciting pool server 163.123.152.89
Jan 03 16:35:22 dipsy ntpd[708]: Soliciting pool server 107.155.79.3
Jan 03 16:35:23 dipsy ntpd[708]: Soliciting pool server 66.85.78.80
Jan 03 16:35:24 dipsy ntpd[708]: receive: Unexpected origin timestamp 
0xe39ce14d.26c92953 does not match aorg 00. from 
server@3.217.79.242 xmt 0xe39ce14c.c2bde0d4
Jan 03 16:35:26 dipsy systemd[1]: NetworkManager-dispatcher.service: 
Succeeded.

Jan 03 16:35:36 dipsy systemd[1]: systemd-fsckd.service: Succeeded.
Jan 03 16:35:36 dipsy systemd[1]: systemd-hostnamed.service: Succeeded.


Start Firefox.  Browse to YouTube.  Play "Relaxing Christmas Jazz Music 
10 Hours".  Minimize Firefox window.  Wait.  Look at systemd journal 
after crash:


2021-01-03 19:37:25 root@dipsy ~
# journalctl | tail
Jan 03 19:41:32 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:32 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:32 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:32 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:33 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:33 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:33 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:33 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:33 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16
Jan 03 19:41:33 dipsy kernel: nouveau :01:00.0: Xorg[724]: 
nv50cal_space: -16



After reboot:

2021-01-03 19:56:21 root@dipsy ~
# journalctl --list-boots
-1 34a8ac614d574be5ae0258dffc462c15 Sun 2021-01-03 16:35:06 
PST<80><94>Sun 2
 0 f5adb0073b924ecf8e3733c64acfba32 Sun 2021-01-03 19:54:27 
PST<80><94>Sun 2


2021-01-03 20:00:55 root@dipsy ~
# journalctl -b -1 | grep nouveau | tail
Jan 03 19:53:50 dipsy kernel:  ? nouveau_channel_idle+0x94/0xe0 [nouveau]
Jan 03 19:53:50 dipsy kernel:  nouveau_abi16_chan_fini.isra.1+0xa0/0x110 
[nouveau]

Jan 03 19:53:50 dipsy kernel:  nouveau_abi16_fini+0x2d/0x70 [nouveau]
Jan 03 19:53:50 dipsy kernel:  nouveau_drm_postclose+0x4c/0xf0 [nouveau]
Jan 03 19:53:50 dipsy kernel: nouveau :01:00.0: fifo: channel 2 
[Xorg[724]] kick timeout
Jan 03 19:53:50 dipsy kernel: nouveau: Xorg[724]::906f: 
detach sw failed, -110

Jan 03 19:53:50 dipsy kernel: nouveau :01:00.0: fifo: SCHED_ERROR 0d []
Jan 03 19:53:52 dipsy kernel: nouveau :01:00.0: fifo: runlist update 
timeout
Jan 03 19:53:52 dipsy kernel: nouveau :01:00.0: fifo: INTR 0001: 
0003
Jan 03 19:53:53 dipsy kernel: nouveau :01:00.0: DRM: GPU lockup - 
switching to software fbcon



The systemd journal could prove to be useful.  Thank you.  :-)


David

Re: AMD Radeon 6490M

[Felix Miata]

Felix Miata composed on 2021-01-03 22:24 (UTC-0500):

> LuKaRo composed on 2021-01-04 03:24 (UTC+0100):

>> Any ideas on how to get graphics output on that machine? I don't even
>> need the radeon graphics, the integrated Intel graphics would be okay
>> for a start as well. My full Xorg.0.log  and
>> my dmesg  are attached here
>>  and here .. Thanks
>> a lot in advance for any ideas!

> Did you check to see if there is a way in the BIOS to disable the Radeon?

You may be able to disable the Radeon indirectly adding this to the kernel 
command
line in Grub:

radeon.modeset=0

I suspect doing this could functionally make the Intel GPU preferred.

> Getting "dual graphics" or "hybrid graphics" going on a laptop is a common
> problem. I don't have any, but I see a lot of threads about getting them 
> going.
> With Intel and NVidia together, this is called "Optimus".

> Your 6490M is a "Terascale" class Radeon, so don't let anything you might read
> about "Southern Islands" or "Sea Islands" waste your time.

> Start with a read of this driver primer (which applies to all distros, not 
> just
> openSUSE), to avoid potential confusion when you see the word "driver":
> .
> You may wish to try a bit of what you find there.

> Try hitting escape as soon as the screen goes black. Do you get a stream of 
> text
> messages? If yes, do you see any clues? You can make the messages more 
> permanent
> by reconfiguring in /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT= line to
> exclude quiet and changing splash=silent to splash=verbose or omitting it
> altogether, possibly needing instead or in addition one of the following:

>   noplymouth
>   plymouth=0
>   plymouth.enable=0

> Sending /var/log/Xorg.0.log to http://paste.debian.net/ or 
> http://pastbin.com/ if
> it exists, or ~/.local/share/xorg/Xorg.0.log if it exists, will help us help 
> you
> if examining it yourself doesn't enable you to find a solution on your own.

> Examining output from "sudo journalctl -b" will enable searching for error
> messages that don't show up in Xorg.0.log. Grep for "failed" and "error" in 
> dmesg too.

> I have Terascale ATI as well, HD 6450 working fine, but not in a laptop or 
> with
> dual graphics. 
-- 
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: AMD Radeon 6490M

[Felix Miata]

LuKaRo composed on 2021-01-04 03:24 (UTC+0100):

> Any ideas on how to get graphics output on that machine? I don't even
> need the radeon graphics, the integrated Intel graphics would be okay
> for a start as well. My full Xorg.0.log  and
> my dmesg  are attached here
>  and here .. Thanks
> a lot in advance for any ideas!

Did you check to see if there is a way in the BIOS to disable the Radeon?

Getting "dual graphics" or "hybrid graphics" going on a laptop is a common
problem. I don't have any, but I see a lot of threads about getting them going.
With Intel and NVidia together, this is called "Optimus".

Your 6490M is a "Terascale" class Radeon, so don't let anything you might read
about "Southern Islands" or "Sea Islands" waste your time.

Start with a read of this driver primer (which applies to all distros, not just
openSUSE), to avoid potential confusion when you see the word "driver":
.
You may wish to try a bit of what you find there.

Try hitting escape as soon as the screen goes black. Do you get a stream of text
messages? If yes, do you see any clues? You can make the messages more permanent
by reconfiguring in /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT= line to
exclude quiet and changing splash=silent to splash=verbose or omitting it
altogether, possibly needing instead or in addition one of the following:

noplymouth
plymouth=0
plymouth.enable=0

Sending /var/log/Xorg.0.log to http://paste.debian.net/ or http://pastbin.com/ 
if
it exists, or ~/.local/share/xorg/Xorg.0.log if it exists, will help us help you
if examining it yourself doesn't enable you to find a solution on your own.

Examining output from "sudo journalctl -b" will enable searching for error
messages that don't show up in Xorg.0.log. Grep for "failed" and "error" in 
dmesg too.

I have Terascale ATI as well, HD 6450 working fine, but not in a laptop or with
dual graphics.
-- 
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/

AMD Radeon 6490M

[LuKaRo]

Hi everyone,

I just installed Debian Buster with KDE Plasma on a notebook that has an
AMD Radeon 6490M and an Intel HD Graphics 3000 installed. The
installation (text-based) worked fine, however, after rebooting, I just
get a tty, X won't start. When checking dmesg for any errors, I found:

[drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for R600 or 
later requires firmware installed

Xorg furthermore listed errors like this:

[14.666] (II) FBDEV(4): using default device
[14.682] (II) modeset(G0): using drv /dev/dri/card0
[14.682] (EE) Screen 0 deleted because of no matching config section.
[14.682] (II) UnloadModule: "radeon"
[14.682] (EE) Screen 0 deleted because of no matching config section.
[14.682] (II) UnloadModule: "modesetting"
[14.682] (EE) Screen 1 deleted because of no matching config section.
[14.682] (II) UnloadModule: "fbdev"
[14.682] (II) UnloadSubModule: "fbdevhw"
[14.682] (EE) 
Fatal server error:
[14.683] (EE) Cannot run in framebuffer mode. Please specify busIDs
for all framebuffer devices

So I searched the internet and found several

sources

that

recommended installation of

|firmware-amd-graphics|

from non-free. I installed that package, but afterwards the system won't
boot at all - it only displays "loading initial ramdisk" and then the
screen goes black.

Any ideas on how to get graphics output on that machine? I don't even
need the radeon graphics, the integrated Intel graphics would be okay
for a start as well. My full Xorg.0.log  and
my dmesg  are attached here
 and here .. Thanks
a lot in advance for any ideas!

Kind regards,
LuKaRo

Re: Nvidia Optimus, Debian 10, and Firefox ESR crashes

[Alexander V. Makartsev]

On 04.01.2021 04:41, David Christensen wrote:

On 2021-01-03 06:51, Alexander V. Makartsev wrote:

On 03.01.2021 02:52, David Christensen wrote:


Any suggestions for trouble-shooting the crashes?


Have you checked the systemd journal?
Even after you reboot frozen system you can see last syslog messages 
easily from previous boot with this command:

 $ sudo journalctl -b -1

Journald keeps logs from multiple previous boots.
 $ sudo journalctl --list-boots

You can select them by index. ( "0" is current boot, "-1" is previous 
boot, etc. )


2021-01-03 14:01:19 root@dipsy ~
# journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal 
was found.


2021-01-03 14:01:29 root@dipsy ~
# journalctl --list-boots
 0 8b60854b67c243679bec112a7050f054 Sun 2021-01-03 14:01:00 
PST<80><94>Sun 2



No of much use (?).


Sorry, I completely forgot this feature isn't yet [1] enabled by default.
This is what I get on my system:
$ journalctl --list-boots | tail -n3
 -2 e9c28f25bcbe4e26a93e519d231e046e Fri 2021-01-01 19:42:32 +05—Sat 
2021-01-02 03:28:07 +05
 -1 766d50af660f4904839a3f6b1aa5b2c2 Sat 2021-01-02 11:31:12 +05—Sun 
2021-01-03 06:46:03 +05
  0 a65baabd511b490eb65d2e8c69e70700 Sun 2021-01-03 12:37:32 +05—Mon 
2021-01-04 05:00:01 +05




Start Firefox, browse YouTube, play video "Relaxing Christmas Jazz 
Music 10 Hours" (not in full screen) -- crashes after ~50 minutes:



2021-01-03 15:35:15 root@dipsy ~
# journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal 
was found.


2021-01-03 15:35:18 root@dipsy ~
# journalctl --list-boots
 0 8b60854b67c243679bec112a7050f054 Sun 2021-01-03 14:01:00 
PST<80><94>Sun 2



Again, not of much use (?).  How do I get information out of the 
systemd journal?



You can read a brief tutorial on journal here. [2]
For now, until you enable persistent journal, you have only current boot 
journal:

$ journalctl -b 0



dmesg(1) has some information, both about boot and the crash:
2021-01-03 15:40:11 root@dipsy ~
# dmesg | grep nouveau | tail
[ 2964.485920] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.542072] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.598799] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.654669] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.710811] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.767008] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.822927] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.879084] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.935106] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.991455] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16

2021-01-03 15:40:14 root@dipsy ~
# dmesg | grep nouveau | wc
    519    3686   34789


Suggestions?

It looks like "nouveau" deadlock bug. [3] Have you tried to install 
proprietary driver?
Last supported driver version for your VGA is 390, so you will need to 
install "nvidia-legacy-390xx-driver" package from Debian non-free repo.


    $ sudo apt install nvidia-legacy-390xx-driver 
nvidia-legacy-390xx-kernel-dkms nvidia-legacy-390xx-kernel-support




[1] https://lists.debian.org/debian-devel/2020/02/msg0.html
[2] 
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

[3] https://bugs.freedesktop.org/show_bug.cgi?id=81690

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: 'apt upgrade' doet iets anders dan 'apt-get upgrade'

[Cecil Westerhof]

Richard Lucassen  writes:

> On Sun, 03 Jan 2021 17:22:26 +0100
> Cecil Westerhof  wrote:
>
>> > MAILTO=""
>> > MAILON="upgrade"
>> >
>> > Dat doet precies wat je wilt. Niet upgraden maar de packages alvast
>> > downloaden en je vertellen dat er moet worden ge-update.
>> 
>> Niet helemaal: door dat alvast downloaden loopt mijn partitie
>> langzamerhand vol.
>
> Draai je wel eens "apt clean"?

Nope, daar liep ik dus laatst tegenaan.


> Maar ik gebruik het "niet downloaden" dus nooit, maar volgens mij kun je
> dat gewoon uitzetten, je krijgt dan alleen de notificatie:
>
> $ cat /etc/cron-apt/action.d/3-download 
> autoclean -y
> dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
>
> Volgens mij kun je het daarmee instellen. Met dat apt is alles
> mogelijk, je moet alleen een universitaire studie ervoor volgen :)

Ik heb nooit een universitaire studie gevolgd. ;-)
Voorlopig werkt het, maar ik zou binnenkort eens in het bovenstaande
kunnen duiken.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: recommendations for supported, affordable hardware raid controller.

[Michael Stone]

On Sun, Jan 03, 2021 at 11:25:40AM +0200, Andrei POPESCU wrote:

That would mean all data is written to the disk twice and would make a
journaling file system twice as slow compared to a non-journaling file
system; the journal is typically on the same storage.


That's almost never how it's actually implemented these days, exactly 
because of the hideous performance penalty. Barring a non-default option 
like ext3's data=journal what generally happens is that the data is 
written to the disk, then the *metadata* is written to the journal, and 
then the metadata is updated in its final location. The total amount of 
data written to the journal is relatively low. The primary benefit of 
this sort of scheme is avoiding a fsck on unclean shutdown; you may end 
up with old data, new data, or partially written data. Applications 
which need more data integrity guarantees generally implement some sort 
of journalling and/or use atomic filesystem operations. (E.g., write a 
temporary file, flush/sync, rename--that guarantees either the old file or 
the new file will be present, but not a partially written file.)

Re: enable persistent journal (was: Nvidia Optimus, Debian 10...)

[Felix Miata]

David Christensen composed on 2021-01-03 15:41 (UTC-0800):

> Again, not of much use (?).  How do I get information out of the systemd 
> journal?

sudo mkdir /var/log/journal

or

turn it on in /etc/systemd/journald.conf.
-- 
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: enable journal (was: Nvidia Optimus, Debian 10...)

[Felix Miata]

David Christensen composed on 2021-01-03 15:41 (UTC-0800):

> Again, not of much use (?).  How do I get information out of the systemd 
> journal?

sudo mkdir /var/log/journal

or

turn it on in /etc/systemd/journald.conf.
-- 
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: Nvidia Optimus, Debian 10, and Firefox ESR crashes

[David Christensen]

(Re-ordered for clarity.)

On 2021-01-03 04:01, Andrew M.A. Cater wrote:

On Sat, Jan 02, 2021 at 01:52:47PM -0800, David Christensen wrote:

On 2021-01-02 05:23, Darac Marjal wrote:



On 01/01/2021 23:51, David Christensen wrote:

I have a Dell Latitude E6520 with Nvidia Optimus graphics:



I have disabled Optimus in the CMOS Setup:

Video -> Optimus -> Enable Optimus -> unchecked


Optimus has (finally) become natively supported by the 
Proprietary NVIDIA driver recently (it's just a matter of

running an application the environment variable
__NV_PRIME_RENDER_OFFLOAD set to 1 and that process will use the
dGPU).



2021-01-02 13:45:52 root@dipsy ~ # lsmod | sort Module Size  Used
by



button 16384  1 nouveau


drm   495616  6 drm_kms_helper,ttm,nouveau 
drm_kms_helper208896  1 nouveau



i2c_algo_bit   16384  1 nouveau



mxm_wmi16384  1 nouveau



ttm   126976  1 nouveau



video  49152  3 dell_wmi,dell_laptop,nouveau



dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor,mxm_wmi,nouveau


If you can afford to reinstall the machine: change the option back 
above. Do an expert text mode install which should work using basic 
graphics. Do _NOT_ install a desktop environment or anything much 
more than a> bare text mode only system. Finish the install. Reboot.

At that point, install the proprietary drivers. Then, and only then,
use tasksel to install a desktop environment which will pick up the
Nividia proprietary driver and use that to drive the desktop.


If nouveau is installed, you then have a significant problem 
installing the proprietary drivers hence the suggestion to 
re-install. I found this out the hard way with a laptop a little 
while ago that was using Optimus :(


As they say -- "there is no substitute for experience".


That sounds like a viable work-around.  Thank you.  :-)


David

Re: Nvidia Optimus, Debian 10, and Firefox ESR crashes

[David Christensen]

On 2021-01-03 06:51, Alexander V. Makartsev wrote:

On 03.01.2021 02:52, David Christensen wrote:


Any suggestions for trouble-shooting the crashes?


Have you checked the systemd journal?
Even after you reboot frozen system you can see last syslog messages 
easily from previous boot with this command:

     $ sudo journalctl -b -1

Journald keeps logs from multiple previous boots.
     $ sudo journalctl --list-boots

You can select them by index. ( "0" is current boot, "-1" is previous 
boot, etc. )


2021-01-03 14:01:19 root@dipsy ~
# journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal 
was found.


2021-01-03 14:01:29 root@dipsy ~
# journalctl --list-boots
 0 8b60854b67c243679bec112a7050f054 Sun 2021-01-03 14:01:00 
PST<80><94>Sun 2



No of much use (?).


Start Firefox, browse YouTube, play video "Relaxing Christmas Jazz Music 
10 Hours" (not in full screen) -- crashes after ~50 minutes:



2021-01-03 15:35:15 root@dipsy ~
# journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal 
was found.


2021-01-03 15:35:18 root@dipsy ~
# journalctl --list-boots
 0 8b60854b67c243679bec112a7050f054 Sun 2021-01-03 14:01:00 
PST<80><94>Sun 2



Again, not of much use (?).  How do I get information out of the systemd 
journal?



dmesg(1) has some information, both about boot and the crash:

2021-01-03 15:40:07 root@dipsy ~
# dmesg | grep nouveau | head -n 30
[1.828481] nouveau :01:00.0: NVIDIA GF119 (0d9160a1)
[1.849058] nouveau :01:00.0: bios: version 75.19.6a.01.02
[1.849961] nouveau :01:00.0: fb: 512 MiB DDR3
[1.922123] nouveau :01:00.0: DRM: VRAM: 512 MiB
[1.922254] nouveau :01:00.0: DRM: GART: 1048576 MiB
[1.922382] nouveau :01:00.0: DRM: TMDS table version 2.0
[1.922502] nouveau :01:00.0: DRM: DCB version 4.0
[1.922621] nouveau :01:00.0: DRM: DCB outp 00: 01000323 00010034
[1.922741] nouveau :01:00.0: DRM: DCB outp 01: 02011300 
[1.922861] nouveau :01:00.0: DRM: DCB outp 02: 08024382 00020010
[1.922981] nouveau :01:00.0: DRM: DCB outp 03: 020323a6 0f220010
[1.923101] nouveau :01:00.0: DRM: DCB outp 04: 02032362 00020010
[1.923221] nouveau :01:00.0: DRM: DCB outp 05: 040433b6 0f220010
[1.923342] nouveau :01:00.0: DRM: DCB outp 06: 04043372 00020010
[1.923464] nouveau :01:00.0: DRM: DCB conn 00: 0041
[1.923583] nouveau :01:00.0: DRM: DCB conn 01: 0100
[1.923700] nouveau :01:00.0: DRM: DCB conn 02: 1246
[1.923820] nouveau :01:00.0: DRM: DCB conn 03: 2346
[1.923937] nouveau :01:00.0: DRM: DCB conn 04: 00010461
[1.926692] nouveau :01:00.0: DRM: MM: using COPY0 for buffer copies
[2.127037] nouveau :01:00.0: DRM: allocated 1920x1080 fb: 
0x6, bo (ptrval)

[2.127308] fbcon: nouveaufb (fb0) is primary device
[2.935223] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[2.950329] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 
on minor 0

[  319.407414] nouveau :01:00.0: fifo: INTR 0080
[ 2936.944954] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2937.000338] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2937.059429] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2937.115040] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2937.173447] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16

2021-01-03 15:40:11 root@dipsy ~
# dmesg | grep nouveau | tail
[ 2964.485920] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.542072] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.598799] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.654669] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.710811] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.767008] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.822927] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.879084] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.935106] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16
[ 2964.991455] nouveau :01:00.0: Xorg[731]: nv50cal_space: -16

2021-01-03 15:40:14 root@dipsy ~
# dmesg | grep nouveau | wc
5193686   34789


Suggestions?


David

Re: recommendations for supported, affordable hardware raid controller.

[Stefan Monnier]

>> AIUI a journaling filesystem provides a two-step process to achieve atomic
>> writes of multiple sectors to disk -- e.g. a process wants to put some data
>> into a block here (say, a file), a block there (say, a directory), etc., and
>> consistency of the on-disk data structures must be preserved.  The journal
>> provides a two-step process whereby everything is written to the journal,
>> then everything is written to disk.
> That would mean all data is written to the disk twice and would make a
> journaling file system twice as slow compared to a non-journaling file
> system; the journal is typically on the same storage.

On rotating storage, it's definitely not that bad, since typically every
file modification will involve several parts of the disk (at least the
actual data and the inode, and often more), so the log only adds one
head movement to the 2 or 3 already needed.  Furthermore, once it's
written to the log, there is no hurry to do the other writes, so they
can be delayed and coalesced with other nearby writes, reducing head
movement yet further.

So, all in all, the performance impact can be quite varied and will
heavily depend on your use case (and on how much work went into tuning
the filesystem and journaling code).


Stefan

Re: recommendations for supported, affordable hardware raid controller.

[David Christensen]

On 2021-01-03 01:25, Andrei POPESCU wrote:

On Sb, 02 ian 21, 13:35:06, David Christensen wrote:



AIUI a journaling filesystem provides a two-step process to achieve atomic
writes of multiple sectors to disk -- e.g. a process wants to put some data
into a block here (say, a file), a block there (say, a directory), etc., and
consistency of the on-disk data structures must be preserved.  The journal
provides a two-step process whereby everything is written to the journal,
then everything is written to disk.


That would mean all data is written to the disk twice and would make a
journaling file system twice as slow compared to a non-journaling file
system; the journal is typically on the same storage.

Even if you put the journal on another storage, having the data written
there in parallel would basically result in a sort of RAID ;)


If either step is interrupted, the
filesystem driver will detect the failure and respond.  When done, either
all of the blocks have been updated on disk or none of the blocks on disk
have been changed.


My understanding of [1] is that the journal only keeps track of metadata
and/or data *updates*.

In case of a crash it can only tell you whether the write was
"completed". It has no way to know whether the data on disk is actually
correct.

[1] https://en.wikipedia.org/wiki/Journaling_file_system

When using a non-checksumming file system we are trusting the storage to
either return correct data or report a read error (bad block) in order
to restore it from the "other" copies (in case of RAID) or, worst case,
from backup.

If the storage returns *wrong* data instead a non-checksumming file
system will never notice as it has no concept of what the correct data
should be.

A RAID by itself is also unable to distinguish between correct and
incorrect data and may even overwrite the good data with the bad data.

If we are lucky the error is noticed *and* the backups contain the
correct data (the backup may have been created from the corrupt data).

Without good integrity checks it is also very difficult to tell how
probable such issues are.


Yes, data and metadata integrity checking is different than responding 
to errors report by integrated drive controllers and/or interface 
controllers.  They address different failure modes.  But Murphy's Law 
tells me there are others.



I would postulate that copy-on-write technology could be/ is already 
included in journaling file systems to improve efficiency.



As they say, "the devil is in the details".


But, I am not going to read a mountain of web pages/ books and/or crawl 
source code to find out.  As a computer user and hobbyist developer, my 
challenges are learning what is available OOTB at a sufficient level to 
choose the appropriate pieces for, and apply them correctly to, my 
needs.  My primary metrics are correctness and stability; I avoid 
"bleeding edge", "testing", "unstable", etc..  I must rely on other 
people to develop, test, document, package, and support what I use.



I await dm-integrity being included in the Debian Installer.


Ubuntu figured out how to do ZFS-on-root OOTB; I wish Debian would do 
the same.



David

Re: 'apt upgrade' doet iets anders dan 'apt-get upgrade'

[Richard Lucassen]

On Sun, 03 Jan 2021 17:22:26 +0100
Cecil Westerhof  wrote:

> > MAILTO=""
> > MAILON="upgrade"
> >
> > Dat doet precies wat je wilt. Niet upgraden maar de packages alvast
> > downloaden en je vertellen dat er moet worden ge-update.
> 
> Niet helemaal: door dat alvast downloaden loopt mijn partitie
> langzamerhand vol.

Draai je wel eens "apt clean"?

Maar ik gebruik het "niet downloaden" dus nooit, maar volgens mij kun je
dat gewoon uitzetten, je krijgt dan alleen de notificatie:

$ cat /etc/cron-apt/action.d/3-download 
autoclean -y
dist-upgrade -d -y -o APT::Get::Show-Upgraded=true

Volgens mij kun je het daarmee instellen. Met dat apt is alles
mogelijk, je moet alleen een universitaire studie ervoor volgen :)

-- 
richard lucassen
http://contact.xaq.nl/

Re: Una de discs durs

[Narcis Garcia]

Em sumo a la primera mesura de provar un altre cable S.ATA
I aleshores, fer una comprovació completa de disc, però no amb el
sistema instal·lat sinó amb una Debian Stable en sessió «Live».



Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 3/1/21 a les 9:29, Josep Lladonosa ha escrit:
> Hola, Joan,
> 
> 
> Que no sigui cosa del cable SATA.
> A la feina hem tingut experiències similars i canviant-lo s'ha resolt.
> 
> La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> exemple.
> 
> Cada fabricant indica la seva garantia.
> Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec que
> és de Western Digital, ara, i que també està bé).
> 
> Bon any,
> Josep
> 
> El dg., 3 de gen. 2021, 9:01, Joan  > va escriure:
> 
> El problema que tinc m'ha passat dugues vegades en dugues setmanes, i
> tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb) no
> massa vell, de potser un parell d'anys, o un problema del soft que
> "desgabella" el disc
> 
> És un disc secundari (el sistema el tinc en un SSD) a on guardo videos,
> fotos, etc. Un dels meus sospitosos com a causa de tot plegat podria
> ser l'amule.
> 
> Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> queda en mode d'emergència, perquè detecta un error:
> 
> de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode 38666373
> has an invalid extent node (blk 154697780, lblk 0) de gen. 02 16:21:12
> pc2019 systemd-fsck[502]: magatzem: UNEXPECTED INCONSISTENCY; RUN fsck
> MANUALLY. de gen. 02 16:21:12 pc2019 systemd-fsck[502]:         (i.e.,
> without -a or -p options) de gen. 02 16:21:12 pc2019 systemd-fsck[430]:
> fsck failed with exit status 4. de gen. 02 16:21:12 pc2019
> systemd-fsck[430]: Running request emergency.target/start/replace de
> gen. 02 16:21:12 pc2019 systemd[1]:
> 
> systemd-fsck@dev-disk-by\x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Main process exited, code=exited, status=1/FAILURE de gen. 02 16:21:12
> pc2019 systemd[1]:
> 
> systemd-fsck@dev-disk-by\x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019 systemd[1]:
> Failed to start File System Check on
> /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem. de
> gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local File
> Systems. de gen. 02 16:21:12 pc2019 systemd[1]: local-fs.target: Job
> local-fs.target/start failed with result 'dependency'. de gen. 02
> 16:21:12 pc2019 systemd[1]: local-fs.target: Triggering OnFailure=
> dependencies. de gen. 02 16:21:12 pc2019 systemd[1]:
> media-magatzem.mount: Job media-magatzem.mount/start failed with result
> 'dependency'.
> 
> I a mi em mostra aquesta pantalla:
> 
> 
> https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> 
> 
> 
> Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> 
> Que em dona aquestes pantalles (les resumeixo, perquè bàsicament son 20
> minuts de anar dient "yes" a tot el que em proposa, després de la
> revisió que dura unes 8 hores o més:
> 
> 
> https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> 
> 
> 
> https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> 
> 
> 
> https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> 
> 
> 
> Llavors, les meves preguntes:
> 
> 1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
> amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
> fer-li un clonezilla?
> 
> 2) Podria ser un problema originat pel software? (en aquest sentit no
> sé si actualitzar la meva Debian Testing, que no actualitzo en general
> de cop, sinó a bocinets).
> 
> 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò que
> es fa al primari cada nosequantes arrencades. Diria que no, i que és
> una opció configurable al fstab. El meu fstab és aquest:
> 
> UUID=... /               ext4    errors=remount-ro 0       1
> # /home was on /dev/sdb6 during installation
> 

Re: Problems with kept back packages

[shadowmaker]

El 2021-01-03 15:45, David Wright escribió:
On Sun 03 Jan 2021 at 14:56:26 (+), shadowma...@logorroici.org 
wrote:

I have no idea how to solve this problem: I installed a Debian 10 in
my computer.


Recently? If so, you might be best off by reinstalling 10 from scratch.


The GPU was only supported with linux 5.8 so I updated to
bullseye.


You might be better off installing 5.8 from buster-backports.


I don't know how to configure correctly the sources.list
file so I just changed all the 'buster' for 'bullseye' and it upgraded
well (but the Debian-security failed I don't know why. It would be
interesting if someone helps me with that).


Because there is no security support for testing.


Yea, I realized and just commented that line
Now I am in an unstable version :)
I just want my GPU to work... But now I generate other problem...
I wrote twice a line in the sources.list and now 'apt upgrade' gives a 
problem because some files are twice configured in 'sources.list'. I 
fixed the bad lines but the problem didn't solve. How do I fix this 
little problem?



I rebooted to use the last
kernel an the GPU controllers worked this time. But, the startx (I
installed GNOME) didn't work. I tried to upgrade and... More than 500
packages were kept back... I am using bullseye so I don't think I have
a deprecated version. But  don't know how to configure the sources...
Could someone send me a configuration for the last bullseye system?



It doesn't sound as if you're familiar enough with Debian to be able
to comfortably run a testing system.


As I said above, now I made a bigger problem... I am not familiar enough 
to Debian, but I need some components working and they are not available 
on Debian 10 (I need the 5.8 kernel for the GPU and some packages in 
testing to use the touchpad).


Happy hacking

Re: RDP

[Hans]

Am Sonntag, 3. Januar 2021, 13:51:55 CET schrieb Pòl Hallen:

Hi,

Debian will be fine if using a leightweight window manager. I am running 
Debian on my EEEPC 1001, which has a 1,66 GHz CPU, 2GB RAM and a 240GB SSD.

Note: The SSD does not increase speed, but uses lower power consumption and is 
better fit against mechanical disturbance.

Also note, that my SSD is encrypted, which is slowing down the performance I 
won with using a SSD drive. However, it is still fast enough for my daily 
work, it is just starting slow (1-2 minutes until the window manager is up).

I had best performance with LXDE, but also plasma5 is running usable (in 
plasma5 the screen ios sometimes a little bit flickering, when hoovering with 
the mouse).

For VNC and RDP , remmina is also my choice, it is really faster than vncview 
or tightvnc (tried others, too)

The EEEPC is also well usable, when running livesystems from the sd card or 
usb-stick. SD-Card is preferred, because no one can break it accidently. And 
it is a little bit faster.

I have a multiboot-sd card with several livesystems on it (about 20, smaller 
and bigger ones) , just as Trinity-Rescue-Kit, KALI-Linux (32-bit with LXDE), 
Knoppix, Gparted, Falcon4, Kon-Boot, Windows-Rescue, Systemrescue and a lot 
more (all together fit on a 16 GB SD-card).

Hope this helps a little bit.

Have a happy new year and best regards

Hans

> Hi folks :-)
> sorry if question is semi-OT :)
> 
> I need to "exhume" old hw to exclusive use it with remmina RDP client
> 
> what's the best way? A lightweight debian distro?
> 
> is there a specific free distro? or use something like puppy linux?
> 
> thanks for help!



signature.asc
Description: This is a digitally signed message part.

Re: RDP

[Nicholas Geovanis]

On Sun, Jan 3, 2021, 6:58 AM Pòl Hallen  wrote:

> Hi folks :-)
> sorry if question is semi-OT :)
>
> I need to "exhume" old hw to exclusive use it with remmina RDP client
> what's the best way? A lightweight debian distro?
> is there a specific free distro? or use something like puppy linux?
>

I've run remmina on Debian 8 and Ubuntu 14 (I think). That was 3 or 4 years
ago. Try to make it a machine with more RAM if you can.

thanks for help!
>
> --
> Pol
>
>

Re: I have a Gigabyte GA-A320M-H is there a BUG in this motherboard?

[John Boxall]

On 2021-01-02 4:06 a.m., ike wrote:

On 01/01/2021 11:42 PM, ike wrote:

 I have a Gigabyte GA-A320M-H I have tried to install Debian 10.7 .
I
 have enable Iommu and CSM. When the menu comes up it does not
matter
 what I select after I hit enter the screen is just a mess can you
help
 me please. After I press enter the screen is just lines dots and a
 mess.
 I under stand there is a BUG in Lommu if so how do I fix it. I am
not
 an expert with this so be patient with me please.
 Thank you Isaac Shields
 nejek...@bigpond.com





Issac,

If you have been able to complete the Buster install and install GRUB on 
the appropriate disk, please try the following:


__DISABLE__  IOMMU support in the motherboard BIOS.

Reboot to the GRUB menu and type "e" to edit the default boot
option

type " iommu=soft" (no quotes) at the end of the "linux" line.

Press the "F10" key to boot the default option.


If that works (the system comes up to a Debian login screen) then you 
need to edit /etc/default/grub (under the root user; create a backup 
copy first) and update the line below with:


GRUB_CMDLINE_LINUX="iommu=soft"

Save the updated file

Run the "update-grub" command (again, under the root user).

Reboot

I have two systems with Gigabyte motherboards and I need to add this to 
the GRUB configuration in order to get all USB ports working properly.


--
Regards,

John Boxall

Re: Problems with kept back packages

[David Wright]

On Sun 03 Jan 2021 at 11:56:49 (-0500), Cindy Sue Causey wrote:
> On 1/3/21, David Wright  wrote:
> > On Sun 03 Jan 2021 at 14:56:26 (+), shadowma...@logorroici.org wrote:
> >> I have no idea how to solve this problem: I installed a Debian 10 in
> >> my computer.
> >
> >> I don't know how to configure correctly the sources.list
> >> file so I just changed all the 'buster' for 'bullseye' and it upgraded
> >> well (but the Debian-security failed I don't know why. It would be
> >> interesting if someone helps me with that).
> >
> > Because there is no security support for testing.
> 
> My apologies in advance if I've misinterpreted the question and thus
> am about to waste space. :)
> 
> When I bumped from Buster to Bullseye, it took "a few seconds" of
> digging to figure out why the previous security repository
> declarations failed. I now have this in my user CHOICE of a
> /etc/apt/sources.list.d/debian.sources file:
> 
> Types: deb deb-src
> URIs: http://security.debian.org/debian-security
> Suites: bullseye-security
> Components: main contrib non-free
> 
> It has been so long since I used the /etc/apt/sources.list file method
> that it just now took "a few more seconds" to fall back into it, After
> multiple stabs at it, this FINALLY worked correctly *for me*:
> 
> deb http://security.debian.org/debian-security bullseye-security main
> contrib non-free
> deb-src http://security.debian.org/debian-security bullseye-security
> main contrib non-free
> 
> That's all based on going back to packages.debian.org to refresh my
> brain that I had stable, testing, and unstable all assigned to the
> proper project names (Buster, Bullseye, and Sid, respectively).

I don't follow testing, so the existence of
http://security.debian.org/debian-security/dists/bullseye-security/
was of interest. I would attach its Release file, but it's a
42k waste of bandwidth for list members, so here's a command
for taking a look:

$ wget 
http://security.debian.org/debian-security/dists/bullseye-security/Release

The Release file consists mainly of the well-known string
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
as would be generated by   sha256sum /dev/null.

Cheers,
David.

Re: Problems with kept back packages

[Cindy Sue Causey]

On 1/3/21, David Wright  wrote:
> On Sun 03 Jan 2021 at 14:56:26 (+), shadowma...@logorroici.org wrote:
>> I have no idea how to solve this problem: I installed a Debian 10 in
>> my computer.
>
>
>> I don't know how to configure correctly the sources.list
>> file so I just changed all the 'buster' for 'bullseye' and it upgraded
>> well (but the Debian-security failed I don't know why. It would be
>> interesting if someone helps me with that).
>
> Because there is no security support for testing.
>

My apologies in advance if I've misinterpreted the question and thus
am about to waste space. :)

When I bumped from Buster to Bullseye, it took "a few seconds" of
digging to figure out why the previous security repository
declarations failed. I now have this in my user CHOICE of a
/etc/apt/sources.list.d/debian.sources file:

Types: deb deb-src
URIs: http://security.debian.org/debian-security
Suites: bullseye-security
Components: main contrib non-free

It has been so long since I used the /etc/apt/sources.list file method
that it just now took "a few more seconds" to fall back into it, After
multiple stabs at it, this FINALLY worked correctly *for me*:

deb http://security.debian.org/debian-security bullseye-security main
contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security
main contrib non-free

That's all based on going back to packages.debian.org to refresh my
brain that I had stable, testing, and unstable all assigned to the
proper project names (Buster, Bullseye, and Sid, respectively).

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: Monitor Problem???

[Stephen P. Molnar]

On 01/03/2021 11:39 AM, David Wright wrote:

On Sun 03 Jan 2021 at 06:58:24 (-0500), Stephen P. Molnar wrote:

My main computer runs  Debian Buster and is displaying some unusual
behavior.

The monitor is blanking, without warning, at random times, and
restoring the screen  while I working. There is no warning, nor does
the computer seem to be overheating (I continuously monitor the
temperature).

I rather suspect that it may be a hardware problem. I keep the
software up to date.

I am querying this group because I can't think of a more knowledgeable
source. Any thoughts and suggestions of things that I might be able to
test will be very welcome.

What sort of connection do you have between the computer and the
monitor? We have an HP Spectre that developed an unreliable HDMI
socket within 27 months. The symptoms were as you described.
Being a laptop, the cure was to run the display through the
USB-C port with a hub (dual HDMI, ethernet, dual USB3).

OTOH the worst I've experienced with VGA was flickering colour
balance from dirty/worn pins.

Cheers,
David.


The monitor is hardwired to a switch that, in turn, is hardwired to my 
main Linux Platform and an older Linux computer.


Rebooting the system seems (at least, so far) to  have remediated the 
problem.


Many thanks for your reply. I knew I could rely on the mailing list.

--
Stephen P. Molnar, Ph.D.
www.molecular-modeling.net
614.312.7528 (c)
Skype:  smolnar1

Re: Monitor Problem???

[David Wright]

On Sun 03 Jan 2021 at 06:58:24 (-0500), Stephen P. Molnar wrote:
> My main computer runs  Debian Buster and is displaying some unusual
> behavior.
> 
> The monitor is blanking, without warning, at random times, and
> restoring the screen  while I working. There is no warning, nor does
> the computer seem to be overheating (I continuously monitor the
> temperature).
> 
> I rather suspect that it may be a hardware problem. I keep the
> software up to date.
> 
> I am querying this group because I can't think of a more knowledgeable
> source. Any thoughts and suggestions of things that I might be able to
> test will be very welcome.

What sort of connection do you have between the computer and the
monitor? We have an HP Spectre that developed an unreliable HDMI
socket within 27 months. The symptoms were as you described.
Being a laptop, the cure was to run the display through the
USB-C port with a hub (dual HDMI, ethernet, dual USB3).

OTOH the worst I've experienced with VGA was flickering colour
balance from dirty/worn pins.

Cheers,
David.

Re: 'apt upgrade' doet iets anders dan 'apt-get upgrade'

[Cecil Westerhof]

Richard Lucassen  writes:

> On Sat, 02 Jan 2021 16:09:43 +0100
> Cecil Westerhof  wrote:
>
>> Ik heb dat opgelost door in het script nu apt te gebruiken en stderr
>> naar /dev/null te sturen. (Daar geeft apt namenlijk een waarschuwing
>> als het in een script wordt gebruikt.)
>
> apt install cron-apt
>
> $ cat /etc/cron-apt/config
> # Configuration for cron-apt. For further information about the possible
> # configuration settings see /usr/share/doc/cron-apt/README.gz.
>
> MAILTO=""
> MAILON="upgrade"
>
> Dat doet precies wat je wilt. Niet upgraden maar de packages alvast
> downloaden en je vertellen dat er moet worden ge-update.

Niet helemaal: door dat alvast downloaden loopt mijn partitie
langzamerhand vol.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Monitor Problem???

[Gene Heskett]

On Sunday 03 January 2021 06:58:24 Stephen P. Molnar wrote:

> My main computer runs  Debian Buster and is displaying some unusual
> behavior.
>
> The monitor is blanking, without warning, at random times, and
> restoring the screen  while I working. There is no warning, nor does
> the computer seem to be overheating (I continuously monitor the
> temperature).
>
That has the marks of an older, ccfl backlit, screen with either the 
flourescent tube or its power supply caps, on the way out. If, when the 
back has been removed, you see some alu cans with plastic film printed 
wrappers, and the tops are bulged out, they'll need to be replaced by 
suitable very low ESR replacements. But that will generally need a full 
blown soldering station ($100 and up) and some expertise at soldering.  
If you have both, piece of cake, if not, take it to someone who does, or 
replace it. Modern led backlit monitors are generally brighter and use 
less power.

If that someone has a CET plaque on the wall like I do, that's a definite 
plus.

> I rather suspect that it may be a hardware problem. I keep the
> software up to date.
>
> I am querying this group because I can't think of a more knowledgeable
> source. Any thoughts and suggestions of things that I might be able to
> test will be very welcome.
>
> Thanks in advance.

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: Problems with kept back packages

[David Wright]

On Sun 03 Jan 2021 at 14:56:26 (+), shadowma...@logorroici.org wrote:
> I have no idea how to solve this problem: I installed a Debian 10 in
> my computer.

Recently? If so, you might be best off by reinstalling 10 from scratch.

> The GPU was only supported with linux 5.8 so I updated to
> bullseye.

You might be better off installing 5.8 from buster-backports.

> I don't know how to configure correctly the sources.list
> file so I just changed all the 'buster' for 'bullseye' and it upgraded
> well (but the Debian-security failed I don't know why. It would be
> interesting if someone helps me with that).

Because there is no security support for testing.

> I rebooted to use the last
> kernel an the GPU controllers worked this time. But, the serverx (I
> installed GNOME) didn't work. I tried to upgrade and... More than 500
> packages were kept back... I am using bullseye so I don't think I have
> a deprecated version. But  don't know how to configure the sources...
> Could someone send me a configuration for the last bullseye system?

It doesn't sound as if you're familiar enough with Debian to be able
to comfortably run a testing system.

> Thanks in advance.
> Happy hacking!

Cheers,
David.

Problems with kept back packages

[shadowmaker]

I have no idea how to solve this problem: I installed a Debian 10 in my 
computer. The GPU was only supported with linux 5.8 so I updated to 
bullseye. I don't know how to configure correctly the sources.list file 
so I just changed all the 'buster' for 'bullseye' and it upgraded well 
(but the Debian-security failed I don't know why. It would be 
interesting if someone helps me with that). I rebooted to use the last 
kernel an the GPU controllers worked this time. But, the serverx (I 
installed GNOME) didn't work. I tried to upgrade and... More than 500 
packages were kept back... I am using bullseye so I don't think I have a 
deprecated version. But  don't know how to configure the sources... 
Could someone send me a configuration for the last bullseye system?

Thanks in advance.
Happy hacking!

Re: Nvidia Optimus, Debian 10, and Firefox ESR crashes

[Alexander V. Makartsev]

On 03.01.2021 02:52, David Christensen wrote:


Any suggestions for trouble-shooting the crashes?


Have you checked the systemd journal?
Even after you reboot frozen system you can see last syslog messages 
easily from previous boot with this command:

    $ sudo journalctl -b -1

Journald keeps logs from multiple previous boots.
    $ sudo journalctl --list-boots

You can select them by index. ( "0" is current boot, "-1" is previous 
boot, etc. )



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Monitor Problem???

[Andrei POPESCU]

On Du, 03 ian 21, 06:58:24, Stephen P. Molnar wrote:
> My main computer runs  Debian Buster and is displaying some unusual
> behavior.
> 
> The monitor is blanking, without warning, at random times, and restoring the
> screen  while I working. There is no warning, nor does the computer seem to
> be overheating (I continuously monitor the temperature).

Make sure the cables are properly connected, at both ends.

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


signature.asc
Description: PGP signature

Re: Debian10 btrfs+luks

[Camaleón]

El 2021-01-03 a las 13:06 +0100, Borja Gutiérrez Fernández escribió:

> Quiero instalar Debian10 sobre btrfs y luks en un portatil nuevo. He
> estado buscando documentación, y he encontrado algunos post en el foro
> de Debian, con las que orientar el proceso. He probado la instalación en
> una VM, y el proceso ha finalizado bien, pero en el momento de arranque
> se me queda colgado, con un mensaje de error un tanto raro.

El error exacto es importante, y también saber quién lo genera: si viene
de la UEFI o de Debian (GRUB).

> Lo extraño, es que no me pide la contraseña para desbloquear las particiones
> cifradas, y no tengo claro, dónde está el error. Mi pregunta es,
> conocéis algún post o documento a modo de orientación?.

Tienes una guía bastante completa aquí, aunque es para Ubuntu los pasos 
y los conceptos serán los mismos. Mira a ver si has hecho todos los 
pasos:

Ubuntu 20.04 with btrfs-luks full disk encryption including /boot and 
auto-apt snapshots with Timeshift
https://mutschler.eu/linux/install-guides/ubuntu-btrfs/

Linux Multiboot with BTRFS, LUKS and EFI (Part 2)
https://teejeetech.medium.com/linux-multiboot-with-btrfs-luks-and-efi-part-2-7b0896c03cce

Saludos,

-- 
Camaleón 

Failed to migrate controller cgroups

[Michael Grant]

I'm seeing warnings like this in my logs:

Jan  3 04:48:49 bottom systemd[3436917]: -.slice: Failed to migrate controller 
cgroups from /user.slice/user-108.slice/user@108.service, ignoring: Permission 
denied
Jan  3 08:20:25 bottom systemd[1410]: -.slice: Failed to migrate controller 
cgroups from /user.slice/user-108.slice/user@108.service, ignoring: Permission 
denied
Jan  3 08:20:25 bottom systemd[1411]: -.slice: Failed to migrate controller 
cgroups from /user.slice/user-115.slice/user@115.service, ignoring: Permission 
denied
Jan  3 08:41:04 bottom systemd[6153]: -.slice: Failed to migrate controller 
cgroups from /user.slice/user-1001.slice/user@1001.service, ignoring: 
Permission denied

I did some googling around and someone recommended looking at the output of 
journalctl:

# journalctl -b --no-hostname -u user@1001.service
-- Journal begins at Sat 2020-10-17 13:43:00 EDT, ends at Sun 2021-01-03 
08:41:16 EST. --
Jan 03 08:41:04 systemd[1]: Starting User Manager for UID 1001...
Jan 03 08:41:04 systemd[6153]: pam_unix(systemd-user:session): session opened 
for user strange by (uid=0)
Jan 03 08:41:04 systemd[6153]: Queued start job for default target Main User 
Target.
Jan 03 08:41:04 systemd[6153]: -.slice: Failed to migrate controller cgroups 
from /user.slice/user-1001.slice/user@1001.service, ignoring: Permission denied
Jan 03 08:41:04 systemd[6153]: Created slice User Application Slice.
Jan 03 08:41:04 systemd[6153]: Reached target Paths.
Jan 03 08:41:04 systemd[6153]: Reached target Timers.
Jan 03 08:41:04 systemd[6153]: Starting D-Bus User Message Bus Socket.
Jan 03 08:41:04 systemd[6153]: Listening on GnuPG network certificate 
management daemon.
Jan 03 08:41:04 systemd[6153]: Listening on GnuPG cryptographic agent and 
passphrase cache (access for web browsers).
Jan 03 08:41:04 systemd[6153]: Listening on GnuPG cryptographic agent and 
passphrase cache (restricted).
Jan 03 08:41:04 systemd[6153]: Listening on GnuPG cryptographic agent 
(ssh-agent emulation).
Jan 03 08:41:04 systemd[6153]: Listening on GnuPG cryptographic agent and 
passphrase cache.
Jan 03 08:41:04 systemd[6153]: Listening on D-Bus User Message Bus Socket.
Jan 03 08:41:04 systemd[6153]: Reached target Sockets.
Jan 03 08:41:04 systemd[6153]: Reached target Basic System.
Jan 03 08:41:04 systemd[6153]: Reached target Main User Target.
Jan 03 08:41:04 systemd[6153]: Startup finished in 119ms.
Jan 03 08:41:04 systemd[1]: Started User Manager for UID 1001.

But this isn't helpful in finding the problem.  Where else might I look to find 
out what is causing this permission error so that I can fix it?



signature.asc
Description: PGP signature

Debian10 btrfs+luks

[Borja Gutiérrez Fernández]

Buenas,

Quiero instalar Debian10 sobre btrfs y luks en un portatil nuevo. He
estado buscando documentación, y he encontrado algunos post en el foro
de Debian, con las que orientar el proceso. He probado la instalación en
una VM, y el proceso ha finalizado bien, pero en el momento de arranque
se me queda colgado, con un mensaje de error un tanto raro. Lo extraño, 
es que no me pide la contraseña para desbloquear las particiones
cifradas, y no tengo claro, dónde está el error. Mi pregunta es,
conocéis algún post o documento a modo de orientación?.

Muchas gracias.

-- 
Borja Gutiérrez Fernández.

RDP

[Pòl Hallen]

Hi folks :-)
sorry if question is semi-OT :)

I need to "exhume" old hw to exclusive use it with remmina RDP client

what's the best way? A lightweight debian distro?

is there a specific free distro? or use something like puppy linux?

thanks for help!

--
Pol

Re: Monitor Problem???

[Alexander V. Makartsev]

On 03.01.2021 16:58, Stephen P. Molnar wrote:
My main computer runs  Debian Buster and is displaying some unusual 
behavior.


The monitor is blanking, without warning, at random times, and 
restoring the screen  while I working. There is no warning, nor does 
the computer seem to be overheating (I continuously monitor the 
temperature).


I rather suspect that it may be a hardware problem. I keep the 
software up to date.


I am querying this group because I can't think of a more knowledgeable 
source. Any thoughts and suggestions of things that I might be able to 
test will be very welcome.


Thanks in advance.


What is model\make of the monitor? For how long was it in service?
Does it have a power led indicator? Does it change color from green 
(normal mode) to yellow (standby mode) during blanking?

Does it have an internal or external PSU?

From the description it sure does look like the monitor is the culprit 
and it is hardware problem.
I'd suspect dried out electrolytic capacitors on power lines. They need 
to be inspected and replaced with a new ones.
Or it could be flaky ribbon cable connections between internal PCBs 
and\or LCD. In this case you need to clean contacts of the cables with 
rubbing alcohol. Let them to dry out completely, before reassembling 
monitor.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Monitor Problem???

[hdv@gmail]

On 2021-01-03 12:58, Stephen P. Molnar wrote:
My main computer runs  Debian Buster and is displaying some unusual 
behavior.


The monitor is blanking, without warning, at random times, and restoring 
the screen  while I working. There is no warning, nor does the computer 
seem to be overheating (I continuously monitor the temperature).


I rather suspect that it may be a hardware problem. I keep the software 
up to date.


I am querying this group because I can't think of a more knowledgeable 
source. Any thoughts and suggestions of things that I might be able to 
test will be very welcome.


I suspect it is a software problem, not a hardware problem. The reason 
is I have been seeing the same for almost a year now with my display. I 
can't find anything that indicates a hardware problem and after all this 
time the display/monitor is still trucking on without the problem 
getting any worse.


I am not 100% sure, but it seems like sometimes the display is put into 
sleep mode and can't be woken up. Restarting X or doing a modprobe from 
a remote machine over ssh doesn't help. Nor does anything else. The only 
way to get the monitor to activate again is to reboot. After some 
digging I gave up on finding the root cause and accepted that I'd have 
to reboot once in a while. There is nothing in the logs to give any 
indication of a possible cause. Maybe I should have tried harder, but I 
just don't have the time for that at the moment.


FYI, this is the relevant hardware in my system:

MoBo = ASUS PRO WS X570-ACE
CPU = AMD Ryzen 9 3950X
Graphics = ASUS AREZ-RX560-4G-EVO

Debian version is Bullseye following testing very closely.

Sorry I can't help you with this.

Grx HdV

Re: Monitor Problem???

[Georgi Naplatanov]

On 1/3/21 1:58 PM, Stephen P. Molnar wrote:
> My main computer runs  Debian Buster and is displaying some unusual
> behavior.
> 
> The monitor is blanking, without warning, at random times, and restoring
> the screen  while I working. There is no warning, nor does the computer
> seem to be overheating (I continuously monitor the temperature).
> 
> I rather suspect that it may be a hardware problem. I keep the software
> up to date.
> 
> I am querying this group because I can't think of a more knowledgeable
> source. Any thoughts and suggestions of things that I might be able to
> test will be very welcome.
> 

Hi Stephen,

what kind of computer is yours - desktop or notebook?

In case it's a notebook what is exact model?

In case it's a desktop computer, what is the video card and which video
drivers are you using?

Kind regards
Georgi

Monitor Problem???

[Stephen P. Molnar]

My main computer runs  Debian Buster and is displaying some unusual 
behavior.


The monitor is blanking, without warning, at random times, and restoring 
the screen  while I working. There is no warning, nor does the computer 
seem to be overheating (I continuously monitor the temperature).


I rather suspect that it may be a hardware problem. I keep the software 
up to date.


I am querying this group because I can't think of a more knowledgeable 
source. Any thoughts and suggestions of things that I might be able to 
test will be very welcome.


Thanks in advance.

--
Stephen P. Molnar, Ph.D.
www.molecular-modeling.net
614.312.7528 (c)
Skype:  smolnar1

Re: Una de discs durs

[Eloi]

El 3/1/21 a les 11:59, Eloi ha escrit:

Responc entre línies i tallant part del missatge.

El 3/1/21 a les 9:01, Joan ha escrit:

[...]

Llavors, les meves preguntes:

1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
fer-li un clonezilla?


Una forma de determinar si és problema de maquinari seria fent servir 
badblocks, no per marcar els sectors defectuosos sinó simplement per 
saber si n'hi ha. En el teu cas, com que el disc és molt gran, 
necessitaries passar un paràmetre addicional. Pots provar això:


badblocks -b 4096 -e 1 -s -v /dev/

En detall: -b 4096 perquè el disc és gran (sense ell es nega a 
funcionar), -e 1 per parar al primer error que trobi, -s per tenir 
alguna cosa a mirar mentre va fent i -v perquè xerri una mica més.


Això sí, trigarà ESTONA (per a un disc de 4TB podria arribar a les 24 
hores) i mentrestant el disc hauria d'estar desmuntat.
Per cert, una puntualització important: el fet que trobi errors no vol 
dir necessàriament que estiguin al disc físic, doncs com bé s'ha 
comentat també podria ser problema del connector. Per filar més prim, si 
els errors passen sempre als mateixos sectors m'inclinaria a pensar en 
un problema propi del disc, però si passen a sectors diferents de forma 
aparentment aleatòria seria senyal que el problema està en la comunicació.

Re: Una de discs durs

[Eloi]

Responc entre línies i tallant part del missatge.

El 3/1/21 a les 9:01, Joan ha escrit:

[...]

Llavors, les meves preguntes:

1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
fer-li un clonezilla?


Una forma de determinar si és problema de maquinari seria fent servir 
badblocks, no per marcar els sectors defectuosos sinó simplement per 
saber si n'hi ha. En el teu cas, com que el disc és molt gran, 
necessitaries passar un paràmetre addicional. Pots provar això:


badblocks -b 4096 -e 1 -s -v /dev/

En detall: -b 4096 perquè el disc és gran (sense ell es nega a 
funcionar), -e 1 per parar al primer error que trobi, -s per tenir 
alguna cosa a mirar mentre va fent i -v perquè xerri una mica més.


Això sí, trigarà ESTONA (per a un disc de 4TB podria arribar a les 24 
hores) i mentrestant el disc hauria d'estar desmuntat.



2) Podria ser un problema originat pel software? (en aquest sentit no
sé si actualitzar la meva Debian Testing, que no actualitzo en general
de cop, sinó a bocinets).


El mal (si és que es tracta d'un error de programari, que seria estrany) 
ja està fet, a més si com dius el problema el tens en un disc secundari 
en principi actualitzar hauria de ser més o menys neutre. Potser l'única 
excepció seria si tens muntat /home allà i a l'arrencar de nou algun 
programa actualitzat comenci una migració de dades que compliqui encara 
més el tema.


Però vaja, per la meva experiència la causa més comuna d'errades 
massives de disc seria una apagada intempestiva, com quan se'n va la 
llum o desendolles el disc, si és extern, mentre encara treballa. Les 
errades físiques de disc solen ser més puntuals, a menys que el disc ja 
portés temps amb problemes.



3) No sé si al disc secundari és fa un fsck (o com es digui). Allò que
es fa al primari cada nosequantes arrencades. Diria que no, i que és
una opció configurable al fstab. El meu fstab és aquest:

UUID=... /   ext4errors=remount-ro 0   1
# /home was on /dev/sdb6 during installation
UUID=... /home   ext4defaults0   2
# swap was on /dev/sdb5 during installation
UUID=...swapsw  0   0
# Segon disc dur 4Tb
UUID=e... /media/magatzem   ext4defaults0   2

(de fet, ara que hi penso, no sé si es fa el fsck a la partició /home,
tampoc). Diria que això te a veure amb el darrer nombre de la columna,
però ara he vist que systemd s'ho munta diferent i només distingeix el
valor zero (o buit), i la resta:

https://unix.stackexchange.com/a/248578

I per tant ja no sé quan ni com es fan el txequejos.


El que determina el 1 o el 2 de l'última columna de fstab és en quin 
moment de l'arrencada cridar el fsck. Generalment es posa un 1 al 
sistema arrel (aleshores fsck s'executa des del ramdisk de l'init) i un 
2 per a la resta (fent servir, aquest cop, el fsck del sistema arrel). 
La idea era evitar que un fsck sobre un disc amb problemes fos el 
responsable de comprovar-lo.


El fet de determinar, per a sistemes ext*, si passar efectivament o no 
un fsck ve determinat per dues condicions: primer, si el sistema s'ha 
desmuntat incorrectament, queda un indicador al disc i quan el detecta 
fa la comprovació. Si no és el cas, el sistema de fitxers registra tant 
els dies que han passat com els cops que s'ha muntat des de l'últim 
fsck, i quan algun d'aquests dos valors supera un límit configurable 
aleshores fa la comprovació.


Per mirar tant quan fa que s'ha passat un fsck com la programació dels 
límits pots fer servir la comanda següent:


dumpe2fs -h /dev/XXX

Per exemple, entre altres línies treu:

Mount count:  10
Maximum mount count:  25
Last checked: Sun Oct 18 10:11:18 2020
Check interval:   7776000 (3 months)
Next check after: Sat Jan 16 09:11:18 2021

En aquest cas, he muntat el disc 10 vegades des de l'última comprovació, 
que es va fer el 18 d'octubre passat, i està programat perquè faci la 
següent comprovació després de muntar el disc 25 cops (o sigui, d'aquí 
15 muntades més) o al cap de 3 mesos (el 16 de gener), el que succeeixi 
abans.


Per ajustar els valors dels marges pots fer servir tune2fs, passant -c i 
un número de recompte de muntatges (25) o -i i un marge de temps en dies 
(90).


Tingues present, però, que un valor 0 al fstab per a les comprovacions 
pot fer i farà que aquests límits no s'apliquin de forma automàtica sinó 
quan facis tu manualment un fsck, motiu pel qual a vegades llançant-lo 
manualment (sense -f) no fa res i a vegades ho fa tot: els criteris per 
decidir-ho són els mateixos.



4) Un colega em va comentar que ell força un test SMART via script, no
sé si a l'arrencar... No sé si això és una bona opció... Teniu algun
suggeriment al respecte, per vetllar per la bona salut dels discs
(assumint que si el disc comença a fallar per la seva obsolescència
programada, no hi ha res a fer).


El 

Re: Una de discs durs

[Joan]

Merci Josep,

Un amic m'ha comentat que ell també va sol·lucionar un problema
semblant canviant el cable. Així que provaré això primer...

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Sun, 3 Jan 2021 09:29:35 +0100
Josep Lladonosa  va escriure:

> Hola, Joan,
> 
> 
> Que no sigui cosa del cable SATA.
> A la feina hem tingut experiències similars i canviant-lo s'ha resolt.
> 
> La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> exemple.
> 
> Cada fabricant indica la seva garantia.
> Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> que és de Western Digital, ara, i que també està bé).
> 
> Bon any,
> Josep
> 
> El dg., 3 de gen. 2021, 9:01, Joan  va escriure:
> 
> > El problema que tinc m'ha passat dugues vegades en dugues setmanes,
> > i tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb)
> > no massa vell, de potser un parell d'anys, o un problema del soft
> > que "desgabella" el disc
> >
> > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > plegat podria ser l'amule.
> >
> > Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> > queda en mode d'emergència, perquè detecta un error:
> >
> > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > 38666373 has an invalid extent node (blk 154697780, lblk 0) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > systemd-fsck[502]: (i.e., without -a or -p options) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit status
> > 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running request
> > emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > systemd[1]: systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > 16:21:12 pc2019 systemd[1]:
> > systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > systemd[1]: Failed to start File System Check on
> > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Job local-fs.target/start failed with result
> > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > media-magatzem.mount/start failed with result 'dependency'.
> >
> > I a mi em mostra aquesta pantalla:
> >
> >
> > https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> >
> > Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> >
> > Que em dona aquestes pantalles (les resumeixo, perquè bàsicament
> > son 20 minuts de anar dient "yes" a tot el que em proposa, després
> > de la revisió que dura unes 8 hores o més:
> >
> >
> > https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> >
> > https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> >
> > https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> >
> > Llavors, les meves preguntes:
> >
> > 1) Us sembla que és un fallo de hard (el disc comença a fer el
> > tonto, amb només 15 mesos), i ja em puc espabilar a comprar-ne un
> > altra i fer-li un clonezilla?
> >
> > 2) Podria ser un problema originat pel software? (en aquest sentit
> > no sé si actualitzar la meva Debian Testing, que no actualitzo en
> > general de cop, sinó a bocinets).
> >
> > 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò
> > que es fa al primari cada nosequantes arrencades. Diria que no, i
> > que és una opció configurable al fstab. El meu fstab és aquest:
> >
> > UUID=... /   ext4errors=remount-ro 0   1
> > # /home was on /dev/sdb6 during installation
> > UUID=... /home   ext4defaults0   2
> > # swap was on /dev/sdb5 during installation
> > UUID=...swapsw  0   0
> > # Segon disc dur 4Tb
> > UUID=e... /media/magatzem   ext4defaults0
> > 2
> >
> > (de fet, ara que hi penso, no sé si es fa el fsck a la partició
> > /home, tampoc). Diria que això te a veure amb el darrer nombre de
> > la columna, però ara he vist que systemd s'ho munta 

Firmweare des disques dur ?

[ptilou]

Slt,

Bonne année !

Je voulais vous dire que y’a peut depuis que j’ai installé le gestionnaire de 
*.deb, il a perdu le volet de sélection automatique de paquet, (genre station 
de bureau, serveur de fichier, n’as, noeud de serveur, etc ) sa m’oblige à 
chercher les paquets. ( suse 15.2)
(Tu me fais travailler, mais ta oublié de me payer ?)

Et alors trois disque dur, ont perdu leur firmware, et un va chez seagate en 
récupération de données et deux en échange de garanties, la c’est technique, 
puisque les premiere recherche montre qu’il faut connaître courant et tension 
et que c’est augmentant un des deux facteur, que l’on peut écrire sur la 
mémoire ?

J’ai un troisième disque qui est en convalescence, et j’ai re-installé sur une 
clés USB, et là clés boot, puit après elle cherche sur le support usb,la 
partition boot ?
Là clés je l’as sort elle est totalement intégré sur une autre station , pas 
besoin d’un Fsck.
C’est le bios ?

https://photos.app.goo.gl/B2iNKXjhT1gaGFRc9

Et donc en urgence abonnement premier chez Jeff, fermeture chez le fruit vérolé 
des deux abonnements, puis celui de Jeff, pour ouvrir chez microchiot, donc on 
travail dans l’urgence et c’est pas bon pour vous !

Mais l’effacement des firmware de disque dur je ne connaissais pas, en faite je 
change de machine et de convertisseur, on attend l’initialisation du disque les 
deux voyant rouge (tension) bleu échange sur le bus série ? Et rien à l’écran 
des systèmes : ni lsusb, ni lspci, mount, fdisk, il existe quoi d’autre comme 
commande ?

— 
Ptilou

Re: ZFS guidance

[Andrei POPESCU]

On Sb, 02 ian 21, 16:10:39, Gregory Seidman wrote:
> I've been running 10+ LVM volumes on top of dmcrypt on top of md RAID1 on
> Debian for many, many years and it has served me well. I've been
> double-mirroring (i.e. three active drives in the RAID array) for the last
> several with the idea that I can manually fail a disk, pull it out (and
> replace with a fresh drive), and put it somewhere safe off-site as an easy
> approach to backup (and I'm only concerned with disaster recovery, not
> individual file recovery).

Does this mean you don't care if you delete or change a file by mistake?

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


signature.asc
Description: PGP signature

Re: recommendations for supported, affordable hardware raid controller.

[Andrei POPESCU]

On Sb, 02 ian 21, 13:35:06, David Christensen wrote:
> On 2021-01-02 03:24, Andrei POPESCU wrote:
> 
> > http://www.unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html
> 
> That looks interesting.  Thanks for the link.  :-)
> 
> 
> On 2021-01-02 08:08, Richard Hector wrote:
> > On 3/01/21 12:24 am, Andrei POPESCU wrote:
> > > In case of data corruption (system crash, power outage, user error,
> > > or even just a HDD "hiccup") plain md without the dm-integrity
> > > layer won't even be able to tell which is the good data and will
> > > overwrite your good data with bad data. Silently.
> 
> > I've had crashes and power outages and never noticed any problems,
> > not that that means they won't happen (or even that they haven't
> > happened). Does a journalling filesystem on top not cover that?
> 
> AIUI a journaling filesystem provides a two-step process to achieve atomic
> writes of multiple sectors to disk -- e.g. a process wants to put some data
> into a block here (say, a file), a block there (say, a directory), etc., and
> consistency of the on-disk data structures must be preserved.  The journal
> provides a two-step process whereby everything is written to the journal,
> then everything is written to disk.

That would mean all data is written to the disk twice and would make a 
journaling file system twice as slow compared to a non-journaling file 
system; the journal is typically on the same storage.

Even if you put the journal on another storage, having the data written 
there in parallel would basically result in a sort of RAID ;)

> If either step is interrupted, the
> filesystem driver will detect the failure and respond.  When done, either
> all of the blocks have been updated on disk or none of the blocks on disk
> have been changed.

My understanding of [1] is that the journal only keeps track of metadata 
and/or data *updates*.

In case of a crash it can only tell you whether the write was 
"completed". It has no way to know whether the data on disk is actually 
correct.

[1] https://en.wikipedia.org/wiki/Journaling_file_system

When using a non-checksumming file system we are trusting the storage to 
either return correct data or report a read error (bad block) in order 
to restore it from the "other" copies (in case of RAID) or, worst case, 
from backup.

If the storage returns *wrong* data instead a non-checksumming file 
system will never notice as it has no concept of what the correct data 
should be. 

A RAID by itself is also unable to distinguish between correct and 
incorrect data and may even overwrite the good data with the bad data.

If we are lucky the error is noticed *and* the backups contain the 
correct data (the backup may have been created from the corrupt data).

Without good integrity checks it is also very difficult to tell how 
probable such issues are.


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


signature.asc
Description: PGP signature

Re: Cannot compile qemu

[tomas]

On Sat, Jan 02, 2021 at 07:57:02PM +0100, Kamil Jońca wrote:
> 
> I tried to compile qemu by myself (this is not the first time).
> I issued
> %sudo apt-get build-dep qemu
> %apt-get source qemu
> and then
> in qemu directory
> %debuild -us -uc -b
> claims about header files:

[...]

> config-temp/qemu-conf.c:1:10: fatal error: sys/endian.h: No such file or 
> directory
> 1 | #include 
>   |  ^~
> compilation terminated.
> 
> any hints?

No idea whether this leads somewhere, but FWIW, sys/endian.h is in
libbsd-dev:

| tomas@trotzki:~$ apt-file search sys/endian.h
| freebsd-glue: /usr/include/freebsd/sys/endian.h
| libbsd-dev: /usr/include/bsd/sys/endian.h

Perhaps there's a buglet in quemu's build deps, perhaps there are
other forces at play.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Cannot compile qemu

[deloptes]

Kamil Jońca wrote:

> cc -fPIE -DPIE -std=gnu99 -Wall -m64 -mcx16 -D_GNU_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
> -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes
> -fno-strict-aliasing -fno-common -fwrapv -g -O2
> -fdebug-prefix-map=/home/kjonca/tmp/debian/qemu-5.2+dfsg=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wold-style-declaration -Wold-style-definition
> -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self
> -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
> -Wexpansion-to-defined -Wno-missing-include-dirs -Wno-shift-negative-value
> -Wno-psabi -fstack-protector-strong -o config-temp/qemu-conf.exe
> config-temp/qemu-conf.c -pie -Wl,-z,relro -Wl,-z,now -m64 -g -O2
> -fdebug-prefix-map=/home/kjonca/tmp/debian/q emu-5.2+dfsg=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong
> config-temp/qemu-conf.c:1:10: fatal error: sys/endian.h: No such file or
> directory 1 | #include  |          ^~
> compilation terminated.
> 
> any hints?

Hi,
I compiled qemu debian packages customized (basically removing all the stuff
and architectures I do not need) few weeks ago.
I used qemu (svn/git) source and debian packaging for buster.
To compile the default setup you need a lot of cross-compile tools. 
My goal was to get the arm emulator without GUI. It took me about a week to
get the proper configuration (altering the debian defaults).
Either you install all the tools, or you need to adjust the configuration.

I just wonder why you compile config-temp/qemu-conf.exe < EXE?
I admit this is very odd

regards

Re: Una de discs durs

[Josep Lladonosa]

Hola, Joan,


Que no sigui cosa del cable SATA.
A la feina hem tingut experiències similars i canviant-lo s'ha resolt.

La fiabilitat dels discs durs és poca, sempre és recomanable tenir còpies
de seguretat i fer-los treballar per parelles, en raid 1, per exemple.

Cada fabricant indica la seva garantia.
Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec que és
de Western Digital, ara, i que també està bé).

Bon any,
Josep

El dg., 3 de gen. 2021, 9:01, Joan  va escriure:

> El problema que tinc m'ha passat dugues vegades en dugues setmanes, i
> tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb) no
> massa vell, de potser un parell d'anys, o un problema del soft que
> "desgabella" el disc
>
> És un disc secundari (el sistema el tinc en un SSD) a on guardo videos,
> fotos, etc. Un dels meus sospitosos com a causa de tot plegat podria
> ser l'amule.
>
> Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> queda en mode d'emergència, perquè detecta un error:
>
> de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode 38666373
> has an invalid extent node (blk 154697780, lblk 0) de gen. 02 16:21:12
> pc2019 systemd-fsck[502]: magatzem: UNEXPECTED INCONSISTENCY; RUN fsck
> MANUALLY. de gen. 02 16:21:12 pc2019 systemd-fsck[502]: (i.e.,
> without -a or -p options) de gen. 02 16:21:12 pc2019 systemd-fsck[430]:
> fsck failed with exit status 4. de gen. 02 16:21:12 pc2019
> systemd-fsck[430]: Running request emergency.target/start/replace de
> gen. 02 16:21:12 pc2019 systemd[1]:
> systemd-fsck@dev-disk-by
> \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Main process exited, code=exited, status=1/FAILURE de gen. 02 16:21:12
> pc2019 systemd[1]:
> systemd-fsck@dev-disk-by
> \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019 systemd[1]:
> Failed to start File System Check on
> /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem. de
> gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local File
> Systems. de gen. 02 16:21:12 pc2019 systemd[1]: local-fs.target: Job
> local-fs.target/start failed with result 'dependency'. de gen. 02
> 16:21:12 pc2019 systemd[1]: local-fs.target: Triggering OnFailure=
> dependencies. de gen. 02 16:21:12 pc2019 systemd[1]:
> media-magatzem.mount: Job media-magatzem.mount/start failed with result
> 'dependency'.
>
> I a mi em mostra aquesta pantalla:
>
>
> https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
>
> Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
>
> Que em dona aquestes pantalles (les resumeixo, perquè bàsicament son 20
> minuts de anar dient "yes" a tot el que em proposa, després de la
> revisió que dura unes 8 hores o més:
>
>
> https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
>
> https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
>
> https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
>
> Llavors, les meves preguntes:
>
> 1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
> amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
> fer-li un clonezilla?
>
> 2) Podria ser un problema originat pel software? (en aquest sentit no
> sé si actualitzar la meva Debian Testing, que no actualitzo en general
> de cop, sinó a bocinets).
>
> 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò que
> es fa al primari cada nosequantes arrencades. Diria que no, i que és
> una opció configurable al fstab. El meu fstab és aquest:
>
> UUID=... /   ext4errors=remount-ro 0   1
> # /home was on /dev/sdb6 during installation
> UUID=... /home   ext4defaults0   2
> # swap was on /dev/sdb5 during installation
> UUID=...swapsw  0   0
> # Segon disc dur 4Tb
> UUID=e... /media/magatzem   ext4defaults0   2
>
> (de fet, ara que hi penso, no sé si es fa el fsck a la partició /home,
> tampoc). Diria que això te a veure amb el darrer nombre de la columna,
> però ara he vist que systemd s'ho munta diferent i només distingeix el
> valor zero (o buit), i la resta:
>
> https://unix.stackexchange.com/a/248578
>
> I per tant ja no sé quan ni com es fan el txequejos.
>
> 4) Un colega em va comentar que ell força un test SMART via script, no
> sé si a l'arrencar... No sé si això és una bona opció... Teniu algun
> suggeriment al respecte, per vetllar per la bona salut dels discs
> (assumint que si el disc comença a fallar per la seva obsolescència
> programada, no hi ha res a fer).
>
> 5) Per cert, sabeu quina garantia tenen, els discos durs? I, en cas de
> comprar-ne un de nou, si n'hi ha que donin més fiabilitat?
>
> Fins ara!
>
> --
> Joan Cervan i Andreu
> http://personal.calbasi.net
>
> 

Una de discs durs

[Joan]

El problema que tinc m'ha passat dugues vegades en dugues setmanes, i
tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb) no
massa vell, de potser un parell d'anys, o un problema del soft que
"desgabella" el disc

És un disc secundari (el sistema el tinc en un SSD) a on guardo videos,
fotos, etc. Un dels meus sospitosos com a causa de tot plegat podria
ser l'amule.

Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
queda en mode d'emergència, perquè detecta un error:

de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode 38666373
has an invalid extent node (blk 154697780, lblk 0) de gen. 02 16:21:12
pc2019 systemd-fsck[502]: magatzem: UNEXPECTED INCONSISTENCY; RUN fsck
MANUALLY. de gen. 02 16:21:12 pc2019 systemd-fsck[502]: (i.e.,
without -a or -p options) de gen. 02 16:21:12 pc2019 systemd-fsck[430]:
fsck failed with exit status 4. de gen. 02 16:21:12 pc2019
systemd-fsck[430]: Running request emergency.target/start/replace de
gen. 02 16:21:12 pc2019 systemd[1]:
systemd-fsck@dev-disk-by\x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
Main process exited, code=exited, status=1/FAILURE de gen. 02 16:21:12
pc2019 systemd[1]:
systemd-fsck@dev-disk-by\x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019 systemd[1]:
Failed to start File System Check on
/dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem. de
gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local File
Systems. de gen. 02 16:21:12 pc2019 systemd[1]: local-fs.target: Job
local-fs.target/start failed with result 'dependency'. de gen. 02
16:21:12 pc2019 systemd[1]: local-fs.target: Triggering OnFailure=
dependencies. de gen. 02 16:21:12 pc2019 systemd[1]:
media-magatzem.mount: Job media-magatzem.mount/start failed with result
'dependency'.

I a mi em mostra aquesta pantalla:

https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=

Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1

Que em dona aquestes pantalles (les resumeixo, perquè bàsicament son 20
minuts de anar dient "yes" a tot el que em proposa, després de la
revisió que dura unes 8 hores o més:

https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=

Llavors, les meves preguntes:

1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
fer-li un clonezilla?

2) Podria ser un problema originat pel software? (en aquest sentit no
sé si actualitzar la meva Debian Testing, que no actualitzo en general
de cop, sinó a bocinets).

3) No sé si al disc secundari és fa un fsck (o com es digui). Allò que
es fa al primari cada nosequantes arrencades. Diria que no, i que és
una opció configurable al fstab. El meu fstab és aquest:

UUID=... /   ext4errors=remount-ro 0   1
# /home was on /dev/sdb6 during installation
UUID=... /home   ext4defaults0   2
# swap was on /dev/sdb5 during installation
UUID=...swapsw  0   0
# Segon disc dur 4Tb
UUID=e... /media/magatzem   ext4defaults0   2

(de fet, ara que hi penso, no sé si es fa el fsck a la partició /home,
tampoc). Diria que això te a veure amb el darrer nombre de la columna,
però ara he vist que systemd s'ho munta diferent i només distingeix el
valor zero (o buit), i la resta:

https://unix.stackexchange.com/a/248578

I per tant ja no sé quan ni com es fan el txequejos.

4) Un colega em va comentar que ell força un test SMART via script, no
sé si a l'arrencar... No sé si això és una bona opció... Teniu algun
suggeriment al respecte, per vetllar per la bona salut dels discs
(assumint que si el disc comença a fallar per la seva obsolescència
programada, no hi ha res a fer). 

5) Per cert, sabeu quina garantia tenen, els discos durs? I, en cas de
comprar-ne un de nou, si n'hi ha que donin més fiabilitat?

Fins ara!

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi