Re: dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
I discovred on some BIOSes undocumented features: Some options can be enabled when set UEFI active, or also when setting a boot password and a BIOS password. Sometimes even new settings appear, when passwords are set. I know, this sounds weired, but as I said: this ware undocumented. Also take a look at "modified bioses". There are many people, who are reverse engennering BIOSes, and add things or set things free. There are some sites in the web, where you can get modded bioses. They are mostly tested and never had problems with those. This is an example: https://www.bios-mods.com/downloads/[1] but I suggest to search for other sites, too. Hope this helps. Good luck, Hans [1] https://www.bios-mods.com/downloads/
Re: dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
On Tue, Jan 09, 2024 at 04:50:28AM +, Albretch Mueller wrote: > On 1/6/24, Albretch Mueller wrote: > > I may not even have an NVMe card in my computer as the manufacturer > > claims. > > My DELL Inspiron 5593 actually does have a M.2 512GB KIOXIA NVMe SSD, > which I need to use! The problem, as I described here without getting > a solution for it: > > // __ I cannot change BIOS settings on my laptop? > > > https://forums.tomshardware.com/threads/i-cannot-change-bios-settings-on-my-laptop.3833102/ > ~ Where did the laptop come from? Some (few) ex-business laptops are sold with a BIOS password set by an original owner, say, where the vendor has reconditioned them but can't unlock the BIOS. That is unusual: if the worst comes to the worst, just reflash the BIOS. > is that I can't access/change the BIOS settings on my own laptop to > make the hdd work in AHCI mode, I think. I have also read that Debian > Linux has problems operating such cards: > Which operating system(s) do you have on this? Do you have a Windows 10 that was preinstalled by someone? Dells have an annoying habit of installing with the BIOS setting as RAID by default. if Windows or another operating system is there and already installed, it may be that you can't modify it while there's an OS using it, if you see what I mean. The same goes for a vendor installing Windows as Legacy/MBR - if you then want to change to UEFI, it's easier just to reinstall the whole thing. > https://superuser.com/questions/1502756/debian-not-detecting-nvme-asus-zenbook-ux430ua > > I purchased a Dell XPS 8930 with an NVMe dirve. Debian and Fedora did > not recognize the NVMe. I had to use Ubuntu 18.04 for the drive to be > recognized. I'm not sure what Ubuntu is doing that Debian is not, but > I suspect it has something to do with updates. Debian tends to stick > with old and broken software. They will not upgrade for users. – jww > Nov 23, 2019 at 4:28 > ~ That's a very old quote now ... > You may know how to deal with such problems, better than I do, since > I don't tend to mind the intricate technical details about computer > hardware, even though I understand well the physics in them. > Can you get into the BIOS to change anything e.g. time settings or default NumLock to check? > Every piece of computer hardware my paranoia uses seems to have a > mind of its own. I have decided to not use computers (do all the > writing by hand on paper), but the data processing and algorithmic > basis of my paper I have to do on a computer. > > Any suggestions? > > lbrtchx > All best, as ever, Andy (amaca...@debian.org)
Re: dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
On 1/6/24, Albretch Mueller wrote: > I may not even have an NVMe card in my computer as the manufacturer > claims. My DELL Inspiron 5593 actually does have a M.2 512GB KIOXIA NVMe SSD, which I need to use! The problem, as I described here without getting a solution for it: // __ I cannot change BIOS settings on my laptop? https://forums.tomshardware.com/threads/i-cannot-change-bios-settings-on-my-laptop.3833102/ ~ is that I can't access/change the BIOS settings on my own laptop to make the hdd work in AHCI mode, I think. I have also read that Debian Linux has problems operating such cards: https://superuser.com/questions/1502756/debian-not-detecting-nvme-asus-zenbook-ux430ua I purchased a Dell XPS 8930 with an NVMe dirve. Debian and Fedora did not recognize the NVMe. I had to use Ubuntu 18.04 for the drive to be recognized. I'm not sure what Ubuntu is doing that Debian is not, but I suspect it has something to do with updates. Debian tends to stick with old and broken software. They will not upgrade for users. – jww Nov 23, 2019 at 4:28 ~ You may know how to deal with such problems, better than I do, since I don't tend to mind the intricate technical details about computer hardware, even though I understand well the physics in them. Every piece of computer hardware my paranoia uses seems to have a mind of its own. I have decided to not use computers (do all the writing by hand on paper), but the data processing and algorithmic basis of my paper I have to do on a computer. Any suggestions? lbrtchx
Re: dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
Sorry, but I don't think I am making much sense out those reported errors. I may not even have an NVMe card in my computer as the manufacturer claims. lbrtchx
Re: dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
On 1/6/24, Jeffrey Walton wrote: > Before going down the rabbit hole, I would: > > 2. use a new [known good] ethernet cable I am not even using a cable! >There is another discussion of PCI AER at ><https://forums.developer.nvidia.com/t/pcie-bus-error-severity-corrected-type-physical-layer-id-0010-receiver-id/251840/19>. >You might find something of interest in it. Thank you I spent some time going over their discussions which in two cases were pretty similar to my problem and I decided to post my problem: https://forums.developer.nvidia.com/t/dmesg-reporting-lots-of-errors-apparently-relating-to-my-nvidia-card-and-realtek-rtl810xe-pci-express-fast-ethernet-controller/278001 I will let you know how it went. lbrtchx
Re: dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
On Fri, Jan 5, 2024 at 9:18 AM Albretch Mueller wrote: > > I decided to upgrade to Bookworm because I needed to use some NVRAM > memory supposedly available in my computer, but then my wireless > Ethernet started to "complain". I initially thought those errors might > be related to the lazy use of the Ethernet drivers from Bullseye but > when I started to use Bookworm's drivers the errors became more > complicated. Following some hints from: > > > https://askubuntu.com/questions/863150/pcie-bus-error-severity-corrected-type-physical-layer-id-00e5receiver-id > > [290569.588458] pcieport :00:1d.0: AER: Multiple Corrected error > received: :01:00.0 > [290569.588488] r8169 :01:00.0: PCIe Bus Error: > severity=Corrected, type=Physical Layer, (Receiver ID) > [290569.588489] r8169 :01:00.0: device [10ec:8136] error > status/mask=0001/6000 > [290569.588491] r8169 :01:00.0:[ 0] RxErr (First) > > I found out it was the Realtek RTL810xE PCI Express Fast Ethernet controller: > > $ lspci -nn | grep PCIe > 00:1d.1 PCI bridge [0604]: Intel Corporation Ice Lake-LP PCIe Port > [8086:34b1] (rev 30) > > $ sudo hwinfo --pci > ... > 14: PCI 100.0: 0200 Ethernet controller > [Created at pci.386] > Unique ID: lkKU.j9EpqGNzpV9 > Parent ID: 1GTX.j6F4IaHYGk7 > SysFS ID: /devices/pci:00/:00:1d.0/:01:00.0 > SysFS BusID: :01:00.0 > Hardware Class: network > Model: "Realtek RTL810xE PCI Express Fast Ethernet controller" > Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd." > Device: pci 0x8136 "RTL810xE PCI Express Fast Ethernet controller" > SubVendor: pci 0x1028 "Dell" > SubDevice: pci 0x097c > Revision: 0x07 > Driver: "r8169" > Driver Modules: "r8169" > Device File: enp1s0 > I/O Ports: 0x3000-0x3fff (rw) > Memory Range: 0x9140-0x91400fff (rw,non-prefetchable) > Memory Range: 0x9120-0x91203fff (ro,non-prefetchable) > IRQ: 16 (2575859 events) > HW Address: c0:3e:ba:26:aa:93 > Permanent HW Address: c0:3e:ba:26:aa:93 > Link detected: no > Module Alias: "pci:v10ECd8136sv1028sd097Cbc02sc00i00" > Driver Info #0: > Driver Status: r8169 is active > Driver Activation Cmd: "modprobe r8169" > Config Status: cfg=new, avail=yes, need=no, active=unknown > ... > $ > > $ sudo hwinfo --network > 25: None 00.0: 10701 Ethernet > [Created at net.126] > Unique ID: VV91.ndpeucax6V1 > Parent ID: qru8.BzdVZ3YOQjC > SysFS ID: /class/net/wlp2s0 > SysFS Device Link: /devices/pci:00/:00:1d.1/:02:00.0 > Hardware Class: network interface > Model: "Ethernet network interface" > Driver: "ath10k_pci" > Driver Modules: "ath10k_pci" > Device File: wlp2s0 > HW Address: 5c:3a:45:0a:fb:c1 > Permanent HW Address: 5c:3a:45:0a:fb:c1 > Link detected: yes > Config Status: cfg=new, avail=yes, need=no, active=unknown > Attached to: #4 (Ethernet controller) > > 26: None 00.0: 10700 Loopback > [Created at net.126] > Unique ID: ZsBS.GQNx7L4uPNA > SysFS ID: /class/net/lo > Hardware Class: network interface > Model: "Loopback network interface" > Device File: lo > Link detected: yes > Config Status: cfg=new, avail=yes, need=no, active=unknown > > 27: None 00.0: 10701 Ethernet > [Created at net.126] > Unique ID: QObM.ndpeucax6V1 > Parent ID: lkKU.j9EpqGNzpV9 > SysFS ID: /class/net/enp1s0 > SysFS Device Link: /devices/pci:00/:00:1d.0/:01:00.0 > Hardware Class: network interface > Model: "Ethernet network interface" > Driver: "r8169" > Driver Modules: "r8169" > Device File: enp1s0 > HW Address: c0:3e:ba:26:aa:93 > Permanent HW Address: c0:3e:ba:26:aa:93 > Link detected: no > Config Status: cfg=new, avail=yes, need=no, active=unknown > Attached to: #8 (Ethernet controller) > $ > > After using Bookworm drivers I am still getting: > > [ 9514.141680] pcieport 0000:00:1d.0: AER: Multiple Corrected error > received: :01:00.0 > [ 9514.141723] r8169 :01:00.0: PCIe Bus Error: severity=Corrected, > type=Physical Layer, (Receiver ID) > [ 9514.141728] r8169 :01:00.0: device [10ec:8136] error > status/mask=0001/6000 > [ 9514.141734] r8169 :01:00.0:[ 0] RxErr (First) > > Why would such errors start happening with I tried to use the NVRAM > card? Why would that happen? How do you troubleshoot such errors in a > more in depth way? Before going down the rabbit hole, I would: 1. update f
Re: dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
I started my computer with the Bullseye Debian live DVD and the dmesg log is not flooded with such error messages (as it does with Bookworm): [ 8095.737532] pcieport :00:1d.0: AER: Multiple Corrected error received: :01:00.0 [ 8095.737572] r8169 :01:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [ 8095.737576] r8169 :01:00.0: device [10ec:8136] error status/mask=0001/6000 [ 8095.737579] r8169 :01:00.0:[ 0] RxErr (First) This is what dmesg told me about the two networking interfaces (before I exposed my computer): $ sudo dmesg | grep "r8169\|ath10k_pci" [1.162609] r8169 :01:00.0 eth0: RTL8106e, c0:3e:ba:26:aa:93, XID 449, IRQ 124 [1.191058] r8169 :01:00.0 enp1s0: renamed from eth0 [ 47.676697] ath10k_pci :02:00.0: enabling device ( -> 0002) [ 47.677983] ath10k_pci :02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 47.982673] ath10k_pci :02:00.0: firmware: failed to load ath10k/pre-cal-pci-:02:00.0.bin (-2) [ 47.982709] ath10k_pci :02:00.0: firmware: failed to load ath10k/cal-pci-:02:00.0.bin (-2) [ 47.982723] ath10k_pci :02:00.0: firmware: failed to load ath10k/QCA9377/hw1.0/firmware-6.bin (-2) [ 47.982735] ath10k_pci :02:00.0: firmware: failed to load ath10k/QCA9377/hw1.0/firmware-5.bin (-2) [ 47.982747] ath10k_pci :02:00.0: firmware: failed to load ath10k/QCA9377/hw1.0/firmware-4.bin (-2) [ 47.982758] ath10k_pci :02:00.0: firmware: failed to load ath10k/QCA9377/hw1.0/firmware-3.bin (-2) [ 47.982771] ath10k_pci :02:00.0: firmware: failed to load ath10k/QCA9377/hw1.0/firmware-2.bin (-2) [ 47.982774] ath10k_pci :02:00.0: Failed to find firmware-N.bin (N between 2 and 6) from ath10k/QCA9377/hw1.0: -2 [ 47.982777] ath10k_pci :02:00.0: could not fetch firmware files (-2) [ 47.982779] ath10k_pci :02:00.0: could not probe fw (-2) [ 88.046124] r8169 :01:00.0: firmware: failed to load rtl_nic/rtl8106e-1.fw (-2) [ 88.046204] r8169 :01:00.0: Direct firmware load for rtl_nic/rtl8106e-1.fw failed with error -2 [ 88.046223] r8169 :01:00.0: Unable to load firmware rtl_nic/rtl8106e-1.fw (-2) [ 88.046679] RTL8208 Fast Ethernet r8169-0-100:00: attached PHY driver [RTL8208 Fast Ethernet] (mii_bus:phy_addr=r8169-0-100:00, irq=IGNORE) [ 88.213703] r8169 :01:00.0 enp1s0: Link is Down Then I install the ath10 drivers to be able to connect to the Internet and dmesg is still fine, but I can't use the NVRAM. $ sudo lspci -nn | grep PCIe $ $ sudo lspci -nn | grep PCI 00:1d.0 PCI bridge [0604]: Intel Corporation Ice Lake-LP PCI Express Root Port #9 [8086:34b0] (rev 30) 00:1d.1 PCI bridge [0604]: Intel Corporation Device [8086:34b1] (rev 30) 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller [10ec:8136] (rev 07) $ In order to use the NVRAM you suggested to me to update to Bookworm, but then there appears to be some conflict between the NVRAM which I do see and the wired Realtek Ethernet controller, which I don't understand because I am not using that: 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller (rev 07) firmware at all. Any elucidations on such firm-, hardware, OS conflicts? lbrtchx
dmesg reporting lots of errors apparently emanating from a Realtek RTL810xE PCI Express Fast Ethernet controller ...
I decided to upgrade to Bookworm because I needed to use some NVRAM memory supposedly available in my computer, but then my wireless Ethernet started to "complain". I initially thought those errors might be related to the lazy use of the Ethernet drivers from Bullseye but when I started to use Bookworm's drivers the errors became more complicated. Following some hints from: https://askubuntu.com/questions/863150/pcie-bus-error-severity-corrected-type-physical-layer-id-00e5receiver-id [290569.588458] pcieport :00:1d.0: AER: Multiple Corrected error received: :01:00.0 [290569.588488] r8169 :01:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [290569.588489] r8169 :01:00.0: device [10ec:8136] error status/mask=0001/6000 [290569.588491] r8169 :01:00.0:[ 0] RxErr (First) I found out it was the Realtek RTL810xE PCI Express Fast Ethernet controller: $ lspci -nn | grep PCIe 00:1d.1 PCI bridge [0604]: Intel Corporation Ice Lake-LP PCIe Port [8086:34b1] (rev 30) $ sudo hwinfo --pci ... 14: PCI 100.0: 0200 Ethernet controller [Created at pci.386] Unique ID: lkKU.j9EpqGNzpV9 Parent ID: 1GTX.j6F4IaHYGk7 SysFS ID: /devices/pci:00/:00:1d.0/:01:00.0 SysFS BusID: :01:00.0 Hardware Class: network Model: "Realtek RTL810xE PCI Express Fast Ethernet controller" Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd." Device: pci 0x8136 "RTL810xE PCI Express Fast Ethernet controller" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x097c Revision: 0x07 Driver: "r8169" Driver Modules: "r8169" Device File: enp1s0 I/O Ports: 0x3000-0x3fff (rw) Memory Range: 0x9140-0x91400fff (rw,non-prefetchable) Memory Range: 0x9120-0x91203fff (ro,non-prefetchable) IRQ: 16 (2575859 events) HW Address: c0:3e:ba:26:aa:93 Permanent HW Address: c0:3e:ba:26:aa:93 Link detected: no Module Alias: "pci:v10ECd8136sv1028sd097Cbc02sc00i00" Driver Info #0: Driver Status: r8169 is active Driver Activation Cmd: "modprobe r8169" Config Status: cfg=new, avail=yes, need=no, active=unknown ... $ $ sudo hwinfo --network 25: None 00.0: 10701 Ethernet [Created at net.126] Unique ID: VV91.ndpeucax6V1 Parent ID: qru8.BzdVZ3YOQjC SysFS ID: /class/net/wlp2s0 SysFS Device Link: /devices/pci:00/:00:1d.1/:02:00.0 Hardware Class: network interface Model: "Ethernet network interface" Driver: "ath10k_pci" Driver Modules: "ath10k_pci" Device File: wlp2s0 HW Address: 5c:3a:45:0a:fb:c1 Permanent HW Address: 5c:3a:45:0a:fb:c1 Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #4 (Ethernet controller) 26: None 00.0: 10700 Loopback [Created at net.126] Unique ID: ZsBS.GQNx7L4uPNA SysFS ID: /class/net/lo Hardware Class: network interface Model: "Loopback network interface" Device File: lo Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown 27: None 00.0: 10701 Ethernet [Created at net.126] Unique ID: QObM.ndpeucax6V1 Parent ID: lkKU.j9EpqGNzpV9 SysFS ID: /class/net/enp1s0 SysFS Device Link: /devices/pci:00/:00:1d.0/:01:00.0 Hardware Class: network interface Model: "Ethernet network interface" Driver: "r8169" Driver Modules: "r8169" Device File: enp1s0 HW Address: c0:3e:ba:26:aa:93 Permanent HW Address: c0:3e:ba:26:aa:93 Link detected: no Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #8 (Ethernet controller) $ After using Bookworm drivers I am still getting: [ 9514.141680] pcieport :00:1d.0: AER: Multiple Corrected error received: :01:00.0 [ 9514.141723] r8169 :01:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [ 9514.141728] r8169 0000:01:00.0: device [10ec:8136] error status/mask=0001/6000 [ 9514.141734] r8169 :01:00.0:[ 0] RxErr (First) Why would such errors start happening with I tried to use the NVRAM card? Why would that happen? How do you troubleshoot such errors in a more in depth way? lbrtchx
Re: Debian 12: errors when using Python3 venv?
Hello On 15.6.2023 7.03, Kushal Kumaran wrote: On Wed, Jun 14 2023 at 03:55:44 PM, Nicholas Papadonis wrote: Hi, I just cleanly installed Debian 11 and am trying to create a virtual environment for Python. I get the following error, does anyone know how to resolve this? Am I missing some packages that need to be installed? 1843 [deb12:~]$ python3 -m venv pt Traceback (most recent call last): File "", line 189, in _run_module_as_main File "", line 148, in _get_module_details File "", line 112, in _get_module_details File "/usr/lib/python3.11/venv/__init__.py", line 7, in import logging File "/usr/lib/python3.11/logging/__init__.py", line 43, in import threading File "/home/vboxuser/threading.py", line 3, in sem = threading.Semaphore() ^^^ AttributeError: partially initialized module 'threading' has no attribute 'Semaphore' (most likely due to a circular import) Your /home/vboxuser/threading.py is hiding the threading module from the python standard library. Python is loading the first file with .py extension as module when it is requested by an import in the called script. Even an empty file is loaded as module. The feature or bad thing is that the current directory is in the python path. $ touch threading.py $ python -m venv my_venv Traceback (most recent call last): File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details return _get_module_details(pkg_main_name, error) File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details __import__(pkg_name) File "/usr/lib/python3.10/venv/__init__.py", line 7, in import logging File "/usr/lib/python3.10/logging/__init__.py", line 217, in _lock = threading.RLock() AttributeError: module 'threading' has no attribute 'RLock' Error in sys.excepthook: BR, Roland
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
Mario Marietto (12023-06-21): > A rude behavior like yours The rude person here is you and only you. -- Nicolas George
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
@Nicolas George : what about if I don't understand what ? I presume that between us before all there are some relevant cultural differences. A rude behavior like yours is not tolerable,since I haven't offended you personally. I have only expressed opinions based on the cultural view of the place where I live. So,try to be calm. We are reasonable people,I think. I want to think this. On Wed, Jun 21, 2023 at 9:18 AM Nicolas George wrote: > Mario Marietto (12023-06-20): > > Or am I missing something ? > > Yes, a lot. > > -- > Nicolas George > > -- Mario.
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
Mario Marietto (12023-06-20): > Or am I missing something ? Yes, a lot. -- Nicolas George
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
@nicolas george : you consider yourself a democratic person ? Do you fight every day for the freedom of speech of other people ? I don't see any insult from myself. The fact that you see it does not make it is. And what about your invitation to the other people to ignore me ? I consider this behavior the worst demonstration of a liberal and democratic society. Where do you live ? I always thought that the USA was the first nation to fight for the freedom of expression of everyone. I don't even understand what has hurted you. It makes no sense that you feel offended because I don't know you. I could not have said something that could have tarnished your reputation and your honor,simply because I did not and do not know anything about you. So you are inviting others not to help me on the basis of a general and philosophical argumentation ? Or am I missing something ? On Wed, Jun 21, 2023 at 12:35 AM Nicolas George wrote: > Mario Marietto (12023-06-20): > > ---> Second, you are asking for help: that means your time is less > valuable > > than the time of people who might help you, and the most effort comes > from > > you. > > > > it's not a matter of effort : not everything is under our control : If I > > don't know something,I COULD learn MORE,but if I don't know that thing > > YET,I might NEVER know it. Knowledge is limited,but also imagination can > be > > limited. Your sentence is dangerous,because it "paints" someone that can > do > > everything,can learn everything,can imagine what he/she does not know > yet. > > You are painting some kind of superhero that has everything under his > > control. Tell me that there are limits to what someone can > > do,learn,imagine,because it's so important. The worst personality > > structure, the sickest,in terms of clinical psychology is the > narcissistic > > / omnipotent one. > > Do not expect any help from me in the future. > > And I urge the competent people on this mailing list to read this > insulting and entitled paragraph and consider whether they want to > expend time helping somebody like you. > > Good luck. > > -- > Nicolas George > -- Mario.
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
Mario Marietto (12023-06-21): > Probably you call troll what you find difficult to understand ? I'm a > psychologist,not a troll. Troll is a behavior, like entitled brat or asshole. Psychologist is a profession. They are not incompatible. I thought a psychologist would know the difference between a behavior and a profession. -- Nicolas George
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
Mario Marietto (12023-06-20): > ---> Second, you are asking for help: that means your time is less valuable > than the time of people who might help you, and the most effort comes from > you. > > it's not a matter of effort : not everything is under our control : If I > don't know something,I COULD learn MORE,but if I don't know that thing > YET,I might NEVER know it. Knowledge is limited,but also imagination can be > limited. Your sentence is dangerous,because it "paints" someone that can do > everything,can learn everything,can imagine what he/she does not know yet. > You are painting some kind of superhero that has everything under his > control. Tell me that there are limits to what someone can > do,learn,imagine,because it's so important. The worst personality > structure, the sickest,in terms of clinical psychology is the narcissistic > / omnipotent one. Do not expect any help from me in the future. And I urge the competent people on this mailing list to read this insulting and entitled paragraph and consider whether they want to expend time helping somebody like you. Good luck. -- Nicolas George
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
Probably you call troll what you find difficult to understand ? I'm a psychologist,not a troll. Try to read and understand. This is the right method to understand more than what you understand now. If you talk about troll,you close the door to a lot of interesting topics. Ok,they probably aren't inherent to your job,but you may find them useful for your own growth. On Wed, Jun 21, 2023 at 12:09 AM wrote: > Mario Marietto wrote: > > ---> Second, you are asking for help: that means your time is less > > valuable than the time of people who might help you, and the most > > effort comes from you. > > > > it's not a matter of effort : not everything is under our control : > > If I don't know something,I COULD learn MORE,but if I don't know that > > thing YET,I might NEVER know it. Knowledge is limited,but also > > imagination can be limited. Your sentence is dangerous,because it > > "paints" someone that can do everything,can learn everything,can > > imagine what he/she does not know yet. You are painting some kind of > > superhero that has everything under his control. Tell me that there > > are limits to what someone can do,learn,imagine,because it's so > > important. The worst personality structure, the sickest,in terms of > > clinical psychology is the narcissistic / omnipotent one. > > I call troll. > > > On Tue, Jun 20, 2023 at 5:48 PM Nicolas George > > wrote: > > > > > Mario Marietto (12023-06-20): > > > > What about if I don't know which kind of information you need ? > > > > I'm the hobbyist,you are the developer. It's better that you ask > > > > what you want to know and I try to reply with my limited > > > > knowledge. > > > > > > You are doubly mistaken here. > > > > > > First, this is a users mailing lists: the people who might help you > > > are not developers, they are users just like you. > > > > > > Second, you are asking for help: that means your time is less > > > valuable than the time of people who might help you, and the most > > > efforts come from you. > > > > > > If you expect useful help on this mailing-list, start by respecting > > > the people who are here, and that includes observing how their > > > mails are formatted and trying to do the same. > > > > > > -- > > > Nicolas George > > > > > > > > > > -- Mario.
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
Mario Marietto wrote: > ---> Second, you are asking for help: that means your time is less > valuable than the time of people who might help you, and the most > effort comes from you. > > it's not a matter of effort : not everything is under our control : > If I don't know something,I COULD learn MORE,but if I don't know that > thing YET,I might NEVER know it. Knowledge is limited,but also > imagination can be limited. Your sentence is dangerous,because it > "paints" someone that can do everything,can learn everything,can > imagine what he/she does not know yet. You are painting some kind of > superhero that has everything under his control. Tell me that there > are limits to what someone can do,learn,imagine,because it's so > important. The worst personality structure, the sickest,in terms of > clinical psychology is the narcissistic / omnipotent one. I call troll. > On Tue, Jun 20, 2023 at 5:48 PM Nicolas George > wrote: > > > Mario Marietto (12023-06-20): > > > What about if I don't know which kind of information you need ? > > > I'm the hobbyist,you are the developer. It's better that you ask > > > what you want to know and I try to reply with my limited > > > knowledge. > > > > You are doubly mistaken here. > > > > First, this is a users mailing lists: the people who might help you > > are not developers, they are users just like you. > > > > Second, you are asking for help: that means your time is less > > valuable than the time of people who might help you, and the most > > efforts come from you. > > > > If you expect useful help on this mailing-list, start by respecting > > the people who are here, and that includes observing how their > > mails are formatted and trying to do the same. > > > > -- > > Nicolas George > > > > >
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
---> Second, you are asking for help: that means your time is less valuable than the time of people who might help you, and the most effort comes from you. it's not a matter of effort : not everything is under our control : If I don't know something,I COULD learn MORE,but if I don't know that thing YET,I might NEVER know it. Knowledge is limited,but also imagination can be limited. Your sentence is dangerous,because it "paints" someone that can do everything,can learn everything,can imagine what he/she does not know yet. You are painting some kind of superhero that has everything under his control. Tell me that there are limits to what someone can do,learn,imagine,because it's so important. The worst personality structure, the sickest,in terms of clinical psychology is the narcissistic / omnipotent one. On Tue, Jun 20, 2023 at 5:48 PM Nicolas George wrote: > Mario Marietto (12023-06-20): > > What about if I don't know which kind of information you need ? I'm the > > hobbyist,you are the developer. It's better that you ask what you want to > > know and I try to reply with my limited knowledge. > > You are doubly mistaken here. > > First, this is a users mailing lists: the people who might help you are > not developers, they are users just like you. > > Second, you are asking for help: that means your time is less valuable > than the time of people who might help you, and the most efforts come > from you. > > If you expect useful help on this mailing-list, start by respecting the > people who are here, and that includes observing how their mails are > formatted and trying to do the same. > > -- > Nicolas George > > -- Mario.
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
Mario Marietto (12023-06-20): > What about if I don't know which kind of information you need ? I'm the > hobbyist,you are the developer. It's better that you ask what you want to > know and I try to reply with my limited knowledge. You are doubly mistaken here. First, this is a users mailing lists: the people who might help you are not developers, they are users just like you. Second, you are asking for help: that means your time is less valuable than the time of people who might help you, and the most efforts come from you. If you expect useful help on this mailing-list, start by respecting the people who are here, and that includes observing how their mails are formatted and trying to do the same. -- Nicolas George
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
What about if I don't know which kind of information you need ? I'm the hobbyist,you are the developer. It's better that you ask what you want to know and I try to reply with my limited knowledge. On Tue, Jun 20, 2023 at 4:48 PM Stefan Monnier wrote: > > ok,do you have some workaround to propose to me,boys ? > > Not before you give more info, no. > > > Stefan > > -- Mario.
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
> ok,do you have some workaround to propose to me,boys ? Not before you give more info, no. Stefan
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
ok,do you have some workaround to propose to me,boys ? Thank you. On Tue, Jun 20, 2023 at 3:18 AM Jeffrey Walton wrote: > On Mon, Jun 19, 2023 at 8:48 PM Stefan Monnier > wrote: > > > > [...] > > > of=/dev/mmcblk1 status=progress bs=2M but very rarely it wants to > boot. I > > > don't understand where the error is. When I insert the sd card into the > > > slot it beeps and it prepares itself to boot chrome OS from the > internal > > > memory,not Linux from the sd card. > > > > > > The problem could be systemd or whatever does that,to check and fix > disk > > > > What makes you think so? The description of the error you give about > > gives me the impression the Chromebook doesn't even begin to boot the > > GNU/Linux distribution on your SD card, in which case systemd can't be > > the culprit. > > Yeah, I had a lot of problems with a Chromebook several years ago. I > think I could get it into Developer Mode, but I could not get it to > boot to USB. I spent days trying to get it to work. It was a Toshiba > CB35, if I recall correctly. > > I find it best to donate old Chromebooks to a church or other > non-profit. They are low-end, and they are not worth spending too much > time on. > > Jeff > > -- Mario.
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
On Mon, Jun 19, 2023 at 8:48 PM Stefan Monnier wrote: > > [...] > > of=/dev/mmcblk1 status=progress bs=2M but very rarely it wants to boot. I > > don't understand where the error is. When I insert the sd card into the > > slot it beeps and it prepares itself to boot chrome OS from the internal > > memory,not Linux from the sd card. > > > > The problem could be systemd or whatever does that,to check and fix disk > > What makes you think so? The description of the error you give about > gives me the impression the Chromebook doesn't even begin to boot the > GNU/Linux distribution on your SD card, in which case systemd can't be > the culprit. Yeah, I had a lot of problems with a Chromebook several years ago. I think I could get it into Developer Mode, but I could not get it to boot to USB. I spent days trying to get it to work. It was a Toshiba CB35, if I recall correctly. I find it best to donate old Chromebooks to a church or other non-profit. They are low-end, and they are not worth spending too much time on. Jeff
Re: How to stop systemd or whatever does,to always tries to check and fix disk errors
[...] > of=/dev/mmcblk1 status=progress bs=2M but very rarely it wants to boot. I > don't understand where the error is. When I insert the sd card into the > slot it beeps and it prepares itself to boot chrome OS from the internal > memory,not Linux from the sd card. > > The problem could be systemd or whatever does that,to check and fix disk What makes you think so? The description of the error you give about gives me the impression the Chromebook doesn't even begin to boot the GNU/Linux distribution on your SD card, in which case systemd can't be the culprit. Stefan
How to stop systemd or whatever does,to always tries to check and fix disk errors
Hello. I would like to upgrade the kernel and I want to enable KVM on my old but still functional "Samsung Chromebook ARM model XE303C12 SNOW" because later I want to virtualize FreeBSD with qemu and kvm. I've started following this tutorial : *http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/* <http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/> As you can see,they used Ubuntu 13.04 as userland. No,I don't want to run such an old ubuntu version ! Actually my problem is that only 2 times over 10 tries my chromebook is able to boot correctly with the same setup. I've also completely erased the sd card with sudo dd if=/dev/zero of=/dev/mmcblk1 status=progress bs=2M but very rarely it wants to boot. I don't understand where the error is. When I insert the sd card into the slot it beeps and it prepares itself to boot chrome OS from the internal memory,not Linux from the sd card. The problem could be systemd or whatever does that,to check and fix disk errors because it does not support natively chrome os disk partitions flags. So it may break those flags after the first boot. So,I want to ask if there is a method that stops systemd or whatever to check and fix disk errors. Thanks. -- Mario.
Re: Debian 12: errors when using Python3 venv?
On Wed, Jun 14 2023 at 03:55:44 PM, Nicholas Papadonis wrote: > Hi, > > I just cleanly installed Debian 11 and am trying to create a virtual > environment for Python. > > I get the following error, does anyone know how to resolve this? Am I > missing some packages that need to be installed? > > 1843 [deb12:~]$ python3 -m venv pt > Traceback (most recent call last): > File "", line 189, in _run_module_as_main > File "", line 148, in _get_module_details > File "", line 112, in _get_module_details > File "/usr/lib/python3.11/venv/__init__.py", line 7, in > import logging > File "/usr/lib/python3.11/logging/__init__.py", line 43, in > import threading > File "/home/vboxuser/threading.py", line 3, in > sem = threading.Semaphore() > ^^^ > AttributeError: partially initialized module 'threading' has no attribute > 'Semaphore' (most likely due to a circular import) Your /home/vboxuser/threading.py is hiding the threading module from the python standard library. -- regards, kushal
Re: Debian 12: errors when using Python3 venv?
Am Wed, Jun 14, 2023 at 03:55:44PM -0400 schrieb Nicholas Papadonis: > File "/home/vboxuser/threading.py", line 3, in I'm surprised about this file. It should not appear by creating a python venv. Best regards Ulf
Re: Debian 12: errors when using Python3 venv?
Hey there, On Wed, Jun 14, 2023 at 3:56 PM Nicholas Papadonis < nick.papadonis...@gmail.com> wrote: > I just cleanly installed Debian 11 and am trying to create a virtual > environment for Python. > Assuming you meant Debian 12 here, based on the subject line, and am answering as such. > I get the following error, does anyone know how to resolve this? Am I > missing some packages that need to be installed? > > 1843 [deb12:~]$ python3 -m venv pt > First time I ran this I was notified that I didn't have the python3-venv package installed. After taking care of that, I was able to run your command without any errors on my clean Debian 12 system. Traceback (most recent call last): > File "", line 189, in _run_module_as_main > File "", line 148, in _get_module_details > File "", line 112, in _get_module_details > File "/usr/lib/python3.11/venv/__init__.py", line 7, in > import logging > File "/usr/lib/python3.11/logging/__init__.py", line 43, in > import threading > File "/home/vboxuser/threading.py", line 3, in > sem = threading.Semaphore() > ^^^ > AttributeError: partially initialized module 'threading' has no attribute > 'Semaphore' (most likely due to a circular import) > This won't be helpful information for you in that I am not providing a solution, but please know that I couldn't reproduce your issue on my system so I suspect there is something amiss with yours. I hope this is something of a pointer for you. David
Debian 12: errors when using Python3 venv?
Hi, I just cleanly installed Debian 11 and am trying to create a virtual environment for Python. I get the following error, does anyone know how to resolve this? Am I missing some packages that need to be installed? 1843 [deb12:~]$ python3 -m venv pt Traceback (most recent call last): File "", line 189, in _run_module_as_main File "", line 148, in _get_module_details File "", line 112, in _get_module_details File "/usr/lib/python3.11/venv/__init__.py", line 7, in import logging File "/usr/lib/python3.11/logging/__init__.py", line 43, in import threading File "/home/vboxuser/threading.py", line 3, in sem = threading.Semaphore() ^^^ AttributeError: partially initialized module 'threading' has no attribute 'Semaphore' (most likely due to a circular import)
Re: libqt5 errors
On Tue, May 30, 2023 at 12:57 AM Owen Hogarth wrote: > > I am running debian version: > PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" > NAME="Debian GNU/Linux" > VERSION_ID="12" > VERSION="12 (bookworm)" > VERSION_CODENAME=bookworm > ID=debian > HOME_URL="https://www.debian.org/; > SUPPORT_URL="https://www.debian.org/support; > BUG_REPORT_URL="https://bugs.debian.org/; > > Linux me 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) > x86_64 GNU/Linux > > I am getting these libqt5 errors. > /../libs/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x82) [0x7f4829cbf6c2] > /../libs/libQt5Widgets.so.5(_ZN7QWidget5eventEP6QEvent+0x121b) > [0x7f4851ba3b4b] > /../libs/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x100) > [0x7f4851b6ad00] > /../libs/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1cf) > [0x7f4851b6c16f] > /../libs/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0xa4) > [0x7f4829c94e14] > /../libs/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x334) > [0x7f4829c95d34] > /../libs/libQt5Core.so.5(+0x2ec6d3) [0x7f4829cec6d3] > /../libs/libglib-2.0.so.0(g_main_context_dispatch+0x27e) [0x7f482d265f2e] > /../libs/libglib-2.0.so.0(+0x66198) [0x7f482d266198] > /../libs/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f482d26623c] > /../libs/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x58) > [0x7f4829cec188] > /../libs/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b6) > [0x7f4829c90eb6] > /../libs/libQt5Widgets.so.5(_ZN7QDialog4execEv+0x1d6) [0x7f4851d67cb6] > /../libs/libBMDDavUI.so(_ZN8BmdDavUI17UiFramelessDialog4execEv+0x1c) > [0x7f485238703c] > /../libs/libQt5Core.so.5(_ZNK11QMetaMethod6invokeEP7QObjectN2Qt14ConnectionTypeE22QGenericReturnArgument16QGenericArgumentS5_S5_S5_S5_S5_S5_S5_S5_S5_+0x51f) > [0x7f4829ca040f] > /../libs/libQt5Core.so.5(+0x2cba5d) [0x7f4829ccba5d] > /../libs/libQt5Widgets.so.5(_ZN9QShortcut5eventEP6QEvent+0xa1) > [0x7f4851b8a2d1] > /../libs/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x100) > [0x7f4851b6ad00] > /../libs/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1cf) > [0x7f4851b6c16f] > /../libs/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0xa4) > [0x7f4829c94e14] > /../libs/libQt5Gui.so.5(_ZN12QShortcutMap13dispatchEventEP9QKeyEvent+0x6b5) > [0x7f482a352685] > /../libs/libQt5Gui.so.5(_ZN12QShortcutMap11tryShortcutEP9QKeyEvent+0x73) > [0x7f482a351bb3] > /../libs/libQt5Gui.so.5(_ZN22QWindowSystemInterface19handleShortcutEventEP7QWindowmi6QFlagsIN2Qt16KeyboardModifierEEjjjRK7QStringbt+0x19b) > [0x7f482a2ff82b] > /../libs/libQt5Gui.so.5(_ZN22QGuiApplicationPrivate15processKeyEventEPN29QWindowSystemInterfacePrivate8KeyEventE+0x7d) > [0x7f482a322f8d] > /../libs/libQt5Gui.so.5(_ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0xdb) > [0x7f482a3026fb] > /../libs/libglib-2.0.so.0(g_main_context_dispatch+0x27e) [0x7f482d265f2e] > /../libs/libglib-2.0.so.0(+0x66198) [0x7f482d266198] > /../libs/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f482d26623c] > /../libs/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x58) > [0x7f4829cec188] > /../libs/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b6) > [0x7f4829c90eb6] > /../libs/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x71) [0x7f4829c953b1] > /lib/x86_64-linux-gnu/libc.so.6(+0x2718a) [0x7f483d44618a] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f483d446245] > /../libs/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x82) [0x7f4829cbf6c2] > /../libs/libQt5Widgets.so.5(_ZN7QWidget5eventEP6QEvent+0x121b) > [0x7f4851ba3b4b] > /../libs/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x100) > [0x7f4851b6ad00] > /../libs/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1cf) > [0x7f4851b6c16f] > /../libs/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0xa4) > [0x7f4829c94e14] > /../libs/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x334) > [0x7f4829c95d34] > /../libs/libQt5Core.so.5(+0x2ec6d3) [0x7f4829cec6d3] > /../libs/libglib-2.0.so.0(g_main_context_dispatch+0x27e) [0x7f482d265f2e] > /../libs/libglib-2.0.so.0(+0x66198) [0x7f482d266198] > /../libs/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f482d26623c] > /../libs/libQt5Core.so.5(_ZN20QEventDispatcherGlib13pr
libqt5 errors
I am running debian version: PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/; SUPPORT_URL="https://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; Linux me 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux I am getting these libqt5 errors. /../libs/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x82) [0x7f4829cbf6c2] /../libs/libQt5Widgets.so.5(_ZN7QWidget5eventEP6QEvent+0x121b) [0x7f4851ba3b4b] /../libs/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x100) [0x7f4851b6ad00] /../libs/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1cf) [0x7f4851b6c16f] /../libs/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0xa4) [0x7f4829c94e14] /../libs/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x334) [0x7f4829c95d34] /../libs/libQt5Core.so.5(+0x2ec6d3) [0x7f4829cec6d3] /../libs/libglib-2.0.so.0(g_main_context_dispatch+0x27e) [0x7f482d265f2e] /../libs/libglib-2.0.so.0(+0x66198) [0x7f482d266198] /../libs/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f482d26623c] /../libs/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x58) [0x7f4829cec188] /../libs/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b6) [0x7f4829c90eb6] /../libs/libQt5Widgets.so.5(_ZN7QDialog4execEv+0x1d6) [0x7f4851d67cb6] /../libs/libBMDDavUI.so(_ZN8BmdDavUI17UiFramelessDialog4execEv+0x1c) [0x7f485238703c] /../libs/libQt5Core.so.5(_ZNK11QMetaMethod6invokeEP7QObjectN2Qt14ConnectionTypeE22QGenericReturnArgument16QGenericArgumentS5_S5_S5_S5_S5_S5_S5_S5_S5_+0x51f) [0x7f4829ca040f] /../libs/libQt5Core.so.5(+0x2cba5d) [0x7f4829ccba5d] /../libs/libQt5Widgets.so.5(_ZN9QShortcut5eventEP6QEvent+0xa1) [0x7f4851b8a2d1] /../libs/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x100) [0x7f4851b6ad00] /../libs/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1cf) [0x7f4851b6c16f] /../libs/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0xa4) [0x7f4829c94e14] /../libs/libQt5Gui.so.5(_ZN12QShortcutMap13dispatchEventEP9QKeyEvent+0x6b5) [0x7f482a352685] /../libs/libQt5Gui.so.5(_ZN12QShortcutMap11tryShortcutEP9QKeyEvent+0x73) [0x7f482a351bb3] /../libs/libQt5Gui.so.5(_ZN22QWindowSystemInterface19handleShortcutEventEP7QWindowmi6QFlagsIN2Qt16KeyboardModifierEEjjjRK7QStringbt+0x19b) [0x7f482a2ff82b] /../libs/libQt5Gui.so.5(_ZN22QGuiApplicationPrivate15processKeyEventEPN29QWindowSystemInterfacePrivate8KeyEventE+0x7d) [0x7f482a322f8d] /../libs/libQt5Gui.so.5(_ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0xdb) [0x7f482a3026fb] /../libs/libglib-2.0.so.0(g_main_context_dispatch+0x27e) [0x7f482d265f2e] /../libs/libglib-2.0.so.0(+0x66198) [0x7f482d266198] /../libs/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f482d26623c] /../libs/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x58) [0x7f4829cec188] /../libs/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b6) [0x7f4829c90eb6] /../libs/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x71) [0x7f4829c953b1] /lib/x86_64-linux-gnu/libc.so.6(+0x2718a) [0x7f483d44618a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f483d446245] /../libs/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x82) [0x7f4829cbf6c2] /../libs/libQt5Widgets.so.5(_ZN7QWidget5eventEP6QEvent+0x121b) [0x7f4851ba3b4b] /../libs/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x100) [0x7f4851b6ad00] /../libs/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1cf) [0x7f4851b6c16f] /../libs/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0xa4) [0x7f4829c94e14] /../libs/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x334) [0x7f4829c95d34] /../libs/libQt5Core.so.5(+0x2ec6d3) [0x7f4829cec6d3] /../libs/libglib-2.0.so.0(g_main_context_dispatch+0x27e) [0x7f482d265f2e] /../libs/libglib-2.0.so.0(+0x66198) [0x7f482d266198] /../libs/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f482d26623c] /../libs/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x58) [0x7f4829cec188] /../libs/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b6) [0x7f4829c90eb6] /../libs/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x71) [0x7f4829c953b1] /lib/x86_64-linux-gnu/libc.so.6(+0x2718a) [0x7f483d44618a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f483d446245] Is there anything that can be done about these missing calls?
Re: Boot Errors
When you get the "invalid argument" error do you see something in the output of "dmesg"? Can you try to mount it from another distro live-USB or from the Debian installer rescue mode? Enviado desde Outlook Mobile<https://aka.ms/blhgte> From: Michael Lee Sent: Thursday, March 2, 2023 4:30:47 PM To: debian-user@lists.debian.org Subject: Boot Errors While running the stable branch of 64-bit Debian, rebooted into an alternative OS, but forgot to unmount a USB device beforhand. Shutdown was taking too long, so forced it anyway. Now when I try to start Linux, I get these error messages: [1.922640] platform gpio_ich.2.auto: failed to claim resource 0:[io 0x0480-0x04ff] [8.934607] BTRFS error (device sdc2): parent transid verify faild on 176160768 wanted 680981 found 680979 [8.934649] BTRFS error (device sdc2): failed to read block groups 1 - 5 [8.935724] BTRFS error (device sdc2): open_ctree failed mount: mounting /dev/sdc2 on /root failed: invalid argument failed to mount /dev/sdc2 as root file system Then the initramfs command prompt appears. A little hard to find much on that. Read in the btrfs wiki that <-o ro,usebackuproot> with the mount command could help when the "wanted" and "found" numbers were not too far apart. mount -t btrfs -o ro,usebackuproot /dev/sdc2 TRIED with: /sysroot GOT: mount: mounting /dev/sdc2 on /sysroot failed: invalid argument TRIED with: / GOT: mount: mounting /dev/sdc2 on / failed: invalid argument TRIED with: /root GOT: mount: mounting /dev/sdc2 on /root failed: invalid argument Is this a GRUB issue, a btrfs issue, or must I reinstall the operating system, and if so where can I find out which files must be preserved in order to maintain continuity?
Boot Errors
While running the stable branch of 64-bit Debian, rebooted into an alternative OS, but forgot to unmount a USB device beforhand. Shutdown was taking too long, so forced it anyway. Now when I try to start Linux, I get these error messages: [1.922640] platform gpio_ich.2.auto: failed to claim resource 0:[io 0x0480-0x04ff] [8.934607] BTRFS error (device sdc2): parent transid verify faild on 176160768 wanted 680981 found 680979 [8.934649] BTRFS error (device sdc2): failed to read block groups 1 - 5 [8.935724] BTRFS error (device sdc2): open_ctree failed mount: mounting /dev/sdc2 on /root failed: invalid argument failed to mount /dev/sdc2 as root file system Then the initramfs command prompt appears. A little hard to find much on that. Read in the btrfs wiki that <-o ro,usebackuproot> with the mount command could help when the "wanted" and "found" numbers were not too far apart. mount -t btrfs -o ro,usebackuproot /dev/sdc2 TRIED with: /sysroot GOT: mount: mounting /dev/sdc2 on /sysroot failed: invalid argument TRIED with: / GOT: mount: mounting /dev/sdc2 on / failed: invalid argument TRIED with: /root GOT: mount: mounting /dev/sdc2 on /root failed: invalid argument Is this a GRUB issue, a btrfs issue, or must I reinstall the operating system, and if so where can I find out which files must be preserved in order to maintain continuity?
Re: re-compiling package twice errors out
Roberto C. Sánchez writes: > On Thu, Feb 16, 2023 at 10:37:00AM +0100, Andreas Leha wrote: >> >> Dear Tomas, >> >> Thanks for the swift reply! >> >> OK, then I should do `quilt pop -a` before the second compilation, >> right? >> >> But that leads to another error message: >> > > This can be considered a bug in the package. The idea is that debuild > run 'debian/rules clean' first and the 'clean' target is expected to > restore the source tree to the same state as what it was freshly > unpacked (and all the quilt patches applied). This package apparently > doesn't do this correctly (or at all), and so you are forced to start by > unpacking each team in order to have a clean build. The correct > solution is to fix the 'clean' target so that you can repeatedly run the > build without having to remove the package directory and unpack it > again. > > Regards, > > -Roberto Thanks for all responses!
Re: re-compiling package twice errors out
On Thu, Feb 16, 2023 at 10:37:00AM +0100, Andreas Leha wrote: > > Dear Tomas, > > Thanks for the swift reply! > > OK, then I should do `quilt pop -a` before the second compilation, > right? > > But that leads to another error message: > This can be considered a bug in the package. The idea is that debuild run 'debian/rules clean' first and the 'clean' target is expected to restore the source tree to the same state as what it was freshly unpacked (and all the quilt patches applied). This package apparently doesn't do this correctly (or at all), and so you are forced to start by unpacking each team in order to have a clean build. The correct solution is to fix the 'clean' target so that you can repeatedly run the build without having to remove the package directory and unpack it again. Regards, -Roberto -- Roberto C. Sánchez
Re: re-compiling package twice errors out
writes: > On Thu, Feb 16, 2023 at 10:05:54AM +0100, Andreas Leha wrote: >> Dear all, >> >> I am re-compiling xscreensaver. >> >> Re-compiling once works fine: >> >> apt-get source xscreensaver >> cd xscreensaver-6.0.6+dfsg1 >> LANG=C debuild -us -uc >> >> >> Re-compiling a second time errors out, though: >> >> > LANG=C debuild -us -uc >> (skipped lines) >> dpkg-source: info: using source format '3.0 (quilt)' >> dpkg-source: info: building xscreensaver using existing >> ./xscreensaver_6.06+dfsg1.orig.tar.xz >> dpkg-source: info: using patch list from debian/patches/series >> dpkg-source: error: cannot represent change to hacks/fonts/OCRAStd.otf: >> binary file contents changed >> dpkg-source: error: add hacks/fonts/OCRAStd.otf in >> debian/source/include-binaries if you want to store the modified binary in >> the debian >> tarball >> dpkg-source: warning: newly created empty file >> 'po/.intltool-merge-cache.lock' will not be represented in diff >> dpkg-source: error: unrepresentable changes to source >> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit >> status 1 >> debuild: fatal error at line 1182: >> dpkg-buildpackage -us -uc -ui failed >> >> >> What am I missing here? > > It is trying to apply the patches to an already patched source. > > If you run the whole thing (debuild etc) you best start from > a freshly unpacked source package. > > Otherwise you want to jump into the middle of the package > build (e.g. patches already applied or so). Then you'll have > to understand how that specific build system works (e.g. > configure, make or similar). > > Cheers Dear Tomas, Thanks for the swift reply! OK, then I should do `quilt pop -a` before the second compilation, right? But that leads to another error message: > apt-get source xscreensaver > cd xscreensaver-6.0.6+dfsg1 > LANG=C debuild -us -uc > quilt pop -a -f > LANG=C debuild -us -uc dpkg-buildpackage -us -uc -ui dpkg-buildpackage: info: source package xscreensaver dpkg-buildpackage: info: source version 6.06+dfsg1-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Tormod Volden dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 10_upstream_skip_retired_hacks.patch dpkg-source: info: applying 12_upstream_man_beats_speereev_backslash.patch dpkg-source: info: applying 20_hacks_man_section.patch dpkg-source: info: applying 20_skip_install-pam.patch dpkg-source: info: applying 50_debian_branding.patch dpkg-source: info: applying 51_generalize_external_commands.patch dpkg-source: info: applying 52_standard_time_format.patch dpkg-source: info: applying 53_default_newLoginCommand.patch dpkg-source: info: applying 55_add_unicode_hack.patch dpkg-source: info: applying 57_grabDesktopImages_default_off.patch dpkg-source: info: applying 75_Makefile_in-ignore-alien-platforms.patch dpkg-source: info: applying 81_hacks_deterministic_file_order.patch dpkg-source: info: applying 90_remove_Easter_egg_about_version.patch dpkg-source: info: applying 92_hacks_images_distclean.patch dpkg-source: info: applying 94_allow_unrecognized_conf_opts.patch dpkg-source: info: applying 96_nogl-build-for-nogl-config.patch dpkg-source: info: applying 98_daemon_desktop_file.patch dpkg-source: info: applying 100_configure_allow_warnings.patch fakeroot debian/rules clean dh clean --without autoreconf debian/rules override_dh_auto_clean make[1]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1' [ ! -f Makefile ] || /usr/bin/make distclean make[2]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1' make[3]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/utils' rm -f *.o a.out core make[3]: Leaving directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/utils' make[3]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/jwxyz' rm -f *.o a.out core make[3]: Leaving directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/jwxyz' make[3]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/hacks/images' Makefile:64: *** target file 'distclean' has both : and :: entries. Stop. make[3]: Leaving directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/hacks/images' make[2]:
Re: re-compiling package twice errors out
On Thu, Feb 16, 2023 at 10:05:54AM +0100, Andreas Leha wrote: > Dear all, > > I am re-compiling xscreensaver. > > Re-compiling once works fine: > > apt-get source xscreensaver > cd xscreensaver-6.0.6+dfsg1 > LANG=C debuild -us -uc > > > Re-compiling a second time errors out, though: > > > LANG=C debuild -us -uc > (skipped lines) > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building xscreensaver using existing > ./xscreensaver_6.06+dfsg1.orig.tar.xz > dpkg-source: info: using patch list from debian/patches/series > dpkg-source: error: cannot represent change to hacks/fonts/OCRAStd.otf: > binary file contents changed > dpkg-source: error: add hacks/fonts/OCRAStd.otf in > debian/source/include-binaries if you want to store the modified binary in > the debian > tarball > dpkg-source: warning: newly created empty file > 'po/.intltool-merge-cache.lock' will not be represented in diff > dpkg-source: error: unrepresentable changes to source > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit > status 1 > debuild: fatal error at line 1182: > dpkg-buildpackage -us -uc -ui failed > > > What am I missing here? It is trying to apply the patches to an already patched source. If you run the whole thing (debuild etc) you best start from a freshly unpacked source package. Otherwise you want to jump into the middle of the package build (e.g. patches already applied or so). Then you'll have to understand how that specific build system works (e.g. configure, make or similar). Cheers -- t signature.asc Description: PGP signature
re-compiling package twice errors out
Dear all, I am re-compiling xscreensaver. Re-compiling once works fine: apt-get source xscreensaver cd xscreensaver-6.0.6+dfsg1 LANG=C debuild -us -uc Re-compiling a second time errors out, though: > LANG=C debuild -us -uc (skipped lines) dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building xscreensaver using existing ./xscreensaver_6.06+dfsg1.orig.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: error: cannot represent change to hacks/fonts/OCRAStd.otf: binary file contents changed dpkg-source: error: add hacks/fonts/OCRAStd.otf in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: newly created empty file 'po/.intltool-merge-cache.lock' will not be represented in diff dpkg-source: error: unrepresentable changes to source dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 1 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui failed What am I missing here? Thanks in advance. Andreas
Re: kernel errors
On 06/02/2023 00:11, Richmond wrote: Max Nikulin writes: On 05/02/2023 03:12, Richmond wrote: The errors about sr0 come before the stuff about resume. Does the following command generate similar errors (taken from initrd scripts, UUID is intentionally not from the set of existing partitions)? blkid -l -t UUID=---- -o device It didn't produce any output. Sorry, I have no motivation to dig into /usr/share/initramfs-tools deeper. Perhaps you may try debug kernel option in combination with bad UUID for resume from grub ... debug resume=UUID=---- with hope to get more verbose output around of optical drive access. You may try to report a bug against initramfs-tools that errors messages are unhelpful and even confusing when resume configuration is inconsistent due to a mistake. Perhaps resume argument may be validated during generation of initrd, however in some cases it will give false positive.
Re: kernel errors
Max Nikulin writes: > On 05/02/2023 03:12, Richmond wrote: >> The errors about sr0 come before the stuff about resume. > > Does the following command generate similar errors (taken from initrd > scripts, UUID is intentionally not from the set of existing > partitions)? > > blkid -l -t UUID=---- -o device > > I would try it at first in normally running system. Perhaps some > caches may be involved preventing query to the optical drive. I have > no bright idea how to cause drop to initrd shell to try the command > there, perhaps root=... kernel command line parameter may be removed > or changed to non-existing device from grub prompt. > > I am unsure which particular command from initrd scans devices, my > guess may be wrong. It didn't produce any output.
Re: kernel errors
On 05/02/2023 03:12, Richmond wrote: The errors about sr0 come before the stuff about resume. Does the following command generate similar errors (taken from initrd scripts, UUID is intentionally not from the set of existing partitions)? blkid -l -t UUID=---- -o device I would try it at first in normally running system. Perhaps some caches may be involved preventing query to the optical drive. I have no bright idea how to cause drop to initrd shell to try the command there, perhaps root=... kernel command line parameter may be removed or changed to non-existing device from grub prompt. I am unsure which particular command from initrd scans devices, my guess may be wrong.
Re: kernel errors
Richmond wrote: > David Wright writes: > >> On Sat 04 Feb 2023 at 17:38:25 (+), Richmond wrote: >>> David Wright writes: >>>> On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: >>>>> Max Nikulin writes: >>>>>> On 03/02/2023 01:47, Richmond wrote: >>>>>>> It might be a good way for someone to reproduce the error on some >>>>>>> other >>>>>>> machine. I have no problems with the CD/DVD writer and have used it a >>>>>>> few times recently. >>>>>> Do you see the same errors if kernel command line is edited from grub >>>>>> to pass non-existing UUID specified in the resume=UUID=... argument? >>>>>> It might be a quick way to reproduce the issue. >>>>> I looked in grub but couldn't see any resume parameter. I think the way >>>>> things work has changed, and this is hidden away somewhere. >>>> There are hundreds and hundreds of kernel command-line parameters, >>>> so I'm not sure how you expect to see any evidence of each one in >>>> Grub's configuration. >>> We were talking about editing from grub during boot time, not looking in >>> grubs configuration. >> You wrote: "I looked in grub". >> >> My interpretation: "I looked in grub.cfg by typing 'E' on one or more >> of the entries in Grub's blue screen when booting the computer". >> > I see. Max (and you) mean add the resume parameter, not edit an existing one. > I > was looking for an existing one. I will try this. > It worked, I recreated the error, including the stuff about sr0. The errors about sr0 come before the stuff about resume.
Re: kernel errors
David Wright writes: > On Sat 04 Feb 2023 at 17:38:25 (+), Richmond wrote: >> David Wright writes: >> > On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: >> >> Max Nikulin writes: >> >> > On 03/02/2023 01:47, Richmond wrote: >> >> >> It might be a good way for someone to reproduce the error on some >> >> >> other >> >> >> machine. I have no problems with the CD/DVD writer and have used it a >> >> >> few times recently. >> >> > >> >> > Do you see the same errors if kernel command line is edited from grub >> >> > to pass non-existing UUID specified in the resume=UUID=... argument? >> >> > It might be a quick way to reproduce the issue. >> >> >> >> I looked in grub but couldn't see any resume parameter. I think the way >> >> things work has changed, and this is hidden away somewhere. >> > >> > There are hundreds and hundreds of kernel command-line parameters, >> > so I'm not sure how you expect to see any evidence of each one in >> > Grub's configuration. >> >> We were talking about editing from grub during boot time, not looking in >> grubs configuration. > > You wrote: "I looked in grub". > > My interpretation: "I looked in grub.cfg by typing 'E' on one or more > of the entries in Grub's blue screen when booting the computer". > I see. Max (and you) mean add the resume parameter, not edit an existing one. I was looking for an existing one. I will try this.
Re: kernel errors
On Sat 04 Feb 2023 at 17:38:25 (+), Richmond wrote: > David Wright writes: > > On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: > >> Max Nikulin writes: > >> > On 03/02/2023 01:47, Richmond wrote: > >> >> It might be a good way for someone to reproduce the error on some > >> >> other > >> >> machine. I have no problems with the CD/DVD writer and have used it a > >> >> few times recently. > >> > > >> > Do you see the same errors if kernel command line is edited from grub > >> > to pass non-existing UUID specified in the resume=UUID=... argument? > >> > It might be a quick way to reproduce the issue. > >> > >> I looked in grub but couldn't see any resume parameter. I think the way > >> things work has changed, and this is hidden away somewhere. > > > > There are hundreds and hundreds of kernel command-line parameters, > > so I'm not sure how you expect to see any evidence of each one in > > Grub's configuration. > > We were talking about editing from grub during boot time, not looking in > grubs configuration. You wrote: "I looked in grub". My interpretation: "I looked in grub.cfg by typing 'E' on one or more of the entries in Grub's blue screen when booting the computer". If my interpretation is correct, please reread my post and, if you think Max's suggested action would be productive, try it out. If not, please elaborate on your use of the word "grub" in "I looked in grub". Cheers, David.
Re: kernel errors
David Wright writes: > On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: >> Max Nikulin writes: >> > On 03/02/2023 01:47, Richmond wrote: >> >> It might be a good way for someone to reproduce the error on some >> >> other >> >> machine. I have no problems with the CD/DVD writer and have used it a >> >> few times recently. >> > >> > Do you see the same errors if kernel command line is edited from grub >> > to pass non-existing UUID specified in the resume=UUID=... argument? >> > It might be a quick way to reproduce the issue. >> >> I looked in grub but couldn't see any resume parameter. I think the way >> things work has changed, and this is hidden away somewhere. > > There are hundreds and hundreds of kernel command-line parameters, > so I'm not sure how you expect to see any evidence of each one in > Grub's configuration. We were talking about editing from grub during boot time, not looking in grubs configuration.
Re: kernel errors
Hi, i wrote: > > Maybe the script which runs blkid or alike has vanished during the recent > > reconstruction of the initrd which fixed the problems ? Richmond wrote: > I didn't need to reconstruct initrd to cause the problems. As far as I > remember all I did was destroy the swap space, having commented-it-out > of fstab. So I imagin that the scripts are the same. I rather meant the run which you meantioned in your mail of Thu, 02 Feb 2023 14:05:37 +: > > > sudo update-initramfs -u > > > After I did this, the errors went away. It is possible that there were files in /scripts/local-block before this run. > find /tmp/initrd21/ -print|xargs grep -i blkid|less > /tmp/initrd21/scripts/functions: DEV="$(blkid -l -t "$DEV" -o device)" || > return 1 This is the kind of blkid run which i expect to cause the mislead read attempts to the pseudo-end of /dev/sr0. If the given attribute is not found, then it cycles over all block devices, not knowing about the purpose of resuming and the usefulness of the device types. It is in function resolve_device() which obviously shall find a device matching either LABEL, UUID, PARTLABEL, or PARTUUID. A plausible caller of resolve_device() would be in hooks/resume: if resume_dev_node="$(resolve_device "$RESUME")" && \ blkid -p -n swap "$resume_dev_node" >/dev/null 2>&1; then But i fail to make the connection to the loop with the messages about /scripts/local-block. Have a nice day :) Thomas
Re: kernel errors
On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote:
> Max Nikulin writes:
> > On 03/02/2023 01:47, Richmond wrote:
> >> It might be a good way for someone to reproduce the error on some
> >> other
> >> machine. I have no problems with the CD/DVD writer and have used it a
> >> few times recently.
> >
> > Do you see the same errors if kernel command line is edited from grub
> > to pass non-existing UUID specified in the resume=UUID=... argument?
> > It might be a quick way to reproduce the issue.
>
> I looked in grub but couldn't see any resume parameter. I think the way
> things work has changed, and this is hidden away somewhere.
There are hundreds and hundreds of kernel command-line parameters,
so I'm not sure how you expect to see any evidence of each one in
Grub's configuration. Imagine how often any one particular parameter
is employed by someone, eg,
earlycon= [KNL] Output early console device and options.
When used with no options, the early console is
determined by stdout-path property in device tree's
chosen node or the ACPI SPCR table if supported by
the platform.
lpuart,
lpuart32,
Use early console provided by Freescale LP UART driver
found on Freescale Vybrid and QorIQ LS1021A processors.
A valid base address must be provided, and the serial
port must already be setup and configured.
https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html
One caveat, though, about adding resume= in Grub. If a system has no
mention of resume when the initrd is built, I don't know whether the
scripts are included for handling it. In your case, you appear to
have these scripts, so it should be ok. Mind you, have you reported
what's in /etc/initramfs-tools/conf.d/resume? I've asked this before
(see last point below).
> > Is it realistic that usually optical drives are skipped during UUID
> > searches, but specific driver exposes a wrong property, so the device
> > is considered as a regular disk drive?
>
> I don't know.
Much of what I see grepped in this thread is stuff that I could read
off my machine. For example:
$ grep -r -I blkid
main/usr/lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{builtin}="blkid"
main/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid
--offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
main/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid
--noraid"
main/usr/lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*",
IMPORT{builtin}="blkid"
main/usr/lib/cryptsetup/functions:elif blk_t="$(blkid -s TYPE -o value
-- "$s")" && [ "$blk_t" = "BitLocker" ]; then
main/usr/lib/cryptsetup/functions:spec="$(blkid -l -t "$spec" -o
device)" || spec=
main/usr/lib/cryptsetup/functions:if uuid="$(blkid -s UUID -o value --
"$device")" && [ -n "$uuid" ]; then
main/scripts/local: # device in /dev and isn't resolvable by blkid (e.g.
mtd0)
main/scripts/functions: # blkid has a more complete list of file systems,
main/scripts/functions: FSTYPE=$(blkid -o value -s TYPE "${FS}") ||
return
main/scripts/functions: DEV="$(blkid -l -t "$DEV" -o device)" || return
1
$
(I have a few extra crypto lines.)
I wouldn't mind seeing a few properties and configuration parameters
from your machine, which will obviously differ from mine. (See my
previous post.)
Cheers,
David.
Re: kernel errors
Max Nikulin writes: > On 03/02/2023 01:47, Richmond wrote: >> It might be a good way for someone to reproduce the error on some >> other >> machine. I have no problems with the CD/DVD writer and have used it a >> few times recently. > > Do you see the same errors if kernel command line is edited from grub > to pass non-existing UUID specified in the resume=UUID=... argument? > It might be a quick way to reproduce the issue. I looked in grub but couldn't see any resume parameter. I think the way things work has changed, and this is hidden away somewhere. > > Is it realistic that usually optical drives are skipped during UUID > searches, but specific driver exposes a wrong property, so the device > is considered as a regular disk drive? I don't know.
Re: kernel errors
"Thomas Schmitt" writes:
> Hi,
>
> Richmond wrote:
>> /tmp/initrd21/scripts/local:[ "${quiet?}" != "y" ] && log_begin_msg
>> "Running /scripts/local-block"
>> [...]
>> local_block()
>> {
>>[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
>>run_scripts /scripts/local-block "$@"
>> [...]
>> Then later this, which would explain the delays: (The video shows
>> "waiting for suspend/resume device")
>> [...]
>> log_begin_msg "Waiting for ${name}"
>> [...]
>> while true; do
>> sleep 1
>> time_elapsed="$(time_elapsed)"
>>
>> local_block "${dev_id}"
>
> I remember to have seen this code under
> https://sources.debian.org/src/initramfs-tools/unstable/
> when i looked for occurences of "local-block". (This URL is currently not
> working for me.)
> I did not find any built-in runs of programs like blkid or lsblk. Thus i
> concluded that such runs would be in files of /scripts/local-block or other
> local customization of the initrd.
>
> We are most probably at the right spot of initramfs-tools.
> Maybe the script which runs blkid or alike has vanished during the recent
> reconstruction of the initrd which fixed the problems ?
I didn't need to reconstruct initrd to cause the problems. As far as I
remember all I did was destroy the swap space, having commented-it-out
of fstab. So I imagin that the scripts are the same. But I could test
that as suggested by Max Nikulin by altering the resume parameter from
grub before booting.
>
> Does fgrep find anything about "blkid" in /tmp/initrd21 ?
I did it like this:
find /tmp/initrd21/ -print|xargs grep -i blkid|less
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules:
IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules:
IMPORT{builtin}="blkid --noraid"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*",
IMPORT{builtin}="blkid"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{builtin}="blkid"
/tmp/initrd21/scripts/functions:# blkid has a more complete list of
file systems,
/tmp/initrd21/scripts/functions:FSTYPE=$(blkid -o value -s TYPE
"${FS}") || return
/tmp/initrd21/scripts/functions:DEV="$(blkid -l -t "$DEV" -o
device)" || return 1
/tmp/initrd21/scripts/local:# device in /dev and isn't resolvable by blkid
(e.g. mtd0)
Re: kernel errors
Hi,
Richmond wrote:
> /tmp/initrd21/scripts/local:[ "${quiet?}" != "y" ] && log_begin_msg
> "Running /scripts/local-block"
> [...]
> local_block()
> {
>[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
>run_scripts /scripts/local-block "$@"
> [...]
> Then later this, which would explain the delays: (The video shows
> "waiting for suspend/resume device")
> [...]
> log_begin_msg "Waiting for ${name}"
> [...]
> while true; do
> sleep 1
> time_elapsed="$(time_elapsed)"
>
> local_block "${dev_id}"
I remember to have seen this code under
https://sources.debian.org/src/initramfs-tools/unstable/
when i looked for occurences of "local-block". (This URL is currently not
working for me.)
I did not find any built-in runs of programs like blkid or lsblk. Thus i
concluded that such runs would be in files of /scripts/local-block or other
local customization of the initrd.
We are most probably at the right spot of initramfs-tools.
Maybe the script which runs blkid or alike has vanished during the recent
reconstruction of the initrd which fixed the problems ?
Does fgrep find anything about "blkid" in /tmp/initrd21 ?
Have a nice day :)
Thomas
Re: kernel errors
On 03/02/2023 01:47, Richmond wrote: It might be a good way for someone to reproduce the error on some other machine. I have no problems with the CD/DVD writer and have used it a few times recently. Do you see the same errors if kernel command line is edited from grub to pass non-existing UUID specified in the resume=UUID=... argument? It might be a quick way to reproduce the issue. Is it realistic that usually optical drives are skipped during UUID searches, but specific driver exposes a wrong property, so the device is considered as a regular disk drive?
Re: kernel errors
sorry, replied to wrong list. On Fri, 03 Feb 2023 16:55:18 -0500, John Covici wrote: > > For instance I just got a post from Freedom Scientific which had the > announcement in the Email and also link to the post. > On Fri, 03 Feb 2023 15:28:55 -0500, > David Wright wrote: > > > > On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote: > > > David Wright writes: > > > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > > > >> "Thomas Schmitt" writes: > > > >> > > > > >> > (If not there, then in the /scripts/local-block directory of the > > > >> > initrd ?) > > > >> > > > >> I don't know how I would look in that. Is it in RAM at boot time? > > > > > > > >Choose your kernel ↓↓Pick any name > > > > > > > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > > > > $ ls -GlgR /tmp/initrd21/main/scripts/ > > > > /tmp/initrd21/main/scripts/: > > > > total 48 > > > > -rw-r--r-- 1 11152 Jan 14 2021 functions > > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > > > > -rw-r--r-- 1 5303 Jan 14 2021 local > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > > > > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > > > > > > > /tmp/initrd21/main/scripts/init-bottom: > > > > total 8 > > > > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > > > > > > > /tmp/initrd21/main/scripts/init-top: > > > > total 20 > > > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > > > > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > > > > -rwxr-xr-x 1 167 Jan 14 2021 keymap > > > > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > > > > > > > /tmp/initrd21/main/scripts/local-block: > > > > total 8 > > > > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > > > > > > > /tmp/initrd21/main/scripts/local-bottom: > > > > total 20 > > > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > > > > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > > > > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > > > > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > > > > > > > /tmp/initrd21/main/scripts/local-premount: > > > > total 12 > > > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > > > > -rwxr-xr-x 1 863 Jan 14 2021 resume > > > > > > > > /tmp/initrd21/main/scripts/local-top: > > > > total 20 > > > > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > > > > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > > > > $ > > > > > > > > This is a desktop with random-key swap, so no resume. > > > > There are encrypted partitions present. YMMV. > > > > > > > > Cheers, > > > > David. > > > > > > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > > ~$ find /tmp/initrd21/ -print|grep "local-block" > > > ~$ find /tmp/initrd21/ -print|grep "local" > > > > > > /tmp/initrd21/usr/local > > > /tmp/initrd21/usr/local/share > > > /tmp/initrd21/usr/local/share/fonts > > > /tmp/initrd21/usr/local/share/fonts/.uuid > > > /tmp/initrd21/scripts/local-bottom > > > /tmp/initrd21/scripts/local-bottom/ntfs_3g > > > /tmp/initrd21/scripts/local-bottom/ORDER > > > /tmp/initrd21/scripts/local > > > /tmp/initrd21/scripts/local-premount > > > /tmp/initrd21/scripts/local-premount/ntfs_3g > > > /tmp/initrd21/scripts/local-premount/ORDER > > > /tmp/initrd21/scripts/local-premount/resume > > > > > > No local block. :-? > > > > > > find /tmp/initrd21/ -print|grep local|grep block > > > > > > No output here. > > > > Well, no, but there is a resume sitting there in local-premount, > > which suggests to me¹ that you perhaps have something in > > /etc/initramfs-tools/conf.d/resume. Has that been reported? > > > > I'd also be interested to see the output from: > > > > $ ls -lR /dev/disk | grep sr > > > > and > > > > $ grep -e sr -e sw /etc/fstab > > > > The intent of that last pattern is to see the swap lines that you > > have been commenting out. > > > > Of course, we might not see anything unusual anywhere while the > > machines are in their "fixed" state (whatever that means). > > > > ¹ This is a guess, based on the fact that I also have that file in > > initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume, > > and something somewhere has to read the word "none". > > > > Cheers, > > David. > > > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > cov...@ccs.covici.com > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: kernel errors
For instance I just got a post from Freedom Scientific which had the announcement in the Email and also link to the post. On Fri, 03 Feb 2023 15:28:55 -0500, David Wright wrote: > > On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote: > > David Wright writes: > > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > > >> "Thomas Schmitt" writes: > > >> > > > >> > (If not there, then in the /scripts/local-block directory of the > > >> > initrd ?) > > >> > > >> I don't know how I would look in that. Is it in RAM at boot time? > > > > > >Choose your kernel ↓↓Pick any name > > > > > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > > > $ ls -GlgR /tmp/initrd21/main/scripts/ > > > /tmp/initrd21/main/scripts/: > > > total 48 > > > -rw-r--r-- 1 11152 Jan 14 2021 functions > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > > > -rw-r--r-- 1 5303 Jan 14 2021 local > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > > > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > > > > > /tmp/initrd21/main/scripts/init-bottom: > > > total 8 > > > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > > > > > /tmp/initrd21/main/scripts/init-top: > > > total 20 > > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > > > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > > > -rwxr-xr-x 1 167 Jan 14 2021 keymap > > > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > > > > > /tmp/initrd21/main/scripts/local-block: > > > total 8 > > > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > > > > > /tmp/initrd21/main/scripts/local-bottom: > > > total 20 > > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > > > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > > > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > > > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > > > > > /tmp/initrd21/main/scripts/local-premount: > > > total 12 > > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > > > -rwxr-xr-x 1 863 Jan 14 2021 resume > > > > > > /tmp/initrd21/main/scripts/local-top: > > > total 20 > > > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > > > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > > > $ > > > > > > This is a desktop with random-key swap, so no resume. > > > There are encrypted partitions present. YMMV. > > > > > > Cheers, > > > David. > > > > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > ~$ find /tmp/initrd21/ -print|grep "local-block" > > ~$ find /tmp/initrd21/ -print|grep "local" > > > > /tmp/initrd21/usr/local > > /tmp/initrd21/usr/local/share > > /tmp/initrd21/usr/local/share/fonts > > /tmp/initrd21/usr/local/share/fonts/.uuid > > /tmp/initrd21/scripts/local-bottom > > /tmp/initrd21/scripts/local-bottom/ntfs_3g > > /tmp/initrd21/scripts/local-bottom/ORDER > > /tmp/initrd21/scripts/local > > /tmp/initrd21/scripts/local-premount > > /tmp/initrd21/scripts/local-premount/ntfs_3g > > /tmp/initrd21/scripts/local-premount/ORDER > > /tmp/initrd21/scripts/local-premount/resume > > > > No local block. :-? > > > > find /tmp/initrd21/ -print|grep local|grep block > > > > No output here. > > Well, no, but there is a resume sitting there in local-premount, > which suggests to me¹ that you perhaps have something in > /etc/initramfs-tools/conf.d/resume. Has that been reported? > > I'd also be interested to see the output from: > > $ ls -lR /dev/disk | grep sr > > and > > $ grep -e sr -e sw /etc/fstab > > The intent of that last pattern is to see the swap lines that you > have been commenting out. > > Of course, we might not see anything unusual anywhere while the > machines are in their "fixed" state (whatever that means). > > ¹ This is a guess, based on the fact that I also have that file in > initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume, > and something somewhere has to read the word "none". > > Cheers, > David. > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: kernel errors
On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote: > David Wright writes: > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > >> "Thomas Schmitt" writes: > >> > > >> > (If not there, then in the /scripts/local-block directory of the initrd > >> > ?) > >> > >> I don't know how I would look in that. Is it in RAM at boot time? > > > >Choose your kernel ↓↓Pick any name > > > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > > $ ls -GlgR /tmp/initrd21/main/scripts/ > > /tmp/initrd21/main/scripts/: > > total 48 > > -rw-r--r-- 1 11152 Jan 14 2021 functions > > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > > -rw-r--r-- 1 5303 Jan 14 2021 local > > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > > > /tmp/initrd21/main/scripts/init-bottom: > > total 8 > > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > > > /tmp/initrd21/main/scripts/init-top: > > total 20 > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > > -rwxr-xr-x 1 167 Jan 14 2021 keymap > > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > > > /tmp/initrd21/main/scripts/local-block: > > total 8 > > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > > > /tmp/initrd21/main/scripts/local-bottom: > > total 20 > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > > > /tmp/initrd21/main/scripts/local-premount: > > total 12 > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > > -rwxr-xr-x 1 863 Jan 14 2021 resume > > > > /tmp/initrd21/main/scripts/local-top: > > total 20 > > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > > $ > > > > This is a desktop with random-key swap, so no resume. > > There are encrypted partitions present. YMMV. > > > > Cheers, > > David. > > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > ~$ find /tmp/initrd21/ -print|grep "local-block" > ~$ find /tmp/initrd21/ -print|grep "local" > > /tmp/initrd21/usr/local > /tmp/initrd21/usr/local/share > /tmp/initrd21/usr/local/share/fonts > /tmp/initrd21/usr/local/share/fonts/.uuid > /tmp/initrd21/scripts/local-bottom > /tmp/initrd21/scripts/local-bottom/ntfs_3g > /tmp/initrd21/scripts/local-bottom/ORDER > /tmp/initrd21/scripts/local > /tmp/initrd21/scripts/local-premount > /tmp/initrd21/scripts/local-premount/ntfs_3g > /tmp/initrd21/scripts/local-premount/ORDER > /tmp/initrd21/scripts/local-premount/resume > > No local block. :-? > > find /tmp/initrd21/ -print|grep local|grep block > > No output here. Well, no, but there is a resume sitting there in local-premount, which suggests to me¹ that you perhaps have something in /etc/initramfs-tools/conf.d/resume. Has that been reported? I'd also be interested to see the output from: $ ls -lR /dev/disk | grep sr and $ grep -e sr -e sw /etc/fstab The intent of that last pattern is to see the swap lines that you have been commenting out. Of course, we might not see anything unusual anywhere while the machines are in their "fixed" state (whatever that means). ¹ This is a guess, based on the fact that I also have that file in initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume, and something somewhere has to read the word "none". Cheers, David.
Re: kernel errors
"Thomas Schmitt" writes:
> Hi,
>
> Richmond wrote:
>> No local block. :-?
>
> Maybe you can find our from where the message comes:
>
> grep -r 'Running.*scripts.*local-block' /tmp/initrd21
>
>
grep -r 'Running.*scripts.*local-block' /tmp/initrd21
/tmp/initrd21/scripts/local:[ "${quiet?}" != "y" ] && log_begin_msg
"Running /scripts/local-block"
This contains:
===
local_block()
{
[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
run_scripts /scripts/local-block "$@"
[ "$quiet" != "y" ] && log_end_msg
}
===
Then later this, which would explain the delays: (The video shows
"waiting for suspend/resume device")
===
# If the root device hasn't shown up yet, give it a little while
# to allow for asynchronous device discovery (e.g. USB). We
# also need to keep invoking the local-block scripts in case
# there are devices stacked on top of those.
if ! real_dev=$(resolve_device "${dev_id}") ||
! get_fstype "${real_dev}" >/dev/null; then
log_begin_msg "Waiting for ${name}"
# Timeout is max(30, rootdelay) seconds (approximately)
slumber=30
if [ "${ROOTDELAY:-0}" -gt $slumber ]; then
slumber=$ROOTDELAY
fi
while true; do
sleep 1
time_elapsed="$(time_elapsed)"
local_block "${dev_id}"
# If mdadm's local-block script counts the
# number of times it is run, make sure to
# run it the expected number of times.
while true; do
if [ -f /run/count.mdadm.initrd ]; then
count="$(cat /run/count.mdadm.initrd)"
elif [ -n "${count}" ]; then
# mdadm script deleted it; put it back
count=$((count + 1))
echo "${count}" >/run/count.mdadm.initrd
else
:
Re: kernel errors
Hi, Richmond wrote: > No local block. :-? Maybe you can find our from where the message comes: grep -r 'Running.*scripts.*local-block' /tmp/initrd21 Have a nice day :) Thomas
Re: kernel errors
David Wright writes: > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: >> "Thomas Schmitt" writes: >> > >> > (If not there, then in the /scripts/local-block directory of the initrd ?) >> >> I don't know how I would look in that. Is it in RAM at boot time? > >Choose your kernel ↓↓Pick any name > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > $ ls -GlgR /tmp/initrd21/main/scripts/ > /tmp/initrd21/main/scripts/: > total 48 > -rw-r--r-- 1 11152 Jan 14 2021 functions > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > -rw-r--r-- 1 5303 Jan 14 2021 local > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > /tmp/initrd21/main/scripts/init-bottom: > total 8 > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > /tmp/initrd21/main/scripts/init-top: > total 20 > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > -rwxr-xr-x 1 167 Jan 14 2021 keymap > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > /tmp/initrd21/main/scripts/local-block: > total 8 > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > /tmp/initrd21/main/scripts/local-bottom: > total 20 > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > /tmp/initrd21/main/scripts/local-premount: > total 12 > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > -rwxr-xr-x 1 863 Jan 14 2021 resume > > /tmp/initrd21/main/scripts/local-top: > total 20 > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > $ > > This is a desktop with random-key swap, so no resume. > There are encrypted partitions present. YMMV. > > Cheers, > David. ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 ~$ find /tmp/initrd21/ -print|grep "local-block" ~$ find /tmp/initrd21/ -print|grep "local" /tmp/initrd21/usr/local /tmp/initrd21/usr/local/share /tmp/initrd21/usr/local/share/fonts /tmp/initrd21/usr/local/share/fonts/.uuid /tmp/initrd21/scripts/local-bottom /tmp/initrd21/scripts/local-bottom/ntfs_3g /tmp/initrd21/scripts/local-bottom/ORDER /tmp/initrd21/scripts/local /tmp/initrd21/scripts/local-premount /tmp/initrd21/scripts/local-premount/ntfs_3g /tmp/initrd21/scripts/local-premount/ORDER /tmp/initrd21/scripts/local-premount/resume No local block. :-? find /tmp/initrd21/ -print|grep local|grep block No output here.
Re: kernel errors
Michel Verdier writes: > Le 2 février 2023 Richmond a écrit : > >> There is no such file. Earlier I ran this: >> >> find / -print|grep "scripts/local-block" >> >> and it found nothing, which led me to believe it is some temporary file... >>> >>> (If not there, then in the /scripts/local-block directory of the initrd ?) > > its part of initramfs-tools to build initrd when you use cryptsetup, > mdadm, etc > > $ locate local-block > /usr/share/initramfs-tools/scripts/local-block > /usr/share/initramfs-tools/scripts/local-block/cryptroot > > $ apt-file search /usr/share/initramfs-tools/scripts/local-block > cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot > lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 > mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm > osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl sudo locate local-block produced no output. sudo apt-file search /usr/share/initramfs-tools/scripts/local-block cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl I don't have an encrypted file system. sudo aptitude show cryptsetup-initramfs|grep State State: not installed sudo aptitude show lvm2|grep State State: not installed sudo aptitude show mdadm|grep State State: not installed sudo aptitude show osk-sdl|grep State State: not installed
Re: kernel errors
On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > "Thomas Schmitt" writes: > > > > (If not there, then in the /scripts/local-block directory of the initrd ?) > > I don't know how I would look in that. Is it in RAM at boot time? Choose your kernel ↓↓Pick any name $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 cpio: etc/console-setup/null: Cannot mknod: Operation not permitted $ ls -GlgR /tmp/initrd21/main/scripts/ /tmp/initrd21/main/scripts/: total 48 -rw-r--r-- 1 11152 Jan 14 2021 functions drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom drwxr-xr-x 2 4096 Feb 2 18:45 init-top -rw-r--r-- 1 5303 Jan 14 2021 local drwxr-xr-x 2 4096 Feb 2 18:45 local-block drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom drwxr-xr-x 2 4096 Feb 2 18:45 local-premount drwxr-xr-x 2 4096 Feb 2 18:45 local-top -rw-r--r-- 1 3093 Jan 14 2021 nfs /tmp/initrd21/main/scripts/init-bottom: total 8 -rw-r--r-- 1 77 Jan 23 21:46 ORDER -rwxr-xr-x 1 611 Aug 7 08:25 udev /tmp/initrd21/main/scripts/init-top: total 20 -rw-r--r-- 1 314 Jan 23 21:46 ORDER -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide -rwxr-xr-x 1 296 Jan 14 2021 blacklist -rwxr-xr-x 1 167 Jan 14 2021 keymap -rwxr-xr-x 1 568 Aug 7 08:25 udev /tmp/initrd21/main/scripts/local-block: total 8 -rw-r--r-- 1 82 Jan 23 21:46 ORDER -rwxr-xr-x 1 246 Feb 1 2022 cryptroot /tmp/initrd21/main/scripts/local-bottom: total 20 -rw-r--r-- 1 336 Jan 23 21:46 ORDER -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc -rwxr-xr-x 1 307 Feb 1 2022 cryptroot -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g /tmp/initrd21/main/scripts/local-premount: total 12 -rw-r--r-- 1 165 Jan 23 21:46 ORDER -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g -rwxr-xr-x 1 863 Jan 14 2021 resume /tmp/initrd21/main/scripts/local-top: total 20 -rw-r--r-- 1 162 Jan 23 21:46 ORDER -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot $ This is a desktop with random-key swap, so no resume. There are encrypted partitions present. YMMV. Cheers, David.
Re: kernel errors
Le 2 février 2023 Richmond a écrit : > There is no such file. Earlier I ran this: > > find / -print|grep "scripts/local-block" > > and it found nothing, which led me to believe it is some temporary file... >> >> (If not there, then in the /scripts/local-block directory of the initrd ?) its part of initramfs-tools to build initrd when you use cryptsetup, mdadm, etc $ locate local-block /usr/share/initramfs-tools/scripts/local-block /usr/share/initramfs-tools/scripts/local-block/cryptroot $ apt-file search /usr/share/initramfs-tools/scripts/local-block cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl
Re: kernel errors
"Thomas Schmitt" writes: > Indeed. But why should only the kernel be brain damaged ? > > (I expect some generic UUID searcher for block devices. Probably the sr > devices are near the end of its iteration. So one would not see any > protest in the log if the UUID is found on the device which is tried > earlier.) It crossed my mind that someone could conceivably be using the Universal Disk Format on a DVD RW. > Still missing is the code which wants to inspect sr. I tried to learn > about /scripts/local-block in initramfs-tools. Regrettably it seems to > be about a local customization of the initrd, which is not done by > initramfs-tools but by its customers. > A search for "local-block" in Debian's source collection by > https://codesearch.debian.net/search?q=local-block > did not yield good candidates. > > Do you see something related to resume in the output of > ls /usr/share/initramfs-tools/scripts/local-block There is no such file. Earlier I ran this: find / -print|grep "scripts/local-block" and it found nothing, which led me to believe it is some temporary file... > > (If not there, then in the /scripts/local-block directory of the initrd ?) I don't know how I would look in that. Is it in RAM at boot time? In the log which appears on the screen it says: Begin: Waiting for suspend/resume device ... Begin: Running /scripts/local-block ... done. random: crng init done /scripts/local-block ... done. Then this last line was repeated 17 times and much time was spent. Then it gave up.
Re: kernel errors
Hi, Richmond wrote: > Perhaps the system was looking for resume space on sr0? That's my guess too. We already knew that the read address and block size come from the kernel's brain damaged representation of a drive which has not seen a medium since boot. My suspicion was that libblkid is involved. But it was not clear what software wanted the service of libblkid. Now we have a candidate for that. > It seems a strange thing to do. Indeed. But why should only the kernel be brain damaged ? (I expect some generic UUID searcher for block devices. Probably the sr devices are near the end of its iteration. So one would not see any protest in the log if the UUID is found on the device which is tried earlier.) > But also it is quite a coincidence if the errors > occur when the resume space is messed up, and they go away when it is > fixed. That has happened twice. Empirically the situation is clear. Still missing is the code which wants to inspect sr. I tried to learn about /scripts/local-block in initramfs-tools. Regrettably it seems to be about a local customization of the initrd, which is not done by initramfs-tools but by its customers. A search for "local-block" in Debian's source collection by https://codesearch.debian.net/search?q=local-block did not yield good candidates. Do you see something related to resume in the output of ls /usr/share/initramfs-tools/scripts/local-block (If not there, then in the /scripts/local-block directory of the initrd ?) Have a nice day :) Thomas
Re: kernel errors - SOLVED
piorunz writes: > On 02/02/2023 14:05, Richmond wrote: >> After I did this, the errors went away. >> I don't know why the errors reference sr0, it's a mystery. > > They will most likely come back, this error is related to optical > drive, nothing to do with swap space. Perhaps the system was looking for resume space on sr0? It seems a strange thing to do. But also it is quite a coincidence if the errors occur when the resume space is messed up, and they go away when it is fixed. That has happened twice. It might be a good way for someone to reproduce the error on some other machine. I have no problems with the CD/DVD writer and have used it a few times recently.
Re: kernel errors - SOLVED
On 02/02/2023 14:05, Richmond wrote: After I did this, the errors went away. I don't know why the errors reference sr0, it's a mystery. They will most likely come back, this error is related to optical drive, nothing to do with swap space. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors - SOLVED
Richmond writes: > It may be a coincidence but yesterday I installed some > libguestfs-tools. Now I see errors when booting, which also appear in > /var/log/messages: > > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer > kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer These errors started occurring again. This time I knew what I had done, I commented out a line in fstab referencing a swap space, because the system had two swap spaces defined and I wanted to use one for something else. What I overlooked was that this swap space was also the resume space. During the boot there were other messages which did not appear in the journal so I filmed them with a smart phone: Running /scripts/local-block.. These occurred over and over, but allowed me to find this site: https://tipstricks.itmatrix.eu/solving-the-running-scripts-local-block-loop-while-booting-in-linux/ Which explained the problem and how to fix it. I had already edited: /etc/initramfs-tools/conf.d/resume To use the other swap space. But this did not help because I missed this crucial step: sudo update-initramfs -u After I did this, the errors went away. I don't know why the errors reference sr0, it's a mystery.
Re: kernel errors
Hi, Thomas Amm wrote: > First you might remove the pktcdvd module: > Not sure if it causes this specific problem but it is for pre- > growisofs CD-RW writing. The packet writing device bundles smaller write requests in larger chunks and ensures to write only at addresses and with sizes which are aligned to the medium's Fixed Packet Size. With CD this size can be chosen. With DVD it is 16 = 32 KiB. With BD it is 32 = 64 KiB. > Nobody uses that anymore Packet writing is life prolonging with random access writing to formatted CD-RW and maybe to DVD-RAM, DVD+RW, and BD-RE. It is needed for random access writing to formatted DVD-RW, which only accept write operations with 32 KiB granularity. Burn programs do not need /dev/pktcdvd, because they usually write sequentially with a suitable alignment. (.. and sequential writing is the most life prolonging way of writing.) > and it interferes with "straight" CD/DVD-burning. Not necessarily. The /dev/pktcdvd device uses the /dev/sr device when it performs its operations. But as long as it is not used, the /dev/sr device will not be disturbed. And even if so, then the media types which are suitable for /dev/pktcdvd can stand WRITE commands from two uncoordinated processes. Have a nice day :) Thomas
Re: kernel errors
On Mon, 2023-01-23 at 17:34 +, Richmond wrote: > Sven Joachim writes: > > > On 2023-01-23 16:13 +, Richmond wrote: > > > > > I put a dvd in and mounted it. Then rebooted. I saw these > > > messages: > > > > > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > > > [ 3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer > > > dvd-ram cd/rw xa/form2 cdda tray > > > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 > > > > > > Then removed the DVD and rebooted, back to these: > > > > > > [ 4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer > > > dvd-ram cd/rw xa/form2 cdda tray > > > [ 9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: > > > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > > > [ 9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready > > > [current] > > > [ 9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not > > > present - tray closed > > > [ 9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 > > > ff fc 00 00 02 00 > > > [ 9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer > > > > > > I am starting to consider re-installing, although everything is > > > working, > > > I don't like the look of it. Perhaps I should just re-install the > > > kernel? > > > > This would most likely not help. Instead you should try to figure > > out > > what process is trying to read from your empty drive, and why. > > Consulting journalctl might help with that. > > > > Cheers, > > Sven > > re-installing kernel didn't work. > > I looked in journalctl and saw this: > > kernel: PM: Image not found (code -22) > > It's looking for a resume from hibernate maybe. > > So then it became apparent that the kernel parameter to resume is a > disk > by id which looks different from the ones in /etc/fstab. I am not > sure > how that came about. > First you might remove the pktcdvd module: pktsetup -d /dev/sr0 -q Not sure if it causes this specific problem but it is for pre- growisofs CD-RW writing. Nobody uses that anymore and it interferes with "straight" CD/DVD-burning. If the error messages still show up after that it's most likely an unreadable DVD or your DVD-drive is beginning to fail. Usually the tracking lasers in these devices get deadjusted after a few years and readjusting them would be too much effort.
Re: kernel errors
Hi, piorunz wrote: > read attempts continue, Obviously your drive groper is different from Richmond's. Both get lured into their activities by the kernel bugs. > Inserting blank disc on every reboot is not a solution in my opinion. And I > didn't verified it myself, It would be interesting to know, nevertheless. > so I don't know if its going to work in my case, > or Linux at some point will realize the trick. :D It might last a while until Linux gets to a better behavior. My patches from 2020 are not totally trivial. So even if they still are applicable and there is a sponsor who gets them reviewed, i doubt that they would easily get accepted. Richmond reports from OpenSUSE with kernel 5.3 that the handling of blank media seems to have changed. But i still see it with 5.10. If you can identify the program which gets lured into probing the drive, then you could ask its developer to ignore optical drives of which the kernel reports sector size 512. But as soon as a medium was in the drive, the deception begins again. Have a nice day :) Thomas
Re: kernel errors
On 25/01/2023 15:26, Thomas Schmitt wrote: it might be that there are no further (periodic) read attempts. If the messages only appear once during the boot procedure, then i think the issue is explored as far as possible without starting kernel programming. Just to briefly comment on this - read attempts continue, please see my earlier messages in this thread, including original bug report 2 years ago. dmesg is infested with these errors in red, periodically there is another one, triggered by something, it goes on forever. Inserting blank disc on every reboot is not a solution in my opinion. And I didn't verified it myself, so I don't know if its going to work in my case, or Linux at some point will realize the trick. :D -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors
Hi, Richmond wrote: > VENDOR MODEL SIZE PHY-SEC LOG-SEC > HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 > It has stayed like this after I removed it. Next question would be whether the error messages stopped after this. But re-reading your initial post: > > I see errors when booting, which also appear in /var/log/messages: it might be that there are no further (periodic) read attempts. If the messages only appear once during the boot procedure, then i think the issue is explored as far as possible without starting kernel programming. The Linux kernel is buggy in respect to sector size and readable capacity of empty optical drives or drives with unreadable media. Ignore the error messages during system startup. You could try whether having a CD or DVD in the drive while booting silences the error messages. But i would not consider this as a workable long term solution. It is still not known what change on your system caused the read attempts to begin. The involved software could be made smarter to ignore sr devices which bear the impossible sector size 512. This size indicates that no medium was seen in the device since the device was started up. > I tried this on the same PC, but OpenSUSE 15.2, kernel 5.3 and putting > the blank disk in did not change the values, it still showed 512. It's a vivid bug, then. So my proposal to have a CD or DVD in the tray while booting would need the additional prescription that the medium must really be readable. And the possible workaround for periodic read attempts would not work any more. Have a nice day :) Thomas
Re: kernel errors
Richmond writes: > "Thomas Schmitt" writes: > >> Hi, >> >> i wrote: >>> > If you have some blank optical medium, then try whether the emitter of >>> > the read attempt can be discouraged if the drive is perceived as offering >>> > just one block of 2048 bytes. >> >> Richmond wrote: >>> I don't know how to do that. Do you mean make a DVD with 1 block of data? >> >> Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW. >> The size perception will change to >> VENDOR MODEL SIZE PHY-SEC LOG-SEC >> HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 >> >> Pull it out again, and this state will persist until you put in a medium >> which is readable, or until you reboot. >> > > I put in a blank DVD+RW. > > lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* > VENDOR MODEL SIZE PHY-SEC LOG-SEC > HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 > > It has stayed like this after I removed it. I tried this on the same PC, but OpenSUSE 15.2, kernel 5.3 and putting the blank disk in did not change the values, it still showed 512.
Re: kernel errors
"Thomas Schmitt" writes: > Hi, > > i wrote: >> > If you have some blank optical medium, then try whether the emitter of >> > the read attempt can be discouraged if the drive is perceived as offering >> > just one block of 2048 bytes. > > Richmond wrote: >> I don't know how to do that. Do you mean make a DVD with 1 block of data? > > Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW. > The size perception will change to > VENDOR MODEL SIZE PHY-SEC LOG-SEC > HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 > > Pull it out again, and this state will persist until you put in a medium > which is readable, or until you reboot. > I put in a blank DVD+RW. lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 It has stayed like this after I removed it.
Re: kernel errors
Hi, i wrote: > > If you have some blank optical medium, then try whether the emitter of > > the read attempt can be discouraged if the drive is perceived as offering > > just one block of 2048 bytes. Richmond wrote: > I don't know how to do that. Do you mean make a DVD with 1 block of data? Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW. The size perception will change to VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 Pull it out again, and this state will persist until you put in a medium which is readable, or until you reboot. > > There are many motivations to read the start of the device and fewer to > > read its end. One reason to read the end is the GPT backup header, which > > would sit 512 bytes before the end. > > The main GPT header block is at byte 512 of the storage device. > I am not using GPT on any systems. They all have ext4 root partitions. GPT might be used to mark partitions. It is the newer partition table format, which replaced most usages of the old MBR partition table. Whatever, it is not about what you actually use, but what the yet unknown software is looking for. libblkid would check for properties like PARTTYPE, PARTLABEL, or PARTUUID. Therefore it would look for GPT header blocks, regardless whether they are there. Have a nice day :) Thomas
Re: kernel errors
"Thomas Schmitt" writes: > I assume that you will see the same result there. lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST HL-DT-ST_DVDRAM_GH15F 1073741312 512 512 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux > > If you have some blank optical medium, then try whether the emitter of > the read attempt can be discouraged if the drive is perceived as offering > just one block of 2048 bytes. I don't know how to do that. Do you mean make a DVD with 1 block of data? > There are many motivations to read the start of the device and fewer to > read its end. One reason to read the end is the GPT backup header, which > would sit 512 bytes before the end. > The main GPT header block is at byte 512 of the storage device. I am not using GPT on any systems. They all have ext4 root partitions.
Re: kernel errors
On 25/01/2023 10:38, Thomas Schmitt wrote: Are users of Debian 10 (actually of kernel 4.19) here who are willing to run lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* directly after booting with empty drive tray ? $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODELSIZE PHY-SEC LOG-SEC hp hp_DVDRW_GUE1N 1073741312 512 512 $ sudo dmesg | grep sr0 [2.635585] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [2.707836] sr 1:0:0:0: Attached scsi CD-ROM sr0 Invisible medium seen by kernel is exactly 1GiB in size minus 512 bytes. But no errors in dmesg yet. By the way this is after power off, power on, with freshly upgraded stable kernel 5.10.0-21. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors
Hi, i wrote: > > Back in 2020 i would quite surely have noticed > > if that behavior had been shown. Richmond wrote: > lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* > VENDOR MODELSIZE PHY-SEC LOG-SEC > TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312 512 512 > > 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux So this behavior is not new. > This is a laptop where I rarely use the CD/DVD. Note it is not the same > computer as was getting errors before, that was debian 11. I assume that you will see the same result there. It would explain the block address of the first read attempt and the log messages about unaligned access. kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer If you have some blank optical medium, then try whether the emitter of the read attempt can be discouraged if the drive is perceived as offering just one block of 2048 bytes. -- The unresolved riddle is which software began to try reading from the optical drive after your recent package installations or upgrades. It might be a different one than the software which does similar read attempts on piorunz' machine since years. In any case these softwares inquire the device capacity from systemd or directly from the kernel. Then they try to read end and start of the obtained capacity. There are many motivations to read the start of the device and fewer to read its end. One reason to read the end is the GPT backup header, which would sit 512 bytes before the end. The main GPT header block is at byte 512 of the storage device. This would explain the next failed read attempt: kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 I wonder why the caller did not want only 512 or 1024 bytes. The number of 2 requested blocks cannot come from the read-ahead mechanism of the Linux block layer. I would still place my bet on something like blkid, which wants to know whether there is a partition table. Maybe there was a change about a customer of libblkid. Have a nice day :) Thomas
Re: kernel errors
"Thomas Schmitt" writes: > > Are users of Debian 10 (actually of kernel 4.19) here who are willing to > run > lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* > directly after booting with empty drive tray ? lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODELSIZE PHY-SEC LOG-SEC TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312 512 512 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux This is a laptop where I rarely use the CD/DVD. Note it is not the same computer as was getting errors before, that was debian 11.
Re: kernel errors
Hi, piorunz wrote: > CD inserted: > $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 > VENDOR MODEL SIZE PHY-SEC LOG-SEC > hp hp_DVDRW_GUE1N 62765670420482048 > DVD inserted: > $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 > VENDOR MODELSIZE PHY-SEC LOG-SEC > hp hp_DVDRW_GUE1N 335334604820482048 So we know that the kernel-perceived block size is correctly 2048 when a medium is inserted. Do the complaints continue to appear in the logs while the medium is loaded ? The remaining question is what the kernel perceives after the system has booted and no medium was inserted since then. And for completeness, what the kernel perceives when the tray is empty after the running system already saw a medium in it (I'll give my own answers to that question further below.) > I noticed it when DVD disc was loading and until it did, lsblk was happily > reporting that 627656704 bytes CD is still there for every userspace app to > use and send queries to. The problem is actually that the size does not get set to 0 when the medium gets unloaded. (Further bug: Blank media get attributed size 2048.) In preparation of a fix, Karel Zak of util-linux changed lsblk so that it would report devices of SIZE 0. But after getting no feedback on other bug fix patches for Linux, i did not submit my fix for the size problem to the kernel developers. Back in september 2020 it would have consisted of four patches: cdrom: introduce new exported function cdrom_disc_information() sr: introduce resetter functions for sr_cd_check() and get_sectorsize() sr: attribute size 0 to "empty" (aka blank) media sr: attribute size 0 to not loaded or unusable media > And queries are being sent, my guess is from file > manager, to query and display CD name etc. if there is one, because it > thinks everything is fine and its okay to ask. That's my suspicion too. I now am baffled by the result on a Debian 11 with drives not used since booting it: $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODEL SIZE PHY-SEC LOG-SEC PIONEER PIONEER_BD-RW_BDR-S09 1073741312 512 512 TSSTcorp CDDVDW_SH-S223B 1073741312 512 512 The first one is a built-in SATA drive, the second is SATA in a USB box. All are perceived with wrong block size and a fictional capacity of 1 GiB - 512 bytes. I'd say that this is some clueless default setting that must be new since kernel 4.19 of Debian 10. Back in 2020 i would quite surely have noticed if that behavior had been shown. $ uname -a Linux ... 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux Are users of Debian 10 (actually of kernel 4.19) here who are willing to run lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* directly after booting with empty drive tray ? Whatever, when i let a DVD+RW wander through the drives and then put it back on the shelf, i afterwards get the usual outdated capacity and the correct block size: VENDOR MODEL SIZE PHY-SEC LOG-SEC PIONEER PIONEER_BD-RW_BDR-S09 470037299220482048 TSSTcorp CDDVDW_SH-S223B 470037299220482048 >From now on the system seems to behave like i am used from older Debian versions. Wrong but reliable. I know of no way to bring the capacity perception to 0. But the size can be reduced to 2048 bytes by inserting a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW or BD-R medium. A totally unused BD-RE or DVD+RW might do the trick too (do not allow a burn program to format them). Here i used a blank BD-R on the Pioneer and a blank DVD-R on the Samsung: VENDOR MODEL SIZE PHY-SEC LOG-SEC PIONEER PIONEER_BD-RW_BDR-S09 204820482048 TSSTcorp CDDVDW_SH-S223B204820482048 This state remains when the medium is removed until the next medium is inserted and fully assessed by the drive. The drive groping software on your machine seems to want to read more than just a single block of 2048 bytes. So reducing the perceived size to 2048 by inserting a blank medium once after booting might already do the trick. (I wonder why the "VENDOR" name gets prepended to the actual "MODEL" name with the Pioneer drive and probably the HP one of piorunz but not to the Samsung drive CDDVDW_SH-S223B. I know that the Pioneer identifies its model name as "BD-RW BDR-S09", not as "PIONEER BD-RW BDR-S09".) Have a nice day :) Thomas
Re: kernel errors
On 24/01/2023 18:58, Thomas Schmitt wrote: Hi, the log messages about "unaligned transfer" would be explained if indeed the block size of the drive would be mistaken as 512 bytes rather than 2048 bytes. So it might be interesting to let lsblk report "sector" sizes as perceived by the kernel: lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 I get from the empty drive (last medium in was a CD-RW): VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 28748390420482048 and with a BD-RE loaded: VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 2475687936020482048 CD inserted: $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 VENDOR MODEL SIZE PHY-SEC LOG-SEC hp hp_DVDRW_GUE1N 62765670420482048 DVD inserted: $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 VENDOR MODELSIZE PHY-SEC LOG-SEC hp hp_DVDRW_GUE1N 335334604820482048 I noticed that when there is no disc or disc is loading, this command above is still reporting last used disc even when it's already gone. Meaning, kernel does not know there is no disc. I noticed it when DVD disc was loading and until it did, lsblk was happily reporting that 627656704 bytes CD is still there for every userspace app to use and send queries to. And queries are being sent, my guess is from file manager, to query and display CD name etc. if there is one, because it thinks everything is fine and its okay to ask. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors
Hi, the log messages about "unaligned transfer" would be explained if indeed the block size of the drive would be mistaken as 512 bytes rather than 2048 bytes. So it might be interesting to let lsblk report "sector" sizes as perceived by the kernel: lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 I get from the empty drive (last medium in was a CD-RW): VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 28748390420482048 and with a BD-RE loaded: VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 2475687936020482048 Have a nice day :) Thomas
Re: kernel errors
Hi, piorunz wrote: > Today, kernel 5.10, Debian 11 Bullseye, and problem still exists :D > > $ lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 > VENDOR MODELSIZE > hp hp_DVDRW_GUE1N 1073741312 Now that's a strange size: 1 GiB - 512 bytes. The readable data capacity of an optical drive should be divisible by 2048, but the reported size is not. (I remember to have read of very old CD drives with a hardware switch which changes the data block size from 2048 to 512 bytes.) What do you get from the lsblk command when a readable DVD is inserted and later when the medium is out of the drive again ? Have a nice day :) Thomas
Re: kernel errors
On 23/01/2023 15:01, Thomas Schmitt wrote: I wonder what might have caused this. But this line brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 where pior...@gmail.com tried to get this processed as bug of udev. No solution was found. That would be me. Over three years ago, on kernel 4.19. Today, kernel 5.10, Debian 11 Bullseye, and problem still exists :D However, error message has since changed, word udev is not present in the message. Old format: udev: Buffer I/O error on dev sr0, logical block 0, async page read New format: Buffer I/O error on dev sr0, logical block 0, async page read As I've removed optical drive from my desktop computer, this now happens on a laptop computer, which has not seen a CD inserted into the tray for about 6 months. There should be absolutely no errors, just one read attempt - "sorry, no medium". But dmesg is infested with read attempt errors. This particular laptop now, is with KDE, 100% clean and updated Debian stable. For those interested, filtered "sudo dmesg | grep sr0" is attached and model of the drive is below. $ lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 VENDOR MODELSIZE hp hp_DVDRW_GUE1N 1073741312 -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄ [2.603616] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [2.675633] sr 1:0:0:0: Attached scsi CD-ROM sr0 [ 658.218324] sr 1:0:0:0: [sr0] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 658.218328] sr 1:0:0:0: [sr0] tag#29 Sense Key : Not Ready [current] [ 658.218331] sr 1:0:0:0: [sr0] tag#29 Add. Sense: Medium not present - tray closed [ 658.218333] sr 1:0:0:0: [sr0] tag#29 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 658.218336] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 [ 658.250926] sr 1:0:0:0: [sr0] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 658.250932] sr 1:0:0:0: [sr0] tag#14 Sense Key : Not Ready [current] [ 658.250936] sr 1:0:0:0: [sr0] tag#14 Add. Sense: Medium not present - tray closed [ 658.250939] sr 1:0:0:0: [sr0] tag#14 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 [ 658.250942] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 658.250947] Buffer I/O error on dev sr0, logical block 0, async page read [ 658.250950] Buffer I/O error on dev sr0, logical block 1, async page read [ 658.250952] Buffer I/O error on dev sr0, logical block 2, async page read [ 658.250954] Buffer I/O error on dev sr0, logical block 3, async page read [ 658.250956] Buffer I/O error on dev sr0, logical block 4, async page read [ 658.250958] Buffer I/O error on dev sr0, logical block 5, async page read [ 658.250960] Buffer I/O error on dev sr0, logical block 6, async page read [ 658.250962] Buffer I/O error on dev sr0, logical block 7, async page read [ 667.549410] sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 667.549415] sr 1:0:0:0: [sr0] tag#0 Sense Key : Not Ready [current] [ 667.549419] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Medium not present - tray closed [ 667.549422] sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 667.549425] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 [ 667.602070] sr 1:0:0:0: [sr0] tag#31 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 667.602075] sr 1:0:0:0: [sr0] tag#31 Sense Key : Not Ready [current] [ 667.602078] sr 1:0:0:0: [sr0] tag#31 Add. Sense: Medium not present - tray closed [ 667.602080] sr 1:0:0:0: [sr0] tag#31 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 [ 667.602083] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 667.602090] Buffer I/O error on dev sr0, logical block 0, async page read [ 667.602094] Buffer I/O error on dev sr0, logical block 1, async page read [ 667.602096] Buffer I/O error on dev sr0, logical block 2, async page read [ 667.602097] Buffer I/O error on dev sr0, logical block 3, async page read [ 667.602099] Buffer I/O error on dev sr0, logical block 4, async page read [ 667.602101] Buffer I/O error on dev sr0, logical block 5, async page read [ 667.602104] Buffer I/O error on dev sr0, logical block 6, async page read [ 667.602106] Buffer I/O error on dev sr0, logical block 7, async page read [ 1874.677595] sr 1:0:0:0: [sr0] tag#31 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 1874.677600] sr 1:0:0:0: [sr0] tag#31 Sense Key : Not Ready [current] [ 1874.677604] sr 1:0:0:0: [sr0] tag#31 Add. Sense: Medium not present - tray closed [ 1874.677607] sr 1:0:0:0: [sr0] tag#31 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 1874.677611] blk_update_request
Re: kernel errors
David Wright writes: > On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote: >> It may be a coincidence but yesterday I installed some >> libguestfs-tools. Now I see errors when booting, which also appear in >> /var/log/messages: >> >> kernel: [ 9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s >> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready >> [current] >> kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not >> present - tray closed >> kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff >> fc 00 00 02 00 >> kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer >> kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer >> kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer >> kernel: [ 9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s >> kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready >> [current] >> kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not >> present - tray closed >> kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 >> 00 00 00 02 00 >> kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer >> kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer >> >> I removed the toos, and also disabled udiskd or udisk2d: >> >> systemctl stop udisks2.service >> systemctl disable udisks2.service >> >> But the errors are still occuring. How can I stop them? >> >> Installing the tools did some strange things like regenerating the grub >> menu. > > When you've removed the packages, keep a copy of your grub.cfg for > comparison and then reconfigure grub (grub-mkconfig). See if the > messages go away. The messages didn't go away. And I tried to reconfigure swap and resume, and got more errors, so I reinstalled the system, formatting the root partition. > > Did you have something strange in your optical drive when you > installed these tools, in anticipation of using the latter on > the former? No, but I did have a usb stick plugged in, and it had ChromeOS Flex on it. In fact that appeared on the grub menu yesterday and I tried to boot ChromeOS Flex from it. That was no doubt a big mistake.
Re: kernel errors
On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote: > It may be a coincidence but yesterday I installed some > libguestfs-tools. Now I see errors when booting, which also appear in > /var/log/messages: > > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer > kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer > kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=0s > kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready > [current] > kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present > - tray closed > kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 > 00 00 00 02 00 > kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer > kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer > > I removed the toos, and also disabled udiskd or udisk2d: > > systemctl stop udisks2.service > systemctl disable udisks2.service > > But the errors are still occuring. How can I stop them? > > Installing the tools did some strange things like regenerating the grub > menu. When you've removed the packages, keep a copy of your grub.cfg for comparison and then reconfigure grub (grub-mkconfig). See if the messages go away. Did you have something strange in your optical drive when you installed these tools, in anticipation of using the latter on the former? Cheers, David.
Re: kernel errors
Sven Joachim writes: > On 2023-01-23 16:13 +, Richmond wrote: > >> I put a dvd in and mounted it. Then rebooted. I saw these messages: >> >> [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 >> [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram >> cd/rw xa/form2 cdda tray >> [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 >> >> Then removed the DVD and rebooted, back to these: >> >> [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram >> cd/rw xa/form2 cdda tray >> [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK >> driverbyte=DRIVER_SENSE cmd_age=2s >> [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] >> [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - >> tray closed >> [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 >> 00 02 00 >> [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer >> >> I am starting to consider re-installing, although everything is working, >> I don't like the look of it. Perhaps I should just re-install the >> kernel? > > This would most likely not help. Instead you should try to figure out > what process is trying to read from your empty drive, and why. > Consulting journalctl might help with that. > > Cheers, >Sven re-installing kernel didn't work. I looked in journalctl and saw this: kernel: PM: Image not found (code -22) It's looking for a resume from hibernate maybe. So then it became apparent that the kernel parameter to resume is a disk by id which looks different from the ones in /etc/fstab. I am not sure how that came about.
Re: kernel errors
Hi, Richmond wrote: > I put a dvd in and mounted it. Then rebooted. I saw these messages: > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram > cd/rw xa/form2 cdda tray > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 Looks normal. > Then removed the DVD and rebooted, back to these: I wonder what happens if you simply put in and out the medium, without rebooting. It looks somewhat as if the kernel perceives a wrong medium status and size and so lures some software like blkid into trying to read the last 4 KiB before the end of the first GiB. What do you get from: lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 I get: VENDOR MODEL SIZE HL-DT-ST BDDVDRW GGC-H20L 4700372992 (It is a known bug of Linux to report the size of the last loaded medium if the drive tray is empty. But exactly 1 GiB is a strange size for a DVD medium and rebooting should clear this misperception.) > I am starting to consider re-installing, although everything is working, > I don't like the look of it. Perhaps I should just re-install the kernel? If you do, then check whether the messages are not there after base system installation and then try to find out which further package causes those read attempts. Have a nice day :) Thomas
Re: kernel errors
On 2023-01-23 16:13 +, Richmond wrote: > I put a dvd in and mounted it. Then rebooted. I saw these messages: > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram > cd/rw xa/form2 cdda tray > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 > > Then removed the DVD and rebooted, back to these: > > [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram > cd/rw xa/form2 cdda tray > [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=2s > [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] > [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray > closed > [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 > 02 00 > [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer > > I am starting to consider re-installing, although everything is working, > I don't like the look of it. Perhaps I should just re-install the > kernel? This would most likely not help. Instead you should try to figure out what process is trying to read from your empty drive, and why. Consulting journalctl might help with that. Cheers, Sven
Re: kernel errors
"Thomas Schmitt" writes: > Hi, > > Richmond wrote: >> kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s >> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready >> [current] >> kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not >> present - tray closed >> kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff >> fc 00 00 02 00 > > Your optical drive gets asked for 2 blocks iand answers that there is no > medium recognized in the tray. The request was to read from block 0x07fffc > = 524284 = 1023.9921875 MiB = 1 GiB - 4 KiB. > This is not a usual medium capcity. So i wonder from where the caller had > that block address. > > >> kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > > I wonder what might have caused this. But this line brings me to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 > where pior...@gmail.com tried to get this processed as bug of udev. > No solution was found. > > >> kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s >> kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready >> [current] >> kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not >> present - tray closed >> kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 >> 00 00 00 02 00 > > This read attempt wanted to get 2 blocks from block address 0. > More plausible as a wild guess, than 1 GiB - 4 KiB. > > > What happens if you give the drive a readable DVD ? > Maybe the software which issues the READ commands shows up with some more > enlightening complaint. > > > Have a nice day :) > > Thomas I put a dvd in and mounted it. Then rebooted. I saw these messages: [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 Then removed the DVD and rebooted, back to these: [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray closed [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer I am starting to consider re-installing, although everything is working, I don't like the look of it. Perhaps I should just re-install the kernel?
Re: kernel errors
Hi, Richmond wrote: > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 Your optical drive gets asked for 2 blocks iand answers that there is no medium recognized in the tray. The request was to read from block 0x07fffc = 524284 = 1023.9921875 MiB = 1 GiB - 4 KiB. This is not a usual medium capcity. So i wonder from where the caller had that block address. > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer I wonder what might have caused this. But this line brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 where pior...@gmail.com tried to get this processed as bug of udev. No solution was found. > kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=0s > kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current] > kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present > - tray closed > kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 > 00 00 00 02 00 This read attempt wanted to get 2 blocks from block address 0. More plausible as a wild guess, than 1 GiB - 4 KiB. What happens if you give the drive a readable DVD ? Maybe the software which issues the READ commands shows up with some more enlightening complaint. Have a nice day :) Thomas
kernel errors
It may be a coincidence but yesterday I installed some libguestfs-tools. Now I see errors when booting, which also appear in /var/log/messages: kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready [current] kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not present - tray closed kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current] kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present - tray closed kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer I removed the toos, and also disabled udiskd or udisk2d: systemctl stop udisks2.service systemctl disable udisks2.service But the errors are still occuring. How can I stop them? Installing the tools did some strange things like regenerating the grub menu.
Re: Fixing errors on a BTRFS partition?
Well, I didn't fix the errors, but I was able to use 'btrfs replace' to move the file system to an external HDD. The SDD I ordered apparently is ping-ponging its way from Kansas City to various area post offices and back again before they get it on the right truck. Sigh... - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Fixing errors on a BTRFS partition?
* On 2023 15 Jan 10:07 -0600, Andy Smith wrote: > Hello, > > On Thu, Jan 12, 2023 at 04:57:07PM -0600, Intense Red wrote: > > > Everything online hints that attempting repair is particularly > > > dangerous, but what else am I to do? > > > >You sum up my experience with BTRFS. I too was "scared" off from it and > > reformatted my BTRFS partitions and went back to ext4 -- it's a known > > quantity fit for humans with tons of advice of how to handle > > problems/errors. > > I too don't have a lot of love for btrfs, but I think it is a bit > unfair to criticise it in this scenario, which is a failing SD card > with no redundancy. If there'd been redundancy then btrfs should > have noticed the problems and got the data from the other > copy/copies, but here it had no opportunity to do so. > > In the same situation, ext4 would have just carried on until it got > read/write errors but this wouldn't have been any better. btrfs got > the same errors and reported more of its own that it noticed from > the incorrect checksums. > > It sounds like the OP's use case didn't involve redundancy nor did > it involve any of the other btrfs features such as compression or > snapshots, so btrfs probably wasn't a good choice here. ext4 or XFS > may have been better here just because they are simpler. I can > understand not wanting to have a learning experience when it comes > to one's data. Perhaps this needs to be taken up with the Freedom Box Foundation (it has close ties to Debian) as it is the image they provide that chose btrfs to be written to the micro-SD card and used as an appliance on the Freedom Box Pioneer hardware (Olimex A20-OLinuXino-LIME2). *I* did not choose this filesystem for this application, just to be clear. If there is a better choice for what is intended to be an appliance running from a micro-SD card, then that should be communicated to the Freedom Box people. I have an SSD on order and will rebuild with ext4. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Replacing drive in Btrfs Raid10 partition? (Was: Fixing errors on a BTRFS partition?)
Guys, Quick offtop question as we are talking about Btrfs: How do you replace drives in Btrfs Raid10 array? I am in the process of upgrading 4 drives to twice as big ones. Since forever, I've been using this (example): sudo btrfs device add -f /dev/sdf1 /home sudo btrfs device remove /dev/sdd1 /home But now I am reading, newer fancy method is: sudo btrfs replace /dev/sdd1 /dev/sdf1 /home Which one is better please? For both situation where drive has failed or is still operational? -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: Fixing errors on a BTRFS partition?
Hello, On Thu, Jan 12, 2023 at 04:57:07PM -0600, Intense Red wrote: > > Everything online hints that attempting repair is particularly > > dangerous, but what else am I to do? > >You sum up my experience with BTRFS. I too was "scared" off from it and > reformatted my BTRFS partitions and went back to ext4 -- it's a known > quantity fit for humans with tons of advice of how to handle problems/errors. I too don't have a lot of love for btrfs, but I think it is a bit unfair to criticise it in this scenario, which is a failing SD card with no redundancy. If there'd been redundancy then btrfs should have noticed the problems and got the data from the other copy/copies, but here it had no opportunity to do so. In the same situation, ext4 would have just carried on until it got read/write errors but this wouldn't have been any better. btrfs got the same errors and reported more of its own that it noticed from the incorrect checksums. It sounds like the OP's use case didn't involve redundancy nor did it involve any of the other btrfs features such as compression or snapshots, so btrfs probably wasn't a good choice here. ext4 or XFS may have been better here just because they are simpler. I can understand not wanting to have a learning experience when it comes to one's data. The btrfs mailing list is pretty helpful. I think if one was not scared to ask for help there regarding unfamiliar steps, btrfs in a redundant configuration is pretty safe for your data. My gripes with it over the years have been user interface, bugs and availability issues, not resilience i.e. I've never lost data to it. Having said that, I really do not trust things like SD cards or CompactFlash cards (remember those? I still have one in service in a firewall) for main storage unless they will be largely or entirely read-only. In my mind they are more suited to phones and cameras and similar devices. Similarly, USB storage. Attaching a USB drive (or stick!) to an Intel NUC or Raspberry Pi and exposing that over SMB is what some people consider network attached storage, and I'm sure there's people reading this who have done this for years and never had a problem, but I've had and seen so many problems with non-trivial use of USB storage. For myself, I'd want any long term setup to be attached by SATA or NVMe or over network to same. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Fixing errors on a BTRFS partition?
On Thu, Jan 12, 2023 at 8:43 AM Nate Bargmann wrote: > > I have a Freedom Box Pioneer (hardware is an Olimex A20-OLinuXino-LIME2 > unit with a Samsung 128 GB micro-SD card. The micro-SD is partitioned > into 2GB boot ext2 and the remainder as the root partition as BTRFS. > > The thing has been crashing for months and now it started giving GPG > signature errors when trying to run 'apt update'. I copied the entire > micro-SD card to an image file with dd so I have a backup. Running > 'btrfs check' resulted in a lot of errors so I ran the check and > directed the output to a file which is over 2MB in size! The following > is a small snippet of what it in the file: The microSD card is failing. Replace it. Jeff
Re: Fixing errors on a BTRFS partition?
* On 2023 12 Jan 16:58 -0600, Intense Red wrote: > > Everything online hints that attempting repair is particularly > > dangerous, but what else am I to do? > >You sum up my experience with BTRFS. I too was "scared" off from it and > reformatted my BTRFS partitions and went back to ext4 -- it's a known > quantity fit for humans with tons of advice of how to handle problems/errors. I had experimented with BTRFS some years ago as its virtual partitions feature is attractive for things like tmp, var, and usr where each is "separate" but is part of a larger fixed partition. Choosing proper sizes is eased somewhat. Other than that its not my choice, usually. In this case the card came already formatted with the root partition as BTRFS so I left it alone. An SSD is on order. I still have to use a micro-SD card for the boot partition as the MICRO cannot boot directly to the SSD as far as I know. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Fixing errors on a BTRFS partition?
* On 2023 12 Jan 08:15 -0600, Dan Ritter wrote: > Nate Bargmann wrote: > > I have a Freedom Box Pioneer (hardware is an Olimex A20-OLinuXino-LIME2 > > unit with a Samsung 128 GB micro-SD card. The micro-SD is partitioned > > into 2GB boot ext2 and the remainder as the root partition as BTRFS. > > > > The thing has been crashing for months > > For the future: don't let things go this long. I know it's > tempting to say "maybe it won't happen again", but the second > time should be the last time before you take action. At one point I replaced another piece of hardware that was on the same Ethernet switch as this unit and the crashes cleared up for a while. Then I suspected a flaky power adapted but haven't addressed it and then I suspected RF from my amateur radio operations and put the power cord in a ferrite core with no positive results. It wasn't until the 'apt update' GPG failure this morning (the Freedom box image is setup to auto update) in a manual update attempt that the light bulb lit up. > > and now it started giving GPG > > signature errors when trying to run 'apt update'. I copied the entire > > micro-SD card to an image file with dd so I have a backup. Running > > 'btrfs check' resulted in a lot of errors so I ran the check and > > directed the output to a file which is over 2MB in size! The following > > is a small snippet of what it in the file: > > ... > > > Everything online hints that attempting repair is particularly > > dangerous, but what else am I to do? At the moment the system is pretty > > much useless. > > > 1: get a new card, or, much better, replace with a SATA > SSD. (I see the Olimex has a SATA port. Use it!) Here's a > https://www.newegg.com/adata-ultimate-su800-128gb/p/N82E16820215015?Item=9SIAJNUBMB4508 > $29 128GB SSD from a reputable manufacturer. > > 2: Reinstall Debian on the new disk. Don't use btrfs on a > single-drive system; only use btrfs on a mirrored system. In most cases, > use ext4. > > 3: copy all the data you can from the image file. Looks like a plan I will do. I had an SATA drive on it to begin with but then decided to just use the micro-SD card. My guess that a quite large card with much excess capacity would wear level enough for long life. Well, maybe 18 months or so is "long life". For the record, the Freedom Box micro-SD card image formats the root partition as BTRFS. It wasn't a choice of mine. I've used ext2/3/4 for many years and that system has always done well for me. Fortunately this isn't a system that is critical, but it does serve some purposes. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Fixing errors on a BTRFS partition?
> Everything online hints that attempting repair is particularly > dangerous, but what else am I to do? You sum up my experience with BTRFS. I too was "scared" off from it and reformatted my BTRFS partitions and went back to ext4 -- it's a known quantity fit for humans with tons of advice of how to handle problems/errors. -- "The US has never had a 'foreign policy' but a fanatical domestic policy which, once it had bled through to the Pacific, sought new hosts on which to feed." -- Patrick Wilkinson.
Re: Fixing errors on a BTRFS partition?
On Thu, Jan 12, 2023 at 14:10:22 +, piorunz wrote: > To satiate your curiosity, you can find out what files are corrupted, some > of the errors are giving filenames. If not, this is my saved command to > obtain filename from inode numbers: > sudo btrfs inspect-internal inode-resolve 50845 / > > And obtain filename from logical error: > sudo btrfs inspect-internal logical-resolve -v 540115857408 / > > As far as I know, Btrfs may refuse to read file with wrong checksum, there > may be another command to do that. I believe mounting with -o rescue=all will allow to read corrupted files, so the remaining parts of non-replaceable files can be salvaged; though I fortunately never had to put this to test myself. Specifically the ignoredatacsums setting, see https://btrfs.readthedocs.io/en/stable/Administration.html#mount-options Note that this requires a sufficiently new kernel. On Thu, Jan 12, 2023 at 08:58:52 -0500, Dan Ritter wrote: > For the future: don't let things go this long. I know it's > tempting to say "maybe it won't happen again", but the second > time should be the last time before you take action. To add to this: usually it is recommended to regularly run `btrfs scrub` to detect (and in case of redunancy repair) data degradation. Running also `btrfs check` regularly to verify the fs structure also isn't a bad idea. This makes it more likely you'll notice a failing device before it gets as bad as it is now. > 2: Reinstall Debian on the new disk. Don't use btrfs on a > single-drive system; only use btrfs on a mirrored system. In most cases, > use ext4. For the record, I don't agree with BTRFS only being useful with RAID. BTRFS’ scrub and check can detect corruption early, rather then bitrot silently continuing until it starts crashing and there might be other features like e.g. transparent compression which might make it worthwhile for one’s single-device usecases. (In theory redunancy can also be used with a single device by creating the FS with the "dup" data profile, but this of course offers les protection than separate devices.)
Re: Fixing errors on a BTRFS partition?
Try this article https://en.opensuse.org/SDB:BTRFS On Thu, Jan 12, 2023, 5:43 AM Nate Bargmann wrote: > I have a Freedom Box Pioneer (hardware is an Olimex A20-OLinuXino-LIME2 > unit with a Samsung 128 GB micro-SD card. The micro-SD is partitioned > into 2GB boot ext2 and the remainder as the root partition as BTRFS. > > The thing has been crashing for months and now it started giving GPG > signature errors when trying to run 'apt update'. I copied the entire > micro-SD card to an image file with dd so I have a backup. Running > 'btrfs check' resulted in a lot of errors so I ran the check and > directed the output to a file which is over 2MB in size! The following > is a small snippet of what it in the file: > > [1/7] checking root items > [2/7] checking extents > checksum verify failed on 2337062912 found 0098 wanted 0025 > checksum verify failed on 2337062912 found 0098 wanted 0025 > Csum didn't match > owner ref check failed [2337062912 16384] > ERROR: errors found in extent allocation tree or chunk allocation > [3/7] checking free space cache > [4/7] checking fs roots > checksum verify failed on 2337062912 found 0098 wanted 0025 > checksum verify failed on 2337062912 found 0098 wanted 0025 > Csum didn't match > root 11670 inode 1109704 errors 200, dir isize wrong > root 11670 inode 1109705 errors 2001, no inode item, link count wrong > unresolved ref dir 1109704 index 2 namelen 4 name json filetype 1 > errors 4, no inode ref > root 11670 inode 1109706 errors 2001, no inode item, link count wrong > unresolved ref dir 1095383 index 2 namelen 11 name 20-json.ini > filetype 7 errors 4, no inode ref > root 11670 inode 1109707 errors 2001, no inode item, link count wrong > unresolved ref dir 978863 index 4 namelen 7 name apache2 filetype > 2 errors 4, no inode ref > root 11670 inode 1109710 errors 2001, no inode item, link count wrong > unresolved ref dir 1095409 index 2 namelen 11 name 20-json.ini > filetype 7 errors 4, no inode ref > root 11670 inode 1109711 errors 2001, no inode item, link count wrong > unresolved ref dir 978863 index 5 namelen 3 name fpm filetype 2 > errors 4, no inode ref > root 11670 inode 1109714 errors 2001, no inode item, link count wrong > unresolved ref dir 978864 index 30 namelen 4 name json filetype 1 > errors 4, no inode ref > root 11670 inode 1109734 errors 2001, no inode item, link count wrong > unresolved ref dir 45938 index 176 namelen 17 name > gschemas.compiled filetype 1 errors 4, no inode ref > root 11670 inode 1109735 errors 2001, no inode item, link count wrong > unresolved ref dir 6679 index 36 namelen 15 name giomodule.cache > filetype 1 errors 4, no inode ref > root 11670 inode 1109771 errors 2001, no inode item, link count wrong > unresolved ref dir 295871 index 242 namelen 24 name > rsyslog.service.dsh-also filetype 1 errors 4, no inode ref > root 11670 inode 1109784 errors 2001, no inode item, link count wrong > unresolved ref dir 978742 index 31 namelen 12 name readline.ini > filetype 1 errors 4, no inode ref > . > . > . > ERROR: errors found in fs roots > Opening filesystem to check... > Checking filesystem on /dev/mmcblk0p2 > UUID: ea375ed2-d6e7-49d4-9b19-a624ba09b96c > The following tree block(s) is corrupted in tree 11670: > tree block bytenr: 6562955264, level: 1, node key: (1109704, 96, 3) > found 19331854402 bytes used, error(s) found > total csum bytes: 14201108 > total tree bytes: 1242775552 > total fs tree bytes: 1160757248 > total extent tree bytes: 61292544 > btree space waste bytes: 327420862 > file data blocks allocated: 182356692992 > referenced 113920880640 > > > Everything online hints that attempting repair is particularly > dangerous, but what else am I to do? At the moment the system is pretty > much useless. > > All insights appreciated. > > - Nate > > -- > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 > >
