Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Stefan Monnier]

>> Every time you have to reboot, it means your OS has somewhat failed you.
>   i don't think that at all.  remember that each person can
> have different preferences, requirements and expectations.

That's why I wrote "have to".
Of course, if you choose to reboot it, it's not you OS's fault.

> system to begin with but i hate the idea that it is doing
> nothing at all useful just sitting there if i'm not going
> to be using it any time soon.

IIUC in your case you could just as well suspend/hibernate instead of
shutting down and that would solve the "just sitting there" problem
without having to reboot: the reboot is your choice and you're indeed
perfectly entitled to that preference.


Stefan

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[David Wright]

On Wed 05 Feb 2020 at 22:54:33 (-0500), Michael Stone wrote:
> On Wed, Feb 05, 2020 at 07:33:38PM -0600, David Wright wrote:
> > On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote:
> > > On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
> > > > On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:
> > > > > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> > > > > > While I'm sure this can be managed by explicitly setting UUIDs, I've
> > > > > > found it much more pleasant to manage explicit names (I personally
> > > > > > prefer LVM names over filesystem labels, but filesystem labels work 
> > > > > > well
> > > > > > for those filesystems I don't put under LVM).  Not only I can 
> > > > > > pronounce
> > > > > > them and they carry meaning, but they tend to be much more visible 
> > > > > > (and
> > > > > > hence easier to manipulate).
> > > > >
> > > > > I dislike using names becaues it's *much* more common to find name
> > > > > collisions than UUID collisions. (E.g., a bunch of disks with
> > > > > filesystems all labeled with easy to remember names like "root" or
> > > > > "home".) Reboot with a couple of those in your system on a
> > > > > label-oriented configuration and you may have a very bad day.
> > > >
> > > > Rather a strawman argument there. There's no reason not to choose
> > > > sensible LABELs, unlike the examples you've given there, which fail
> > > > for at least two reasons: they're unlikely to be unique and they're
> > > > too overloaded with meaning.
> > > 
> > > What does "sensible" mean in this context? On a static system all of
> > > this is a complete waste of time because nothing changes. If you start
> > > upgrading disks, using external drives, moving things around, etc., it
> > > may very well be that the same "sensible" label applies to a
> > > filesystem found on more than one disk.
> > 
> > To make that argument, you have to put scare quotes round sensible
> > because common sense would lead you to use different LABELs for
> > partitions that you intend to distinguish by LABEL. To do otherwise
> > would be like suggesting that two teams who play in red should do
> > so without a change of shirt for one team.
> 
> You seem to just be stuck in this mindset where you think that it's
> somehow weird or unusual to name a root filesystem "root" instead of
> "kumquat" or some other meaningless string.

I opined that it's unwise to LABEL a filesystem "root" if you're using
LABELs as the determining name. It's not weird, and I have no idea
whether it's usual or not. The reason I called it unwise is that it's
limiting. For example, if I make it a habit to call the root
filesystem on this laptop "root", what should I LABEL the other root
filesystem as? Is it sensible to have two fstab files like:

LABEL=root /   ext4 errors=remount-ro 0 1
LABEL=previous /media/previous ext4 errors=remount-ro 0 1
and
LABEL=previous /   ext4 errors=remount-ro 0 1
LABEL=root /media/previous ext4 errors=remount-ro 0 1

That's what I mean about excessive overloading of meanings.

> I don't really have a
> response to that except to note that in my experience your naming
> conventions are an outlier and that it's a waste of time making
> assertions about what people should use as names instead of simply
> acknowledging what people actually use as names.

I have very little knowledge of what people are using as names, if
anything, unless they post them here. That doesn't prevent my having
an opinion, nor anybody else. How I spend my time is up to me.
I thought I had limited my assertions to pointing out that your
arguments appeared to be directed against things *not* stated,
like "labels prevent problems".

> > > Can problems be avoided
> > > through careful attention to detail?
> > 
> > I'd call the LABEL problem's solution blindingly obvious. Ironically,
> > one has to be more careful with *certain* operations when using UUIDs
> > because one is less likely to spot a duplication. I'm thinking of,
> > say, copying partitions.
> 
> Again, asserting that using labels in a fashion that avoids potential
> collisions is "blindlingly obvious" implies that the problems I've
> seen people have with label-based schemes must mean that they're too
> ignorant to do the "obviously" correct thing. That seems presumptuous
> at least.

Pointing out a pitfall to someone doesn't mean that you're calling
them ignorant, particularly in a forum like this where you don't
have any idea who "they" are.

> OTOH, following best practices when copying raw partitions (including
> changing the UUID) seems to be something to be glossed over
> (presumably because only changing the label in that exact case is
> "obvious"?)

No, I'm not trying to gloss over it. What I would say is that if you
have a partition LABELled   sex   and you clone it, and then you
find yourself typing
# mount LABEL=sex /media/myclone
you're more likely to notice the 

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[songbird]

Stefan Monnier wrote:
>>> PS: The only problem with LVM names is that Linux doesn't let you
>>> rename a volume group while it's active (at least last time I tried),
>>> which makes it painful to rename the volume group in which lives your
>>> root partition.
>> How painful is it to dd a live cd, boot from it and rename?
>
> Very.  It's called "downtime".
> Every time you have to reboot, it means your OS has somewhat failed you.

  i don't think that at all.  remember that each person can
have different preferences, requirements and expectations.

  i reboot my computer once or twice a day depending upon what
i'm doing.  it takes only a few seconds.

  at the end of the day i turn it off since i don't like 
wasting electricity.  it is a fairly low power consuming
system to begin with but i hate the idea that it is doing
nothing at all useful just sitting there if i'm not going
to be using it any time soon.  since it does shut down and
start up quickly enough it isn't an issue.


  songbird

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Michael Stone]

On Wed, Feb 05, 2020 at 07:33:38PM -0600, David Wright wrote:

On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote:

