On 1/22/24 04:46, David Christensen wrote:
On 1/21/24 21:42, gene heskett wrote:
On 1/21/24 18:29, David Christensen wrote:
On 1/21/24 14:48, gene heskett wrote:
On 1/21/24 16:13, David Christensen wrote:
On 1/21/24 03:47, gene heskett wrote:
On 1/21/24 01:33, David Christensen wrote:
3.
On 1/21/24 21:42, gene heskett wrote:
On 1/21/24 18:29, David Christensen wrote:
On 1/21/24 14:48, gene heskett wrote:
On 1/21/24 16:13, David Christensen wrote:
On 1/21/24 03:47, gene heskett wrote:
On 1/21/24 01:33, David Christensen wrote:
3. For Amanda, either add more HDD's to the
On 1/21/24 18:29, David Christensen wrote:
On 1/21/24 14:48, gene heskett wrote:
On 1/21/24 16:13, David Christensen wrote:
On 1/21/24 03:47, gene heskett wrote:
On 1/21/24 01:33, David Christensen wrote:
I am still uncertain if those are internal SSD errors or SATA
errors. Please check if
On 1/21/24 14:48, gene heskett wrote:
On 1/21/24 16:13, David Christensen wrote:
On 1/21/24 03:47, gene heskett wrote:
On 1/21/24 01:33, David Christensen wrote:
I am still uncertain if those are internal SSD errors or SATA
errors. Please check if you see matching errors in dmesg(1).
There
On 1/21/24 16:13, David Christensen wrote:
On 1/21/24 03:47, gene heskett wrote:
On 1/21/24 01:33, David Christensen wrote:
I am still uncertain if those are internal SSD errors or SATA errors.
Please check if you see matching errors in dmesg(1).
There aren't any. Those hours would very
On 1/21/24 03:47, gene heskett wrote:
On 1/21/24 01:33, David Christensen wrote:
I am still uncertain if those are internal SSD errors or SATA errors.
Please check if you see matching errors in dmesg(1).
There aren't any. Those hours would very closely correspond to my
attempts to rsync and
On 1/21/24 04:35, Max Nikulin wrote:
On 21/01/2024 03:23, gene heskett wrote:
Right now nothing in the system is north of 32C, might get to 36C at
the end of a 9 minute build of something in OpenSCAD.
I would say that 53°C and even 44°C is well above 36°C you expected:
On 21/01/2024 12:48,
On 1/21/24 01:33, David Christensen wrote:
On 1/20/24 21:48, gene heskett wrote:
New -x version for this SSD attached
> SMART Attributes Data Structure revision number: 1
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL
On 21/01/2024 03:23, gene heskett wrote:
Right now nothing in the system is north of 32C, might get to 36C at
the end of a 9 minute build of something in OpenSCAD.
I would say that 53°C and even 44°C is well above 36°C you expected:
On 21/01/2024 12:48, gene heskett wrote:
SCT Status
On 1/20/24 21:48, gene heskett wrote:
New -x version for this SSD attached
> SMART Attributes Data Structure revision number: 1
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAGSVALUE WORST THRESH FAIL RAW_VALUE
> 5 Reallocated_Sector_Ct PO--CK
On 1/21/24 00:30, Max Nikulin wrote:
On 21/01/2024 03:23, gene heskett wrote:
On 1/20/24 10:24, Max Nikulin wrote:
On 19/01/2024 06:10, gene heskett wrote:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
190 Airflow_Temperature_Cel 0x0032 071
ata recovery software may give you a recipe. A search engine should
help to find it.
On 1/20/24 10:24, Max Nikulin wrote:
On 19/01/2024 06:10, gene heskett wrote:
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
179
On 19/01/2024 06:10, gene heskett wrote:
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 085 085 010
On 1/19/24 21:34, gene heskett wrote:
On 1/19/24 20:29, Felix Miata wrote:
gene heskett composed on 2024-01-19 19:09 (UTC-0500):
On 1/19/24 15:56, David Christensen wrote:
https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-cable.aspx
Cheap enough at 18", ordered 4
On 1/19/24 20:29, Felix Miata wrote:
gene heskett composed on 2024-01-19 19:09 (UTC-0500):
On 1/19/24 15:56, David Christensen wrote:
No sign of that snipped stuff.
https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-cable.aspx
Cheap enough at 18", ordered 4 packs
gene heskett composed on 2024-01-19 19:09 (UTC-0500):
> On 1/19/24 15:56, David Christensen wrote:
> No sign of that snipped stuff.
>
>> https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-cable.aspx
> Cheap enough at 18", ordered 4 packs of 3 for service & build stock,
>
On 1/19/24 15:56, David Christensen wrote:
No sign of that snipped stuff.
https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-cable.aspx
Cheap enough at 18", ordered 4 packs of 3 for service & build stock,
thanks David.
I call that the "wiggle" test.
So do I but
On 1/18/24 23:23, gene heskett wrote:
On 1/19/24 00:55, David Christensen wrote:
I am unclear if those errors are inside the SSD or if they are the
SATA communications link between the SSD and the motherbaord or HBA
port and/or main memory (?). Does dmesg(1) show anything?
I'm not sure what
On 1/19/24 00:03, Anssi Saari wrote:
My only mdraid was on raw partitions but that never had any issues. I
think zfs effectively does the same, no partitions.
You can do it either way on ZFS.
David
On 19/01/24 at 20:14, Nicolas George wrote:
Franco Martelli (12024-01-19):
One case against using partitions on mdraid: if your array gets messed
up, you get to recreate those partition tables yourself and that's just
hilarious if you don't have a backup. Happened to a friend of mine,
reason
Franco Martelli (12024-01-19):
> > One case against using partitions on mdraid: if your array gets messed
> > up, you get to recreate those partition tables yourself and that's just
> > hilarious if you don't have a backup. Happened to a friend of mine,
> > reason was a UPS brownout.
> How can I
On 19/01/24 at 09:03, Anssi Saari wrote:
One case against using partitions on mdraid: if your array gets messed
up, you get to recreate those partition tables yourself and that's just
hilarious if you don't have a backup. Happened to a friend of mine,
reason was a UPS brownout.
How can I get a
On 1/19/24 04:50, Thomas Schmitt wrote:
Hi,
Anssi Saari
It does seem strange to me, even in MS-DOS era I was able to set a
terminal scrollback to 5000 lines without issue, when RAM was maybe 4 MB
and a DOS terminal program probably had access to way less than that.
I have no problems with
On 1/19/24 03:12, Anssi Saari wrote:
gene heskett writes:
The OOM death of the system was the xfce4 terminal apparently being
set for unlimited scrollback and that was eating the memory. Switching
to Konsole with has the ability to control the scrollback to 200
lines, and its taken all 32G's
Hi,
Anssi Saari
> It does seem strange to me, even in MS-DOS era I was able to set a
> terminal scrollback to 5000 lines without issue, when RAM was maybe 4 MB
> and a DOS terminal program probably had access to way less than that.
I have no problems with 130 xterms of 10,000 lines each.
> So
gene heskett writes:
> The OOM death of the system was the xfce4 terminal apparently being
> set for unlimited scrollback and that was eating the memory. Switching
> to Konsole with has the ability to control the scrollback to 200
> lines, and its taken all 32G's as .cache and 1536 1k blocks of
Franco Martelli writes:
> I don't know if it is a good idea, in fact it exists a special
> partition type for RAID array listed in fdisk, I used that for my
> RAID:
One case against using partitions on mdraid: if your array gets messed
up, you get to recreate those partition tables yourself and
On 1/19/24 00:55, David Christensen wrote:
On 1/18/24 15:10, gene heskett wrote:
On 1/18/24 16:08, David Christensen wrote:
On 1/18/24 03:47, gene heskett wrote:
I have issued a smartctl -tlong on all 4 drives, results in about 3
hours.
A SMART long test should find and fix any read
On 1/18/24 15:10, gene heskett wrote:
On 1/18/24 16:08, David Christensen wrote:
On 1/18/24 03:47, gene heskett wrote:
I have issued a smartctl -tlong on all 4 drives, results in about 3
hours.
A SMART long test should find and fix any read errors.
Which has now been done on all 4 SSD. but
On Thu 18 Jan 2024 at 00:57:07 (-0800), David Christensen wrote:
> On 1/17/24 22:44, gene heskett wrote:
> > One thing that bothers me is there is no way the installers parted
> > shows partition names for non-raid disks. To me that is a serious
> > bug. It appears from the h
On 1/18/24 16:08, David Christensen wrote:
On 1/18/24 03:47, gene heskett wrote:
On 1/18/24 03:57, David Christensen wrote:
The old /home RAID10 still has its metadata on disk. I would install
the "mdadm" package, edit /etc/fstab, copy and rework the old /home
line (new mount point, add
On 1/18/24 03:47, gene heskett wrote:
On 1/18/24 03:57, David Christensen wrote:
The old /home RAID10 still has its metadata on disk. I would install
the "mdadm" package, edit /etc/fstab, copy and rework the old /home
line (new mount point, add option "ro"), create the mount point, and
Hi,
On Thu, Jan 18, 2024 at 10:28:30AM -0600, Nicholas Geovanis wrote:
> Sounds like this group has finally achieved a long overdue consensus. How
> many times since LVM was ready for root/boot volumes have I been told that
> using partitions was necessary good practice. Even had that in job
>
On 2024-01-17, Thomas Schmitt wrote:
> Hi,
>
> Curt wrote:
>> I discovered a couple of discussions of the phenomenon, the upshot of which
>> were:
>> 1) That's what you get when you purchase cheap SSDs.
>>
On 18/01/2024 04:20, Thomas Schmitt wrote:
I normally start new xterms by
xterm -ls -geometry 80x24 -bg wheat -fg black -sl 1 +sb &
Options may be put into ~/.Xresources
xterm*vt100.saveLines: 1
xterm*VT100.background: wheat
xterm*VT100.foreground: black
! etc
Use xrdb to merge
On Wed, Jan 17, 2024, 9:35 PM gene heskett wrote:
> On 1/17/24 19:54, Steve McIntyre wrote:
> > Andy Smith wrote:
> ...
> >> Then there will just be people going by taste.
> >>
> >> Personally I still put them directly on drives. If I ever get taken
> >> out by one of those crappy
Hey Andy.
Andy Smith wrote:
>
>On Thu, Jan 18, 2024 at 12:53:43AM +, Steve McIntyre wrote:
>> I'm clearly a member of a third group of people,,, :-)
>
>Oh, I didn't mean to imply that those going by taste were in a
>minority! Taste, or possibly, "just never thought about it" could
>well be
Hello,
On Thu, Jan 18, 2024 at 12:53:43AM +, Steve McIntyre wrote:
> I'm clearly a member of a third group of people,,, :-)
Oh, I didn't mean to imply that those going by taste were in a
minority! Taste, or possibly, "just never thought about it" could
well be the biggest group. I was only
fresh install. I prefer the
latter, because I can estimate the effort and I am reasonably confident
of the outcome.
One thing that bothers me is there is no way the installers parted
shows partition names for non-raid disks. To me that is a serious bug.
It appears from the help that it can
ause I can estimate the effort and I am reasonably confident
of the outcome.
One thing that
bothers me is there is no way the installers parted shows partition
names for non-raid disks. To me that is a serious bug. It appears from
the help that it can LABEL a partition but can't read that
Hi,
gene heskett wrote:
> > where did the extra 19.4G's come from? Can filesystem
> > ext4's overhead account for that?
In an earlier mail:
> > > command line: rsync -a --bwlimit=10m --fsync --progress /home/
> > > /mnt/homevol
David Christensen wrote:
> Please RTFM rsync(1) to choose your
On Tue, 16 Jan 2024 21:10:28 -0500
gene heskett wrote:
> gene@coyote:~/src/klipper-docs$ lsblk -d -o
> NAME,MAJ:MIN,MODEL,SERIAL,WWN /dev/sd[hijkl]
> NAME MAJ:MIN MODEL SERIAL WWN
> sdh8:112 Gigastone SSD GSTD02TB230102
> sdi8:128 Gigastone SSD GST02TBG221146
> sdj
to do is convince it to not install orca and brltty. Probably by
unplugging _all_ usb stuff except the keyboard and mouse buttons.
What would solve many of my problems is a bit of help from someone who
it running trinity to tell me how to install it on a system w/o any
installed gui which obviously
d brltty. Probably by
unplugging _all_ usb stuff except the keyboard and mouse buttons.
What would solve many of my problems is a bit of help from someone who
it running trinity to tell me how to install it on a system w/o any
installed gui which obviously disables synaptic. That leaves apt,
apt
already have a dvd with the most recent netinstall burnt. All I have
to do is convince it to not install orca and brltty. Probably by
unplugging _all_ usb stuff except the keyboard and mouse buttons.
What would solve many of my problems is a bit of help from someone who
it running trinity to
On Wed 17 Jan 2024 at 15:34:09 (-0500), gene heskett wrote:
> On 1/17/24 12:27, Thomas Schmitt wrote:
> > David Christensen wrote:
> > > I suspect the conflicting serial numbers are causing problems in the
> > > kernel,
> > > as indicated by the /dev/disk/by-id/* problems.
> >
> > That's not in
On 1/17/24 19:54, Steve McIntyre wrote:
Andy Smith wrote:
The newer set of people recommending partitions are mostly doing so
because there's been a few incidents of "helpful" PC motherboards
detecting on boot what they think is a corrupt GPT, and replacing it
with a blank one, damaging the
On 1/17/24 15:58, gene heskett wrote:
Now the question is how did it make
this: homevol s/b very close to /home in size but:
root@coyote:~# df && free
Filesystem 1K-blocks Used Available Use% Mounted on
udev 16327704 0 16327704 0% /dev
tmpfs
Andy Smith wrote:
>
>The newer set of people recommending partitions are mostly doing so
>because there's been a few incidents of "helpful" PC motherboards
>detecting on boot what they think is a corrupt GPT, and replacing it
>with a blank one, damaging the RAID. This is a real thing that has
rror (via shell redirection).
A related issue is that lots of standard output can slow a program.
Minimizing a terminal can help. Redirecting standard output to a file
or to /dev/null can help, especially when done on the remote host while
using ssh(1).
The best solution is to tell rsync(1)
A related issue is that lots of standard output can slow a program.
Minimizing a terminal can help. Redirecting standard output to a file
or to /dev/null can help, especially when done on the remote host while
using ssh(1).
The best solution is to tell rsync(1) not to generate messages on
standa
On 1/17/24 16:16, Thomas Schmitt wrote:
Hi,
i wrote:
What did finally help ? Just the shorter terminal scroll back memory ?
gene heskett wrote:
That, and possibly the --bwlimit=10m, giving the SSD time to keep their
stuff in one sock.
Then i place my bet on the terminal alone.
Linux
Hi,
i wrote:
> > What did finally help ? Just the shorter terminal scroll back memory ?
gene heskett wrote:
> That, and possibly the --bwlimit=10m, giving the SSD time to keep their
> stuff in one sock.
Then i place my bet on the terminal alone.
Linux is able to handle disk-to
On 1/17/24 09:31, Thomas Schmitt wrote:
Hi,
David Christensen wrote:
I suspect the conflicting serial numbers are causing problems in the kernel,
as indicated by the /dev/disk/by-id/* problems.
That's not in the kernel but in udev/systemd's process of creating the
symbolic links in
ine
at the same time.
Should not be a problem if labeled uniquely. And that's easily affected
by gparted.
One of you made the remark that seems to be the secret password.
What did finally help ? Just the shorter terminal scroll back memory ?
That, and possibly the --bwlimit=10m, givi
On 1/17/24 12:27, Thomas Schmitt wrote:
Hi,
David Christensen wrote:
I suspect the conflicting serial numbers are causing problems in the kernel,
as indicated by the /dev/disk/by-id/* problems.
That's not in the kernel but in udev/systemd's process of creating the
symbolic links in
On 1/17/24 12:16, Thomas Schmitt wrote:
Hi,
Curt wrote:
I discovered a couple of discussions of the phenomenon, the upshot of which
were:
1) That's what you get when you purchase cheap SSDs.
https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/
2) SSDs
On 1/17/24 11:38, Curt wrote:
On 2024-01-17, Thomas Schmitt wrote:
This is just weird.
I still have difficulties to believe that any disk manufacturer would
hand out disks with colliding serial numbers. I googled for this
phenomenon, but except two mails of Gene nothing similar popped up.
I
ot be a problem if labeled uniquely. And that's easily affected
by gparted.
One of you made the remark that seems to be the secret password.
What did finally help ? Just the shorter terminal scroll back memory ?
That, and possibly the --bwlimit=10m, giving the SSD time to keep their
stuff in one so
Hi,
i see that i messed up "h" and "k" in my explanation of the fight over
the link targets in /dev/disk/by-id. So another attempt:
sdh has a unique serial number GSTD02TB230102. Thus we see in
https://lists.debian.org/debian-user/2024/01/msg00667.html
these two links:
/dev/sdh
Hi,
David Christensen wrote:
> I suspect the conflicting serial numbers are causing problems in the kernel,
> as indicated by the /dev/disk/by-id/* problems.
That's not in the kernel but in udev/systemd's process of creating the
symbolic links in /dev/disk/by-id/.
It gets /dev/sd[h-l] and
Hi,
Curt wrote:
> I discovered a couple of discussions of the phenomenon, the upshot of which
> were:
> 1) That's what you get when you purchase cheap SSDs.
> https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/
> 2) SSDs belonging to the same software
On 1/17/24 06:18, gene heskett wrote:
On 1/17/24 00:52, David Christensen wrote:
I suggest removing one GST02TBG221146 and one GSTG02TB230206. Put
them on the shelf, in other computer(s), or sell them. Then perhaps
copying the /home RAID10 2 TB to one Gigastone 2 TB SSD would work.
Or
On 1/16/24 23:46, Thomas Schmitt wrote:
Gene Heskett wrote:
One of these mails from a thread in december reveals that the three
unique serial numbers GSTD02TB230102, GST02TBG221146, GSTG02TB230206
each come with a different version of "1C0", "7A0", "5A0", respectively.
On 2024-01-17, Thomas Schmitt wrote:
>
> This is just weird.
> I still have difficulties to believe that any disk manufacturer would
> hand out disks with colliding serial numbers. I googled for this
> phenomenon, but except two mails of Gene nothing similar popped up.
I discovered a couple of
fore doing so, one would have to make sure that
it is not some weird effect of them all being plugged into that machine
at the same time.
> One of you made the remark that seems to be the secret password.
What did finally help ? Just the shorter terminal scroll back memory ?
It would explain why a ver
On 1/17/24 02:42, Thomas Schmitt wrote:
Hi,
Gene Heskett wrote:
lsblk, which I've published several times, shows 5 drives.
Duh. Obviously this thread overstretches my mental capacity.
And I've since tried cp in addition to rsync, does the same thing, killing
the sysytem with the OOM but
On 1/17/24 00:52, David Christensen wrote:
On 1/16/24 17:08, gene heskett wrote:
> lsblk, which I've published several times, shows 5 drives. by-id listing
> only shows 3. The drive I've been trying to use bounces from /dev/sdd to
> sde to sdh dependin on which controller it is curently
Hi,
Gene Heskett wrote:
> lsblk, which I've published several times, shows 5 drives.
Duh. Obviously this thread overstretches my mental capacity.
> And I've since tried cp in addition to rsync, does the same thing, killing
> the sysytem with the OOM but much quicker. cp using all system memory
On 1/16/24 17:08, gene heskett wrote:
> lsblk, which I've published several times, shows 5 drives. by-id listing
> only shows 3. The drive I've been trying to use bounces from /dev/sdd to
> sde to sdh dependin on which controller it is curently plugged into.
>
> And I've since tried cp in
gene heskett composed on 2024-01-16 20:08 (UTC-0500):
> Felix Miata wrote:
>> I straightened out the wrapping mess, and gave each entry a line number. I
>> see
>> nothing I recognize as representing serial number duplication among /dev/sdX
>> (physical device) names:
>> /dev/sda 9
On 1/16/24 11:08, Thomas Schmitt wrote:
ls -l /dev/sd[ij]*
oot@coyote:~# ls -l /dev/sd[ij]*
brw-rw 1 root disk 8, 128 Jan 16 05:01 /dev/sdi
brw-rw 1 root disk 8, 129 Jan 16 05:01 /dev/sdi1
brw-rw 1 root disk 8, 144 Jan 16 05:01 /dev/sdj
brw-rw 1 root disk 8, 145 Jan 16 05:01
On 1/16/24 06:09, Felix Miata wrote:
Tom Furie composed on 2024-01-16 08:18 (UTC):
Felix Miata writes:
/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
So this
On Tue 16 Jan 2024 at 20:08:12 (-0500), gene heskett wrote:
> On 1/16/24 00:56, Felix Miata wrote:
> > gene heskett composed on 2024-01-15 17:56 (UTC-0500):
> >
> > > Thanks for that composition: but it will be word wrapped:
> > > root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
>
On 1/16/24 01:18, Felix Miata wrote:
Felix Miata composed on 2024-01-16 01:05 (UTC-0500):
gene heskett composed on 2024-01-15 18:37 (UTC-0500):
Ah,but I finally glombed onto the bug tan memory bar in htop as it was
runniing, someplace in the data chain is a huge memory leak, my crash is
On 1/16/24 01:05, Felix Miata wrote:
gene heskett composed on 2024-01-15 18:37 (UTC-0500):
Ah,but I finally glombed onto the bug tan memory bar in htop as it was
runniing, someplace in the data chain is a huge memory leak, my crash is
caused by the OOM daemon killing things. And it only occurs
On 1/16/24 00:56, Felix Miata wrote:
gene heskett composed on 2024-01-15 17:56 (UTC-0500):
Thanks for that composition: but it will be word wrapped:
root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
"$(realpath "$j")" "$j" ; done
/dev/sr0
On Tue 16 Jan 2024 at 06:08:35 (-0500), Felix Miata wrote:
> Tom Furie composed on 2024-01-16 08:18 (UTC):
> > Felix Miata writes:
>
> >> /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
> >> How does a printer get a storage device assignment???
>
> > By having some kind of
On Tue 16 Jan 2024 at 09:40:19 (-0500), Greg Wooledge wrote:
> On Tue, Jan 16, 2024 at 09:31:54AM -0500, Felix Miata wrote:
> > David Wright composed on 2024-01-16 08:05 (UTC-0600):
> > > On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
> > >> gene heskett composed on 2024-01-15 17:56
Hello,
On Tue, Jan 16, 2024 at 01:01:02PM -0800, David Christensen wrote:
> On 1/16/24 11:51, Franco Martelli wrote:
> > I thought it was mandatory for a RAID to partition drives with this
> > partition type, am I wrong?
In the ancient past it was required, because that was one of the
ways that
On 1/16/24 11:51, Franco Martelli wrote:
On 15/01/24 at 08:43, David Christensen wrote:
When I built and ran a Debian 2 @ HDD RAID1 using mdadm(8), I did not
partiton the HDD's -- I gave mdadm(8) the whole drives.
I don't know if it is a good idea, in fact it exists a special partition
type
On 15/01/24 at 08:43, David Christensen wrote:
This I am still trying to do, the first pass copied all 350G of /home
but went to the wrong drive, and I had mounted the drive by its label.
It is now /dev/sdh and all labels above it are now wrong. Crazy.
These SSD's all have an OTP serial number.
Hello,
On Tue, Jan 16, 2024 at 01:17:42AM -0500, Felix Miata wrote:
> If rsync really is bugged, maybe a change of options would avoid the bug. Try
> instead of -av, -rlptgoDAXUNH. Could it be that verbosity is the OOM
> crippler, and
> not necessarily from rsync itself, but possibly from the
Hi,
i, too, wondered where there should be a duplicate serial number.
But indeed:
David Wright wrote:
> > /dev/sdi53 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146
> > /dev/sdj1 54 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1
> ↑ that is /really/ bad!
Does the
On 16/01/2024 15:18, Tom Furie wrote:
/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
I have heard that some devices expose a USB mass storage interface out
of the
On Tue, Jan 16, 2024 at 09:31:54AM -0500, Felix Miata wrote:
> David Wright composed on 2024-01-16 08:05 (UTC-0600):
>
> > On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
>
> >> gene heskett composed on 2024-01-15 17:56 (UTC-0500):
>
> >>> Thanks for that composition: but it will be
David Wright composed on 2024-01-16 08:05 (UTC-0600):
> On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
>> gene heskett composed on 2024-01-15 17:56 (UTC-0500):
>>> Thanks for that composition: but it will be word wrapped:
>>> root@coyote:~# for j in /dev/disk/by-id/* ; do printf
On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
> gene heskett composed on 2024-01-15 17:56 (UTC-0500):
>
> > Thanks for that composition: but it will be word wrapped:
> > root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
> > "$(realpath "$j")" "$j" ; done
> > /dev/sr0
Il 16/01/2024 12:08, Felix Miata ha scritto:
Tom Furie composed on 2024-01-16 08:18 (UTC):
Felix Miata writes:
/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
So
Tom Furie composed on 2024-01-16 08:18 (UTC):
> Felix Miata writes:
>> /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
>> How does a printer get a storage device assignment???
> By having some kind of SD card slot or similar.
So this pollution only results from a
Felix Miata writes:
> /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
> How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
Felix Miata composed on 2024-01-16 01:05 (UTC-0500):
> gene heskett composed on 2024-01-15 18:37 (UTC-0500):
>> Ah,but I finally glombed onto the bug tan memory bar in htop as it was
>> runniing, someplace in the data chain is a huge memory leak, my crash is
>> caused by the OOM daemon killing
gene heskett composed on 2024-01-15 18:37 (UTC-0500):
> Ah,but I finally glombed onto the bug tan memory bar in htop as it was
> runniing, someplace in the data chain is a huge memory leak, my crash is
> caused by the OOM daemon killing things. And it only occurs when I run
> rsync. Only takes
gene heskett composed on 2024-01-15 17:56 (UTC-0500):
> Thanks for that composition: but it will be word wrapped:
> root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
> "$(realpath "$j")" "$j" ; done
> /dev/sr0/dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865
>
On Mon 15 Jan 2024 at 18:27:14 (-0500), gene heskett wrote:
> On 1/15/24 14:57, David Wright wrote:
> > On Sun 14 Jan 2024 at 20:15:16 (-0500), gene heskett wrote:
> > > On 1/14/24 18:57, Felix Miata wrote:
> > > > gene heskett composed on 2024-01-14 18:39 (UTC-0500):
> > > > > Felix Miata wrote:
On Mon 15 Jan 2024 at 20:31:55 (-0500), gene heskett wrote:
> On 1/15/24 19:11, David Christensen wrote:
> > On 1/15/24 16:03, gene heskett wrote:
> > > On 1/15/24 18:41, gene heskett wrote:
> > > > On 1/15/24 17:58, gene heskett wrote:
> > > > > On 1/15/24 14:55, David Wright wrote:
> > > > > >
On 1/15/24 17:31, gene heskett wrote:
On 1/15/24 19:11, David Christensen wrote:
On 1/15/24 16:03, gene heskett wrote:
On 1/15/24 18:41, gene heskett wrote:
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett
On 1/15/24 19:11, David Christensen wrote:
On 1/15/24 16:03, gene heskett wrote:
On 1/15/24 18:41, gene heskett wrote:
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
ata-Gigastone_SSD_GST02TBG221146
On 1/15/24 16:03, gene heskett wrote:
On 1/15/24 18:41, gene heskett wrote:
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
ata-Gigastone_SSD_GST02TBG221146
ata-Gigastone_SSD_GSTD02TB230102
101 - 200 of 20780 matches
Mail list logo
