Hardware Error Messages
I have a Desktop PC running Debian 11. A few days ago I found the following error messages on an xterm window running in the background :- Message from syslogd@piglit at Sep 28 09:44:25 ... kernel:[51369.604961] [Hardware Error]: Deferred error, no action required. Message from syslogd@piglit at Sep 28 09:44:25 ... kernel:[51369.604965] [Hardware Error]: CPU:1 (19:21:2) MC27_STATUS[Over|-|-|-|PCC|SyndV|UECC|Deferred|Poison|Scrub]: 0xd3edbbfde0a1894c Message from syslogd@piglit at Sep 28 09:44:25 ... kernel:[51369.604969] [Hardware Error]: IPID: 0x, Syndrome: 0x Message from syslogd@piglit at Sep 28 09:44:25 ... kernel:[51369.604970] [Hardware Error]: Power, Interrupts, etc. Ext. Error Code: 33 Message from syslogd@piglit at Sep 28 09:44:25 ... kernel:[51369.604971] [Hardware Error]: cache level: RESV, tx: RESV Can any helpful information be obtained from them or are they high level pretty meaningless messages ? Does Debian have any way of trapping low level hardware Error Messages ?
Clock Icon
I have a clock icon on my desktop PC which opens on reboot and then remains on the top right of the screen all the time. However, for some reason it has moved (not sure how this happened) and is now in the middle of the screen under my browser windows (so not visible). I would like to move the clock, but can't seem to move it with my mouse - none of the buttons when pressed and held down move it and right clicking doesn't do anything either. Can anyone help, please ?
Migrating from hard drives to SSDs
I am thinking of changing my storage from two 1TB hard drives in a software RAID 1 configuration to two M.2 Nvme 1 TB SSDs. The two SSDs would be put into a software RAID 1 configuration. Currently each hard drive contains both the operating system and user data. What steps would you recommend to achieve the above result and would those steps be the quickest way ? One of the M.2 slots can operate at PCIe 4.0 and PCIe 3.0, while the other slot can only operate at PCIe 3.0. If they are to be in a RAID 1 array, I guess that both slots should be operated at PCIe 3.0 speed.
Re: Corrupt root filesystem
On 20:30, Fri, 7 Jul 2023 Reco > On Fri, Jul 07, 2023 at 06:26:28PM +0100, Mick Ab wrote: > > The error messages were of the form :- > > > > "/dev/mapper/vgpcname-root contains a file system with errors, check > > forced. > >Inodes that were a part of a corrupted orphan linked lost found. > >/dev/mapper/vgpcname-root : UNEXPECTED INCONSISTENCY; RUN fsck > > manually.(i.e ., > >without -a or -p options). fsck exited with status code 4. The root > >filesystem on /dev/mapper/vgpcname-root requires a manual fsck > > > > There is then a flashing prompt after "(initramfs)". > > So, first things first, it's not "before reboot". > It's "during the boot". And note that initramfs ran fsck, but it failed. > > Second, yes, that particular filesystem is indeed required fsck. > > > > The following command was thus run :- > > sudo fsck -y /dev/mapper/vgpcname-root > > The PC could then be rebooted. > > You've got it wrong here again. > During initramfs stage root filesystem is mounted readonly. > This allows it to be checked by fsck, without causing an additional > damage. > And, since it's a root filesystem, it's *required* to reboot after the > fsck. > > > > The file system is ext4. > > Thanks. It's a rare sight these days that people actually answer all the > questions they're asked. > > Now, assuming you're using a stock Debian kernel, it's unlikely to be a > kernel bug. Likewise, we can exclude some "user-firendly" software (I'm > looking at you, GNOME). > > Which leaves us with the hardware fault. > > Hate to bring it to you, but additional information would be welcome. > You're using lvm2, it's obvious. > But which drive your physical volume resides on? > I.e. make, model, SMART attributes if any? > > Reco > I have two 1 TB 7500 rpm Seagate hard drives (I don't know the model name). They are in a Debian software RAID 1 array. I do not have any SMART diagnostics, but the RAID 1 array looks okay judging from a 'cat /proc/mdstat' output. Also no audible sign of any imminent failure of either hard drive.
Re: Corrupt root filesystem
On 18:10, Fri, 7 Jul 2023 Mick Ab > On 16:22, Fri, 7 Jul 2023 Andy Smith > > > Hi Mick, > > > > On Fri, Jul 07, 2023 at 04:01:23PM +0100, Mick Ab wrote: > > > Twice, when trying to reboot my PC, I have had error messages which > > > indicate the root file system is corrupted and needs the manual use of fsck > > > to fix the root file system before a reboot can be done. > > > > > > Any thoughts please as to what might cause the above problem ? > > > > It's something that happened in the past so difficult to tell. You > > will keep getting the message until you run fsck to fix it. You did > > not say whether you had done that so I'll assume not. > > > > I would be booting into a live or rescue environment and running > > fsck -n first to see what it will do, before running a real fsck. > > Also have backups. > > > > Most likely thing is that fixes it and you have no further > > problems. If it keeps happening to you, however, then this will need > > more investigation. > > > > Cheers, > > Andy > > > > -- > > https://bitfolk.com/ -- No-nonsense VPS hosting > > Sorry, I should have said that fsck was manually run on the root file system (as advised by the error message) each time that the error occurred. On both occasions, the system was rebooted okay. > > I am concerned that this error might keep recurring, so am keen to find out what is causing this error.
Re: Corrupt root filesystem
On 16:39, Fri, 7 Jul 2023 Reco > On July 7, 2023 6:01:23 PM GMT+03:00, Mick Ab < recoverymail123...@gmail.com> wrote: > >Twice, when trying to reboot my PC, I have had error messages which > >indicate the root file system is corrupted and needs the manual use of fsck > >to fix the root file system before a reboot can be done. > > > > Typically, running fsck requires an unmounted filesystem (or at least readonly one). Achieving this before the reboot is a pretty hard trick. > > Thus, more information is needed. What does the message says exactly? What is the type (ext4, xfs, whatever) of the problematic filesystem? > > >Any thoughts please as to what might cause the above problem ? > > A hardware fault. A kernel bug. Overprotective software. > Could be anything. > > Reco > Hi. > The error messages were of the form :- "/dev/mapper/vgpcname-root contains a file system with errors, check forced. Inodes that were a part of a corrupted orphan linked lost found. /dev/mapper/vgpcname-root : UNEXPECTED INCONSISTENCY; RUN fsck manually.(i.e ., without -a or -p options). fsck exited with status code 4. The root filesystem on /dev/mapper/vgpcname-root requires a manual fsck There is then a flashing prompt after "(initramfs)". The following command was thus run :- sudo fsck -y /dev/mapper/vgpcname-root The PC could then be rebooted. The file system is ext4.
Corrupt root filesystem
Twice, when trying to reboot my PC, I have had error messages which indicate the root file system is corrupted and needs the manual use of fsck to fix the root file system before a reboot can be done. Any thoughts please as to what might cause the above problem ?
Re: Raid Array and Changing Motherboard
On 19:58, Sun, 2 Jul 2023 David Christensen > On 7/2/23 10:23, Mick Ab wrote: > > I have a software RAID 1 array of two hard drives. Each of the two disks > > contains the Debian operating system and user data. > > > > I am thinking of changing the motherboard because of problems that might be > > connected to the current motherboard. The new motherboard would be the same > > make and model as the current motherboard. > > > > Would I need to recreate the RAID 1 array for the new motherboard I.e. > > re-initialise the current RAID 1 disks and repopulate the disks with data > > or can I just set up the software RAID on the new motherboard without > > affecting the current data on the RAID 1 drives ? > > > Shutdown the machine. Boot using a live USB stick. Type notes into a > text file. Use script(1) to record console sessions. Use dd(1) to take > an image of each disk to an external HDD (consider piping dd(1) to > gzip(1) to save space). Shutdown. Take note of which HDD is cabled to > which motherboard port. Replace motherboard. Connect HDD's to the same > motherboard ports. Boot. It should "just work". > > > Post details if you have problems. > > > David > > Thanks for your reply. I don't quite understand what you are proposing. Do you mean the external HDDs would form a new RAID 1 array for the new motherboard ? What would happen to the original RAID 1 disks ?
Raid Array and Changing Motherboard
I have a software RAID 1 array of two hard drives. Each of the two disks contains the Debian operating system and user data. I am thinking of changing the motherboard because of problems that might be connected to the current motherboard. The new motherboard would be the same make and model as the current motherboard. Would I need to recreate the RAID 1 array for the new motherboard I.e. re-initialise the current RAID 1 disks and repopulate the disks with data or can I just set up the software RAID on the new motherboard without affecting the current data on the RAID 1 drives ?
Nvidia GT 710 and Secure Boot
I understand that some people have experienced problems with booting a motherboard with Secure Boot enabled in the BIOS such that they get a blank screen, can't enter the BIOS and possibly can't boot at all. This problem seems to be due to having an old graphics card which doesn't have UEFI firmware, in particular no GOP driver. I have an Nvidia Geforce GT 710 graphics card, which is an old card and probably doesn't have the UEFI firmware or GOP driver needed with the Secure Boot feature. Is there a way in which the GT 710 can be updated to incorporate the necessary UEFI firmware and GOP driver ?
RAM
I wish to obtain information about the RAM installed on my PC using the command line. The information needed is :- Total RAM stored Number of sticks used and amount of RAM on each stick Type of RAM e.g. DDR4 Speed of RAM e.g. 3200 MHz Manufacturer and model number of RAM I have seen the dmidecode command being used, but the reliability of the information returned is not reliable. Is there any command that will reliably give the required RAM information ?
BIOS version
Is there a command that can be used to determine the BIOS version being used on the motherboard. I have used dmidecode, but at the bottom of the man page for dmidecode there is :- "More often than not, information contained in the DMI tables is inaccurate, incomplete or simply wrong."
Replacing a Motherboard and CPU
If I replace a motherboard in a desktop PC with a motherboard of the same model and manufacturer, do I need to do anything apart from reconnecting everything and possibly updating the BIOS ? If, at the same time as replacing the motherboard, i also replace the CPU with a CPU of the same model and manufacturer, do I need to do anything apart from reconnecting everything and possibly updating the BIOS ?
Re: Error Messages
Is it possible that the CPU or motherboard could cause the problem ?
Re: Error Messages
Thanks for all the replies to the Error Messages. I don't know how you find which disk is referred to by ata5. I think dm-0 is a reference to a Raid setup. Other information about my hardware and rebooting :- I have two 1 TB hard drives arranged as a RAID 1 array. The power supply :- Corsair TXM Gold 550 W 80+ Gold Certified Semi-modular ATX About 18 months old. Motherboard BIOS :- Someone else was checking the BIOS. They said it was a Beta version. I discovered my RYZEN 5 5600x is the stepping 0 version of the CPU. Ram :- I don't know the make of the Ram - someone built the PC for me. 16GB DDR4-3200MHz RAM (2 x 8GB sticks, I understand Reboots :- Subsequent to those error messages, I tried a reboot. This failed :- The reboot error says: /dev/mapper/vgpiglit-root contains a file system with errors, check forced. Inodes that were a part of a corrupted orphan linked lost found. /dev/mapper/vgpiglit-root : UNEXPECTED INCONSISTENCY; RUN fsck manually.(i.e ., without -a or -p options). fsck exited with status code 4. The root filesystem on /dev/mapper/vgpiglit-root requires a manual fsck There is then a flashing prompt after "(initramfs)". The fsck command was then performed :- fsck -y /dev/mapper/vgpiglit-root A subsequent reboot worked. Firefox then had a very lengthy cursor lag, but this was solved by deleting the places and favicons data in the Firefox profile. No more error messages yet.
Error Messages
I run a desktop PC with Debian 11, Ryzen 5 5600x CPU and
MSI-B550 A Pro motherboard.
Recently, Hardware error messages such as the following have
appeared every few weeks :-
And around the time of the error messages on the 22nd May, the
syslog extracts say:
May 22 23:11:51 piglit kernel: [1684438.730488] mce: [Hardware Error]:
Machine check events logged
May 22 23:11:51 piglit kernel: [1684438.730489] [Hardware Error]:
Corrected error, no action required.
May 22 23:11:51 piglit kernel: [1684438.730493] [Hardware Error]: CPU:0
(19:21:0) MC13_STATUS[Over|CE|-|AddrV|-|-|-|Poison|Scrub]:
0xc5048b48cbb60f00
May 22 23:11:51 piglit kernel: [1684438.730497] [Hardware Error]: Error
Addr: 0x
May 22 23:11:51 piglit kernel: [1684438.730498] [Hardware Error]: IPID:
0x
May 22 23:11:51 piglit kernel: [1684438.730500] [Hardware Error]: Bank
13 is reserved.
May 22 23:11:51 piglit kernel: [1684438.730500] [Hardware Error]:
internal: RESV
Then last Saturday, there appeared Data Error messages such as the
following :-
May 27 13:24:29 piglit kernel: [2081199.553917] ata5.00: failed command:
READ FPDMA QUEUED
May 27 13:24:29 piglit kernel: [2081199.553919] ata5.00: cmd
60/90:b8:10:14:6c/00:00:03:00:00/40 tag 23 ncq dma 73728 in
May 27 13:24:29 piglit kernel: [2081199.553919] res
40/00:b8:10:14:6c/00:00:03:00:00/40 Emask 0x50 (ATA bus error)
May 27 13:24:29 piglit kernel: [2081199.553920] ata5.00: status: { DRDY
}
May 27 13:24:29 piglit kernel: [2081199.553923] ata5: hard resetting
link
May 27 13:24:30 piglit kernel: [2081200.273917] ata5: SATA link down
(SStatus 0 SControl 310)
May 27 13:24:34 piglit kernel: [2081203.967459] ata5.00: configured for
UDMA/33
More error messages and then :-
processes of 1 users.
May 27 13:58:08 piglit kernel: [2083218.337088] EXT4-fs warning (device
dm-0): ext4_dirblock_csum_verify:400: inode #53: comm opera: No space
for directory leaf checksum. Please run e2fsck -D.
May 27 13:58:08 piglit kernel: [2083218.337091] EXT4-fs error (device
dm-0): __ext4_find_entry:1591: inode #53: comm opera: checksumming
Message from syslogd@piglit at May 27 13:58:09 ...
kernel:[2083218.760570] EXT4-fs (dm-0): failed to convert unwritten
extents to written extents -- potential data loss! (inode 394119, error
-30)
[3135811:3135811:0527/135811.569191:ERROR:gpu_memory_buffer_support_x11.cc(49)]
dri3 extension not supported.
Any thoughts about why the above is happening, please ?
The Opera browser was running at the time. Subsequent to the above
messages, it was found that neither the Opera or Chrome browser could be
opened. Firefox has been opened but seems to run in reduced mode.
Data Error Messages
A desktop PC is running Debian 11 with an AMD Ryzen CPU. The system has been running well, but now the following error messages have been seen :- Message from syslogd@piglit at May 27 13:58:09 ... kernel:[2083218.760570] EXT4-fs (dm-0): failed to convert unwritten extents to written extents -- potential data loss! (inode 394119, error -30) [3135811:3135811:0527/135811.569191:ERROR:gpu_memory_buffer_support_x11.cc(49)] dri3 extension not supported. Message from syslogd@piglit at May 27 13:58:09 ... kernel:[2083218.760570] EXT4-fs (dm-0): failed to convert unwritten extents to written extents -- potential data loss! (inode 394119, error -30) Any thoughts about why the above is happening, please ? The Opera browser was running at the time. Subsequent to the above messages, it was found that neither the Opera or Chrome browser could be opened. Firefox has been opened but seems to run in a basic mode.
Can't open email attachments with Firefox 102.3.0 esr
A few days ago Debian 11 was updated. As part of that update Firefox was updated to Firefox 102.3.0 esr (64 bit). It has subsequently been found that this version of Firefox does not allow email attachments to be opened. Clicking on such an attachment used to always open a dialogue box which had options "Open with..." and "Save" but now it just jumps straight to a Download box with a list of folders to download to. Has anyone else experienced the above problem ? Can anyone please suggest a way to get round the above problem and allow email attachments to be opened rather than downloaded ?
Re: Frozen mouse and keyboard
Thanks Brad for your contribution. I don't think anything can be done with the keyboard when the freeze occurs. On 15:41, Wed, 15 Jun 2022 Brad Rogers On Wed, 15 Jun 2022 15:15:35 +0100 > Joe wrote: > > Hello Joe, > > >Also try Ctrl-Alt-F3 > >to see if a console is reachable as X might have problems. > > Unlikely: OP reported keyboard is frozen, too. > > -- > Regards _ > / ) "The blindingly obvious is never immediately apparent" > / _)rad "Is it only me that has a working delete key?" > I'm in need of your help now > Burn - Judgement Centre >
Re: Frozen mouse and keyboard
Thanks very much, David, for your help. Unfortunately it is not possible to log in to the PC from elsewhere. As to most of your other points, they will have to wait for another similar freeze. I was not able to check logs because, subsequent to the freezing, the PC had to be rebooted due to a mains power cut and the journald system does not persist across boots. On 19:36, Wed, 15 Jun 2022 David Wright On Wed 15 Jun 2022 at 09:21:58 (+0100), Mick Ab wrote: > > I have a fairly new desktop PC running Debian 11. Recently there have > been > > a few occasions when the PC has failed to > > be woken up in the morning after being left overnight. The mouse and > > keyboard are frozen. Sometimes the monitor appears to be off and on > > one occasion it was on. > > Like others, I would try logging in over the network to see if > that is still up. > > Apart from that, I would take a careful look at the BIOS settings > under Power Management. > > Assuming your mouse and keyboard are USB or unwired, perhaps > the USB ports are powering down too? If you plug in a USB stick, > does it light up as normal? > > If there's an ethernet card, is the light still on? Does it > react to (un)plugging? > > Disks spinning? > > How long did the logs keep updating during the night? > > IOW just how dead is the machine? > > > A hard reboot has been used to reset the PC, but it is not a good idea to > > keep doing that. > > Modern filesystems/journals etc are pretty forgiving. > Modern hardware should be unharmed by the experience. > (Unlike back in the days of parking disk heads.) > > Cheers, > David. > >
Frozen mouse and keyboard
I have a fairly new desktop PC running Debian 11. Recently there have been a few occasions when the PC has failed to be woken up in the morning after being left overnight. The mouse and keyboard are frozen. Sometimes the monitor appears to be off and on one occasion it was on. A hard reboot has been used to reset the PC, but it is not a good idea to keep doing that. There is also a worry that if there is a hardware fault, the situation might get worse over time. Has anyone any idea as to what may be causing the problem and what would be the best way to try and solve it ? I anticipate it might be difficult to solve the problem given that the fault is intermittent.
Re: Mounting a USB device
Thanks for the suggestion re rsync, but using tar has been successful with a NTFS drive many times. On 3 Nov 2020 14:11, "The Wanderer" wrote: > On 2020-11-03 at 09:03, ellanios82 wrote: > > > On 11/3/20 2:28 PM, Mick Ab wrote: > > > >> The backup itself is performed using a 'tar -cvpf' type of command > > > > - maybe "rsync" is worth a look > > All else being equal I'd agree, but this is backing up to a NTFS > filesystem, which doesn't support the type of ownership and permissions > information that's likely to be available on the source filesystem; in > that scenario, backing up file-to-file (as with rsync) will lose that > metadata, whereas a tarball will preserve it. > > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard Shaw > >
Re: Mounting a USB device
I have a straightforward need to backup the current system to a portable drive before getting an up to date Debian distribution installed on a new machine. As previously mentioned, system backups have been successfully carried out on a regular basis for years to an NTFS portable drive in a USB 3 port. Recently there was a problem with the USB 3 port and it was also found that the portable drive had become corrupted. Hence a new NTFS portable drive was bought to do the backups. A backup was attempted using the new drive in another USB port. However the manual mount command failed :- # mount /media/backup Failed to write lock '/dev/sde1': Resource temporarily unavailable Error opening '/dev/sde1': Resource temporarily unavailable Failed to mount '/dev/sde1': Resource temporarily unavailable The drive was unplugged from the port without a manual unmount being performed as it was assumed the drive had not been mounted. Maybe, however, the new drive was automatically mounted by the usbmount system (to /media/usb0 ?) when it was plugged in. In any case the drive should have been manually unmounted before it was unplugged. The above mount command is exactly the same as the mount command used whenever the old drive was mounted. The old drive has an entry in /etc/fstab so the system knew about the mount parameters for the old drive. However the new drive does not have an entry in /etc/fstab and the system would surely be confused by the above mount command. Furthermore, a card reader was then plugged into the port vacated by the new drive. An SD card was then inserted into the card reader. Normally the system would then automatically mount the SD card, but it didn't. Some days later, another card reader was plugged into that port and the SD card inserted into the card reader. This time the card was automatically mounted. So there are several happenings above which I do not really understand. This makes me concerned about how to perform the vital backup needed before a new system can be set up. The backup itself is performed using a 'tar -cvpf' type of command.
Re: Mounting a USB device
Many thanks for your email, David. Apologies for any contradictory messages i have posted. My understanding of the automatic mount of USB devices has been rapidly evolving. I have now seen that people have had various problems with usbmount over the years, so I can quite understand why it might not be in the most recent Debian distributions. My plan is to update my distribution very soon, but first I need to do a backup of the system to a USB portable hard drive (which uses NTFS). I would like this backup to go as smoothly as possible. On 31 Oct 2020 22:41, "David Wright" wrote: > On Thu 29 Oct 2020 at 18:40:53 (+0000), Mick Ab wrote: > > I am fairly convinced that the USB 3 port previously mentioned has a > loose > > connection. > > > > It also seems to me that a FAT32 device such as a memory stick is > > automatically mounted when inserted in a USB port while the system > > is running, if such a device is not referenced in /etc/fstab. > > Call that paragraph ¶ 2. > > > What is not clear to me is what happens to an NTFS device such as a > > portable drive when it is inserted in a USB port while the system is > > running, if the device is not referenced in /etc/fstab. > > > > The following point is observed :- > > > > USB devices referenced in /etc/fstab are automatically mounted when the > > system is rebooted, even though their entries include the noauto option > > (the devices are already plugged in when a reboot is performed). > > As I thought, this observation contradicts the first thought expressed > in your Tue, 27 Oct 2020 20:43:52 + post (the last paragraph of > quote below). I presume that although mounting is disallowed for mount -a > (by noauto), your automounter is not constrained in this way. > > > What happens to a USB device that is not referenced in /etc/fstab, > > when it is plugged into a USB port while the system is running :- > > > > If the filesystem is FAT32 (e.g. a memory stick) will it always be > > automatically mounted or will it always have to be manually mounted ? > > Isn't that just what you answered in ¶ 2 above? > > > If the filesystem is NTFS (e.g. a portable hard drive) will it always > > be automatically mounted or will it always have to be manually mounted ? > > > > The automount system appears to be usbmount. > > I guess your answer lies there then. AFAICT usbmount hasn't been > included in the last two stable distributions (stretch and buster). > I've never used it. I assume there are others here for which this > all works. (I've left it a day before replying.) I can't work out > where your questions are leading, and whether you have a problem > to solve (besides having flaky hardware). > > > On 29 Oct 2020 17:33, "David Wright" wrote: > > > On Tue 27 Oct 2020 at 20:43:52 (+), Mick Ab wrote: > > > > > > > > It seems to me that the situation is as follows :- > > > > > > > > Filesystems in /etc/fstab which have the noauto option are not > > > > automatically mounted at boot time, so if these filesystems are > already > > > > plugged into USB ports at boot time, they would subsequently have to > be > > > > manually mounted in order to be used. > > > > > > Cheers, > David. > >
SD card mount problem
A Debian system performed a 'lazy' unmount of a portable hard drive when the drive was unplugged from a USB 2 port. A card reader was then plugged into the port and an SD card was inserted into the card reader. Normally the SD card would be automatically mounted, but this time nothing happened. Some days later, a new card reader was plugged into the port and the SD card inserted into the new card reader. This time, the SD card was automatically mounted. Can anyone please explain why the above happened.
Re: Mounting a USB device
I am fairly convinced that the USB 3 port previously mentioned has a loose connection. It also seems to me that a FAT32 device such as a memory stick is automatically mounted when inserted in a USB port while the system is running, if such a device is not referenced in /etc/fstab. What is not clear to me is what happens to an NTFS device such as a portable drive when it is inserted in a USB port while the system is running, if the device is not referenced in /etc/fstab. The following point is observed :- USB devices referenced in /etc/fstab are automatically mounted when the system is rebooted, even though their entries include the noauto option (the devices are already plugged in when a reboot is performed). What happens to a USB device that is not referenced in /etc/fstab, when it is plugged into a USB port while the system is running :- If the filesystem is FAT32 (e.g. a memory stick) will it always be automatically mounted or will it always have to be manually mounted ? If the filesystem is NTFS (e.g. a portable hard drive) will it always be automatically mounted or will it always have to be manually mounted ? The automount system appears to be usbmount. On 29 Oct 2020 17:33, "David Wright" wrote: > On Tue 27 Oct 2020 at 20:43:52 (+0000), Mick Ab wrote: > > On 27 Oct 2020 18:20, "Kenneth Parker" wrote: > > > On Tue, Oct 27, 2020, 11:51 AM Mick Ab > wrote: > > > > > >> If a filesystem in /etc/fstab has a noauto entry, can that filesystem > > >> only be mounted manually using the mount command or > > >> is there any chance that it will be automatically mounted by > > >> usbmount ? > > >> > > >> The filesystem is used in a USB port. > > > > > > I have a dislike of Gnome, because it seems to mount *every* > Filesystem > > > I have, even ones that I consider sensitive. > > > > > > But it doesn't occur until the GUI comes up. (I set the SystemD > Default > > > Target to multi-user and only type "systemctl start graphical.target" > after > > > I finish my "Apt Ritual"). > > > > > > Not sure what Gnome Package does this. Any Gnome Experts here? > > > > > Thanks for the replies. > > > > It seems to me that the situation is as follows :- > > > > Filesystems in /etc/fstab which have the noauto option are not > > automatically mounted at boot time, so if these filesystems are already > > plugged into USB ports at boot time, they would subsequently have to be > > manually mounted in order to be used. > > > > Filesystems which are plugged into a port after the system has been > booted > > are automatically mounted. > > I have no idea whether your automounter (presumably in use) detects > and mounts sticks when booting up completes, or even before. So is > your "It seems to me that the situation is" based on a gut feeling, > or on some observations? > > As I've mentioned before, I don't have sticks mounted automatically, > but I do have udev create and destroy mounts points when sticks are > inserted and removed. In the syslog, I can see my udev scripts running > on a stick (left already inserted) before, say, setting up swap. > (PIDs in the high 200s for udev, in the mid 400s for swap.) > > In view of your previous thread "Problem unplugging a USB drive", > is the situation you describe above satisfactory for you, or are > you indirectly asking how to change something? > > With flaky ports like those described, it sounds as if Brian's > post would be worth trying out. My own query on that would be > how to implement this approach without populating fstab with > a list of specific devices' LABELs/UUIDs. > > Cheers, > David. > >
Re: Mounting a USB device
The following point is observed :- USB devices referenced in /etc/fstab are automatically mounted when the system is rebooted, even though their entries include the noauto option (the devices are already plugged in when a reboot is performed). What happens to a USB device that is not referenced in /etc/fstab, when it is plugged into a USB port while the system is running :- If the filesystem is FAT32 (e.g. a memory stick) will it always be automatically mounted or will it always have to be manually mounted ? If the filesystem is NTFS (e.g. a portable hard drive) will it always be automatically mounted or will it always have to be manually mounted ? The automount system appears to be usbmount. On 29 Oct 2020 17:33, "David Wright" wrote: > On Tue 27 Oct 2020 at 20:43:52 (+0000), Mick Ab wrote: > > On 27 Oct 2020 18:20, "Kenneth Parker" wrote: > > > On Tue, Oct 27, 2020, 11:51 AM Mick Ab > wrote: > > > > > >> If a filesystem in /etc/fstab has a noauto entry, can that filesystem > > >> only be mounted manually using the mount command or > > >> is there any chance that it will be automatically mounted by > > >> usbmount ? > > >> > > >> The filesystem is used in a USB port. > > > > > > I have a dislike of Gnome, because it seems to mount *every* > Filesystem > > > I have, even ones that I consider sensitive. > > > > > > But it doesn't occur until the GUI comes up. (I set the SystemD > Default > > > Target to multi-user and only type "systemctl start graphical.target" > after > > > I finish my "Apt Ritual"). > > > > > > Not sure what Gnome Package does this. Any Gnome Experts here? > > > > > Thanks for the replies. > > > > It seems to me that the situation is as follows :- > > > > Filesystems in /etc/fstab which have the noauto option are not > > automatically mounted at boot time, so if these filesystems are already > > plugged into USB ports at boot time, they would subsequently have to be > > manually mounted in order to be used. > > > > Filesystems which are plugged into a port after the system has been > booted > > are automatically mounted. > > I have no idea whether your automounter (presumably in use) detects > and mounts sticks when booting up completes, or even before. So is > your "It seems to me that the situation is" based on a gut feeling, > or on some observations? > > As I've mentioned before, I don't have sticks mounted automatically, > but I do have udev create and destroy mounts points when sticks are > inserted and removed. In the syslog, I can see my udev scripts running > on a stick (left already inserted) before, say, setting up swap. > (PIDs in the high 200s for udev, in the mid 400s for swap.) > > In view of your previous thread "Problem unplugging a USB drive", > is the situation you describe above satisfactory for you, or are > you indirectly asking how to change something? > > With flaky ports like those described, it sounds as if Brian's > post would be worth trying out. My own query on that would be > how to implement this approach without populating fstab with > a list of specific devices' LABELs/UUIDs. > > Cheers, > David. > >
Re: Mounting a USB device
Thanks for the replies. It seems to me that the situation is as follows :- Filesystems in /etc/fstab which have the noauto option are not automatically mounted at boot time, so if these filesystems are already plugged into USB ports at boot time, they would subsequently have to be manually mounted in order to be used. Filesystems which are plugged into a port after the system has been booted are automatically mounted. On 27 Oct 2020 18:20, "Kenneth Parker" wrote: > > > On Tue, Oct 27, 2020, 11:51 AM Mick Ab > wrote: > >> If a filesystem in /etc/fstab has a noauto entry, can that filesystem >> only be mounted manually using the mount command or >> is there any chance that it will be automatically mounted by >> usbmount ? >> >> The filesystem is used in a USB port. >> > > I have a dislike of Gnome, because it seems to mount *every* Filesystem > I have, even ones that I consider sensitive. > > But it doesn't occur until the GUI comes up. (I set the SystemD Default > Target to multi-user and only type "systemctl start graphical.target" after > I finish my "Apt Ritual"). > > Not sure what Gnome Package does this. Any Gnome Experts here? > > Kenneth Parker > >>
Mounting a USB device
If a filesystem in /etc/fstab has a noauto entry, can that filesystem only be mounted manually using the mount command or is there any chance that it will be automatically mounted by usbmount ? The filesystem is used in a USB port.
Re: Problem unplugging a USB drive
The automatic mount and unmount were performed by the USB mount system. The stick was newish and hasn't been previously written to. The stick's filesystem is FAT32, in common with most USB sticks. The auto mount command included the -tvfat option. I got the message that you frequently see, so it looks as though the stick just has a dirty bit. On 26 Oct 2020 20:45, "David Wright" wrote: > On Mon 26 Oct 2020 at 17:09:17 (+0000), Mick Ab wrote: > > > > > > […] the messages revealed that just before > > > > > > the stick was unplugged, the kernel suddenly found the stick and > > > > > > automatically mounted it to /media/usb0. > > > Why did the kernel automatically mount the stick ? > > >From the mount point chosen, I would guess that it was mounted by > some kind of automounter. (My guess is based on conversations here: > I don't run either DE or an automounter.) > > > > > > > While the stick was being > > > > > > unplugged, the system performed a 'lazy' unmount from > /media/usb0. > > That seems logical for a automounter. When you pull the stick, > it prevents umount from failing because the device was busy. > Assuming you weren't writing to the stick at the time, the > amount of corruption that would occur is likely to be influenced > by the filesystem on it. In my experience with vfat, it's likely > to be as little setting the dirty bit. > > > > > > > The stick was later plugged back into the USB 3 port and the > dmesg command > > > > > > issued. The dmesg messages revealed that the stick was probably > corrupted > > > > > > due to the lazy unmount. > > I didn't know that dmesg was that precise in diagnosis. I frequently see > "Volume was not properly unmounted. Some data may be corrupt. Please run > fsck." > AIUI that's just the dirty bit speaking. > > I've seen worse, for example: > > [47557.370417] FAT-fs (sdb1): Volume was not properly unmounted. Some data > may be corrupt. Please run fsck. > [47689.952378] FAT-fs (sdb1): error, fat_get_cluster: invalid start > cluster (i_pos 0, start cdc8429e) > [47689.952384] FAT-fs (sdb1): Filesystem has been set read-only > [47689.952491] FAT-fs (sdb1): error, fat_get_cluster: invalid start > cluster (i_pos 0, start 2c494d0f) > > In this case, the stick was on its way out. > > The flakiness of your usb ports might have some influence on disk > corruption in any case. Do you have errors=remount-ro is the > appropriate place(s)? (fstab, in my configuration.) > > > Usually mounts have to be made manually for this port. > > Even if I knew how your machine was configured, I'm not sure I would > know the answer. When I see people using an automounter, but mounting > on a mount point of their choosing, I've always presumed that they're > using a bind mount (assuming that they haven't configured rules for > their automounter). > > I generate only mountpoints automatically with my own rules, but > I mount and unmount devices manually. > > Cheers, > David. > >
Re: Problem unplugging a USB drive
Why did the kernel automatically mount the stick ? Usually mounts have to be made manually for this port. On 26 Oct 2020 15:24, "David Wright" wrote: > On Mon 26 Oct 2020 at 13:56:36 (+), Curt wrote: > > On 2020-10-26, Joe wrote: > > > > > > When you say 'just before', are you talking milliseconds or minutes? > > > > > > USB 'plugs' are appalling, and I've known sticks to be unrecognised, > but > > > found after wiggling the device slightly. > > > > > > > I have a USB port like that; it's fickle. But I only actually realized > > or pinpointed it was the port being fickle (to interpret a certain > > semeiology I won't go into here) because David Wright mentioned the > > phenomenon in this forum not long ago. > > https://lists.debian.org/debian-user/2020/08/msg00506.html > > With caddies, I'd add that things aren't improving at the other end of > the cable. My USB2 caddies have a small connector (I think they're > Mini B) on a 6ft flexible cable at the caddy end. If you hold the > cable a foot away from the caddy and move it side to side, the > miniplug is stable as a rock. > > With the newer caddies, their connectors (3.0 Micro B, I believe) > are on a shorter, stiffer cable. Move the cable in the same way, > and the connector rocks from side to side, eventually generating > errors (or falling out). > > Cheers, > David. > >
Problem unplugging a USB drive
A USB memory stick has been plugged into a USB 3 port for quite a few days. The stick was left there after it was discovered that the kernel does not recognise it (e.g. fdisk - l does not show the stick). It was decided to unplug the stick. Subsequently the command cat /var/log/messages was run and the messages revealed that just before the stick was unplugged, the kernel suddenly found the stick and automatically mounted it to /media/usb0. While the stick was being unplugged, the system performed a 'lazy' unmount from /media/usb0. The stick was later plugged back into the USB 3 port and the dmesg command issued. The dmesg messages revealed that the stick was probably corrupted due to the lazy unmount. My question is :- Why did the kernel suddenly find the stick and automatically mount it just before the stick was unplugged ?
Firefox browser hangs
The following error messages were obtained when Iceweasel tried to access a website. It caused Iceweasel to hang. What is causing the problem and how can it be solved ? PDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure) [Child 12763, MediaPlayback #3] WARNING: Decoder=7fe6f33db200 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - RefPtr, mozilla::MediaResult, true> > mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: file /network/scratch/roberto/freexian/firefox-esr/68.9.0/firefox-esr-68.9.0esr/dom/media/MediaDecoderStateMachine.cpp, line 3307 [Child 12763, MediaPlayback #1] WARNING: Decoder=7fe6f33db200 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - RefPtr, mozilla::MediaResult, true> > mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: file /network/scratch/roberto/freexian/firefox-esr/68.9.0/firefox-esr-68.9.0esr/dom/media/MediaDecoderStateMachine.cpp, line 3307 [Child 12763, MediaPlayback #3] WARNING: Decoder=7fe6f33db200 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - RefPtr, mozilla::MediaResult, true> > mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: file /network/scratch/roberto/freexian/firefox-esr/68.9.0/firefox-esr-68.9.0esr/dom/media/MediaDecoderStateMachine.cpp, line 3307 ATTENTION: default value of option force_s3tc_enable overridden by environment.
Iceweasel hangs
Iceweasel has been running okay on a Debian Jessie desktop for a long time. Lately, it keeps hanging. It was noticed that the following message appeared in an xterm window : ###!!![Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure). What does the above message mean ? Is it related to Iceweasel hanging ? There is no problem with the internet connection since another browser works okay.
Problems with Opera browser
In the last few days, a couple of problems have arisen with using the Opera browser on a Debian Jessie system. Firstly, black rectangles appear on many webpages. Secondly, it is no longer possible to attach files to an email - nothing happens when the Browse button is clicked to find the file that is required to be attached to an email. Opera version is 64.0.3417.73
Continuing problem with malfunctioning USB 3 port
I am still struggling to solve the problem with the malfunctioning USB 3 port on a desktop running Debian. I would be very grateful if someone could please give useful answers to the following questions :- (1) Can the desktop be safely rebooted, if needed, given the USB 3 problem? (2) Can the USB 3 problem be fixed in some way or is the port now permanently unavailable? (3) If the USB 3 port is unavailable, can the new portable hard drive be used to do a back-up of the system from the USB 2 port currently occupied by a card reader or is there any risk the card reader will be messed up again afterwards ? (On a previous occasion, a portable hard drive was plugged into this USB 2 port in place of the card reader. The system issued a message indicating the port was busy. The card reader was plugged back into the USB 2 port and it was then found that a card inserted into the card reader could not be mounted).
Re: Problem with USB 3 port
Could the problem with the USB port possibly cause a problem with an attempt to reboot the system ? On 19 Aug 2020 11:30, "Mick Ab" wrote: > There have been problems recently in trying to use the USB 3 port on a > desktop running Debian. > > The kernel doesn't recognise either a new portable hard drive or a new > flash drive when each have, in turn, be plugged into that port. Neither > device shows up with fdisk -l, lsusb or lsblk commands. > > Now the following has been done :- > > (1) The new flash drive was unplugged from the port > > (2) As root, the following command was run : > > dmesg | tail > > The output was as follows : > > [3974120.938338] usb 1-1: new high-speed USB device number 66 using > xhci_hcd > [3974126.430777] usb 1-1: new high-speed USB device number 67 using > xhci_hcd > [3974131.923271] usb 1-1: new high-speed USB device number 68 using > xhci_hcd > [3974137.415713] usb 1-1: new high-speed USB device number 69 using > xhci_hcd > [3974142.908184] usb 1-1: new high-speed USB device number 70 using > xhci_hcd > > The above sequence continued up to device number 75 > > (3) The flash drive was plugged back into the USB 3 port > > (4) After a few seconds the following command was run as root : > > dmesg | tail -50 > > The output was as follows : > > [3973945.175272] usb 1-1: new high-speed USB device number 34 using > xhci_hcd > [3973950.667736] usb 1-1: new high-speed USB device number 35 using > xhci_hcd > [3973956.164234] usb 1-1: new high-speed USB device number 36 using > xhci_hcd > [3973961.660705] usb 1-1: new high-speed USB device number 37 using > xhci_hcd > [3973967.153175] usb 1-1: new high-speed USB device number 38 using > xhci_hcd > [3973972.645644] usb 1-1: new high-speed USB device number 39 using > xhci_hcd > [3973978.138108] usb 1-1: new high-speed USB device number 40 using > xhci_hcd > > The above sequence continued until device number 83 > > Clearly something is wrong with the port. Can anyone say what is causing > the problem and how it can be fixed. Thank you. >
Problem with USB 3 port
There have been problems recently in trying to use the USB 3 port on a desktop running Debian. The kernel doesn't recognise either a new portable hard drive or a new flash drive when each have, in turn, be plugged into that port. Neither device shows up with fdisk -l, lsusb or lsblk commands. Now the following has been done :- (1) The new flash drive was unplugged from the port (2) As root, the following command was run : dmesg | tail The output was as follows : [3974120.938338] usb 1-1: new high-speed USB device number 66 using xhci_hcd [3974126.430777] usb 1-1: new high-speed USB device number 67 using xhci_hcd [3974131.923271] usb 1-1: new high-speed USB device number 68 using xhci_hcd [3974137.415713] usb 1-1: new high-speed USB device number 69 using xhci_hcd [3974142.908184] usb 1-1: new high-speed USB device number 70 using xhci_hcd The above sequence continued up to device number 75 (3) The flash drive was plugged back into the USB 3 port (4) After a few seconds the following command was run as root : dmesg | tail -50 The output was as follows : [3973945.175272] usb 1-1: new high-speed USB device number 34 using xhci_hcd [3973950.667736] usb 1-1: new high-speed USB device number 35 using xhci_hcd [3973956.164234] usb 1-1: new high-speed USB device number 36 using xhci_hcd [3973961.660705] usb 1-1: new high-speed USB device number 37 using xhci_hcd [3973967.153175] usb 1-1: new high-speed USB device number 38 using xhci_hcd [3973972.645644] usb 1-1: new high-speed USB device number 39 using xhci_hcd [3973978.138108] usb 1-1: new high-speed USB device number 40 using xhci_hcd The above sequence continued until device number 83 Clearly something is wrong with the port. Can anyone say what is causing the problem and how it can be fixed. Thank you.
Kernel doesn't recognises devices on USB 3 port
There is a problem with a USB 3 port on a desktop running Debian. Until recently, a backup of the system had been regularly performed to a portable hard drive plugged into the USB 3 port. The drive had been kept permanently plugged into the port and was only mounted when a backup is required. Then one day the drive could not be mounted. Instead a message of the type 'can't find UUID=' was received. Use of commands such as lsusb, fdisk -l, lsblk, blkid showed that the kernel does not recognise the hard drive. Use of dmesg suggested that the drive itself might have a hardware problem. A new portable hard drive and a new flash drive were, in turn, plugged into the USB 3 port, but fdisk -l, lsblk and lsusb outputs suggest that neither of these devices are recognised by the kernel when in that port. Someone suggested that the desktop should be unplugged completely (I.e. at the mains), left for a few minutes and then rebooted. However, given the uncertainty of the cause of the problem with the port, I am reluctant to shut down the desktop and reboot in case the reboot fails.
Buster and motherboard
I aim to use the AMD Ryzen 5 3600 as the CPU and the MSI X570-A PRO as the motherboard with the stable release of Debian Buster as the operating system. However i was recently given the following information by an MSI user about the MSI X570-A PRO :- "See the following link :- https://community.amd.com/servlet/jiveservlet/downloadimage/ 2-2975897-167843/MSI_X570-PRO.png. png As you can see, according to the above link, the BIOS offered by MSI is still Beta, not the final version of AGESA 1.0.0.5 AGESA 1.0.0.6 is usually the final version that ends the cycle for every Ryzen generation so its a reference (this approach has been so for 1st and 2nd Ryzen generations) offering stability regardless of using 2000 or 3000 series. the BIOS should be flashed to AGESA 1.0.0.6 end of 2018 by the seller before the computer is bought" I have further been informed that the X570 board and Ryzen 3000 series came out about the same time as the stable release of Buster I.e. July 2019 As mentioned at the beginning of this email, various reports have convinced me that the Ryzen 5 3600 CPU will work okay with the stable release of Buster. But the MSI X570-A PRO motherboard and its BIOS may have a serious issue with Buster. Indeed the motherboard may fail to boot. So I am rather concerned about the stability offered by the BIOS on the MSI X570-A PRO motherboard.
Debian 10.0 works with third generation Ryzen
https://www.phoronix.com/scan.php?page=article=3900x-linux-distros=1 The above article shows that Debian 10.0 works okay with a third generation Ryzen CPU. I understood that there were problems with Buster using third generation Ryzen. Has this problem been overcome by installing AMD firmware ? Also does the particular BIOS used on the motherboard help to overcome the problem ?
[no subject]
Hello. I am seeking to have a desktop PC built with the standard Buster kernel (4.19) as the operating system. The CPU proposed for the build is a third generation AMD Ryzen 5. However it has come to my attention that there is a problem in running the standard Buster kernel with third generation AMD Ryzen CPUs. First and second generation CPUs appear to work okay. Also there may be a problem in running the standard Buster kernel with 9th generation Intel CPUs. Does anyone have any info about the above, please ? I further understand that Buster can be made to work with these CPUs by using the backported version of Buster, but I wish to use the standard Buster kernel.