On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
> On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:
> > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> > > While I'm sure this can be managed by explicitly setting UUIDs, I've
> > > found it much more pleasant to manage explicit names (I personally
> > > prefer LVM names over filesystem labels, but filesystem labels work well
> > > for those filesystems I don't put under LVM).  Not only I can pronounce
> > > them and they carry meaning, but they tend to be much more visible (and
> > > hence easier to manipulate).
> >
> > I dislike using names becaues it's *much* more common to find name
> > collisions than UUID collisions. (E.g., a bunch of disks with
> > filesystems all labeled with easy to remember names like "root" or
> > "home".) Reboot with a couple of those in your system on a
> > label-oriented configuration and you may have a very bad day.
>
> Rather a strawman argument there. There's no reason not to choose
> sensible LABELs, unlike the examples you've given there, which fail
> for at least two reasons: they're unlikely to be unique and they're
> too overloaded with meaning.

What does "sensible" mean in this context? On a static system all of
this is a complete waste of time because nothing changes. If you start
upgrading disks, using external drives, moving things around, etc., it
may very well be that the same "sensible" label applies to a
filesystem found on more than one disk.


To make that argument, you have to put scare quotes round sensible
because common sense would lead you to use different LABELs for
partitions that you intend to distinguish by LABEL. To do otherwise
would be like suggesting that two teams who play in red should do
so without a change of shirt for one team.


You seem to just be stuck in this mindset where you think that it's 
somehow weird or unusual to name a root filesystem "root" instead of 
"kumquat" or some other meaningless string. I don't really have a 
response to that except to note that in my experience your naming 
conventions are an outlier and that it's a waste of time making 
assertions about what people should use as names instead of simply 
acknowledging what people actually use as names.



Can problems be avoided
through careful attention to detail?


I'd call the LABEL problem's solution blindingly obvious. Ironically,
one has to be more careful with *certain* operations when using UUIDs
because one is less likely to spot a duplication. I'm thinking of,
say, copying partitions.


Again, asserting that using labels in a fashion that avoids potential 
collisions is "blindlingly obvious" implies that the problems I've seen 
people have with label-based schemes must mean that they're too ignorant 
to do the "obviously" correct thing. That seems presumptuous at least.


OTOH, following best practices when copying raw partitions (including 
changing the UUID) seems to be something to be glossed over (presumably 
because only changing the label in that exact case is "obvious"?)



Stefan and I were posting why we like names. The uniqueness of UUIDs
is a given. (Ironically, it's in the name.)


Perhaps (although the fact that they won't be unique if you copy the raw 
filesystem is a recurring theme) but the argument at the top of the 
thread seems to be that they somehow change unexpectedly and can't be 
relied upon--which would seem to be an even more serious problem (if it 
existed).



And it's a different
argument from the one you appeared to make, 


Yes, I argued against the proposition that actually started the thread, 
which seemed to be that UUIDs are somehow unreliable--in particular,
as compared to labels. For some reason talking about why that isn't 
actually the case makes you start talking about straw men, as though you 
either didn't read or couldn't remember posts from a couple of days ago.



which was that you dislike
using names because other people (presumably) misuse them. 


And you've explained that anybody who uses them other than in the 
(extremely idiosyncratic) manner you prescribe is just doing them wrong 
and its their own fault if there are problems because they must be dumb. 
I'm glad we've managed to so succinctly summarize each other's position.


If I were to summarize my own position it would simply be that I 
encourage people to be aware of potential issues that arise when labels 
collide, and that UUIDs are a (not unreliable) alternative that may work 
better in some circumstances.



OK, perhaps
you run a helpdesk.


The closest I come to that is this mailing list.


Just because you personally use a
feature in a particular way doesn't mean everyone else does. Sometimes
a standard install of an OS can default to labeling schemes that cause
conflicts if you put the drive from one machine into another

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[David Wright]

On Wed 05 Feb 2020 at 16:47:13 (-0500), Greg Wooledge wrote:
> On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
> > I don't suppose either of us will meet a UUID collision in our
> > lifetimes, and it's obviously a sensible scheme to use where there
> > are large numbers of commoditised objects to name.
> 
> Usually a UUID collision is a result of a subtle mistake, like cloning
> a disk and then trying to mount a file system by UUID while the clone
> is still attached.  At least, that's the first scenario I can think of.

There are versions of UUIDs that aren't quite what they seem;
IOW there are predictable ones. There are means of placing strings
into positions where UUIDs are expected, eg tune2fs -U. There's a
vanishingly small probability that a human will spot a deliberately
altered UUID. My assumption in writing the above was that we are
honest brokers, generating UUIDs in a random manner.

In the absence of a RNG of any quality whatsoever, I think the
cryptographic vulnerability of the system will exceed the likelihood
of UUID collisions occurring. I have no information to back that up :)

https://lists.debian.org/debian-user/2020/02/msg5.html

Cheers,
David.

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[David Wright]

On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote:
> On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
> > On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:
> > > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> > > > While I'm sure this can be managed by explicitly setting UUIDs, I've
> > > > found it much more pleasant to manage explicit names (I personally
> > > > prefer LVM names over filesystem labels, but filesystem labels work well
> > > > for those filesystems I don't put under LVM).  Not only I can pronounce
> > > > them and they carry meaning, but they tend to be much more visible (and
> > > > hence easier to manipulate).
> > > 
> > > I dislike using names becaues it's *much* more common to find name
> > > collisions than UUID collisions. (E.g., a bunch of disks with
> > > filesystems all labeled with easy to remember names like "root" or
> > > "home".) Reboot with a couple of those in your system on a
> > > label-oriented configuration and you may have a very bad day.
> > 
> > Rather a strawman argument there. There's no reason not to choose
> > sensible LABELs, unlike the examples you've given there, which fail
> > for at least two reasons: they're unlikely to be unique and they're
> > too overloaded with meaning.
> 
> What does "sensible" mean in this context? On a static system all of
> this is a complete waste of time because nothing changes. If you start
> upgrading disks, using external drives, moving things around, etc., it
> may very well be that the same "sensible" label applies to a
> filesystem found on more than one disk.

To make that argument, you have to put scare quotes round sensible
because common sense would lead you to use different LABELs for
partitions that you intend to distinguish by LABEL. To do otherwise
would be like suggesting that two teams who play in red should do
so without a change of shirt for one team.

> Can problems be avoided
> through careful attention to detail?

I'd call the LABEL problem's solution blindingly obvious. Ironically,
one has to be more careful with *certain* operations when using UUIDs
because one is less likely to spot a duplication. I'm thinking of,
say, copying partitions.

> Sure--but the same is true of
> many other systems. I submit that labels are not inherently "better",
> but merely a matter of preference.

I haven't said one is better than the other, but have just pointed out
why I like LABELs, which you said you dislike.

> If you like them, great! Have fun!
> If giving every thumbdrive its own label and mountpoint makes you
> happy, go for it. I generally expect thumbdrives to be consumables,
> mount them at generic points, and call it a day. YMMV.

And I supported you there, but you snipped it; I wrote of UUIDs:

"it's obviously a sensible scheme to use where there are
large numbers of commoditised objects to name."

> And FWIW, those aren't "strawman arguments", those are based on things
> I've found in the real world.

Stefan and I were posting why we like names. The uniqueness of UUIDs
is a given. (Ironically, it's in the name.) And it's a different
argument from the one you appeared to make, which was that you dislike
using names because other people (presumably) misuse them. OK, perhaps
you run a helpdesk.

> Just because you personally use a
> feature in a particular way doesn't mean everyone else does. Sometimes
> a standard install of an OS can default to labeling schemes that cause
> conflicts if you put the drive from one machine into another
> machine--so this really isn't something I'm making up out of thin air
> that never happens in real life.

IIRC you're describing Debian in the early days, when partitions were
configured only by their kernel names, rather like some people prefer
their network interfaces to be named.

> > > LVM is
> > > more resistant to that as long as you keep the vg names unique. (Call
> > > everything vg0 and you're back to having a bad day.)
> > 
> > It seems that saying "keep the vg names unique" is not very different
> > from saying to keep filesystem LABELs unique.
> 
> It's pretty much exactly the same. If you have multiple logical
> entities addressed by the same name, you might not get the entity you
> expected to get. This isn't always obvious to someone starting out who
> reads something like "labels prevent problems" and hasn't yet run into
> cases where that isn't true and thus hasn't adopted strategies to
> avoid those problems.

That's another strawman argument: I haven't suggested that, you bring
it up, then knock it down: isn't that the definition of a strawman
argument?

LABELs are a tool, as are UUIDs. I like both. UUIDs are great for
creating a nonce name; so good, we wonder how we got by without them.
But LABELs have some advantages (like brevity, memorability, meaning)
which persuades some people to use them without abusing them.

Where I might part company with Stefan is in adopting names with too
much meaning, 

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[0...@caiway.net]

On Tue, 04 Feb 2020 22:19:25 -0500
Stefan Monnier  wrote:
> > How painful is it to dd a live cd, boot from it and rename?
> 
> Very.  It's called "downtime".
> Every time you have to reboot, it means your OS has somewhat failed
> you.
> 
> 
> Stefan
> 

You are absolutely right!

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Stefan Monnier]

> Usually a UUID collision is a result of a subtle mistake, like cloning
> a disk and then trying to mount a file system by UUID while the clone
> is still attached.  At least, that's the first scenario I can think of.

I wouldn't call it a "subtle mistake".  Instead it's what *always*
happens when I make a clone: I always mount it right afterwards to
perform some checks and/or tweaks, and I never have any reason to
unmount the original before doing that.

Of course, that doesn't bother me: the clone's LV has a different name,
so whether the UUID is the same or not doesn't affect it.


Stefan

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Greg Wooledge]

On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
> I don't suppose either of us will meet a UUID collision in our
> lifetimes, and it's obviously a sensible scheme to use where there
> are large numbers of commoditised objects to name.

Usually a UUID collision is a result of a subtle mistake, like cloning
a disk and then trying to mount a file system by UUID while the clone
is still attached.  At least, that's the first scenario I can think of.

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Michael Stone]

On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:

On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:

On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> While I'm sure this can be managed by explicitly setting UUIDs, I've
> found it much more pleasant to manage explicit names (I personally
> prefer LVM names over filesystem labels, but filesystem labels work well
> for those filesystems I don't put under LVM).  Not only I can pronounce
> them and they carry meaning, but they tend to be much more visible (and
> hence easier to manipulate).

I dislike using names becaues it's *much* more common to find name
collisions than UUID collisions. (E.g., a bunch of disks with
filesystems all labeled with easy to remember names like "root" or
"home".) Reboot with a couple of those in your system on a
label-oriented configuration and you may have a very bad day.


Rather a strawman argument there. There's no reason not to choose
sensible LABELs, unlike the examples you've given there, which fail
for at least two reasons: they're unlikely to be unique and they're
too overloaded with meaning.


What does "sensible" mean in this context? On a static system all of 
this is a complete waste of time because nothing changes. If you start 
upgrading disks, using external drives, moving things around, etc., it 
may very well be that the same "sensible" label applies to a filesystem 
found on more than one disk. Can problems be avoided through careful 
attention to detail? Sure--but the same is true of many other systems. I 
submit that labels are not inherently "better", but merely a matter of 
preference. If you like them, great! Have fun! If giving every 
thumbdrive its own label and mountpoint makes you happy, go for it. I 
generally expect thumbdrives to be consumables, mount them at generic 
points, and call it a day. YMMV.


And FWIW, those aren't "strawman arguments", those are based on things 
I've found in the real world. Just because you personally use a feature 
in a particular way doesn't mean everyone else does. Sometimes a 
standard install of an OS can default to labeling schemes that cause 
conflicts if you put the drive from one machine into another machine--so 
this really isn't something I'm making up out of thin air that never 
happens in real life.



LVM is
more resistant to that as long as you keep the vg names unique. (Call
everything vg0 and you're back to having a bad day.)


It seems that saying "keep the vg names unique" is not very different
from saying to keep filesystem LABELs unique.


It's pretty much exactly the same. If you have multiple logical entities 
addressed by the same name, you might not get the entity you expected to 
get. This isn't always obvious to someone starting out who reads 
something like "labels prevent problems" and hasn't yet run into cases 
where that isn't true and thus hasn't adopted strategies to avoid those 
problems.

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[David Wright]

On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:
> On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> > > > Me too, so I usually label the permanent stuff at least. UUID's can and
> > > > will change for no detectable reason.
> > > For those reading along or finding this in search results: no, filesystem
> > > UUIDs don't change for no detectable reason. Don't implement anything 
> > > based
> > > on this theory.
> > 
> > What he meant is that filesystem UUIDs are (re)created automatically
> > based on a heuristic of what it means for a filesystem to be "the same".
> 
> You understand that he didn't actually say that, right? This seems
> like your own personal bugaboo instead.

Yes, what he wrote is elaborated in postings like
https://lists.debian.org/debian-user/2018/01/msg00787.html
https://lists.debian.org/debian-user/2018/01/msg00791.html

> > While I'm sure this can be managed by explicitly setting UUIDs, I've
> > found it much more pleasant to manage explicit names (I personally
> > prefer LVM names over filesystem labels, but filesystem labels work well
> > for those filesystems I don't put under LVM).  Not only I can pronounce
> > them and they carry meaning, but they tend to be much more visible (and
> > hence easier to manipulate).
> 
> I dislike using names becaues it's *much* more common to find name
> collisions than UUID collisions. (E.g., a bunch of disks with
> filesystems all labeled with easy to remember names like "root" or
> "home".) Reboot with a couple of those in your system on a
> label-oriented configuration and you may have a very bad day.

Rather a strawman argument there. There's no reason not to choose
sensible LABELs, unlike the examples you've given there, which fail
for at least two reasons: they're unlikely to be unique and they're
too overloaded with meaning.

I don't suppose either of us will meet a UUID collision in our
lifetimes, and it's obviously a sensible scheme to use where there
are large numbers of commoditised objects to name. Look at cars.
For practical purposes, a VIN is a (U)UID: great for computers,
but totally impractical for human use, hence licence plates,
whose numbers are chosen to be unique only within a juridiction.

My jurisdiction is Home, so every host gets a short memorable
name, and each disk, stick and card does too. Their filesystem
LABELs relate to those names. All are marked with those names,
and I couldn't manage that with UUIDs. None of the names carry
any functional meaning, because functions necessarily change.

Other people will choose LABELs in different ways, but the fact
that some people will choose unwisely does not condemn the method.

> LVM is
> more resistant to that as long as you keep the vg names unique. (Call
> everything vg0 and you're back to having a bad day.)

It seems that saying "keep the vg names unique" is not very different
from saying to keep filesystem LABELs unique.

> On Tue, Feb 04, 2020 at 10:19:25PM -0500, Stefan Monnier wrote:
> > > > PS: The only problem with LVM names is that Linux doesn't let you
> > > > rename a volume group while it's active (at least last time I tried),
> > > > which makes it painful to rename the volume group in which lives your
> > > > root partition.
> > > How painful is it to dd a live cd, boot from it and rename?
> > 
> > Very.  It's called "downtime".
> > Every time you have to reboot, it means your OS has somewhat failed you.
> 
> I'm trying to think of a reason to rename the root partition that
> doesn't involve downtime and coming up empty.

I don't know what the implications of LVM are because I've not used
them. Consequently I don't know why Stefan wrote 'The root partition
is always called "root"', or whether "called" even refers here to a
filesystem LABEL or something else. Some of the posts seem to conflate
the terms partition, VG, LV and LVM.

Cheers,
David.

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Stefan Monnier]

>>What he meant is that filesystem UUIDs are (re)created automatically
>>based on a heuristic of what it means for a filesystem to be "the same".
> You understand that he didn't actually say that, right? This seems like your
> own personal bugaboo instead.

Definitely.

> I dislike using names becaues it's *much* more common to find name
> collisions than UUID collisions. (E.g., a bunch of disks with 
> filesystems all labeled with easy to remember names like "root" or "home".)

Yes, that happens frequently with filesystem labels, which is why I much
prefer LVM names.

> LVM is more resistant to that as long as you keep the vg names unique.

Indeed, my VG names are always unique and descriptive.

> I'm trying to think of a reason to rename the root partition that doesn't
> involve downtime and coming up empty. 

The root partition is always called "root", which is why I was talking
about renaming the VGs rather the LVs.

Yes, it usually involves downtime for some other related reason, but
every time I've had to change a VG's name it would have been *much* more
convenient to do it while the system is up (e.g. would have shortened
the downtime and the administration time noticeably).

Renaming the root VG is really the only case where I find LVM names to
be a point of friction.


Stefan

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Michael Stone]

On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:

Me too, so I usually label the permanent stuff at least. UUID's can and
will change for no detectable reason.

For those reading along or finding this in search results: no, filesystem
UUIDs don't change for no detectable reason. Don't implement anything based
on this theory.


What he meant is that filesystem UUIDs are (re)created automatically
based on a heuristic of what it means for a filesystem to be "the same".


You understand that he didn't actually say that, right? This seems like 
your own personal bugaboo instead. 


While I'm sure this can be managed by explicitly setting UUIDs, I've
found it much more pleasant to manage explicit names (I personally
prefer LVM names over filesystem labels, but filesystem labels work well
for those filesystems I don't put under LVM).  Not only I can pronounce
them and they carry meaning, but they tend to be much more visible (and
hence easier to manipulate).


I dislike using names becaues it's *much* more common to find name 
collisions than UUID collisions. (E.g., a bunch of disks with 
filesystems all labeled with easy to remember names like "root" or 
"home".) Reboot with a couple of those in your system on a 
label-oriented configuration and you may have a very bad day. LVM is 
more resistant to that as long as you keep the vg names unique. (Call 
everything vg0 and you're back to having a bad day.)


On Tue, Feb 04, 2020 at 10:19:25PM -0500, Stefan Monnier wrote:

PS: The only problem with LVM names is that Linux doesn't let you
rename a volume group while it's active (at least last time I tried),
which makes it painful to rename the volume group in which lives your
root partition.

How painful is it to dd a live cd, boot from it and rename?


Very.  It's called "downtime".
Every time you have to reboot, it means your OS has somewhat failed you.


I'm trying to think of a reason to rename the root partition that 
doesn't involve downtime and coming up empty. 

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Curt]

>>> Me too, so I usually label the permanent stuff at least. UUID's can and
>>> will change for no detectable reason.
>> For those reading along or finding this in search results: no, filesystem
>> UUIDs don't change for no detectable reason. Don't implement anything based
>> on this theory.
>
> What he meant is that filesystem UUIDs are (re)created automatically

Your "analysis" appears to be more like what you want to mean than
what Gene was meaning.

> based on a heuristic of what it means for a filesystem to be "the same".

> This heuristic can be wrong in both directions: sometimes you delete and
>create a new filesystem which is supposed to "be" the same filesystem as

This seems like an eminently detectable reason for a UUID change to me.

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Stefan Monnier]

>> PS: The only problem with LVM names is that Linux doesn't let you
>> rename a volume group while it's active (at least last time I tried),
>> which makes it painful to rename the volume group in which lives your
>> root partition.
> How painful is it to dd a live cd, boot from it and rename?

Very.  It's called "downtime".
Every time you have to reboot, it means your OS has somewhat failed you.


Stefan

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[0...@caiway.net]

> PS: The only problem with LVM names is that Linux doesn't let you
> rename a volume group while it's active (at least last time I tried),
> which makes it painful to rename the volume group in which lives your
> root partition.
> 

How painful is it to dd a live cd, boot from it and rename?
3 minutes of pain, if that is what you want to call it?

Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

[Stefan Monnier]

>> Me too, so I usually label the permanent stuff at least. UUID's can and
>> will change for no detectable reason.
> For those reading along or finding this in search results: no, filesystem
> UUIDs don't change for no detectable reason. Don't implement anything based
> on this theory.

What he meant is that filesystem UUIDs are (re)created automatically
based on a heuristic of what it means for a filesystem to be "the same".

This heuristic can be wrong in both directions: sometimes you delete and
create a new filesystem which is supposed to "be" the same filesystem as
before (but gets a new UUID), and other times you copy a filesystem so
as to get "another one" (but it keeps its UUID).

While I'm sure this can be managed by explicitly setting UUIDs, I've
found it much more pleasant to manage explicit names (I personally
prefer LVM names over filesystem labels, but filesystem labels work well
for those filesystems I don't put under LVM).  Not only I can pronounce
them and they carry meaning, but they tend to be much more visible (and
hence easier to manipulate).


Stefan


PS: The only problem with LVM names is that Linux doesn't let you rename
a volume group while it's active (at least last time I tried), which
makes it painful to rename the volume group in which lives your root partition.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Tuesday 04 February 2020 15:03:54 David Wright wrote:

> On Tue 04 Feb 2020 at 11:48:10 (-0500), Gene Heskett wrote:
> > On Tuesday 04 February 2020 08:51:47 Stefan Monnier wrote:
> > > >> I bet some of his RT patches caused a mess
> > > >
> > > > Nope, I just needed to reboot.
> > >
> > > "Needed to reboot" in this context means "need to work around a
> > > bug". I have no idea whether that bug has anything to with the RT
> > > patches, but the fact that rebooting avoided the problem is at
> > > least no proof that the problem was not caused by the RT patches
> > > (nor the opposite).
> >
> > Uptime is as you point out, dependent on the kernel. One of my
> > machines at the farthest reaches of my local net, running wheezy and
> > a small metal lathe, copy paste from an ssh login:
> > gene@lathe:~$ uname -a
> > Linux lathe 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian
> > 3.4.55-4linuxcnc i686 GNU/Linux
> > gene@lathe:~$ uptime
> >  11:09:34 up 167 days, 14:06, 1 user, load average: 0.00, 0.01, 0.05
>
> [etc etc]
>
> No idea what uptime has to do with mounting a card.
>
> But I did wonder why you didn't just try mounting the card in one of
> your several machines.
>
All the others are outside of the house, meaning I'd have to dress for 
the weather.

> Cheers,
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[David Wright]

On Tue 04 Feb 2020 at 11:48:10 (-0500), Gene Heskett wrote:
> On Tuesday 04 February 2020 08:51:47 Stefan Monnier wrote:
> 
> > >> I bet some of his RT patches caused a mess
> > >
> > > Nope, I just needed to reboot.
> >
> > "Needed to reboot" in this context means "need to work around a bug".
> > I have no idea whether that bug has anything to with the RT patches,
> > but the fact that rebooting avoided the problem is at least no proof
> > that the problem was not caused by the RT patches (nor the opposite).
> >
> Uptime is as you point out, dependent on the kernel. One of my machines 
> at the farthest reaches of my local net, running wheezy and a small 
> metal lathe, copy paste from an ssh login:
> gene@lathe:~$ uname -a
> Linux lathe 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc 
> i686 GNU/Linux
> gene@lathe:~$ uptime
>  11:09:34 up 167 days, 14:06, 1 user, load average: 0.00, 0.01, 0.05

[etc etc]

No idea what uptime has to do with mounting a card.

But I did wonder why you didn't just try mounting the card in one of
your several machines.

Cheers,
David.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Tuesday 04 February 2020 08:51:47 Stefan Monnier wrote:

> >> I bet some of his RT patches caused a mess
> >
> > Nope, I just needed to reboot.
>
> "Needed to reboot" in this context means "need to work around a bug".
> I have no idea whether that bug has anything to with the RT patches,
> but the fact that rebooting avoided the problem is at least no proof
> that the problem was not caused by the RT patches (nor the opposite).
>
>
> Stefan
Uptime is as you point out, dependent on the kernel. One of my machines 
at the farthest reaches of my local net, running wheezy and a small 
metal lathe, copy paste from an ssh login:
gene@lathe:~$ uname -a
Linux lathe 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc 
i686 GNU/Linux
gene@lathe:~$ uptime
 11:09:34 up 167 days, 14:06, 1 user, load average: 0.00, 0.01, 0.05

And that machine hasn't a ups.

various other machines running newer stuff have shorter uptimes with a 
ups, this one running stretch:

gene@coyote:/media/sde1$ uname -a
Linux coyote 4.9.0-11-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.189-3+deb9u2 
(2019-11-11) x86_64 GNU/Linux

has never run more than about 30 days, with a ups, without developing an 
excuse to reboot it, in this present case 34 days. Timer wrap, whatever, 
its only good for about 30 days. The glaring exception to the newer= 
shorter uptmes is the rpi4 running one of my lathes, It now has a ups, 
and if I don't reboot it, it will run till the rapture.

One thing I don't do if I can help it, is spin down spinning rust, worst 
thing you every do short of a 30-06 thru it to a hard drive. I've an 
original seacrate 1T drive spinning in this machine with over 80,000 
spinning hours on it, still has the 25 reallocated sectors it had when I 
updated the firmwear in it when it was about 30 days old. I've had 2 
drives fail out of 9 here in the time since I jumped from amigados to 
linux in 1999. Skipped windows although I had to buy a cheap one last 
summer to use as a display for a redpitaya's vector network analyzer.  
I've replaced several because I outgrew them, but only 2 outright 
failures in 2 decades. I think thats pretty good. 

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Greg Wooledge]

On Tue, Feb 04, 2020 at 11:24:56AM -0500, Michael Stone wrote:
> On Tue, Feb 04, 2020 at 11:06:10AM -0500, Gene Heskett wrote:
> > Me too, so I usually label the permanent stuff at least. UUID's can and
> > will change for no detectable reason.
> 
> For those reading along or finding this in search results: no, filesystem
> UUIDs don't change for no detectable reason. Don't implement anything based
> on this theory.

I was just about to make a similar reply.  The only time a file system's
UUID changes is if you destroy and recreate the file system, or go out
of your way to change the UUID through some file-system-specific tool
like xfs_admin -U uuid.

But, labels are great.  If you like using labels, that's fantastic.  Keep
doing that.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Michael Stone]

On Tue, Feb 04, 2020 at 11:06:10AM -0500, Gene Heskett wrote:

Me too, so I usually label the permanent stuff at least. UUID's can and
will change for no detectable reason.


For those reading along or finding this in search results: no, 
filesystem UUIDs don't change for no detectable reason. Don't implement 
anything based on this theory.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Tuesday 04 February 2020 07:47:58 songbird wrote:

> Gene Heskett wrote:
> > On Monday 03 February 2020 23:56:47 David Wright wrote:
> >> Well, at least one of my guesses was correct.
> >>
> >:)
> >
> > FWIW, the reboot fixed the can't mount, both partitions on this sd
> > card now mount normally, but are on /dev/sde now since the were
> > found at bootup. I've had this happen before, back before the other
> > mobo caught fire.
>
>   that is why i always put a label on a file system and
> mount it using that in the fstab.
>
>   i hate how devices can change out from under you
> otherwise.  some people use the UUIDs but i don't like
> those or have enough devices where i want to use them.
> labels work very well for me.
>
Me too, so I usually label the permanent stuff at least. UUID's can and 
will change for no detectable reason. The only time a name changes is if 
the medium has become incontinent on its way to totally dying. But thats 
a SWAG, as I've never had it happen on my watch.

>   songbird


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[David Wright]

On Tue 04 Feb 2020 at 07:47:58 (-0500), songbird wrote:
> Gene Heskett wrote:
> > On Monday 03 February 2020 23:56:47 David Wright wrote:
> >
> >> Well, at least one of my guesses was correct.
> >
> >:)
> >
> > FWIW, the reboot fixed the can't mount, both partitions on this sd card 
> > now mount normally, but are on /dev/sde now since the were found at 
> > bootup. I've had this happen before, back before the other mobo caught 
> > fire.
> 
>   that is why i always put a label on a file system and
> mount it using that in the fstab.
> 
>   i hate how devices can change out from under you 
> otherwise.  some people use the UUIDs but i don't like 
> those or have enough devices where i want to use them.
> labels work very well for me.

