>> 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.
>
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
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,
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,
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
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
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!
> 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
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
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
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
>>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
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.
>>> 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.
>
>
>> 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?
> 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
>> 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
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.
> > >
> > >
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".
> >
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
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
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.
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
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
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
>> 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
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
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
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
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
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
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
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.
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
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
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
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
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,
>
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
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,
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.
>
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
42 matches
Mail list logo
