Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #265863 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2024-01-13 03:50 +0100 |
| Last post | 2024-01-19 21:10 +0100 |
| Articles | 20 on this page of 167 — 25 participants |
Back to article view | Back to linux.debian.user
smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 03:50 +0100
Re: smartctl cannot access my storage, need syntax help "Gareth Evans" <donotspam@fastmail.fm> - 2024-01-13 04:00 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-13 04:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 06:00 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-13 16:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 18:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 18:30 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-13 19:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-14 00:30 +0100
Re: smartctl cannot access my storage, need syntax help Steve McIntyre <steve@einval.com> - 2024-01-14 14:40 +0100
Re: smartctl cannot access my storage, need syntax help Nicolas George <george@nsup.org> - 2024-01-14 11:40 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-14 17:30 +0100
Re: smartctl cannot access my storage, need syntax help Charles Curley <charlescurley@charlescurley.com> - 2024-01-13 06:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-14 13:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-14 20:50 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-15 01:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 02:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 14:50 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-15 19:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 23:00 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-15 21:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 00:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 01:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 01:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 00:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 01:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 01:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 02:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 03:20 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-16 04:00 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 07:00 +0100
Re: smartctl cannot access my storage, need syntax help Tom Furie <tom@furie.org.uk> - 2024-01-16 09:20 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 12:10 +0100
Re: smartctl cannot access my storage, need syntax help Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-16 13:40 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-17 01:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 03:00 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-16 16:00 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-16 15:10 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 15:40 +0100
Re: smartctl cannot access my storage, need syntax help Greg Wooledge <greg@wooledge.org> - 2024-01-16 15:50 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-17 01:20 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-16 17:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 03:20 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 07:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 15:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 18:10 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 18:30 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 20:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:40 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 22:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 22:40 +0100
normally start new xterms [was: Re: smartctl cannot access my storage, need syntax help] Max Nikulin <manikulin@gmail.com> - 2024-01-18 17:40 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-18 20:10 +0100
Re: normally start new xterms conover@panix.com (John Conover) - 2024-01-18 20:20 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-18 21:20 +0100
Re: normally start new xterms conover@panix.com (John Conover) - 2024-01-18 21:40 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 06:50 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 09:10 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 10:20 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 10:40 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 09:10 +0100
Re: normally start new xterms David Wright <deblis@lionunicorn.co.uk> - 2024-01-19 18:10 +0100
Re: normally start new xterms Henning Follmann <hfollmann@itcfollmann.com> - 2024-01-19 15:20 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 16:10 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-18 04:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 22:20 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 08:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 16:40 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 17:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 22:10 +0100
Re: smartctl cannot access my storage, need syntax help Curt <curty@free.fr> - 2024-01-17 17:40 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 18:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 22:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 01:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 02:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 05:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 07:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 07:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 10:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 12:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 22:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-19 07:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-19 08:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-19 22:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-20 01:20 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-20 02:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-20 06:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-20 08:00 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-20 16:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-20 21:30 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-21 06:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-21 07:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-21 12:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-21 22:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-21 23:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-22 00:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-22 06:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-22 10:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-22 12:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-22 19:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-22 20:40 +0100
Re: smartctl cannot access my storage, need syntax help Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 22:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-23 00:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 03:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-23 04:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 05:00 +0100
Powered USB hub [was: Re: smartctl cannot access my storage, need syntax help] Max Nikulin <manikulin@gmail.com> - 2024-01-23 05:20 +0100
Re: Powered USB hub [was: Re: smartctl cannot access my storage, needsyntax help] gene heskett <gheskett@shentel.net> - 2024-01-23 06:10 +0100
Re: Powered USB hub [was: Re: smartctl cannot access my storage, need syntax help] Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-25 11:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-23 08:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:10 +0100
Re: smartctl cannot access my storage, need syntax help Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-23 04:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:50 +0100
Re: smartctl cannot access my storage, need syntax help Karl Vogel <vogelke@pobox.com> - 2024-01-23 06:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:10 +0100
Re: smartctl cannot access my storage, need syntax help Gremlin <scott-andrews@columbus.rr.com> - 2024-01-23 12:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:40 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-25 15:10 +0100
Re: smartctl cannot access my storage, need syntax help "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-01-25 18:20 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-26 12:50 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-29 06:20 +0100
Re: smartctl cannot access my storage, need syntax help Karl Vogel <vogelke@pobox.com> - 2024-01-24 09:30 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-21 10:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-21 18:40 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-19 05:10 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-18 08:40 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-19 09:20 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 11:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-19 13:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-19 13:00 +0100
Re: smartctl cannot access my storage, need syntax help Curt <curty@free.fr> - 2024-01-18 17:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:20 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 18:10 +0100
Re: smartctl cannot access my storage, need syntax help Charles Curley <charlescurley@charlescurley.com> - 2024-01-18 08:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 02:10 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-17 03:00 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-17 05:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-15 08:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 15:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-15 23:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 00:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 00:50 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 07:10 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 07:20 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-16 17:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 02:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 02:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 17:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 00:10 +0100
Re: smartctl cannot access my storage, need syntax help Franco Martelli <martellif67@gmail.com> - 2024-01-16 21:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 22:10 +0100
To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Andy Smith <andy@strugglers.net> - 2024-01-16 22:40 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Steve McIntyre <steve@einval.com> - 2024-01-18 02:00 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) gene heskett <gheskett@shentel.net> - 2024-01-18 04:40 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-18 17:30 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Andy Smith <andy@strugglers.net> - 2024-01-18 18:10 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Andy Smith <andy@strugglers.net> - 2024-01-18 15:20 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Steve McIntyre <steve@einval.com> - 2024-01-18 17:10 +0100
Re: mdraid construction and testing (was: smartctl cannot access my stor...) Felix Miata <mrmazda@earthlink.net> - 2024-01-16 23:00 +0100
Testing storage performance (Was Re: mdraid construction and testing (was: smartctl cannot access my stor...)) Andy Smith <andy@strugglers.net> - 2024-01-17 04:40 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-19 09:10 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Franco Martelli <martellif67@gmail.com> - 2024-01-19 20:10 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Nicolas George <george@nsup.org> - 2024-01-19 20:20 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Franco Martelli <martellif67@gmail.com> - 2024-01-19 20:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-19 21:10 +0100
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-15 21:00 +0100 |
| Message-ID | <HWBhL-3jQw-15@gated-at.bofh.it> |
| In reply to | #265987 |
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
> On 1/14/24 20:19, gene heskett wrote:
> > On 1/14/24 19:48, David Wright wrote:
> > > On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:
> > > > On 1/14/24 07:42, David Christensen wrote:
> > >
> > > > > I am confused -- do you have 4 or 5 Gigastone 2 TB SSD?
> > > >
> > > > 5, ordered in 2 separate orders.
> > > > >
> > > > > > So that one could be formatted ext4 and serve as a
> > > > > backup of the raid10.
> > > > What I am trying to do now, but cannot if it is plugged into a
> > > > motherboard port, hence the repeat of this exercise on the 2nd sata
> > > > card.
> > > > >
> > > > > > how do I make an image of that
> > > > > > raid10 to /dev/sde and get every byte? That
> > > > > seems like the first step
> > > > > > to me.
> > > > 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. I am tempted to use that
> > > > serial number as a label _I_ can control. And according to gparted,
> > > > labels do not survive being incorporated into a raid as the raid is
> > > > all labeled with hostname : partition number. So there really is no
> > > > way in linux to define a drive that is that drive forever. Unreal...
> > >
> > > Interesting to see in how many differents ways you can use the
> > > term "label". BTW I have no idea what an "OTP serial number" is.
> > >
> > OTP=One Time Pad, never to be used again.
I too can lookup acronyms with ease. I asked about "OTP serial number",
not "OTP" serial number.
> I moved the data cable to where I knew I could find it again, as one
> of 5 drives attached to the 16 port card,
No idea what that means.
> and on reboot it shows up in
> an lsblk list as:
> root@coyote:~# lsblk
[ … table showing five Samsungs, five Gigastones, and two
other items, perhaps printer (confirmed later) and camera … ]
> Now confirmed by looking at all 5 with gparted, there are only 3
> unique serial numbers:
I don't see any parted output.
> root@coyote:~# ls /dev/disk/by-id
ls -1 would at least sort out this mess, but more useful would be ls -l
or for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' "$(realpath "$j")" "$j" ; done
as you could then see what the symlinks point to, which after all
is their raison d'être.
Extracting:
> ata-Gigastone_SSD_GST02TBG221146
> ata-Gigastone_SSD_GSTD02TB230102
> ata-Gigastone_SSD_GSTG02TB230206
these devices appear to have normal serial numbers. Do they bear
any other indication, like engravings or stickers? If not, I would,
in turn, plug each one in, read the serial number from its symlink,
and write on it with a marker. While doing that, you could also
run smartctl.
> only 3 unique serial numbers!!!!!!
> udev when finding that situation should scream from the rooftops!!
> not silently overwrite an entry in the by-id that its already made.
If you say so. I never had any problem with udev when I had
three identical USB sticks with the "serial" number
ID_SERIAL=SMI_USB_DISK-0:0
I scratched distinguishing letter on them, and watched xconsole for
the drive letter whenever I plugged one in. At 8GB a piece, the
largest I had at the time, they were very useful. And they didn't
cost me a penny as they were giveaways.
> HTH do I fix that?
> can tune2fs edit a serial number? no.
> can the UUID be rendered read-only, no.
> gparted and similar can change the UUID by a click of the mouse.
> I'm officially screwed and I have had them too long to return them now.
You need to find out, in turn, which ones work, and that goes for
both the SSDs and wherever you plug them in. You can make little
progress at all without distinguishing them, as you have already
shown by copying data to who knows where.
> That could even explain why my first run of rsync worked fine but went
> to a drive that was NOT mounted. And it was mounted by LABEL= The
> only one of those 5 SSD's I had labeled at that time.
You haven't shown any evidence of such LABELling, and most of your
anecdotal narratives don't give much confidence for us to really
know what was actually done. But to be fair, anything could
happen if the hardware is not working properly.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-01-16 00:20 +0100 |
| Message-ID | <HWEpj-3m0d-3@gated-at.bofh.it> |
| In reply to | #266001 |
On 1/15/24 14:56, gene heskett wrote: > 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 > /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 > /dev/sdh /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 > /dev/sdh1 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 > /dev/sdk /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 > /dev/sdk1 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 > /dev/sdf /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T > ... 2 pairs with identical "serial numbers", ... Are you certain that it is not two drives that fail to connect at boot? You previously posted smartctl reports indicating a bad SATA connection. If you disconnect everything except one Gigastone SSD, connect it to a known good motherboard SATA port using a known good SATA cable, connect it to a known good PSU power cable, boot live media into a rescue shell, examine the Gigastone, write down the serial number, shutdown, and repeat for the four other Gigastone drives, can you confirm the duplicate serial numbers? David
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-16 01:00 +0100 |
| Message-ID | <HWF21-3mdg-1@gated-at.bofh.it> |
| In reply to | #266018 |
On 1/15/24 18:15, David Christensen wrote: > On 1/15/24 14:56, gene heskett wrote: >> 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 >> /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 >> /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 >> /dev/sdh /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 >> /dev/sdh1 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 >> /dev/sdk /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 >> /dev/sdk1 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 >> /dev/sdf >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T > >> ... 2 pairs with identical "serial numbers", ... > > > Are you certain that it is not two drives that fail to connect at boot? > You previously posted smartctl reports indicating a bad SATA connection. > > > If you disconnect everything except one Gigastone SSD, connect it to a > known good motherboard SATA port using a known good SATA cable, connect > it to a known good PSU power cable, boot live media into a rescue shell, > examine the Gigastone, write down the serial number, shutdown, and > repeat for the four other Gigastone drives, can you confirm the > duplicate serial numbers? > The serial number that shows in the pix I just posted is everything right of the SSD_ above up to the "part1" If there is a different one some place, tell me how to extract it. In the 6 entries above there are only 3 unique numbers. If gparted is showing me a pack of lies, show me how to prove gparted is lieing, > > David > > . 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
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-01-16 01:10 +0100 |
| Message-ID | <HWFbH-3mvB-7@gated-at.bofh.it> |
| In reply to | #266024 |
On 1/15/24 15:53, gene heskett wrote: > On 1/15/24 18:15, David Christensen wrote: >> On 1/15/24 14:56, gene heskett wrote: >>> 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 >>> /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 >>> /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 >>> /dev/sdh /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 >>> /dev/sdh1 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 >>> /dev/sdk /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 >>> /dev/sdk1 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 >>> /dev/sdf /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T >> >>> ... 2 pairs with identical "serial numbers", ... >> >> >> Are you certain that it is not two drives that fail to connect at >> boot? You previously posted smartctl reports indicating a bad SATA >> connection. >> >> >> If you disconnect everything except one Gigastone SSD, connect it to a >> known good motherboard SATA port using a known good SATA cable, >> connect it to a known good PSU power cable, boot live media into a >> rescue shell, examine the Gigastone, write down the serial number, >> shutdown, and repeat for the four other Gigastone drives, can you >> confirm the duplicate serial numbers? >> > The serial number that shows in the pix I just posted is everything > right of the SSD_ above up to the "part1" If there is a different one > some place, tell me how to extract it. In the 6 entries above there are > only 3 unique numbers. If gparted is showing me a pack of lies, show me > how to prove gparted is lieing, I have no confidence in the Debian instance on your computer. I think your first priority should be to back up your data, using Debian installer media, Debian live, a Debian USB drive you make yourself, or some other known good live media. David
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-16 00:50 +0100 |
| Message-ID | <HWESl-3m9R-3@gated-at.bofh.it> |
| In reply to | #266001 |
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: >>> On 1/14/24 20:19, gene heskett wrote: >>>> On 1/14/24 19:48, David Wright wrote: >>>>> On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote: >>>>>> On 1/14/24 07:42, David Christensen wrote: >>>>> >>>>>>> I am confused -- do you have 4 or 5 Gigastone 2 TB SSD? >>>>>> >>>>>> 5, ordered in 2 separate orders. >>>>>>> >>>>>>> > So that one could be formatted ext4 and serve as a >>>>>>> backup of the raid10. >>>>>> What I am trying to do now, but cannot if it is plugged into a >>>>>> motherboard port, hence the repeat of this exercise on the 2nd sata >>>>>> card. >>>>>>> >>>>>>> > how do I make an image of that >>>>>>> > raid10 to /dev/sde and get every byte? That >>>>>>> seems like the first step >>>>>>> > to me. >>>>>> 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. I am tempted to use that >>>>>> serial number as a label _I_ can control. And according to gparted, >>>>>> labels do not survive being incorporated into a raid as the raid is >>>>>> all labeled with hostname : partition number. So there really is no >>>>>> way in linux to define a drive that is that drive forever. Unreal... >>>>> >>>>> Interesting to see in how many differents ways you can use the >>>>> term "label". BTW I have no idea what an "OTP serial number" is. >>>>> >>>> OTP=One Time Pad, never to be used again. >> >> I too can lookup acronyms with ease. I asked about "OTP serial number", >> not "OTP" serial number. >> >>> I moved the data cable to where I knew I could find it again, as one >>> of 5 drives attached to the 16 port card, >> >> No idea what that means. >> >>> and on reboot it shows up in >>> an lsblk list as: >>> root@coyote:~# lsblk >> >> [ … table showing five Samsungs, five Gigastones, and two >> other items, perhaps printer (confirmed later) and camera … ] >> >>> Now confirmed by looking at all 5 with gparted, there are only 3 >>> unique serial numbers: >> >> I don't see any parted output. > cuz it doesn't want to be copy/pasted. >> >>> root@coyote:~# ls /dev/disk/by-id >> >> ls -1 would at least sort out this mess, but more useful would be ls -l >> or for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' "$(realpath >> "$j")" "$j" ; done >> as you could then see what the symlinks point to, which after all >> is their raison d'être. > 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 > /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 > /dev/sdh /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 > /dev/sdh1 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 > /dev/sdk /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 > /dev/sdk1 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 > /dev/sdf /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T > /dev/sdf1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 > /dev/sdf2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 > /dev/sdf3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 > /dev/sde /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E > /dev/sde1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 > /dev/sde2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 > /dev/sde3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 > /dev/sdd /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V > /dev/sdd1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 > /dev/sdd2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 > /dev/sdd3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 > /dev/sdg /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W > /dev/sdg1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 > /dev/sdg2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 > /dev/sdg3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 > /dev/sda /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V > /dev/sda1 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 > /dev/sda2 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 > /dev/sda3 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 > /dev/md0 /dev/disk/by-id/md-name-coyote:0 > /dev/md0p1 /dev/disk/by-id/md-name-coyote:0-part1 > /dev/md2 /dev/disk/by-id/md-name-coyote:2 > /dev/md1 /dev/disk/by-id/md-name-_none_:1 > /dev/md0 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb > /dev/md0p1 > /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 > /dev/md1 /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 > /dev/md2 /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 > /dev/sdc /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 > /dev/sdb > /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0 > /dev/sdf /dev/disk/by-id/wwn-0x5002538f413394a5 > /dev/sdf1 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 > /dev/sdf2 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 > /dev/sdf3 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 > /dev/sde /dev/disk/by-id/wwn-0x5002538f413394a9 > /dev/sde1 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 > /dev/sde2 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 > /dev/sde3 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 > /dev/sdd /dev/disk/by-id/wwn-0x5002538f413394ae > /dev/sdd1 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 > /dev/sdd2 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 > /dev/sdd3 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 > /dev/sdg /dev/disk/by-id/wwn-0x5002538f413394b0 > /dev/sdg1 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 > /dev/sdg2 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 > /dev/sdg3 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 > /dev/sda /dev/disk/by-id/wwn-0x5002538f42205e8e > /dev/sda1 /dev/disk/by-id/wwn-0x5002538f42205e8e-part1 > /dev/sda2 /dev/disk/by-id/wwn-0x5002538f42205e8e-part2 > /dev/sda3 /dev/disk/by-id/wwn-0x5002538f42205e8e-part3 > root@coyote:~# > but like I wrote, 2 pairs with identical "serial numbers", so the > assunption is that the last one overwrites the first on by udev, when > IMO it should be yelling about the duplicats. >> >> Extracting: >> >>> ata-Gigastone_SSD_GST02TBG221146 >>> ata-Gigastone_SSD_GSTD02TB230102 >>> ata-Gigastone_SSD_GSTG02TB230206 >> >> these devices appear to have normal serial numbers. Do they bear >> any other indication, like engravings or stickers? If not, I would, >> in turn, plug each one in, read the serial number from its symlink, >> and write on it with a marker. While doing that, you could also >> run smartctl. >> >>> only 3 unique serial numbers!!!!!! >>> udev when finding that situation should scream from the rooftops!! >>> not silently overwrite an entry in the by-id that its already made. >> >> If you say so. I never had any problem with udev when I had >> three identical USB sticks with the "serial" number >> ID_SERIAL=SMI_USB_DISK-0:0 >> I scratched distinguishing letter on them, and watched xconsole for >> the drive letter whenever I plugged one in. At 8GB a piece, the >> largest I had at the time, they were very useful. And they didn't >> cost me a penny as they were giveaways. >> >>> HTH do I fix that? >>> can tune2fs edit a serial number? no. >>> can the UUID be rendered read-only, no. >>> gparted and similar can change the UUID by a click of the mouse. >>> I'm officially screwed and I have had them too long to return them now. >> >> You need to find out, in turn, which ones work, and that goes for >> both the SSDs and wherever you plug them in. You can make little >> progress at all without distinguishing them, as you have already >> shown by copying data to who knows where. > > Which occurred before I knew about the dups. Now you seem intent on > calling me a liar, which I do not intentionally do. I have now LABELed > the drives but the only way I can prove it to you ts seems would be to > take screen snapshots x5 of them, and one of those would be too big for > the server. > > Now, I have spent since around 08:30 my time this morning trying to > backup this raid with around 350G of data on it, to one of those 2T > gigastones but have lost the whole system because (apparently) rsync has > a huge memory leak, the system is fine, until I start as root > > "rsync -av --bwlimit=3m --fsync /home/ /mnt/homevol" > > which is where /dev/sdh1 is mounted. watch the system with htop, memory > bar goes to full scale in tan, in 10 to 15 minutes and into swap 500 > kilobytes in another 5 if OOM hasn't killed htop, the OOM daemon starts > killing things, and is not the least fussy what. > > I have tried it without the --bwlimit and --fsync but that just bombs > the system faster. I thought I was overpower the write speed of the > drive but slowing it to garden slug speeds still eats memory and the > system gets killed. 38G of 350G is as far as I'm managed to get copied > from 08:30 to 17:35. If that commandline above it correct, then as > AFAIAC rsync is busted. The memory gauge bar is in 3 colors, green at > the left is I prsume allocated mamory, next is red (cache maybe) and > then tan or orange. The man page does not define what color signifies > which but run rsync, it runs to the right end of the bar in orange/tan, > then into swap and the system slowly dies. > > I'm not a great user of rsync, use mc more often than not. I just have > seen it take up from where the reset or power switch was used to reboot > cuz the control of the system had been killed. So the command line > above might be the problem. You tell me, please. > >>> That could even explain why my first run of rsync worked fine but went >>> to a drive that was NOT mounted. And it was mounted by LABEL= The >>> only one of those 5 SSD's I had labeled at that time. >> >> You haven't shown any evidence of such LABELling, and most of your >> anecdotal narratives don't give much confidence for us to really >> know what was actually done. But to be fair, anything could >> happen if the hardware is not working properly. > I give up, lets see if a gparted screenshot comes thru. there was one > attached when I hit send. > >> Cheers, >> David. >> whoppie-ding, it worked. call me a liar again. >> . > > Cheers, Gene Heskett. 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
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-16 01:10 +0100 |
| Message-ID | <HWFbH-3mvB-9@gated-at.bofh.it> |
| In reply to | #266023 |
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: >>>> On 1/14/24 20:19, gene heskett wrote: >>>>> On 1/14/24 19:48, David Wright wrote: >>>>>> On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote: >>>>>>> On 1/14/24 07:42, David Christensen wrote: >>>>>> >>>>>>>> I am confused -- do you have 4 or 5 Gigastone 2 TB SSD? >>>>>>> >>>>>>> 5, ordered in 2 separate orders. >>>>>>>> >>>>>>>> > So that one could be formatted ext4 and serve as a >>>>>>>> backup of the raid10. >>>>>>> What I am trying to do now, but cannot if it is plugged into a >>>>>>> motherboard port, hence the repeat of thnis exercise on the 2nd sata >>>>>>> card. >>>>>>>> >>>>>>>> > how do I make an image of that >>>>>>>> > raid10 to /dev/sde and get every byte? That >>>>>>>> seems like the first step >>>>>>>> > to me. >>>>>>> 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. I am tempted to use that >>>>>>> serial number as a label _I_ can control. And according to gparted, >>>>>>> labels do not survive being incorporated into a raid as the raid is >>>>>>> all labeled with hostname : partition number. So there really is no >>>>>>> way in linux to define a drive that is that drive forever. Unreal... >>>>>> >>>>>> Interesting to see in how many differents ways you can use the >>>>>> term "label". BTW I have no idea what an "OTP serial number" is. >>>>>> >>>>> OTP=One Time Pad, never to be used again. >>> >>> I too can lookup acronyms with ease. I asked about "OTP serial number", >>> not "OTP" serial number. >>> >>>> I moved the data cable to where I knew I could find it again, as one >>>> of 5 drives attached to the 16 port card, >>> >>> No idea what that means. >>> >>>> and on reboot it shows up in >>>> an lsblk list as: >>>> root@coyote:~# lsblk >>> >>> [ … table showing five Samsungs, five Gigastones, and two >>> other items, perhaps printer (confirmed later) and camera … ] >>> >>>> Now confirmed by looking at all 5 with gparted, there are only 3 >>>> unique serial numbers: >>> >>> I don't see any parted output. >> cuz it doesn't want to be copy/pasted. >>> >>>> root@coyote:~# ls /dev/disk/by-id >>> >>> ls -1 would at least sort out this mess, but more useful would be >>> ls -l >>> or for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' "$(realpath >>> "$j")" "$j" ; done >>> as you could then see what the symlinks point to, which after all >>> is their raison d'être. >> 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 >> /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 >> /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 >> /dev/sdh /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 >> /dev/sdh1 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 >> /dev/sdk /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 >> /dev/sdk1 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 >> /dev/sdf >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T >> /dev/sdf1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 >> /dev/sdf2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 >> /dev/sdf3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 >> /dev/sde >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E >> /dev/sde1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 >> /dev/sde2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 >> /dev/sde3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 >> /dev/sdd >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V >> /dev/sdd1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 >> /dev/sdd2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 >> /dev/sdd3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 >> /dev/sdg >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W >> /dev/sdg1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 >> /dev/sdg2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 >> /dev/sdg3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 >> /dev/sda >> /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V >> /dev/sda1 >> /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 >> /dev/sda2 >> /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 >> /dev/sda3 >> /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 >> /dev/md0 /dev/disk/by-id/md-name-coyote:0 >> /dev/md0p1 /dev/disk/by-id/md-name-coyote:0-part1 >> /dev/md2 /dev/disk/by-id/md-name-coyote:2 >> /dev/md1 /dev/disk/by-id/md-name-_none_:1 >> /dev/md0 >> /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb >> /dev/md0p1 >> /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 >> /dev/md1 >> /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 >> /dev/md2 >> /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 >> /dev/sdc /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 >> /dev/sdb /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0 >> /dev/sdf /dev/disk/by-id/wwn-0x5002538f413394a5 >> /dev/sdf1 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 >> /dev/sdf2 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 >> /dev/sdf3 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 >> /dev/sde /dev/disk/by-id/wwn-0x5002538f413394a9 >> /dev/sde1 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 >> /dev/sde2 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 >> /dev/sde3 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 >> /dev/sdd /dev/disk/by-id/wwn-0x5002538f413394ae >> /dev/sdd1 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 >> /dev/sdd2 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 >> /dev/sdd3 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 >> /dev/sdg /dev/disk/by-id/wwn-0x5002538f413394b0 >> /dev/sdg1 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 >> /dev/sdg2 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 >> /dev/sdg3 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 >> /dev/sda /dev/disk/by-id/wwn-0x5002538f42205e8e >> /dev/sda1 /dev/disk/by-id/wwn-0x5002538f42205e8e-part1 >> /dev/sda2 /dev/disk/by-id/wwn-0x5002538f42205e8e-part2 >> /dev/sda3 /dev/disk/by-id/wwn-0x5002538f42205e8e-part3 >> root@coyote:~# >> but like I wrote, 2 pairs with identical "serial numbers", so the >> assunption is that the last one overwrites the first on by udev, when >> IMO it should be yelling about the duplicats. >>> >>> Extracting: >>> >>>> ata-Gigastone_SSD_GST02TBG221146 >>>> ata-Gigastone_SSD_GSTD02TB230102 >>>> ata-Gigastone_SSD_GSTG02TB230206 >>> >>> these devices appear to have normal serial numbers. Do they bear >>> any other indication, like engravings or stickers? If not, I would, >>> in turn, plug each one in, read the serial number from its symlink, >>> and write on it with a marker. While doing that, you could also >>> run smartctl. >>> There is a sticker on the bottom containing the numbers you see above, and a (upc?) bar code I don't have a reader for. >>>> only 3 unique serial numbers!!!!!! >>>> udev when finding that situation should scream from the rooftops!! >>>> not silently overwrite an entry in the by-id that its already made. >>> >>> If you say so. I never had any problem with udev when I had >>> three identical USB sticks with the "serial" number >>> ID_SERIAL=SMI_USB_DISK-0:0 >>> I scratched distinguishing letter on them, and watched xconsole for >>> the drive letter whenever I plugged one in. At 8GB a piece, the >>> largest I had at the time, they were very useful. And they didn't >>> cost me a penny as they were giveaways. >>> >>>> HTH do I fix that? >>>> can tune2fs edit a serial number? no. >>>> can the UUID be rendered read-only, no. >>>> gparted and similar can change the UUID by a click of the mouse. >>>> I'm officially screwed and I have had them too long to return them now. >>> >>> You need to find out, in turn, which ones work, and that goes for >>> both the SSDs and wherever you plug them in. You can make little >>> progress at all without distinguishing them, as you have already >>> shown by copying data to who knows where. >> >> Which occurred before I knew about the dups. Now you seem intent on >> calling me a liar, which I do not intentionally do. I have now >> LABELed the drives but the only way I can prove it to you ts seems >> would be to take screen snapshots x5 of them, and one of those would >> be too big for the server. >> >> Now, I have spent since around 08:30 my time this morning trying to >> backup this raid with around 350G of data on it, to one of those 2T >> gigastones but have lost the whole system because (apparently) rsync >> has a huge memory leak, the system is fine, until I start as root >> >> "rsync -av --bwlimit=3m --fsync /home/ /mnt/homevol" >> >> which is where /dev/sdh1 is mounted. watch the system with htop, >> memory bar goes to full scale in tan, in 10 to 15 minutes and into >> swap 500 kilobytes in another 5 if OOM hasn't killed htop, the OOM >> daemon starts killing things, and is not the least fussy what. >> >> I have tried it without the --bwlimit and --fsync but that just bombs >> the system faster. I thought I was overpower the write speed of the >> drive but slowing it to garden slug speeds still eats memory and the >> system gets killed. 38G of 350G is as far as I'm managed to get copied >> from 08:30 to 17:35. If that commandline above it correct, then as >> AFAIAC rsync is busted. The memory gauge bar is in 3 colors, green at >> the left is I prsume allocated mamory, next is red (cache maybe) and >> then tan or orange. The man page does not define what color signifies >> which but run rsync, it runs to the right end of the bar in >> orange/tan, then into swap and the system slowly dies. >> >> I'm not a great user of rsync, use mc more often than not. I just have >> seen it take up from where the reset or power switch was used to >> reboot cuz the control of the system had been killed. So the command >> line above might be the problem. You tell me, please. >> >>>> That could even explain why my first run of rsync worked fine but went >>>> to a drive that was NOT mounted. And it was mounted by LABEL= The >>>> only one of those 5 SSD's I had labeled at that time. >>> >>> You haven't shown any evidence of such LABELling, and most of your >>> anecdotal narratives don't give much confidence for us to really >>> know what was actually done. But to be fair, anything could >>> happen if the hardware is not working properly. >> I give up, lets see if a gparted screenshot comes thru. there was one >> attached when I hit send. >> >>> Cheers, >>> David. >>> > > whoppie-ding, it worked. call me a liar again. >>> . >> >> Cheers, Gene Heskett. > > Cheers, Gene Heskett. 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
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-01-16 01:20 +0100 |
| Message-ID | <HWFln-3mz8-3@gated-at.bofh.it> |
| In reply to | #266026 |
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 >>>>> ata-Gigastone_SSD_GSTG02TB230206 >>>> >>>> these devices appear to have normal serial numbers. Do they bear >>>> any other indication, like engravings or stickers? If not, I would, >>>> in turn, plug each one in, read the serial number from its symlink, >>>> and write on it with a marker. While doing that, you could also >>>> run smartctl. >>>> > There is a sticker on the bottom containing the numbers you see above, > and a (upc?) bar code I don't have a reader for. So, two stickers have one number, two stickers have another number, and one sticker has a third number? Or, three stickers have one number, one sticker has another number, and the last stick has a third number? David
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-16 02:40 +0100 |
| Message-ID | <HWGAN-3ncf-1@gated-at.bofh.it> |
| In reply to | #266027 |
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 >>>>>> ata-Gigastone_SSD_GSTD02TB230102 >>>>>> ata-Gigastone_SSD_GSTG02TB230206 >>>>> >>>>> these devices appear to have normal serial numbers. Do they bear >>>>> any other indication, like engravings or stickers? If not, I would, >>>>> in turn, plug each one in, read the serial number from its symlink, >>>>> and write on it with a marker. While doing that, you could also >>>>> run smartctl. >>>>> >> There is a sticker on the bottom containing the numbers you see above, >> and a (upc?) bar code I don't have a reader for. > > > So, two stickers have one number, two stickers have another number, and > one sticker has a third number? Or, three stickers have one number, one > sticker has another number, and the last stick has a third number? 5 ssd's 3 unique numbers on those 5 stickerss the same numbers you can see above. 2 drives with the same sticker, 2 more drive that have identical sticks and one with a different sticker. I am inclined to think the numbers are based on production batches, and not unique as there may be 500 in each batch. > > David > > . 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
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-01-16 03:20 +0100 |
| Message-ID | <HWHdv-3nDw-1@gated-at.bofh.it> |
| In reply to | #266029 |
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 wrote: >>>>>>> ata-Gigastone_SSD_GST02TBG221146 >>>>>>> ata-Gigastone_SSD_GSTD02TB230102 >>>>>>> ata-Gigastone_SSD_GSTG02TB230206 >>>>>> >>>>>> these devices appear to have normal serial numbers. Do they bear >>>>>> any other indication, like engravings or stickers? If not, I would, >>>>>> in turn, plug each one in, read the serial number from its symlink, >>>>>> and write on it with a marker. While doing that, you could also >>>>>> run smartctl. >>>>>> >>> There is a sticker on the bottom containing the numbers you see >>> above, and a (upc?) bar code I don't have a reader for. >> >> >> So, two stickers have one number, two stickers have another number, >> and one sticker has a third number? Or, three stickers have one >> number, one sticker has another number, and the last stick has a third >> number? > > 5 ssd's > 3 unique numbers on those 5 stickerss the same numbers you can see > above. 2 drives with the same sticker, 2 more drive that have identical > sticks and one with a different sticker. I am inclined to think the > numbers are based on production batches, and not unique as there may be > 500 in each batch. Duplicate serial numbers are going to cause confusion. If any of the drives with duplicate numbers are eligible for return, I would return them. If not, perhaps you could resell them to somebody. If you are going to keep them, I seem to recall that all five drives were partitioned with GPT and had one large partition (?). You could invent a unique identifier for each drive, put a physical label on each drive, and assign the same identifier to each GPT partition label. Alternatively, UUID's and/or PARTUUID's should be unique for both MBR and GPT: # ls -l /dev/disk/by-uuid/ # ls -l /dev/disk/by-partuuid/ David
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-16 04:00 +0100 |
| Message-ID | <HWHQd-3nQb-3@gated-at.bofh.it> |
| In reply to | #266029 |
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 Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote: > > > > > > > ata-Gigastone_SSD_GST02TBG221146 > > > > > > > ata-Gigastone_SSD_GSTD02TB230102 > > > > > > > ata-Gigastone_SSD_GSTG02TB230206 > > > > > > > > > > > > these devices appear to have normal serial numbers. Do they bear > > > > > > any other indication, like engravings or stickers? If not, I would, > > > > > > in turn, plug each one in, read the serial number from its symlink, > > > > > > and write on it with a marker. While doing that, you could also > > > > > > run smartctl. > > > > > > > > > There is a sticker on the bottom containing the numbers you > > > see above, and a (upc?) bar code I don't have a reader for. > > > > So, two stickers have one number, two stickers have another > > number, and one sticker has a third number? Or, three stickers > > have one number, one sticker has another number, and the last > > stick has a third number? > > 5 ssd's > 3 unique numbers on those 5 stickerss the same numbers you can see > above. 2 drives with the same sticker, 2 more drive that have > identical sticks and one with a different sticker. I am inclined to > think the numbers are based on production batches, and not unique as > there may be 500 in each batch. Ouch. Well that leaves you with several choices, like exchanging two of them, or moving them to different machines, or using them for backing up but not at the same time as their twin. That's if your use case relies on their serial numbers. If you're using them in a more conventional manner, where UUIDs, LABELs, PARTUUIDs and PARTLABELs are stable, and serial numbers are ignored, then you should have no problems. Just start by inserting them separately for partitioning and filesystem creation with unique strings. But obviously step one is labelling them (unless you're exchanging two of them in nearly-new condition). BTW, I wrote: > You haven't shown any evidence of such LABELling, and most of your > anecdotal narratives don't give much confidence for us to really > know what was actually done. But to be fair, anything could > happen if the hardware is not working properly. Nothing at all there about lying. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2024-01-16 07:00 +0100 |
| Message-ID | <HWKEq-3pFQ-1@gated-at.bofh.it> |
| In reply to | #266001 |
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 > /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 > /dev/sdh /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 > /dev/sdh1 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 > /dev/sdk /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 > /dev/sdk1 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 > /dev/sdf /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T > /dev/sdf1 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 > /dev/sdf2 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 > /dev/sdf3 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 > /dev/sde /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E > /dev/sde1 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 > /dev/sde2 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 > /dev/sde3 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 > /dev/sdd /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V > /dev/sdd1 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 > /dev/sdd2 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 > /dev/sdd3 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 > /dev/sdg /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W > /dev/sdg1 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 > /dev/sdg2 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 > /dev/sdg3 > /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 > /dev/sda /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V > /dev/sda1 > /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 > /dev/sda2 > /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 > /dev/sda3 > /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 > /dev/md0 /dev/disk/by-id/md-name-coyote:0 > /dev/md0p1 /dev/disk/by-id/md-name-coyote:0-part1 > /dev/md2 /dev/disk/by-id/md-name-coyote:2 > /dev/md1 /dev/disk/by-id/md-name-_none_:1 > /dev/md0 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb > /dev/md0p1 > /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 > /dev/md1 /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 > /dev/md2 /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 > /dev/sdc /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 > /dev/sdb /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0 > /dev/sdf /dev/disk/by-id/wwn-0x5002538f413394a5 > /dev/sdf1 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 > /dev/sdf2 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 > /dev/sdf3 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 > /dev/sde /dev/disk/by-id/wwn-0x5002538f413394a9 > /dev/sde1 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 > /dev/sde2 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 > /dev/sde3 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 > /dev/sdd /dev/disk/by-id/wwn-0x5002538f413394ae > /dev/sdd1 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 > /dev/sdd2 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 > /dev/sdd3 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 > /dev/sdg /dev/disk/by-id/wwn-0x5002538f413394b0 > /dev/sdg1 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 > /dev/sdg2 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 > /dev/sdg3 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 > /dev/sda /dev/disk/by-id/wwn-0x5002538f42205e8e > /dev/sda1 /dev/disk/by-id/wwn-0x5002538f42205e8e-part1 > /dev/sda2 /dev/disk/by-id/wwn-0x5002538f42205e8e-part2 > /dev/sda3 /dev/disk/by-id/wwn-0x5002538f42205e8e-part3 > root@coyote:~# > but like I wrote, 2 pairs with identical "serial numbers", so the > assunption is that the last one overwrites the first on by udev, when > IMO it should be yelling about the duplicats. 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/md0 1 /dev/disk/by-id/md-name-coyote:0 /dev/md0 2 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb /dev/md0p1 3 /dev/disk/by-id/md-name-coyote:0-part1 /dev/md0p1 4 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 /dev/md1 5 /dev/disk/by-id/md-name-_none_:1 /dev/md1 6 /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 /dev/md2 7 /dev/disk/by-id/md-name-coyote:2 /dev/md2 8 /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 /dev/sda 9 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V /dev/sda 10 /dev/disk/by-id/wwn-0x5002538f42205e8e /dev/sda1 11 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 /dev/sda1 12 /dev/disk/by-id/wwn-0x5002538f42205e8e-part1 /dev/sda2 13 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 /dev/sda2 14 /dev/disk/by-id/wwn-0x5002538f42205e8e-part2 /dev/sda3 15 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 /dev/sda3 16 /dev/disk/by-id/wwn-0x5002538f42205e8e-part3 /dev/sdb 17 /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0 /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 # How does a printer get a storage device assignment??? /dev/sdd 19 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V /dev/sdd 20 /dev/disk/by-id/wwn-0x5002538f413394ae /dev/sdd1 21 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 /dev/sdd1 22 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 /dev/sdd2 23 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 /dev/sdd2 24 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 /dev/sdd3 25 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 /dev/sdd3 26 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 /dev/sde 27 /dev/disk/by-id/wwn-0x5002538f413394a9 /dev/sde 28 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E /dev/sde1 29 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 /dev/sde1 30 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 /dev/sde2 31 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 /dev/sde2 32 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 /dev/sde3 33 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 /dev/sde3 34 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 /dev/sdf 35 /dev/disk/by-id/wwn-0x5002538f413394a5 /dev/sdf 36 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T /dev/sdf1 37 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 /dev/sdf1 38 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 /dev/sdf2 39 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 /dev/sdf2 40 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 /dev/sdf3 41 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 /dev/sdf3 42 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 /dev/sdg 43 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W /dev/sdg 44 /dev/disk/by-id/wwn-0x5002538f413394b0 /dev/sdg1 45 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 /dev/sdg1 46 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 /dev/sdg2 47 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 /dev/sdg2 48 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 /dev/sdg3 49 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 /dev/sdg3 50 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 /dev/sdh 51 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 /dev/sdh1 52 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 /dev/sdi 53 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 /dev/sdj1 54 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 /dev/sdk 55 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 /dev/sdk1 56 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 /dev/sr0 57 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865 Exactly which line numbers represent duplication among the physical drives? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Tom Furie <tom@furie.org.uk> |
|---|---|
| Date | 2024-01-16 09:20 +0100 |
| Message-ID | <HWMPT-3r7T-1@gated-at.bofh.it> |
| In reply to | #266038 |
Felix Miata <mrmazda@earthlink.net> 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.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2024-01-16 12:10 +0100 |
| Message-ID | <HWPup-3sMH-1@gated-at.bofh.it> |
| In reply to | #266047 |
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 USB-connected printer? IP printer connections don't cause it too? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-16 13:40 +0100 |
| Message-ID | <HWQTv-3txv-5@gated-at.bofh.it> |
| In reply to | #266055 |
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 this pollution only results from a USB-connected printer? IP printer > connections don't cause it too? Yes, IP printers don't.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-17 01:20 +0100 |
| Message-ID | <HX1OV-3Aoi-3@gated-at.bofh.it> |
| In reply to | #266055 |
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 SD card slot or similar.
>
> So this pollution only results from a USB-connected printer? IP printer
> connections don't cause it too?
AIUI (not very well), you only get a /dev/sdX when the linux kernel
is what's writing the blocks on the filesystem.
So when I plug in my Galaxy 4 mobile and tap the appropriate buttons
on its screen, /dev/sdb{,1} appear as a block device and partition:
sdb 8:16 1 29.7G 0 disk
└─sdb1 8:17 1 29.7G 0 part
so I can run fdisk on the SD card while in the phone, for example:
$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Disk model: S5360 Card
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: 0x03399e11
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 62333951 62331904 29.7G c W95 FAT32 (LBA)
$
OTOH with my A13 phone, I don't get a block device created, but just
a FUSE wrapper round the filesystems that Android is running, both
internal and any SD card:
$ mount
[ … ]
aft-mtp-mount on /media/samsungd type fuse.aft-mtp-mount (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
$
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-17 03:00 +0100 |
| Message-ID | <HX3nH-3B7R-1@gated-at.bofh.it> |
| In reply to | #266055 |
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 pollution only results from a USB-connected printer? IP printer > connections don't cause it too? Since I have one of the above printers it does indeed have an editable ipv4 address, but I don't generally use it as the usb2 is faster. Its been so long since I did use that interface that I do not recall if it listed the card memory. I'd expect it would since it can also to a free standing copy from its tabloid sized scanner. The printer can handle tabloid sized paper by hand feeding, so the copy function includes tabloid size too. 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
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-16 16:00 +0100 |
| Message-ID | <HWT4Z-3uPs-1@gated-at.bofh.it> |
| In reply to | #266047 |
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 box to autorun an installer when the device is plugged. Finally the installer switches the device to its normal mode. On Linux usb-modeswitch might be required.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-16 15:10 +0100 |
| Message-ID | <HWSiC-3uxJ-9@gated-at.bofh.it> |
| In reply to | #266038 |
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 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865 > > /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > > /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 It's right here at the top. [ … ] > > root@coyote:~# > > but like I wrote, 2 pairs with identical "serial numbers", so the > > assunption is that the last one overwrites the first on by udev, when > > IMO it should be yelling about the duplicats. > > 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/md0 1 /dev/disk/by-id/md-name-coyote:0 > /dev/md0 2 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb > /dev/md0p1 3 /dev/disk/by-id/md-name-coyote:0-part1 > /dev/md0p1 4 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 > /dev/md1 5 /dev/disk/by-id/md-name-_none_:1 > /dev/md1 6 /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 > /dev/md2 7 /dev/disk/by-id/md-name-coyote:2 > /dev/md2 8 /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 > /dev/sda 9 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V > /dev/sda 10 /dev/disk/by-id/wwn-0x5002538f42205e8e > /dev/sda1 11 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 > /dev/sda1 12 /dev/disk/by-id/wwn-0x5002538f42205e8e-part1 > /dev/sda2 13 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 > /dev/sda2 14 /dev/disk/by-id/wwn-0x5002538f42205e8e-part2 > /dev/sda3 15 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 > /dev/sda3 16 /dev/disk/by-id/wwn-0x5002538f42205e8e-part3 > /dev/sdb 17 /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0 > /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 # How does a printer get a storage device assignment??? I'd /love/ my HP8500 scanner (that's all that works now) to have the USB stick (which I scan onto) be visible to a connected PC or the network. Is that what /dev/sdc is? > /dev/sdd 19 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V > /dev/sdd 20 /dev/disk/by-id/wwn-0x5002538f413394ae > /dev/sdd1 21 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 > /dev/sdd1 22 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 > /dev/sdd2 23 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 > /dev/sdd2 24 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 > /dev/sdd3 25 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 > /dev/sdd3 26 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 > /dev/sde 27 /dev/disk/by-id/wwn-0x5002538f413394a9 > /dev/sde 28 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E > /dev/sde1 29 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 > /dev/sde1 30 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 > /dev/sde2 31 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 > /dev/sde2 32 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 > /dev/sde3 33 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 > /dev/sde3 34 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 > /dev/sdf 35 /dev/disk/by-id/wwn-0x5002538f413394a5 > /dev/sdf 36 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T > /dev/sdf1 37 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 > /dev/sdf1 38 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 > /dev/sdf2 39 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 > /dev/sdf2 40 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 > /dev/sdf3 41 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 > /dev/sdf3 42 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 > /dev/sdg 43 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W > /dev/sdg 44 /dev/disk/by-id/wwn-0x5002538f413394b0 > /dev/sdg1 45 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 > /dev/sdg1 46 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 > /dev/sdg2 47 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 > /dev/sdg2 48 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 > /dev/sdg3 49 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 > /dev/sdg3 50 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 > /dev/sdh 51 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 > /dev/sdh1 52 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 > /dev/sdi 53 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > /dev/sdj1 54 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 ↑↑↑↑↑↑↑↑↑ that is /really/ bad! > /dev/sdk 55 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 > /dev/sdk1 56 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 > /dev/sr0 57 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865 > > Exactly which line numbers represent duplication among the physical drives? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2024-01-16 15:40 +0100 |
| Message-ID | <HWSLE-3uIz-5@gated-at.bofh.it> |
| In reply to | #266070 |
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 '%s\t%s\n' >>> "$(realpath "$j")" "$j" ; done >>> /dev/sr0 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865 >>> /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 >>> /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 > It's right here at the top. I missed that, probably because i & j look similar in the big sea of alphanumerics, /and/ sdi has no partitions, while sdj1 has no parent disk. That seems to smell as much like a bug somewhere as two different disks with the same serial number, a cheap SATA port card maybe. Does ...1146 get duplication like that when connected to any/every available SATA port? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-01-16 15:50 +0100 |
| Message-ID | <HWSVj-3uMd-9@gated-at.bofh.it> |
| In reply to | #266071 |
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 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 > >>> /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > >>> /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 > > > It's right here at the top. > > I missed that, probably because i & j look similar in the big sea of > alphanumerics, /and/ sdi has no partitions, while sdj1 has no parent disk. That > seems to smell as much like a bug somewhere as two different disks with the same > serial number, a cheap SATA port card maybe. Does ...1146 get duplication like > that when connected to any/every available SATA port? I missed it too. It actually looks like someone copy/pasted the pathnames on the right, but then manually typed the device names on the left, and made a typo here. Or, somehow, the device names and the pathnames got mixed together, and someone tried to separate them manually, and got these two crossed.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | linux.debian.user
csiph-web