You can also use any of the links in /dev/disk. For example, I have at
least one system that will only boot from a few favoured USB sticks,
so I use the same ones over for netinst i386 and netinst amd64.
However, the soft labelling on the sticks varies from release to
release, but the ID of each stick doesn't, so in /etc/fstab I use,
for example:

/dev/disk/by-id/usb-Generic_Flash_Disk_58F99DC1-0:0 /media/alsglobal2g iso9660 
ro,user,noauto

(The mount point is created by udev which spots that ID_SERIAL_SHORT=58F99DC1)

Cheers,
David.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[songbird]

Gene Heskett wrote:
> On Monday 03 February 2020 23:56:47 David Wright wrote:
>
>> Well, at least one of my guesses was correct.
>
>:)
>
> FWIW, the reboot fixed the can't mount, both partitions on this sd card 
> now mount normally, but are on /dev/sde now since the were found at 
> bootup. I've had this happen before, back before the other mobo caught 
> fire.

  that is why i always put a label on a file system and
mount it using that in the fstab.

  i hate how devices can change out from under you 
otherwise.  some people use the UUIDs but i don't like 
those or have enough devices where i want to use them.
labels work very well for me.


  songbird

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Stefan Monnier]

>> I bet some of his RT patches caused a mess
> Nope, I just needed to reboot.

