Re: disable auto-linking of /bin -> /usr/bin/
On Wed, 10 Jan 2024, Jeffrey Walton wrote: I think some programs can break, like those that assume / and /usr are both mounted early in the boot process. I think the only guarantee is / will be mounted early, and all programs needed to boot are available from /. I thought there was a discussion about some problems with systemd when / and /usr are different mount points (and only / is mounted early), but I can't find it at the moment. Yes, I thought systemd requires /usr mounted by the initrd.
Re: disable auto-linking of /bin -> /usr/bin/
On Wed, Jan 10, 2024 at 12:49 AM wrote:
>
> On Wed, Jan 10, 2024 at 05:06:33AM +, miphix wrote:
> > If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> > lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> > stand the logic in doing so. However, for specific reasons that would
> > require exhaustive explanations that I would prefer to save us all from
> > me doing, I would like to break this behaviour by having /usr genuinely
> > be whole heartedly installed on its own partition. I'm cool with doing
> > things the hard and painful way. Any details you can share that would
> > allow me to figure out how to break, or divert this behaviour would
> > be appreciated. I'm not elite with linux enough to figure this out,
> > but I am comfertable with digging deep with the right background
> > knowledge to navigate what's needed.
>
> The jargon for this thing is "usrmerge". With that, search engines
> turn up some hits on other people with your same needs, e.g.
>
>
> https://brontosaurusrex.github.io/2023/09/11/Upgrade-Debian-11-to-12-without-usrmerge-errors/
>
> I don't know whether some applications start breaking because of that
> (why should they, but there's badly designed software everywhere).
I think some programs can break, like those that assume / and /usr are
both mounted early in the boot process. I think the only guarantee is
/ will be mounted early, and all programs needed to boot are available
from /. I thought there was a discussion about some problems with
systemd when / and /usr are different mount points (and only / is
mounted early), but I can't find it at the moment.
Also see and
.
Jeff
Re: disable auto-linking of /bin -> /usr/bin/
On Wed, 10 Jan 2024, miphix wrote:
If you were to issue 'ls -l /' You'll find that /bin, /sbin,
lib{32,64,x32} are linked to their counterparts in /usr/. I under-
stand the logic in doing so. However, for specific reasons that would
require exhaustive explanations that I would prefer to save us all from
me doing, I would like to break this behaviour by having /usr genuinely
be whole heartedly installed on its own partition. I'm cool with doing
things the hard and painful way. Any details you can share that would
allow me to figure out how to break, or divert this behaviour would
be appreciated. I'm not elite with linux enough to figure this out,
but I am comfertable with digging deep with the right background
knowledge to navigate what's needed.
This is a very complex migration in progress.
IIRC, before bookworm not having merged usr will work. bookworm will
probably work, but it will fight you and it's not supported, and trixie
plain just won't work.
By the time trixie is released, everything will be in /usr according to
dpkg. Scripts may no longer have consistent paths to the same
application.
Re: disable auto-linking of /bin -> /usr/bin/
Hi, miphix
On Wed, Jan 10, 2024 at 05:06:33AM +, miphix wrote:
> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive explanations that I would prefer to save us all from
> me doing, I would like to break this behaviour by having /usr genuinely
> be whole heartedly installed on its own partition. I'm cool with doing
> things the hard and painful way. Any details you can share that would
> allow me to figure out how to break, or divert this behaviour would
> be appreciated. I'm not elite with linux enough to figure this out,
> but I am comfertable with digging deep with the right background
> knowledge to navigate what's needed.
The jargon for this thing is "usrmerge". With that, search engines
turn up some hits on other people with your same needs, e.g.
https://brontosaurusrex.github.io/2023/09/11/Upgrade-Debian-11-to-12-without-usrmerge-errors/
I don't know whether some applications start breaking because of that
(why should they, but there's badly designed software everywhere).
Cheers & good luck
--
tomás
signature.asc
Description: PGP signature
disable auto-linking of /bin -> /usr/bin/
If you were to issue 'ls -l /' You'll find that /bin, /sbin,
lib{32,64,x32} are linked to their counterparts in /usr/. I under-
stand the logic in doing so. However, for specific reasons that would
require exhaustive explanations that I would prefer to save us all from
me doing, I would like to break this behaviour by having /usr genuinely
be whole heartedly installed on its own partition. I'm cool with doing
things the hard and painful way. Any details you can share that would
allow me to figure out how to break, or divert this behaviour would
be appreciated. I'm not elite with linux enough to figure this out,
but I am comfertable with digging deep with the right background
knowledge to navigate what's needed.
Re: [OFFTOPIC] Filling the FAT
On Tue 09 Jan 2024 at 15:30:49 (-0500), Stefan Monnier wrote: > David Wright [2024-01-09 10:07:26] wrote: > > but what seems most likely is that the root directory filled up. > > The size of that is fixed when formatted, at least up to FAT16. > > Long filenames will eat it up more quickly still. > > Long file names are actually kept in a (hidden) files, so they don't eat > up the directory space any more than normal file names. > (I'm talking about VFAT, here, which is the standard way to add long > file names to FAT) (I find the term "vfat" rather ambiguous.) Here is the output from a USB stick that I used on Boxing Day to pass a copy of a Christmas Day video (a flaming pudding) to a Windows computer. $ grep _FS_ /run/udev/data/b8\:17 E:ID_FS_LABEL=china256 E:ID_FS_LABEL_ENC=china256 E:ID_FS_UUID=F8FA-4A08 E:ID_FS_UUID_ENC=F8FA-4A08 E:ID_FS_VERSION=FAT16 E:ID_FS_TYPE=vfat E:ID_FS_USAGE=filesystem $ $ sudo fdisk -l /dev/sdb Disk /dev/sdb: 246 MiB, 257949696 bytes, 503808 sectors Disk model: DataTraveler 2.0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xefc20858 Device Boot StartEnd Sectors Size Id Type /dev/sdb1 * 63 503807 503745 246M e W95 FAT16 (LBA) $ $ ls -lR /media/china256/ /media/china256/: total 78488 -rw-r- 1 auser auser 80357062 Dec 25 18:35 Looong-Filename.LOONG-EXT drwxr-x--- 2 auser auser 8192 Dec 26 10:18 'System Volume Information' '/media/china256/System Volume Information': total 16 -rw-r- 1 auser auser 76 Dec 26 10:18 IndexerVolumeGuid -rw-r- 1 auser auser 12 Dec 26 10:18 WPSettings.dat $ The windows computer vomited those Boxing Day entries onto the stick. Here's the pertinent bit: # hexdump -C /dev/sdb | grep -B2 -A14 -m1 china256 0001c2b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00026c00 63 68 69 6e 61 32 35 36 20 20 20 08 00 00 00 00 |china256 .| 00026c10 00 00 00 00 00 00 c7 00 af 4e 00 00 00 00 00 00 |.N..| 00026c20 42 6d 00 65 00 2e 00 4c 00 4f 00 0f 00 0e 4f 00 |Bm.e...L.OO.| 00026c30 4e 00 47 00 2d 00 45 00 58 00 00 00 54 00 00 00 |N.G.-.E.X...T...| 00026c40 01 4c 00 6f 00 6f 00 6f 00 6e 00 0f 00 0e 67 00 |.L.o.o.o.ng.| 00026c50 2d 00 46 00 69 00 6c 00 65 00 00 00 6e 00 61 00 |-.F.i.l.e...n.a.| 00026c60 4c 4f 4f 4f 4e 47 7e 31 4c 4f 4f 20 00 14 ef ae |LOOONG~1LOO | 00026c70 29 58 9a 57 00 00 7c 04 9a 57 03 00 c6 26 ca 04 |)X.W..|..W...&..| 00026c80 42 20 00 49 00 6e 00 66 00 6f 00 0f 00 72 72 00 |B .I.n.f.o...rr.| 00026c90 6d 00 61 00 74 00 69 00 6f 00 00 00 6e 00 00 00 |m.a.t.i.o...n...| 00026ca0 01 53 00 79 00 73 00 74 00 65 00 0f 00 72 6d 00 |.S.y.s.t.e...rm.| 00026cb0 20 00 56 00 6f 00 6c 00 75 00 00 00 6d 00 65 00 | .V.o.l.u...m.e.| 00026cc0 53 59 53 54 45 4d 7e 31 20 20 20 16 00 9e 4a 82 |SYSTEM~1 ...J.| 00026cd0 9a 57 9a 57 00 00 4b 82 9a 57 02 00 00 00 00 00 |.W.W..K..W..| 00026ce0 e5 46 55 50 44 4f 7e 31 44 45 42 20 00 50 04 9e |.FUPDO~1DEB .P..| # As you can see, the LOOONG~1LOO entry is preceded by two extra entries (in reverse order) containing a UCS-2 version of Looong-Filename.LOONG-EXT, mixed in with various other bytes. The System Volume Information follows in the same way, and then the start of what looks like a deleted .deb entry, probably ifupdown. > to...@tuxteam.de [2024-01-09 18:14:47] wrote: > > The LFS layer on top of FAT does have some limitations: "Because the > > FAT LFN implementation is layered atop an older, more limited naming > > system, there are inevitable complications, such as if an attempt is > > made to create too many files with the same first six letters" [1]. > > So indeed if you have too many names in the same directory you're likely > to bump into problems (you'd hope it would signal an error rather than > silent corruption, but ...). Whether you run out of directory entries or unique filenames first will depend on the use case. The normal limit for the top-level FAT directory is 512 entries, and I've just checked this by touching 505 empty files (names are A<4 digits>) in the directory above. Adding two 3-entry filenames and the compatibility volume label makes 512 entries. OTOH, there can be ~100 filenames that start with the same five characters, so storing all your Bach cantatas as CantataBWV1, CantataBWV2, etc would presumably fail. > Of course, it's usually easy to work around the problem by spreading the > files within several directory. For ripped CDs, I'd recommend one > directory per CD (I use 2 levels: every artist gets a directory and in > that directory every album gets its own subdirectory). Our car can certainly handle subdirectories: currently our "car stick" has 1421 .m4a files in 60 subdirectories. (OTOH it gets screwed
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 1/9/24 14:34, David Christensen wrote: You can always run smartctl manual ... Correction: manually To get protection against two-device failure, you need 3-day mirrors ... Correction: 3-way Perhaps other readers with madm, ... Correction: mdadm David
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 1/9/24 05:11, The Wanderer wrote: I have an eight-drive RAID-6 array of 2TB SSDs, built back in early-to-mid 2021. Within the past few weeks, I got root-mail notifications from smartd that the ATA error count on two of the drives had increased ... On Sunday (two days ago), I got root-mail notifications from smartd about *all* of the drives in the array. One thing I don't know, which may or may not be important, is whether these alert mails are being triggered when the error-count increase happens, or when a scheduled check of some type is run. Please do a full backup to a portable HDD ASAP. Put that HDD off-site. Get another HDD and do a full backup. Then do incremental backups daily. After a week, two weeks, or a month, swap the drives. At some point, start destroying older backups to make room for new backups. Please burn your most critical data to a high-quality optical media. Enable checksums by some means (extended attributes, checksum file in volume root, etc.). Validate the burn using the checksums. Then burn and validate new critical data every week, two weeks, month, etc.. Validate checksums periodically. AIUI smartd runs periodically via systemd, Perhaps another reader can post the incantation required to display the settings and/or locate past SMART reports on disk. You can always run smartctl manual to get a SMART report whenever you want (I like the --xall/-x option): # smartctl -x DEV I've looked at the SMART attributes for the drives, and am having a hard time determining whether or not there's anything worth being actually concerned about here. Some of the information I'm seeing seems to suggest yes, but other information seems to suggest no. Reading SMART reports has a learning curve. STFW for the terms you do not understand. And, beware that different manufacturers with different engineers make different long-term predictions based upon different short-term test data. Looking at SMART reports over time for the same drive, looking for trends, and noticing problems is exactly the right thing to do. You and smartd did good. :-) Most of the attributes are listed as of type "Old_age". Samsung EVO 870 are good drives, but they are "consumer" drives -- e.g. intended for laptop/ desktop computers that are powered off or hibernating most of the time. The SMART report you attached showed a "Power_On_Hours" attribute value of 22286. Assuming an operational specification of 40 hours/week, that SSD has usage equivalent to 10.7 years. So, it is old. I don't know how to interpret the "Pre-fail" notation for the other attributes. AIUI "Pre-fail" indicates the drive is going to fail soon and should be replaced. My default plan is to identify an appropriate model and buy a pair of replacement drives, but not install them yet; buy another two drives every six months, until I have a full replacement set; and start failing drives out of the RAID array and installing replacements as soon as one either fails, or looks like it's imminently about to fail. If you want 24x7 storage at minimum total cost of ownership, I suggest 3.5" enterprise HDD's. I buy "new" or "open box" older model drives on eBay, the older the cheaper. They typically die within a month or run for years. SAS has more features, yet can be cheaper (assuming you have compatible hardware). I prefer RAID-10 over RAID-5 or RAID-6 because IOPS scales up linearly with the number of mirrors (spindles). So, if one mirror does 120 IOPS (7200 RPM), two mirrors do 240 IOPS, three do 360 IOPS, etc.. Also, resilvering is a direct disk-to-disk copy at sequential read and write speeds. To get protection against two-device failure, you need 3-day mirrors; or, a hot spare and a time delay longer than resilvering time between failures. Finally, depending upon your choice of RAID, volume management, filesystem, etc., you might be able to re-use those SSD's as accelerators -- read cache, write cache, metadata, etc.. (This is easy on ZFS. Perhaps other readers with madm, LVM, btrfs, etc., can comment on SSD acceleration for those.) David
Re: Kernel compiling 6.5 and beyound
On 2024-01-09, HP Garcia wrote: > What dependencies did you install? All are installed with those commands, thanks Debian :) apt build-dep linux apt install build-essential libncurses-dev (last one for running menuconfig with ncurses)
Re: Change suspend type from kde menu
Il 07/01/2024 06:44, Max Nikulin ha scritto: It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm I have realized that earlier I forgot to add --user to systemd-run. To my surprise, it does not work if I set BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of XDG_RUNTIME_DIR. I expected that the former is required for systemd-run. This command works from a root shell prompt, I hope it should work during resume as well. It works :-) setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ systemd-run --user --slice=app.slice /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Even during resume it goes into right slice.
Re: [OFFTOPIC] Filling the FAT
David Wright [2024-01-09 10:07:26] wrote: > but what seems most likely is that the root directory filled up. > The size of that is fixed when formatted, at least up to FAT16. > Long filenames will eat it up more quickly still. Long file names are actually kept in a (hidden) files, so they don't eat up the directory space any more than normal file names. (I'm talking about VFAT, here, which is the standard way to add long file names to FAT) to...@tuxteam.de [2024-01-09 18:14:47] wrote: > The LFS layer on top of FAT does have some limitations: "Because the > FAT LFN implementation is layered atop an older, more limited naming > system, there are inevitable complications, such as if an attempt is > made to create too many files with the same first six letters" [1]. So indeed if you have too many names in the same directory you're likely to bump into problems (you'd hope it would signal an error rather than silent corruption, but ...). Of course, it's usually easy to work around the problem by spreading the files within several directory. For ripped CDs, I'd recommend one directory per CD (I use 2 levels: every artist gets a directory and in that directory every album gets its own subdirectory). Stefan
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 14:01, Michael Kjörling wrote: > On 9 Jan 2024 13:25 -0500, from wande...@fastmail.fm (The Wanderer): > Within the past few weeks, I got root-mail notifications from smartd that the ATA error count on two of the drives had increased - one from 0 to a fairly low value (I think between 10 and 20), the other from 0 to 1. I figured this was nothing to worry about - because of the relatively low values, because the other drives had not shown any such thing, and because of the expected stability and lifetime of good-quality SSDs. On Sunday (two days ago), I got root-mail notifications from smartd about *all* of the drives in the array. This time, the total error counts had gone up to values in the multiple hundreds per drive. Since then (yesterday), I've also gotten further notification mails about at least one of the drives increasing further. So far today I have not gotten any such notifications. >> >> Do you read the provided excerpt from the SMART data as indicating >> that there are hundreds of bad blocks, or that they are rising >> rapidly? > > No; that was your claim, in the paragraph about Sunday's events. That paragraph was about the Uncorrectable_Error_Cnt value, which I do not understand to directly reflect a count of bad blocks. That's why I wanted to clarify; if you *do* understand that to directly reflect bad blocks, I'd like to understand your thinking in arriving at that understanding, and if alternately you were reaching that conclusion from other sources, I'd like to know how and from what, because it would be something I've missed. >> The Runtime_Bad_Block count for that drive is nonzero, but it is >> only 31. >> >> What's high and seems as if it may be rising is the >> Uncorrectable_Error_Cnt value (attribute 187) - which I understand >> to represent *incidents* in which the drive attempted to read a >> sector or block and was unable to do so. > > The drive may be performing internal housekeeping and in doing so > try to read those blocks, or something about your RAID array setup > may be doing so. > > Exactly what are you using for RAID-6? mdraid? An off-board hardware > RAID HBA? Motherboard RAID? Or something else? What you say suggests > mdraid or something similar. mdraid, yes. >> I've ordered a 22TB external drive for the purpose of creating such >> a backup. Fingers crossed that things last long enough for it to >> get here and get the backup created. > > I suggest selecting, installing and configuring (as much as > possible) whatever software you will use to actually perform the > backup while you wait for the drive to arrive. It might save you a > little time later. Opinions differ but I like rsnapshot myself; it's > really just a front-end for rsync, so the copy is simply files, > making partial or full restoration easy without any special tools. My intention was to shut down everything that normally runs, log out as the user who normally runs it, log in as root (whose home directory, like the main installed system, is on a different RAID array with different backing drives), and use rsync from that point. My understanding is that in that arrangement, the only thing accessing the RAID-6 array should be the rsync process itself. For additional clarity: the RAID-6 array is backing a pair of logical volumes, which are backing the /home and /opt partitions. The entire rest of the system is on a series of other logical volumes which are backed by a RAID-1 array, which is based on entirely different drives (different model, different form factor, different capacity, I think even different connection technology) and which has not seen any warnings arise. >> dmesg does have what appears to be an error entry for each of the >> events reported in the alert mails, correlated with the devices in >> question. I can provide a sample of one of those, if desired. > > As long as the drive is being honest about failures and is reporting > failures rapidly, the RAID array can do its work. What you > absolutely don't want to see is I/O errors relating to the RAID array > device (for example, with mdraid, /dev/md*), because that would > presumably mean that the redundancy was insufficient to correct for > the failure. If that happens, you are falling off a proverbial > cliff. Yeah, *that* would be indicative of current catastrophic failure. I have not seen any messages related to the RAID array itself. (For awareness: this is all a source of considerable psychological stress to me, to an extent that is leaving me on the edge of physically ill, and I am managing to remain on the good side of that line only by minimizing my mental engagement with the issue as much as possible. I am currently able to read and respond to these mails without pressing that line, but that may change at any moment, and if so I will stop replying without notice until things change again.) -- The Wanderer
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 9 Jan 2024 13:25 -0500, from wande...@fastmail.fm (The Wanderer): >>> Within the past few weeks, I got root-mail notifications from >>> smartd that the ATA error count on two of the drives had increased >>> - one from 0 to a fairly low value (I think between 10 and 20), the >>> other from 0 to 1. I figured this was nothing to worry about - >>> because of the relatively low values, because the other drives had >>> not shown any such thing, and because of the expected stability and >>> lifetime of good-quality SSDs. >>> >>> On Sunday (two days ago), I got root-mail notifications from >>> smartd about *all* of the drives in the array. This time, the total >>> error counts had gone up to values in the multiple hundreds per >>> drive. Since then (yesterday), I've also gotten further >>> notification mails about at least one of the drives increasing >>> further. So far today I have not gotten any such notifications. > > Do you read the provided excerpt from the SMART data as indicating that > there are hundreds of bad blocks, or that they are rising rapidly? No; that was your claim, in the paragraph about Sunday's events. > The Runtime_Bad_Block count for that drive is nonzero, but it is only 31. > > What's high and seems as if it may be rising is the > Uncorrectable_Error_Cnt value (attribute 187) - which I understand to > represent *incidents* in which the drive attempted to read a sector or > block and was unable to do so. The drive may be performing internal housekeeping and in doing so try to read those blocks, or something about your RAID array setup may be doing so. Exactly what are you using for RAID-6? mdraid? An off-board hardware RAID HBA? Motherboard RAID? Or something else? What you say suggests mdraid or something similar. > I've ordered a 22TB external drive for the purpose of creating such a > backup. Fingers crossed that things last long enough for it to get here > and get the backup created. I suggest selecting, installing and configuring (as much as possible) whatever software you will use to actually perform the backup while you wait for the drive to arrive. It might save you a little time later. Opinions differ but I like rsnapshot myself; it's really just a front-end for rsync, so the copy is simply files, making partial or full restoration easy without any special tools. > dmesg does have what appears to be an error entry for each of the events > reported in the alert mails, correlated with the devices in question. I > can provide a sample of one of those, if desired. As long as the drive is being honest about failures and is reporting failures rapidly, the RAID array can do its work. What you absolutely don't want to see is I/O errors relating to the RAID array device (for example, with mdraid, /dev/md*), because that would presumably mean that the redundancy was insufficient to correct for the failure. If that happens, you are falling off a proverbial cliff. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Change suspend type from kde menu
Il 06/01/2024 17:38, Max Nikulin ha scritto: On 06/01/2024 00:07, Valerio Vanni wrote: Now I'm looking: services are ├─/MainApplication ├─/Player ├─/Television ├─/TrackList └─/org └─/org/kde └─/org/kde/kaffeine I tried to introspect the more likely, MainApplication and Television .RemoveProgram method u - - Do you have any idea what it should do? I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I too expected something similar: stop and play (play for resume) If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. What should I find here? If no file descriptor is resolved to /dev/ (or maybe /sys) then likely the kernel module may be removed without killing the application. For this we don't need to look here: "rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel module cannot be removed. Compare opened file descriptors when video is playing and when it is stopped. Started with --lastchannel Video playing: lr-x-- 1 valerio valerio 64 9 gen 19.47 0 -> /dev/null lrwx-- 1 valerio valerio 64 9 gen 19.47 34 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.47 35 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.47 40 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 41 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 42 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 43 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 44 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.47 55 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 56 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 57 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 59 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.47 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0 no more /dev/dvb/, but still unable to remove module cx23885 Started without --lastchannel Video playing: lrwx-- 1 valerio valerio 64 9 gen 19.56 37 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.56 43 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.56 47 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 49 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 50 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 51 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 52 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.56 58 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 59 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 60 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 It all seems like before, but this time module can be removed.
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 9 Jan 2024 10:21 -0500, from wande...@fastmail.fm (The Wanderer): >>> Model Family: Samsung based SSDs >>> Device Model: Samsung SSD 870 EVO 2TB >> >> These may or may not be under warranty, > > I would be surprised if there were warranty coverage at > this point, but might look a bit deeper; https://www.samsung.com/us/computing/memory-storage/solid-state-drives/870-evo-sata-2-5-ssd-1tb-mz-77e1t0b-am/ indicates that the warranty is five years or 1200 TBW for the 2 TB model. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Change suspend type from kde menu
Il 06/01/2024 16:19, Max Nikulin ha scritto: On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 I have not figured out how to do it, but systemd-run should not use --uid since this way it makes the application a part of system.slice. Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. I confirm, it's under system.slice. So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. I don't see authentication requests, but it still stays under system.slice.
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 11:21, Michael Kjörling wrote: > On 9 Jan 2024 08:11 -0500, from wande...@fastmail.fm (The Wanderer): > >> Within the past few weeks, I got root-mail notifications from >> smartd that the ATA error count on two of the drives had increased >> - one from 0 to a fairly low value (I think between 10 and 20), the >> other from 0 to 1. I figured this was nothing to worry about - >> because of the relatively low values, because the other drives had >> not shown any such thing, and because of the expected stability and >> lifetime of good-quality SSDs. >> >> >> On Sunday (two days ago), I got root-mail notifications from >> smartd about *all* of the drives in the array. This time, the total >> error counts had gone up to values in the multiple hundreds per >> drive. Since then (yesterday), I've also gotten further >> notification mails about at least one of the drives increasing >> further. So far today I have not gotten any such notifications. > > A single or a few bad blocks is nothing to be overly concerned > about. I had an Intel SSD which lived a long, healthy, happy life > with one bad sector and never gave any signs of further problems. > > Hundreds of bad blocks per drive is certainly cause for concern. > > More worrying is a _significant increase in the rate of increase_ of > the bad blocks count. That suggests that the drive is suffering from > some underlying problem. Do you read the provided excerpt from the SMART data as indicating that there are hundreds of bad blocks, or that they are rising rapidly? The Runtime_Bad_Block count for that drive is nonzero, but it is only 31. What's high and seems as if it may be rising is the Uncorrectable_Error_Cnt value (attribute 187) - which I understand to represent *incidents* in which the drive attempted to read a sector or block and was unable to do so. >> So... as the Subject asks, should I be worried? How do I interpret >> these results, and at what point do they start to reflect something >> to take action over? If there is not reason to be worried, what >> *do* these alerts indicate, and at what point *should* I start to >> be worried about them? > > At an absolute minimum, were it me, I would refresh my backups. As > 8-wide RAID-6 of 2TB drives nets you about 12 TB of storage, I'd say > get yourself a ~16 TB external rotational HDD and set up to backup > onto it. You should have backups anyway; there's no time like the > present to get started. I've ordered a 22TB external drive for the purpose of creating such a backup. Fingers crossed that things last long enough for it to get here and get the backup created. > You are admittedly in a much better position than many; if the > errors are randomly located, odds are that you have sufficient > redundancy to manage within the storage array. That's what I'm relying on. > The good part is if you look at SMART attributes 5 and 179; taken in > combination, I take them as indication that all (31) reallocated > sectors have been reallocated into the spare sectors pool, and this > represents approximately 2% of the spare sectors pool. The fact that this is the same value as the Runtime_Bad_Block count (attribute 183) is something I'd noticed before sending that mail, and is probably not a coincidence. > Absolutely do keep an eye on attribute 179. If the spare sectors > pool start to fill up, the drive won't be able to reallocate any > further sectors, and your RAID array won't do you much good. > > I would also keep an eye out for I/O errors in the kernel log, but > be mindful of which devices they are coming from. dmesg does have what appears to be an error entry for each of the events reported in the alert mails, correlated with the devices in question. I can provide a sample of one of those, if desired. -- 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 signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 11:12, Curt wrote: > On 2024-01-09, The Wanderer wrote: > >> My default plan is to identify an appropriate model and buy a pair >> of replacement drives, but not install them yet; buy another two >> drives every six months, until I have a full replacement set; and >> start failing drives out of the RAID array and installing >> replacements as soon as one either fails, or looks like it's >> imminently about to fail. But if the mass notification mails >> indicate that all eight are nearing failure, that might not be >> enough - and if they don't indicate any likelihood of failure this >> year, then buying replacement drives yet might be premature. > > Isn't it advised not to use the drives in this case, or to unmount > them, or to avoid all reads and writes (or however it should be > termed, as we all agree your symptoms mean trouble) in order to avoid > exacerabating the upcoming failure? Or does this go without saying? It probably is, but I don't have an alternative, since this is my daily-driver computer and I can't afford to go without one in the interim. -- 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 signature.asc Description: OpenPGP digital signature
Re: Donate money
On 1/9/24 12:53, Andy Smith wrote: Hello, On Tue, Jan 09, 2024 at 11:30:52AM +1000, David wrote: Perhaps the Debian Project, represented in the media as `an unaccountable collective of hackers', will be next. Debian doesn't sell any products or services and doesn't take donations; the organisations that take donations on Debian's behalf are accountable. They file their tax returns etc. That is probably true. But does it have to be so secretive? This thread has already descended into a "debate" on the gold standard and American imperialism. It would be great if people could try to keep it at least vaguely related to Debian. I don't think that extending of the ladder up the side of the hog that feeds the people who do the work, is off topic. From the remarks my original post has generated, it is obvious we could build that ladder easier w/o paypal blocking the way to take their %... TANSTAAFL. Thanks, Andy Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Donate money
On Tue, 2024-01-09 at 17:53 +, Andy Smith wrote: > Hello, > > On Tue, Jan 09, 2024 at 11:30:52AM +1000, David wrote: > > Perhaps the Debian Project, represented in the media as `an > > unaccountable collective of hackers', will be next. > > Debian doesn't sell any products or services and doesn't take > donations; the organisations that take donations on Debian's behalf > are accountable. They file their tax returns etc. Right. So Debian takes donations. Whether that be directly or indirectly would appear to be immaterial. > This thread has already descended into a "debate" on the gold > standard and American imperialism. It would be great if people could > try to keep it at least vaguely related to Debian. This `debate' was over some time ago. The conclusion being, because of various factors, that something better than Paypal was required. You would appear to be the only one perpetuating it. Can we look forward to it being put to bed now? > > Thanks, > Andy >
Re: Donate money
Hello, On Tue, Jan 09, 2024 at 11:30:52AM +1000, David wrote: > Perhaps the Debian Project, represented in the media as `an > unaccountable collective of hackers', will be next. Debian doesn't sell any products or services and doesn't take donations; the organisations that take donations on Debian's behalf are accountable. They file their tax returns etc. This thread has already descended into a "debate" on the gold standard and American imperialism. It would be great if people could try to keep it at least vaguely related to Debian. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Where to report CVEs missing from the security tracker ?
On 2024-01-09 16:57 +0100, Jorropo wrote: > Hello, there are 6 CVEs on the golang-go package which are not on > https://security-tracker.debian.org/tracker/status/release/stable They are there, just not shown by default. Toggle the "include issues tagged no-dsa" checkbox to see them. > I couldn't find them either there > https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=golang-go Not every CVE has a bug report in the Debian BTS, and there are multiple golang versions packaged. > The list is: > - CVE-2023-29409 https://pkg.go.dev/vuln/GO-2023-1987 > - CVE-2023-29403 https://pkg.go.dev/vuln/GO-2023-1840 > - CVE-2023-29402 https://pkg.go.dev/vuln/GO-2023-1839 > - CVE-2023-39325 https://pkg.go.dev/vuln/GO-2023-2102 > - CVE-2023-39323 https://pkg.go.dev/vuln/GO-2023-2095 > - CVE-2023-39326 https://pkg.go.dev/vuln/GO-2023-2382 > > This has been grabbed from the public golang vulnerability database > searching for anything affecting 1.19.8 (what bookworm ships). > I also checked that no patches have been backported by diffing the std > from golang-go and the upstream 1.19.8 sources. The CVEs are all in the security tracker for the golang-1.19 package: https://security-tracker.debian.org/tracker/source-package/golang-1.19. > Most of them could be fixed by updating to 1.19.12 however the 1.19 > branch is no longer supported. https://endoflife.date/go It is up to the package maintainers to provide updates for stable or not, and upgrading to a newer version might be risky. Version 1.19.13 is in bookworm-backports, however. Cheers, Sven
Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)
On Tue, Jan 09, 2024 at 10:57:29AM -0500, Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
>
> I have serious doubts about the "it".
>
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of copying multiple files would be lost because the FAT was
> > filled, and overwritten from the start by files added later in
> > the session.
>
> The FAT doesn't contain file names. It has a fixed size and contains
> one "word" per block in the partition, and that word indicates simply if
> the corresponding block is free or not, and if not, what is the next
> block of the corresponding "file" (where that "file" may be also
> something like a directory).
>
> The FAT doesn't get filled/emptied: it has the same size whether the
> partition is empty or full, because the partition contains a fixed
> number of blocks.
>
> So, I don't doubt you have seen what you have seen, but whatever you
> have seen was not due to "the FAT was filled".
I gues we are talking about VFAT, otherwise the "long" filename doesn't
make much sense.
The LFS layer on top of FAT does have some limitations: "Because the
FAT LFN implementation is layered atop an older, more limited naming
system, there are inevitable complications, such as if an attempt is
made to create too many files with the same first six letters" [1].
Given the baroque construction of that thing (only Microsoft could've
come up with such a monster), I'd not be surprised if there were known
bugs kept around for backward compatibility.
So perhaps what Brad observed was a name collision in the underlying
("bare") FAT file system (I've seen that back then, Windows 3.1) or
some other strange inhabitant of that code biotope.
Cheers
[1] https://en.wikipedia.org/wiki/Long_filename
--
t
signature.asc
Description: PGP signature
Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)
On Tue, 9 Jan 2024 10:07:26 -0600
David Wright wrote:
Hello David,
>The size of that is fixed when formatted, at least up to FAT16.
>Long filenames will eat it up more quickly still. Create
>subdirectories and the problem goes away.
Yes, this is exactly what I experienced. So not the FAT at fault, but
rather the 'ecosystem'.
How time plays trick on one's memory. :-(
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
If you ain't sticking your knives in me, you will be eventually
Monsoon - Robbie Williams
pgp_96fXkiXqi.pgp
Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 9 Jan 2024 08:11 -0500, from wande...@fastmail.fm (The Wanderer): > Within the past few weeks, I got root-mail notifications from smartd > that the ATA error count on two of the drives had increased - one from 0 > to a fairly low value (I think between 10 and 20), the other from 0 to > 1. I figured this was nothing to worry about - because of the relatively > low values, because the other drives had not shown any such thing, and > because of the expected stability and lifetime of good-quality SSDs. > > > On Sunday (two days ago), I got root-mail notifications from smartd > about *all* of the drives in the array. This time, the total error > counts had gone up to values in the multiple hundreds per drive. Since > then (yesterday), I've also gotten further notification mails about at > least one of the drives increasing further. So far today I have not > gotten any such notifications. A single or a few bad blocks is nothing to be overly concerned about. I had an Intel SSD which lived a long, healthy, happy life with one bad sector and never gave any signs of further problems. Hundreds of bad blocks per drive is certainly cause for concern. More worrying is a _significant increase in the rate of increase_ of the bad blocks count. That suggests that the drive is suffering from some underlying problem. > So... as the Subject asks, should I be worried? How do I interpret these > results, and at what point do they start to reflect something to take > action over? If there is not reason to be worried, what *do* these > alerts indicate, and at what point *should* I start to be worried about > them? At an absolute minimum, were it me, I would refresh my backups. As 8-wide RAID-6 of 2TB drives nets you about 12 TB of storage, I'd say get yourself a ~16 TB external rotational HDD and set up to backup onto it. You should have backups anyway; there's no time like the present to get started. You are admittedly in a much better position than many; if the errors are randomly located, odds are that you have sufficient redundancy to manage within the storage array. The good part is if you look at SMART attributes 5 and 179; taken in combination, I take them as indication that all (31) reallocated sectors have been reallocated into the spare sectors pool, and this represents approximately 2% of the spare sectors pool. Absolutely do keep an eye on attribute 179. If the spare sectors pool start to fill up, the drive won't be able to reallocate any further sectors, and your RAID array won't do you much good. I would also keep an eye out for I/O errors in the kernel log, but be mindful of which devices they are coming from. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Where to report CVEs missing from the security tracker ?
Hello, there are 6 CVEs on the golang-go package which are not on https://security-tracker.debian.org/tracker/status/release/stable I couldn't find them either there https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=golang-go The list is: - CVE-2023-29409 https://pkg.go.dev/vuln/GO-2023-1987 - CVE-2023-29403 https://pkg.go.dev/vuln/GO-2023-1840 - CVE-2023-29402 https://pkg.go.dev/vuln/GO-2023-1839 - CVE-2023-39325 https://pkg.go.dev/vuln/GO-2023-2102 - CVE-2023-39323 https://pkg.go.dev/vuln/GO-2023-2095 - CVE-2023-39326 https://pkg.go.dev/vuln/GO-2023-2382 This has been grabbed from the public golang vulnerability database searching for anything affecting 1.19.8 (what bookworm ships). I also checked that no patches have been backported by diffing the std from golang-go and the upstream 1.19.8 sources. Most of them could be fixed by updating to 1.19.12 however the 1.19 branch is no longer supported. https://endoflife.date/go
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09, The Wanderer wrote: > > My default plan is to identify an appropriate model and buy a pair of > replacement drives, but not install them yet; buy another two drives > every six months, until I have a full replacement set; and start failing > drives out of the RAID array and installing replacements as soon as one > either fails, or looks like it's imminently about to fail. But if the > mass notification mails indicate that all eight are nearing failure, > that might not be enough - and if they don't indicate any likelihood of > failure this year, then buying replacement drives yet might be > premature. > Isn't it advised not to use the drives in this case, or to unmount them, or to avoid all reads and writes (or however it should be termed, as we all agree your symptoms mean trouble) in order to avoid exacerabating the upcoming failure? Or does this go without saying?
Re: Kernel compiling 6.5 and beyound
What dependencies did you install? ~Herb On Tue, Jan 9, 2024, 7:23 AM Michel Verdier wrote: > On 2024-01-08, Herb Garcia wrote: > > > I was able to compile Linux kernel 6.1.X. > > > > When I tried compiling kernel 6.5.x and ran into issues. > > > > I download the required dependencies as required per > > https://www.kernel.org/doc/html/v6.7/process/changes.html#changes > > To compile 6.5 I do > > apt build-dep linux > apt install build-essential libncurses-dev > (last for running menuconfig with ncurses) > make menuconfig > make bindeb-pkg > >
Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)
On Tue 09 Jan 2024 at 10:57:29 (-0500), Stefan Monnier wrote: > >>What are you talking about? FAT does not get “overloaded” by long > >>filenames. > > Seen it happen; > > I have serious doubts about the "it". > > > Long filenames, mixed case, and files saved at the beginning of > > a session of copying multiple files would be lost because the FAT was > > filled, and overwritten from the start by files added later in > > the session. > > The FAT doesn't contain file names. It has a fixed size and contains > one "word" per block in the partition, and that word indicates simply if > the corresponding block is free or not, and if not, what is the next > block of the corresponding "file" (where that "file" may be also > something like a directory). > > The FAT doesn't get filled/emptied: it has the same size whether the > partition is empty or full, because the partition contains a fixed > number of blocks. > > So, I don't doubt you have seen what you have seen, but whatever you > have seen was not due to "the FAT was filled". I would agree with that. I don't follow the evolution of FAT, but what seems most likely is that the root directory filled up. The size of that is fixed when formatted, at least up to FAT16. Long filenames will eat it up more quickly still. Create subdirectories and the problem goes away. With large sticks nowadays, the problem revolves more around the /time/ it takes to read huge subdirectories. I don't know what the limitations on FAT32 root directory sizes are. Cheers, David.
Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)
>>What are you talking about? FAT does not get “overloaded” by long >>filenames. > Seen it happen; I have serious doubts about the "it". > Long filenames, mixed case, and files saved at the beginning of > a session of copying multiple files would be lost because the FAT was > filled, and overwritten from the start by files added later in > the session. The FAT doesn't contain file names. It has a fixed size and contains one "word" per block in the partition, and that word indicates simply if the corresponding block is free or not, and if not, what is the next block of the corresponding "file" (where that "file" may be also something like a directory). The FAT doesn't get filled/emptied: it has the same size whether the partition is empty or full, because the partition contains a fixed number of blocks. So, I don't doubt you have seen what you have seen, but whatever you have seen was not due to "the FAT was filled". Stefan
Re: playing CDROM music questions
On Tue, 9 Jan 2024 16:15:27 +0100
Nicolas George wrote:
Hello Nicolas,
>Pictures or it did not happen.
Didn't bother because it appeared to be a well-understood phenomenon,
based on my limited research.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
I'm not here for your entertainment
U & Ur Hand - P!nk
pgphyuPBCFJB5.pgp
Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 09:38, Dan Ritter wrote: > The Wanderer wrote: > >> So... as the Subject asks, should I be worried? How do I interpret >> these results, and at what point do they start to reflect something >> to take action over? If there is not reason to be worried, what >> *do* these alerts indicate, and at what point *should* I start to >> be worried about them? >> >> I already *am* worried, to the point of having heartburn and >> difficulty sleeping over the possibility of data loss (there's >> enough on here that external backup would be somewhat difficult to >> arrange), but I'm not sure whether or not that is warranted. > > YES. Backup ASAP. > > 2TB and 4TB Samsung 870 EVO disks produced before November 2022 have > this as a known failure mode. AARGH. I spent (what I'm now fairly sure was) *thousands* on these things, after comparing a fair few drive models in reviews, and this is the first I've heard that there was any issue. Thank you for pointing it out. I have now done a bit of specific looking regarding this model, and found a thread discussing it which started in January 2022 and *is still going today*. I have now ordered a high-capacity external hard drive to back up the data (delivery date is this coming Monday), and two Intel enterprise-class drives to start having a reserve on hand for the expected failure. I don't really have the funds right now to buy replacements for everything immediately, at least not without carrying a lot more of a credit-card balance than I want to, but I want to at least get started. >> Model Family: Samsung based SSDs >> Device Model: Samsung SSD 870 EVO 2TB >> Serial Number:S620NJ0R410888A > > These may or may not be under warranty, depending on when you > purchased them and from whom. Assume Samsung will take a long time, > no matter what. IIRC, I bought them via Newegg, in early-to-maybe-mid 2021. (The alternative would be Amazon, but in this case I don't think that's how it happened.) I would be surprised if there were warranty coverage at this point, but might look a bit deeper; even if there is coverage, however, it's not worth waiting (and risking data loss) for the process to complete. This is *not* a stress I need right now... -- 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 signature.asc Description: OpenPGP digital signature
Re: playing CDROM music questions
Brad Rogers (12024-01-09): > Seen it happen; Long filenames, mixed case, and files saved at the > beginning of a session of copying multiple files would be lost because > the FAT was filled, and overwritten from the start by files added later > in the session. > > We are talking in excess of 20,000 (not difficult to achieve with > over 1000 CDs to rip) files here, mixed case, and long file names, all. Pictures or it did not happen. -- Nicolas George signature.asc Description: PGP signature
Re: playing CDROM music questions
On Tue, 9 Jan 2024 13:25:52 +0100
Nicolas George wrote:
Hello Nicolas,
>What are you talking about? FAT does not get “overloaded” by long
>filenames.
Seen it happen; Long filenames, mixed case, and files saved at the
beginning of a session of copying multiple files would be lost because
the FAT was filled, and overwritten from the start by files added later
in the session.
We are talking in excess of 20,000 (not difficult to achieve with
over 1000 CDs to rip) files here, mixed case, and long file names, all.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
It's only bits of plastic, lines projected on the wall
Keep It Clean - The Vibrators
pgpY9oz8w1d5M.pgp
Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
The Wanderer wrote: > So... as the Subject asks, should I be worried? How do I interpret these > results, and at what point do they start to reflect something to take > action over? If there is not reason to be worried, what *do* these > alerts indicate, and at what point *should* I start to be worried about > them? > > I already *am* worried, to the point of having heartburn and difficulty > sleeping over the possibility of data loss (there's enough on here that > external backup would be somewhat difficult to arrange), but I'm not > sure whether or not that is warranted. YES. Backup ASAP. 2TB and 4TB Samsung 870 EVO disks produced before November 2022 have this as a known failure mode. > Model Family: Samsung based SSDs > Device Model: Samsung SSD 870 EVO 2TB > Serial Number:S620NJ0R410888A These may or may not be under warranty, depending on when you purchased them and from whom. Assume Samsung will take a long time, no matter what. -dsr-
Re: Filezilla werkt niet?
Hoi Arjen, Op 05-01-2024 om 17:54 schreef Arjen Bax: Hoi Paul, Verbazingwekkend dat sftp met filezilla niet werkt en met de standaard sftp-client wel. Inderdaad heel raar. Bij twee Windows klanten lukte het wel met WinSCP, en mij lukte het ook wel met gFTP. Hetzelfde probleem ook bij een andere host. De melding 'connection refused' betekent dat er op de gecontacteerde poort van de server geen listener actief is. Ik kreeg haast de indruk dat het naar een andere machine ging... Maar dus alleen bij Filezilla. Uiteraard de hostname goed gecontroleerd, en ook een IP-adres geprobeerd. Het blijft een raadsel. Ik vermoed dat je de snelverbindingsmethode van filezilla gebruikt. Deze methode probeert een aantal protocols uit en ik denk dat daar iets fout gaat. Als je op het keiltje direct rechts van de [Snelverbinden]-knop klikt, zie je dan in de pull-downlijst je connectie-url ertussen zitten? Gebruik in plaats van "snelverbinden" een exact geconfigureerde verbindingsmethode via Bestand->Sitebeheer. Dat geeft een dialoog waar je het protocol (sftp), de hostnaam, het poortnummer en de usernaam expliciet kunt opgeven. Ik gebruik inderdaad normaal de snelverbind methode, maar in dit geval had ik ook methode via sitebeheer geprobeerd. Hij doet het dus ondertussen weer met FileZilla, en ik heb een testaccount in sitebeheer die het nu doet, en waarmee ik een volgende keer kan testen. Groet, Paul. Succes! Vriendelijke groet / Kind regards / Vennlig hilsen, Arjen Bax Op ma 1 jan 2024 om 23:50 schreef Paul van der Vlis : Hoi, Raar probleem met Filezilla, ik kan er opeens niet meer mee connecten via SFTP. Ik krijg een "connection refused". Mijn klant krijgt een timeout. Een paar dagen geleden deed het het nog, zowel bij mij als bij klant. En wat helemaal raar is: geen meldingen in de logs op de server, ook niet als het loglevel op debug staat. En nee, de IP's komen niet voor in de firewall of in hosts.deny. Zelf gebruik ik FileZilla niet veel, maar ik raad het aan klanten aan omdat het voor allerlei OS-en beschikbaar is, en ik het kan supporten vanuit Debian. Klant draait het op Windows. Als ik gFTP of sftp gebruik dan gaat het goed, en krijg ik ook meldingen in de logs. Het lijkt dus niet aan de server-kant te liggen. Werkt het bij jullie wel? Je krijgt automatisch SFTP als je poort 22 gebruikt. Ik doe dit op Debian 11. Groet, Paul PS: weten jullie hoe je dat "snoopy" loggen uit kunt schakelen in auth.log? Heel irritant vind ik dat. Als je ergens op zoekt krijg je steeds je eigen vraag als resultaat van het grep-commando. -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
SMART Uncorrectable_Error_Cnt rising - should I be worried?
This is not directly Debian-related, except insofar as the system involved is running Debian, but we've already had a somewhat similar thread recently and this forum is as likely as any I'm aware of to have people who might have the experience to address the question(s). I would be open to recommendations for alternate / better forums for this inquiry, if people have such. For background: I have an eight-drive RAID-6 array of 2TB SSDs, built back in early-to-mid 2021. Until recently, as far as I'm aware there have not been any problems related to it. Within the past few weeks, I got root-mail notifications from smartd that the ATA error count on two of the drives had increased - one from 0 to a fairly low value (I think between 10 and 20), the other from 0 to 1. I figured this was nothing to worry about - because of the relatively low values, because the other drives had not shown any such thing, and because of the expected stability and lifetime of good-quality SSDs. On Sunday (two days ago), I got root-mail notifications from smartd about *all* of the drives in the array. This time, the total error counts had gone up to values in the multiple hundreds per drive. Since then (yesterday), I've also gotten further notification mails about at least one of the drives increasing further. So far today I have not gotten any such notifications. One thing I don't know, which may or may not be important, is whether these alert mails are being triggered when the error-count increase happens, or when a scheduled check of some type is run. If it's the latter, then it might be that there's a monthly check and that's the reason why all eight drives got mails sent at once, but if it's the former, then the so-close-in-time alerts from all eight drives would seem more likely to reflect a real problem. I've looked at the SMART attributes for the drives, and am having a hard time determining whether or not there's anything worth being actually concerned about here. Some of the information I'm seeing seems to suggest yes, but other information seems to suggest no. Relevant-seeming excerpts from the output of 'smartctl -a' on one of the drives is attached (rather than inline, to avoid line-wrapping). I can provide full output of that command for that drive, or even for all of the drives, if desired. Things that seem to suggest that there may be reason to be concerned include, but may not be limited to: The Uncorrectable_Error_Cnt, which is the value referenced by the alert mails, has risen well above its apparent previous value of 0, and signs are that it may be going to keep rising. The Runtime_Bad_Block count is nonzero. The ECC_Error_Rate is nonzero (and, at least in the case of this specific drive, also equal to the Uncorrectable_Error_Cnt). Most of the attributes are listed as of type "Old_age". That strikes me as unexpected; two and a half years of mostly-read-based operation does not seem like enough to qualify a SSD as "old", although my expectations here may well be off. (I would be inclined to expect five-to-ten years of operation out of a non-defective drive, assuming reasonable physical treatment otherwise, if not considerably more.) As mentioned above, the increase in Uncorrectable_Error_Cnt has happened at nearly the same time (relative to drive installation date) for all the drives, and for some of the drives it seems to be continuing to increase. I don't know how to interpret the "Pre-fail" notation for the other attributes. That terminology could be intended to mean "This drive has entered the final stage before failure, and its failure is expected to be imminent" - or it could equally well be the status that the attributes *start* in, with the intended meaning "This drive has not yet reached a stage where there is any reason to think it might fail". Things that seem to suggest that there may *not* be a reason to be concerned include, but may not be limited to: The "VALUE" column for each of the attributes remains high; most are in the range from 098 to 100, and excluding the Airflow_Temperature_Cel figure, the lowest is 095, for Power_On_Hours. From what I've managed to find in reading online, this column is typically a percentage value, with lower percentages indicating that the drive is closer to failure. The Total_LBAs_Written value, when combined with the Sector Size, results (if my math is correct) in a total-data-written figure of between 3TB and 4TB. That should be *well* under the advertised write endurance of this drive, given that the drive is 2TB and (both IIRC and from what I've found in reading up on such things again after these errors started to occur) those advertised values for similar-capacity drives seem to start in the hundreds of TB and go up. So... as the Subject asks, should I be worried? How do I interpret these results, and at what point do they start to reflect something to take action over? If there is not reason to be worried, what *do* these alerts
Re: playing CDROM music questions
Brad Rogers (12024-01-09): > Depends; I ended up buying three smaller sticks, because the > limitations of the file system meant that the File Allocation Table > got filled up wy before the larger capacity memory sticks did. The USB sticks we were discussing in this thread are way below the limitations of FAT. > Even with the smaller sticks, I had to use all upper case, and stick to > 8.3 names for the files, otherwise the FAT still got overloaded. What are you talking about? FAT does not get “overloaded” by long filenames. -- Nicolas George signature.asc Description: PGP signature
Re: playing CDROM music questions
Haines Brown (12024-01-08): > and that seems to have fixed the buffer problem. Nice. > The scripts folder is in my path. I holds many commands I regularly > use. > > Turns out that the "play" command was earlier taken by another > application. So I changed the command from play to Play, and now it > works without the cache problem. The Play command is: I personally choose to have both a scripts directory not in my $PATH, where I call the commands with explicit path, and a ~/bin directory at the beginning of my path. > mplayer /dev/sr0 cdda:// > > The option -cdrom-device is default and so is optional. Mplayer works > fine without it. The option “-cdrom-device” cannot be the default because it is not self-contained. It is possible “-cdrom-device /dev/sr0” is the default on your system. But if you give the argument to the option without the option, then I think that if you read mplayer's output more carefull you will find it tried to play it as a file, failed and skipped it. > where can find an inexpensive drive to hold about 1000 cds and find As was pointed out, we are looking at between 60 giga-octets lossy-but-transparent and 500 giga-octets lossless, so between a mid-sized USB stick and a small external hard drive. Whether you consider it inexpensive is your estimate. > the time do all the converting? ㋡ Eh, this one is obvious: while you listen to them. You are writing a script to play your CD: just make the script a little more powerful and it will rip them at the same time. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Kernel compiling 6.5 and beyound
On 2024-01-08, Herb Garcia wrote: > I was able to compile Linux kernel 6.1.X. > > When I tried compiling kernel 6.5.x and ran into issues. > > I download the required dependencies as required per > https://www.kernel.org/doc/html/v6.7/process/changes.html#changes To compile 6.5 I do apt build-dep linux apt install build-essential libncurses-dev (last for running menuconfig with ncurses) make menuconfig make bindeb-pkg
Re: VAX emulation/simulation (was Re: systemd-timesyncd)
On 1/9/24 03:15, Thomas Schmitt wrote: Hi, Nicholas Geovanis wrote: You ruined my day :-) It was not my fault. Send complaints to the people who convened as "High Sierra Group" in 1986. Something similar to IBM's kludgiest relic of the early 1960s has appeared in linux? The unixoid community added System Use Protocol and Rock Ridge Interchange Protocol in the early 1990s in order to get X/Open functionality on top of ISO 9660. That's POSIX with long file names (up to 255 bytes) and paths (up to 1024 bytes) where only 0-byte and '/' have special meanings. A company Who Must Not Be Named introduced Joliet to store names of up to 64 characters in a 16 bit character set (while still ignoring the difference between uppercase and lowercase). Linux mount(8) introduced a character mapping from the uppercase character set of ISO 9660 to lowercase. This mapping also removes the version part of the file names. The idea that we need version numbers embedded in filenames involuntarily may be "natural" to somebody. I have never seen any version other than ";1" (and ISOs which simply ignore the specs about file names). It's a non-functional relic, which in Linux can only be uncovered if you suppress Rock Ridge, Joliet, and name mapping during the mount command. And I've been an IBM mainframe admin and developer too. In the times when a full scale mainframe came with a female discus thrower ? http://www.ibmsystem3.nl/5444/images/5444DISK.jpg Ohmy$DIETY! A trip down memory lane. I recall those things, absolute pieces of junk, needed daily 4 hour calibration TLC to make them work for a couple hours. In a TI mainframe, circa 1978, these were made by dynex. I do NOT remember them fondly. 5 megabyte capacity. IBM's 8" floppies in the system 360 were thousands of times more dependable by 1985. In those times, my office trs-80 Color Computer had more memory than the 360, and with os9 level 2, a mini-unix, was faster than the 360. Have a nice day :) You too! Thomas . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: VAX emulation/simulation (was Re: systemd-timesyncd)
Bret Busby (12024-01-09): > Whilst, as I previously made the point, this is all off-topic for a Debian > operating system users mailing list, one (and, only one) of the applications > of version numbers as part of file descriptors, with (in the case of > VAX/VMS) up to the last seven versions of a file, being retained, was a > useful tool for software developers, but, responsible software development, > and, especially, the teaching of responsible software development, have been > abandoned, over the last decades. Could it that “responsible software development” have not been abandoned, like old geezers like to pretend, but rather has moved to using solutions that do not suffer the ugly limitations of implementations in the kernel? Regards, -- Nicolas George signature.asc Description: PGP signature
Re: VAX emulation/simulation (was Re: systemd-timesyncd)
Hi, Bret Busby wrote: > Whilst, as I previously made the point, this is all off-topic for a Debian > operating system users mailing list But i found a premium excuse in the debian-cd and debian-live ISOs. :o) > the last seven versions of a file, being retained, was a > useful tool for software developers, but, responsible software development, > and, especially, the teaching of responsible software development, have been > abandoned, over the last decades. This has obviously been replaced by Source Code Control System, which now has its final successor under the name Git. (A coarse substitute are frequently taken incremental backups.) Have a nice day :) Thomas
Re: serial-getty-ac8jik2j76sc5ckafg5...@public.gmane.org does not start
Rainer Dorsch writes: > Hello, > > I tried to start a serial console on ttyS0, but when I try to start the > serial-getty service, it does not return: > > root@master:~# systemctl status serial-getty@ttyS0.service > ○ serial-getty@ttyS0.service - Serial Getty on ttyS0 > Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled; > preset: enabled) > Active: inactive (dead) > Docs: man:agetty(8) > man:systemd-getty-generator(8) > https://0pointer.de/blog/projects/serial-console.html The only strange thing to me is that name serial-getty@ttyS0.service since I have just serial-getty@ttyS0.service - Serial Getty on ttyS0 But I guess it doesn't really matter. > root@master:~# systemctl start serial-getty@ttyS0.service Does it start when you do that? Any messages? Has it ever worked? What kind of hardware is it? I had quite some issues finding a PCIe card with a serial port that works in Linux but the third or fourth card was the charm. Both console messages and running agetty on it just worked. Doesn't work for Grub though.
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: VAX emulation/simulation (was Re: systemd-timesyncd)
On 9/1/24 16:02, Thomas Schmitt wrote: Hi, Nicholas Geovanis wrote: The idea that we need version numbers embedded in filenames involuntarily may be "natural" to somebody. I have never seen any version other than ";1" (and ISOs which simply ignore the specs about file names). It's a non-functional relic, which in Linux can only be uncovered if you suppress Rock Ridge, Joliet, and name mapping during the mount command. And I've been an IBM mainframe admin and developer too. Whilst, as I previously made the point, this is all off-topic for a Debian operating system users mailing list, one (and, only one) of the applications of version numbers as part of file descriptors, with (in the case of VAX/VMS) up to the last seven versions of a file, being retained, was a useful tool for software developers, but, responsible software development, and, especially, the teaching of responsible software development, have been abandoned, over the last decades. And, that, in itself, is a good example where reverting to a previous version, would be good. Bret Busby Armadale Western Australia (UTC+0800) .
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: VAX emulation/simulation (was Re: systemd-timesyncd)
Hi, Nicholas Geovanis wrote: > You ruined my day :-) It was not my fault. Send complaints to the people who convened as "High Sierra Group" in 1986. > Something similar to IBM's kludgiest relic of the early 1960s has appeared > in linux? The unixoid community added System Use Protocol and Rock Ridge Interchange Protocol in the early 1990s in order to get X/Open functionality on top of ISO 9660. That's POSIX with long file names (up to 255 bytes) and paths (up to 1024 bytes) where only 0-byte and '/' have special meanings. A company Who Must Not Be Named introduced Joliet to store names of up to 64 characters in a 16 bit character set (while still ignoring the difference between uppercase and lowercase). Linux mount(8) introduced a character mapping from the uppercase character set of ISO 9660 to lowercase. This mapping also removes the version part of the file names. > The idea that we need version numbers embedded in filenames > involuntarily may be "natural" to somebody. I have never seen any version other than ";1" (and ISOs which simply ignore the specs about file names). It's a non-functional relic, which in Linux can only be uncovered if you suppress Rock Ridge, Joliet, and name mapping during the mount command. > And I've been an IBM mainframe admin and developer too. In the times when a full scale mainframe came with a female discus thrower ? http://www.ibmsystem3.nl/5444/images/5444DISK.jpg Have a nice day :) Thomas