"Needed to reboot" in this context means "need to work around a bug".
I have no idea whether that bug has anything to with the RT patches, but
the fact that rebooting avoided the problem is at least no proof that
the problem was not caused by the RT patches (nor the opposite).


Stefan

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Tuesday 04 February 2020 02:21:32 deloptes wrote:

> Dan Ritter wrote:
> > There's no FAT filesystem there. It might be corrupted, it might
> > actually be on /dev/sdf with a bogus partition table.
>
> I bet some of his RT patches caused a mess

Nope, I just needed to reboot.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[deloptes]

Dan Ritter wrote:

> There's no FAT filesystem there. It might be corrupted, it might
> actually be on /dev/sdf with a bogus partition table.

I bet some of his RT patches caused a mess

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Monday 03 February 2020 23:56:47 David Wright wrote:

> Well, at least one of my guesses was correct.

:)

FWIW, the reboot fixed the can't mount, both partitions on this sd card 
now mount normally, but are on /dev/sde now since the were found at 
bootup. I've had this happen before, back before the other mobo caught 
fire.

 > Any chance of responding 
> to more than one item at a time? Dan asked for a listing of the
> partition table, and I asked how the "device" was written. I might as
> well add the question: does the second partition fare any better on
> mounting?

Its fixed now, everything looks and works normal. Now to bring the rest 
of my network back up and get some utilities started.
>
> Cheers,
> David.

Shoulda rebooted 3 days ago. But now we wait about a month, for the first 
shoe to drop... My apologies for making several folks waste their time. 

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Monday 03 February 2020 23:56:47 David Wright wrote:

> On Mon 03 Feb 2020 at 16:20:59 (-0500), Gene Heskett wrote:
> > On Monday 03 February 2020 14:15:14 David Wright wrote:
> > > On Mon 03 Feb 2020 at 14:02:31 (-0500), Gene Heskett wrote:
> > > > On Monday 03 February 2020 13:31:16 David Wright wrote:
> > > > > On Mon 03 Feb 2020 at 12:40:20 (-0500), Gene Heskett wrote:
> > > > > > I want to look at its directory structure because its
> > > > > > different, and I'd like to deduce how to generate it in a
> > > > > > kernel make for a newer, preempt-rt kernel.
> > > > >
> > > > > Yes, I can't mount it either, because I'm not running stretch.
> > > >
> > > > And I am running stretch with a custom realtime kernel for
> > > > linuxcnc use.
> > > >
> > > > > > Thanks for any enlightenment.
> > > > >
> > > > > I've given my reason; can you give us yours, for our further
> > > > > enlightenment?
> > > >
> > > > gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1
> > > > /media/sdf1 mount: wrong fs type, bad option, bad superblock on
> > > > /dev/sdf1, missing codepage or helper program, or other error
> > > >
> > > >In some cases useful info is found in syslog - try
> > > >dmesg | tail or so.
> > > >
> > > > And dmesg says:
> > > > [2903524.766017] usb 1-12.4.1.3: new high-speed USB device
> > > > number 20 using xhci_hcd
> > > > [2903525.047017] usb 1-12.4.1.3: New USB device found,
> > > > idVendor=048d, idProduct=1336
> > > > [2903525.047027] usb 1-12.4.1.3: New USB device strings: Mfr=1,
> > > > Product=2, SerialNumber=3
> > > > [2903525.047033] usb 1-12.4.1.3: Product: Mass Storage Device
> > > > [2903525.047037] usb 1-12.4.1.3: Manufacturer: Generic
> > > > [2903525.047041] usb 1-12.4.1.3: SerialNumber: 06
> > > > [2903525.047961] usb-storage 1-12.4.1.3:1.0: USB Mass Storage
> > > > device detected
> > > > [2903525.052481] scsi host7: usb-storage 1-12.4.1.3:1.0
> > > > [2903526.760829] scsi 7:0:0:0: Direct-Access Generic 
> > > > Storage Device 0.00 PQ: 0 ANSI: 2
> > > > [2903526.798501] sd 7:0:0:0: Attached scsi generic sg6 type 0
> > > > [2903526.798879] sd 7:0:0:0: [sdf] 121319424 512-byte logical
> > > > blocks: (62.1 GB/57.8 GiB)
> > > > [2903526.799039] sd 7:0:0:0: [sdf] Write Protect is off
> > > > [2903526.799041] sd 7:0:0:0: [sdf] Mode Sense: 03 00 00 00
> > > > [2903526.799210] sd 7:0:0:0: [sdf] No Caching mode page found
> > > > [2903526.799211] sd 7:0:0:0: [sdf] Assuming drive cache: write
> > > > through [2903526.801588]  sdf: sdf1 sdf2
> > > > [2903526.803323] sd 7:0:0:0: [sdf] Attached SCSI removable disk
> > >
> > > I see there are two partitions, which is a little unusual for a
> > > USB stick. Are you by any chance trying to write a bootable stick?
> > > It might help to know how you wrote this stick, assuming you did.
> >
> > Stick?
>
> Well, here's a very similar log from a USB stick being inserted:
>
> [] usb 1-4: new high-speed USB device number 8 using xhci_hcd
> [] usb 1-4: New USB device found, idVendor=0c76, idProduct=0005,
> bcdDevice= 1.00 [] usb 1-4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3 [] usb 1-4: Product: DataTraveler 2.0
> [] usb 1-4: Manufacturer: Kingston
> [] usb 1-4: SerialNumber: 2731542023F1DE82
> [] usb-storage 1-4:1.0: USB Mass Storage device detected
> [] scsi host3: usb-storage 1-4:1.0
> [] scsi 3:0:0:0: Direct-Access Kingston DataTraveler 2.0 4.10 PQ:
> 0 ANSI: 2 [] sd 3:0:0:0: Attached scsi generic sg1 type 0
> [] sd 3:0:0:0: [sdb] 503808 512-byte logical blocks: (258 MB/246 MiB)
> [] sd 3:0:0:0: [sdb] Write Protect is off
> [] sd 3:0:0:0: [sdb] Mode Sense: 0b 00 00 08
> [] sd 3:0:0:0: [sdb] No Caching mode page found
> [] sd 3:0:0:0: [sdb] Assuming drive cache: write through
> []  sdb: sdb1
> [] sd 3:0:0:0: [sdb] Attached SCSI removable disk
>
> > Its a u-sd card
>
> Well, here's a very different log for a card:
>
> [] pciehp :00:1c.3:pcie004: Slot(3): Card present
> [] pciehp :00:1c.3:pcie004: Slot(3): Link Up
> [] pci :03:00.0: [10ec:5227] type 00 class 0xff
> [] pci :03:00.0: reg 0x10: [mem 0x-0x0fff]
> [] pci :03:00.0: supports D1 D2
> [] pci :03:00.0: PME# supported from D1 D2 D3hot D3cold
> [] pci :03:00.0: BAR 0: assigned [mem 0xb100-0xb1000fff]
> [] pcieport :00:1c.3: PCI bridge to [bus 03-08]
> [] pcieport :00:1c.3:   bridge window [io  0x3000-0x3fff]
> [] pcieport :00:1c.3:   bridge window [mem 0xb100-0xb1ff]
> [] pcieport :00:1c.3:   bridge window [mem 0xb000-0xb0ff
> 64bit pref] [] rtsx_pci :03:00.0: enabling device ( -> 0002)
> [] mmc0: cannot verify signal voltage switch
> [] mmc0: new ultra high speed SDR104 SDHC card at address 
> [] mmcblk0: mmc0: SE32G 29.7 GiB
> []  mmcblk0: p1
>
> So forgive my mistake. OTOH, here's exactly the same card:
>
> [] usb 2-2: new high-speed USB device number 7 using xhci_hcd
> [] usb 2-2: New USB device found, idVendor=0781, idProduct=a7a8,
> 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Monday 03 February 2020 21:34:46 songbird wrote:

> Gene Heskett wrote:
> > On Monday 03 February 2020 13:17:04 Dan Ritter wrote:
> >> Gene Heskett wrote:
> >> > Greetings all;
> >> >
> >> > I want to look at its directory structure because its different,
> >> > and I'd like to deduce how to generate it in a kernel make for a
> >> > newer, preempt-rt kernel.
> >>
> >> Actual error message, please.
> >
> > gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1
> > /media/sdf1
>
>   don't you need a space between -t and vfat?
>
Its always been optional, tried just now, same error.

> > mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
> >missing codepage or helper program, or other error
> >
> >In some cases useful info is found in syslog - try
> >dmesg | tail or so.
> >
> >> sudo parted -l
> >> sudo mkdir /mnt/tmp
> >> sudo mount /dev/sdf1 /mnt/tmp
> >>
> >> -dsr-
> >
> > Thanks Dan R.
> >
> > Cheers, Gene Heskett
>
>   songbird


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[David Wright]

On Mon 03 Feb 2020 at 16:20:59 (-0500), Gene Heskett wrote:
> On Monday 03 February 2020 14:15:14 David Wright wrote:
> > On Mon 03 Feb 2020 at 14:02:31 (-0500), Gene Heskett wrote:
> > > On Monday 03 February 2020 13:31:16 David Wright wrote:
> > > > On Mon 03 Feb 2020 at 12:40:20 (-0500), Gene Heskett wrote:
> > > > > I want to look at its directory structure because its different,
> > > > > and I'd like to deduce how to generate it in a kernel make for a
> > > > > newer, preempt-rt kernel.
> > > >
> > > > Yes, I can't mount it either, because I'm not running stretch.
> > >
> > > And I am running stretch with a custom realtime kernel for linuxcnc
> > > use.
> > >
> > > > > Thanks for any enlightenment.
> > > >
> > > > I've given my reason; can you give us yours, for our further
> > > > enlightenment?
> > >
> > > gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1
> > > /media/sdf1 mount: wrong fs type, bad option, bad superblock on
> > > /dev/sdf1, missing codepage or helper program, or other error
> > >
> > >In some cases useful info is found in syslog - try
> > >dmesg | tail or so.
> > >
> > > And dmesg says:
> > > [2903524.766017] usb 1-12.4.1.3: new high-speed USB device number 20
> > > using xhci_hcd
> > > [2903525.047017] usb 1-12.4.1.3: New USB device found,
> > > idVendor=048d, idProduct=1336
> > > [2903525.047027] usb 1-12.4.1.3: New USB device strings: Mfr=1,
> > > Product=2, SerialNumber=3
> > > [2903525.047033] usb 1-12.4.1.3: Product: Mass Storage Device
> > > [2903525.047037] usb 1-12.4.1.3: Manufacturer: Generic
> > > [2903525.047041] usb 1-12.4.1.3: SerialNumber: 06
> > > [2903525.047961] usb-storage 1-12.4.1.3:1.0: USB Mass Storage device
> > > detected
> > > [2903525.052481] scsi host7: usb-storage 1-12.4.1.3:1.0
> > > [2903526.760829] scsi 7:0:0:0: Direct-Access Generic  Storage
> > > Device 0.00 PQ: 0 ANSI: 2
> > > [2903526.798501] sd 7:0:0:0: Attached scsi generic sg6 type 0
> > > [2903526.798879] sd 7:0:0:0: [sdf] 121319424 512-byte logical
> > > blocks: (62.1 GB/57.8 GiB)
> > > [2903526.799039] sd 7:0:0:0: [sdf] Write Protect is off
> > > [2903526.799041] sd 7:0:0:0: [sdf] Mode Sense: 03 00 00 00
> > > [2903526.799210] sd 7:0:0:0: [sdf] No Caching mode page found
> > > [2903526.799211] sd 7:0:0:0: [sdf] Assuming drive cache: write
> > > through [2903526.801588]  sdf: sdf1 sdf2
> > > [2903526.803323] sd 7:0:0:0: [sdf] Attached SCSI removable disk
> >
> > I see there are two partitions, which is a little unusual for a USB
> > stick. Are you by any chance trying to write a bootable stick?
> > It might help to know how you wrote this stick, assuming you did.
> >
> 
> Stick?

Well, here's a very similar log from a USB stick being inserted:

[] usb 1-4: new high-speed USB device number 8 using xhci_hcd
[] usb 1-4: New USB device found, idVendor=0c76, idProduct=0005, bcdDevice= 1.00
[] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[] usb 1-4: Product: DataTraveler 2.0
[] usb 1-4: Manufacturer: Kingston
[] usb 1-4: SerialNumber: 2731542023F1DE82
[] usb-storage 1-4:1.0: USB Mass Storage device detected
[] scsi host3: usb-storage 1-4:1.0
[] scsi 3:0:0:0: Direct-Access Kingston DataTraveler 2.0 4.10 PQ: 0 ANSI: 2
[] sd 3:0:0:0: Attached scsi generic sg1 type 0
[] sd 3:0:0:0: [sdb] 503808 512-byte logical blocks: (258 MB/246 MiB)
[] sd 3:0:0:0: [sdb] Write Protect is off
[] sd 3:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[] sd 3:0:0:0: [sdb] No Caching mode page found
[] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[]  sdb: sdb1
[] sd 3:0:0:0: [sdb] Attached SCSI removable disk

> Its a u-sd card

Well, here's a very different log for a card:

[] pciehp :00:1c.3:pcie004: Slot(3): Card present
[] pciehp :00:1c.3:pcie004: Slot(3): Link Up
[] pci :03:00.0: [10ec:5227] type 00 class 0xff
[] pci :03:00.0: reg 0x10: [mem 0x-0x0fff]
[] pci :03:00.0: supports D1 D2
[] pci :03:00.0: PME# supported from D1 D2 D3hot D3cold
[] pci :03:00.0: BAR 0: assigned [mem 0xb100-0xb1000fff]
[] pcieport :00:1c.3: PCI bridge to [bus 03-08]
[] pcieport :00:1c.3:   bridge window [io  0x3000-0x3fff]
[] pcieport :00:1c.3:   bridge window [mem 0xb100-0xb1ff]
[] pcieport :00:1c.3:   bridge window [mem 0xb000-0xb0ff 64bit pref]
[] rtsx_pci :03:00.0: enabling device ( -> 0002)
[] mmc0: cannot verify signal voltage switch
[] mmc0: new ultra high speed SDR104 SDHC card at address 
[] mmcblk0: mmc0: SE32G 29.7 GiB 
[]  mmcblk0: p1

So forgive my mistake. OTOH, here's exactly the same card:

[] usb 2-2: new high-speed USB device number 7 using xhci_hcd
[] usb 2-2: New USB device found, idVendor=0781, idProduct=a7a8, bcdDevice= 1.27
[] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[] usb 2-2: Product: SDDR-113
[] usb 2-2: Manufacturer: SanDisk Corp.
[] usb 2-2: SerialNumber: 633301B1
[] usb-storage 2-2:1.0: USB Mass Storage device detected
[] 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[songbird]

Gene Heskett wrote:
> On Monday 03 February 2020 13:17:04 Dan Ritter wrote:
>
>> Gene Heskett wrote:
>> > Greetings all;
>> >
>> > I want to look at its directory structure because its different, and
>> > I'd like to deduce how to generate it in a kernel make for a newer,
>> > preempt-rt kernel.
>>
>> Actual error message, please.
> gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1 /media/sdf1

  don't you need a space between -t and vfat?


> mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
>missing codepage or helper program, or other error
>
>In some cases useful info is found in syslog - try
>dmesg | tail or so.
>
>>
>> sudo parted -l
>> sudo mkdir /mnt/tmp
>> sudo mount /dev/sdf1 /mnt/tmp
>>
>> -dsr-
>
> Thanks Dan R.
>
> Cheers, Gene Heskett


  songbird

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Dan Ritter]

Gene Heskett wrote: 
> On Monday 03 February 2020 14:07:46 David Wright wrote:
> 
> > On Mon 03 Feb 2020 at 13:57:08 (-0500), Gene Heskett wrote:
> > > On Monday 03 February 2020 13:17:04 Dan Ritter wrote:
> > > > Actual error message, please.
> > >
> > > gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1
> > > /media/sdf1 mount: wrong fs type, bad option, bad superblock on
> > > /dev/sdf1, missing codepage or helper program, or other error
> > >
> > >In some cases useful info is found in syslog - try
> > >dmesg | tail or so.
> >
> > What happens if you leave out the type option?
> 
> from dmesg:
> 2903654.091619] FAT-fs (sdf1): bogus number of reserved sectors
> [2903654.091622] FAT-fs (sdf1): Can't find a valid FAT filesystem

> [2911401.900020] FAT-fs (sdf1): invalid media value (0x00)
> [2911401.900031] FAT-fs (sdf1): Can't find a valid FAT filesystem
> 
> 
> I duuno what to make of that!

There's no FAT filesystem there. It might be corrupted, it might
actually be on /dev/sdf with a bogus partition table.

-dsr-

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Monday 03 February 2020 14:15:14 David Wright wrote:

> On Mon 03 Feb 2020 at 14:02:31 (-0500), Gene Heskett wrote:
> > On Monday 03 February 2020 13:31:16 David Wright wrote:
> > > On Mon 03 Feb 2020 at 12:40:20 (-0500), Gene Heskett wrote:
> > > > I want to look at its directory structure because its different,
> > > > and I'd like to deduce how to generate it in a kernel make for a
> > > > newer, preempt-rt kernel.
> > >
> > > Yes, I can't mount it either, because I'm not running stretch.
> >
> > And I am running stretch with a custom realtime kernel for linuxcnc
> > use.
> >
> > > > Thanks for any enlightenment.
> > >
> > > I've given my reason; can you give us yours, for our further
> > > enlightenment?
> >
> > gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1
> > /media/sdf1 mount: wrong fs type, bad option, bad superblock on
> > /dev/sdf1, missing codepage or helper program, or other error
> >
> >In some cases useful info is found in syslog - try
> >dmesg | tail or so.
> >
> > And dmesg says:
> > [2903524.766017] usb 1-12.4.1.3: new high-speed USB device number 20
> > using xhci_hcd
> > [2903525.047017] usb 1-12.4.1.3: New USB device found,
> > idVendor=048d, idProduct=1336
> > [2903525.047027] usb 1-12.4.1.3: New USB device strings: Mfr=1,
> > Product=2, SerialNumber=3
> > [2903525.047033] usb 1-12.4.1.3: Product: Mass Storage Device
> > [2903525.047037] usb 1-12.4.1.3: Manufacturer: Generic
> > [2903525.047041] usb 1-12.4.1.3: SerialNumber: 06
> > [2903525.047961] usb-storage 1-12.4.1.3:1.0: USB Mass Storage device
> > detected
> > [2903525.052481] scsi host7: usb-storage 1-12.4.1.3:1.0
> > [2903526.760829] scsi 7:0:0:0: Direct-Access Generic  Storage
> > Device 0.00 PQ: 0 ANSI: 2
> > [2903526.798501] sd 7:0:0:0: Attached scsi generic sg6 type 0
> > [2903526.798879] sd 7:0:0:0: [sdf] 121319424 512-byte logical
> > blocks: (62.1 GB/57.8 GiB)
> > [2903526.799039] sd 7:0:0:0: [sdf] Write Protect is off
> > [2903526.799041] sd 7:0:0:0: [sdf] Mode Sense: 03 00 00 00
> > [2903526.799210] sd 7:0:0:0: [sdf] No Caching mode page found
> > [2903526.799211] sd 7:0:0:0: [sdf] Assuming drive cache: write
> > through [2903526.801588]  sdf: sdf1 sdf2
> > [2903526.803323] sd 7:0:0:0: [sdf] Attached SCSI removable disk
>
> I see there are two partitions, which is a little unusual for a USB
> stick. Are you by any chance trying to write a bootable stick?
> It might help to know how you wrote this stick, assuming you did.
>

Stick?  Its a u-sd card to boot an rpi4 with.

> Cheers,
> David.


Cheers David, 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Monday 03 February 2020 14:07:46 David Wright wrote:

> On Mon 03 Feb 2020 at 13:57:08 (-0500), Gene Heskett wrote:
> > On Monday 03 February 2020 13:17:04 Dan Ritter wrote:
> > > Actual error message, please.
> >
> > gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1
> > /media/sdf1 mount: wrong fs type, bad option, bad superblock on
> > /dev/sdf1, missing codepage or helper program, or other error
> >
> >In some cases useful info is found in syslog - try
> >dmesg | tail or so.
>
> What happens if you leave out the type option?

from dmesg:
2903654.091619] FAT-fs (sdf1): bogus number of reserved sectors
[2903654.091622] FAT-fs (sdf1): Can't find a valid FAT filesystem
[2904108.303894] INFO: task systemd-udevd:31796 blocked for more than 120 
seconds.
[2904108.303905]   Not tainted 4.9.0-11-rt-amd64 #1 Debian 
4.9.189-3+deb9u2
[2904108.303910] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[2904108.303915] systemd-udevd   D0 31796  1 0x0120
[2904108.303926]  0086 9d357affc800  
9d37ae4e9a00
[2904108.303938]  9d371a884100 9d37a84a8000 bbc3089ffa98 
8963b355
[2904108.303950]  00ffbbc3089ffb70 9d37ae4e9a00 890a9ef1 
9d371a884100
[2904108.303961] Call Trace:
[2904108.303975]  [] ? __schedule+0x275/0x5d0
[2904108.303982]  [] ? __raw_spin_unlock+0x11/0x50
[2904108.303988]  [] ? schedule+0x43/0xd0
[2904108.303995]  [] ? __rt_mutex_slowlock+0xb8/0x140
[2904108.304002]  [] ? 
rt_mutex_slowlock_locked+0xbb/0x220
[2904108.304008]  [] ? rt_mutex_slowlock+0x75/0xc0
[2904108.304018]  [] ? __blkdev_get+0x6a/0x470
[2904108.304024]  [] ? blkdev_get+0x120/0x340
[2904108.304031]  [] ? unpin_current_cpu+0x12/0x70
[2904108.304037]  [] ? migrate_enable+0x1d0/0x310
[2904108.304043]  [] ? migrate_disable+0x84/0xe0
[2904108.304049]  [] ? blkdev_get_by_dev+0x40/0x40
[2904108.304057]  [] ? do_dentry_open+0x234/0x340
[2904108.304063]  [] ? path_openat+0x77a/0x15b0
[2904108.304069]  [] ? vsnprintf+0xf3/0x4f0
[2904108.304076]  [] ? do_filp_open+0x91/0x100
[2904108.304084]  [] ? unpin_current_cpu+0x12/0x70
[2904108.304089]  [] ? migrate_enable+0x1d0/0x310
[2904108.304098]  [] ? do_sys_open+0x12e/0x210
[2904108.304106]  [] ? do_syscall_64+0x75/0x110
[2904108.304114]  [] ? 
entry_SYSCALL_64_after_swapgs+0x58/0xc6
[2911401.900020] FAT-fs (sdf1): invalid media value (0x00)
[2911401.900031] FAT-fs (sdf1): Can't find a valid FAT filesystem

> Cheers,
> David.

I duuno what to make of that!

Thanks 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[David Wright]

On Mon 03 Feb 2020 at 14:02:31 (-0500), Gene Heskett wrote:
> On Monday 03 February 2020 13:31:16 David Wright wrote:
> > On Mon 03 Feb 2020 at 12:40:20 (-0500), Gene Heskett wrote:
> > > I want to look at its directory structure because its different, and
> > > I'd like to deduce how to generate it in a kernel make for a newer,
> > > preempt-rt kernel.
> >
> > Yes, I can't mount it either, because I'm not running stretch.
> 
> And I am running stretch with a custom realtime kernel for linuxcnc use. 
> >
> > > Thanks for any enlightenment.
> >
> > I've given my reason; can you give us yours, for our further
> > enlightenment?
> >
> gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1 /media/sdf1
> mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
>missing codepage or helper program, or other error
> 
>In some cases useful info is found in syslog - try
>dmesg | tail or so.
> 
> And dmesg says:
> [2903524.766017] usb 1-12.4.1.3: new high-speed USB device number 20 
> using xhci_hcd
> [2903525.047017] usb 1-12.4.1.3: New USB device found, idVendor=048d, 
> idProduct=1336
> [2903525.047027] usb 1-12.4.1.3: New USB device strings: Mfr=1, 
> Product=2, SerialNumber=3
> [2903525.047033] usb 1-12.4.1.3: Product: Mass Storage Device
> [2903525.047037] usb 1-12.4.1.3: Manufacturer: Generic
> [2903525.047041] usb 1-12.4.1.3: SerialNumber: 06
> [2903525.047961] usb-storage 1-12.4.1.3:1.0: USB Mass Storage device 
> detected
> [2903525.052481] scsi host7: usb-storage 1-12.4.1.3:1.0
> [2903526.760829] scsi 7:0:0:0: Direct-Access Generic  Storage Device   
> 0.00 PQ: 0 ANSI: 2
> [2903526.798501] sd 7:0:0:0: Attached scsi generic sg6 type 0
> [2903526.798879] sd 7:0:0:0: [sdf] 121319424 512-byte logical blocks: 
> (62.1 GB/57.8 GiB)
> [2903526.799039] sd 7:0:0:0: [sdf] Write Protect is off
> [2903526.799041] sd 7:0:0:0: [sdf] Mode Sense: 03 00 00 00
> [2903526.799210] sd 7:0:0:0: [sdf] No Caching mode page found
> [2903526.799211] sd 7:0:0:0: [sdf] Assuming drive cache: write through
> [2903526.801588]  sdf: sdf1 sdf2
> [2903526.803323] sd 7:0:0:0: [sdf] Attached SCSI removable disk

I see there are two partitions, which is a little unusual for a USB
stick. Are you by any chance trying to write a bootable stick?
It might help to know how you wrote this stick, assuming you did.

Cheers,
David.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[David Wright]

On Mon 03 Feb 2020 at 13:57:08 (-0500), Gene Heskett wrote:
> On Monday 03 February 2020 13:17:04 Dan Ritter wrote:
> > Actual error message, please.
> gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1 /media/sdf1
> mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
>missing codepage or helper program, or other error
> 
>In some cases useful info is found in syslog - try
>dmesg | tail or so.

What happens if you leave out the type option?

> > sudo parted -l
> > sudo mkdir /mnt/tmp
> > sudo mount /dev/sdf1 /mnt/tmp

Cheers,
David.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Monday 03 February 2020 13:31:16 David Wright wrote:

> On Mon 03 Feb 2020 at 12:40:20 (-0500), Gene Heskett wrote:
> > I want to look at its directory structure because its different, and
> > I'd like to deduce how to generate it in a kernel make for a newer,
> > preempt-rt kernel.
>
> Yes, I can't mount it either, because I'm not running stretch.

And I am running stretch with a custom realtime kernel for linuxcnc use. 
>
> > Thanks for any enlightenment.
>
> I've given my reason; can you give us yours, for our further
> enlightenment?
>
gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1 /media/sdf1
mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

And dmesg says:
[2903524.766017] usb 1-12.4.1.3: new high-speed USB device number 20 
using xhci_hcd
[2903525.047017] usb 1-12.4.1.3: New USB device found, idVendor=048d, 
idProduct=1336
[2903525.047027] usb 1-12.4.1.3: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
[2903525.047033] usb 1-12.4.1.3: Product: Mass Storage Device
[2903525.047037] usb 1-12.4.1.3: Manufacturer: Generic
[2903525.047041] usb 1-12.4.1.3: SerialNumber: 06
[2903525.047961] usb-storage 1-12.4.1.3:1.0: USB Mass Storage device 
detected
[2903525.052481] scsi host7: usb-storage 1-12.4.1.3:1.0
[2903526.760829] scsi 7:0:0:0: Direct-Access Generic  Storage Device   
0.00 PQ: 0 ANSI: 2
[2903526.798501] sd 7:0:0:0: Attached scsi generic sg6 type 0
[2903526.798879] sd 7:0:0:0: [sdf] 121319424 512-byte logical blocks: 
(62.1 GB/57.8 GiB)
[2903526.799039] sd 7:0:0:0: [sdf] Write Protect is off
[2903526.799041] sd 7:0:0:0: [sdf] Mode Sense: 03 00 00 00
[2903526.799210] sd 7:0:0:0: [sdf] No Caching mode page found
[2903526.799211] sd 7:0:0:0: [sdf] Assuming drive cache: write through
[2903526.801588]  sdf: sdf1 sdf2
[2903526.803323] sd 7:0:0:0: [sdf] Attached SCSI removable disk

> Cheers,
> David.
Thanks 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Gene Heskett]

On Monday 03 February 2020 13:17:04 Dan Ritter wrote:

> Gene Heskett wrote:
> > Greetings all;
> >
> > I want to look at its directory structure because its different, and
> > I'd like to deduce how to generate it in a kernel make for a newer,
> > preempt-rt kernel.
>
> Actual error message, please.
gene@coyote:~/PublicA/pi-buster$ sudo mount -tvfat /dev/sdf1 /media/sdf1
mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

>
> sudo parted -l
> sudo mkdir /mnt/tmp
> sudo mount /dev/sdf1 /mnt/tmp
>
> -dsr-

Thanks Dan R.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: can't mount sdf1 in stretch, gparted claims its fat32

[David Wright]

On Mon 03 Feb 2020 at 12:40:20 (-0500), Gene Heskett wrote:
> 
> I want to look at its directory structure because its different, and I'd 
> like to deduce how to generate it in a kernel make for a newer, 
> preempt-rt kernel.

Yes, I can't mount it either, because I'm not running stretch.

> Thanks for any enlightenment.

I've given my reason; can you give us yours, for our further enlightenment?

Cheers,
David.

Re: can't mount sdf1 in stretch, gparted claims its fat32

[Dan Ritter]

Gene Heskett wrote: 
> Greetings all;
> 
> I want to look at its directory structure because its different, and I'd 
> like to deduce how to generate it in a kernel make for a newer, 
> preempt-rt kernel.

Actual error message, please.

sudo parted -l
sudo mkdir /mnt/tmp
sudo mount /dev/sdf1 /mnt/tmp

-dsr-