On Mon, 21 Oct 2019, Ben Koenig wrote:
The device node (sdc or sdd) only changes when devices are removed and
attached by the kernel. Intermittent connections caused by a failing
cable, port, or host controller can result in the some really weird stuff
happening. If I was physically present for
I regret my misunderstanding - My assumption was - if you use "partition uuid"
to mount the partition - you do not need to care about /dev/sd* because your
drive is reliably mounted to the mount point.
Naturally - using partition uuid to mount something - implies that you remove
any other
On 10/21/19 8:54 AM, Rich Shepard wrote:
On Mon, 21 Oct 2019, Ben Koenig wrote:
Your fstab config is fine. Nothing in the mount process should
trigger changes in the device node. At this point you need to
physically disconnect the drive and reboot the computer.
Ben,
Here's what
On Mon, 21 Oct 2019, Ben Koenig wrote:
Your fstab config is fine. Nothing in the mount process should trigger
changes in the device node. At this point you need to physically disconnect
the drive and reboot the computer.
Ben,
Here's what /var/log/messages shows (this is the most recent of
On 10/21/19 8:10 AM, Rich Shepard wrote:
On Mon, 21 Oct 2019, Tomas Kuchta wrote:
In one of the weekend posts you learned how to obtain disk and partition
uuid - is there any technical reason to not use uuid to mount your
external
drive?
No. That's why I use it.
I'm trying to say this
On 10/21/19 6:20 AM, Rich Shepard wrote:
On Mon, 21 Oct 2019, Rich Shepard wrote:
Got this fixed!
I wrote too quickly. It's still flipping from the initial /dev/sdc1 to
/dev/sdd1 as it sat there mounted and I responded to your message.
Any thoughts on where I should now look? It must be
In one of the weekend posts you learned how to obtain disk and partition
uuid - is there any technical reason to not use uuid to mount your external
drive?
Uuids definitely do not change unless you change it intentionally.
I do not want to sound weary, but this topic repeats on this list
On Mon, 21 Oct 2019, Rich Shepard wrote:
Got this fixed!
I wrote too quickly. It's still flipping from the initial /dev/sdc1 to
/dev/sdd1 as it sat there mounted and I responded to your message.
Any thoughts on where I should now look? It must be related to the fstab
entry:
On Sun, 20 Oct 2019, Ben Koenig wrote:
Wow. ok. Mounting a drive isn't supposed to change the device node. You
can mount/unmount drives all day long and as along as you don't add
additional devices it should stay the same. My guess is that something is
lingering around in the driver stack. If
Wow. ok. Mounting a drive isn't supposed to change the device node. You can
mount/unmount drives all day long and as along as you don't add additional
devices it should stay the same. My guess is that something is lingering
around in the driver stack. If you can, reboot the computer with the drive
On Sun, 20 Oct 2019, Ben Koenig wrote:
It sounds like this system is having issues mounting that USB device. In
your previous message you mentioned that it worked, so it sounds like its
losing track of something.
Ben,
The issue seems to be the device mount changing from /dev/sdc1 to
Well first of all dirvish is probably just erroring out because it can't
find a file somewhere in /mnt/backup. I know this from your ls command, it
gave an error when you tried to view the contents of your backup directory.
This probably isn't a dirvish problem so we can set it aside for a bit.
On Sun, 20 Oct 2019, Ben Koenig wrote:
Ah I was about to ask about that. One of the things that trips me up about
manual edits in /etc/fstab is that if you make a change to a drive that is
already mounted, it doesn't automatically re-mount it with the new
parameters.
Does dirvish work now?
Ah I was about to ask about that. One of the things that trips me up about
manual edits in /etc/fstab is that if you make a change to a drive that is
already mounted, it doesn't automatically re-mount it with the new
parameters.
Does dirvish work now?
On Sun, Oct 20, 2019 at 11:49 AM Rich
On Sun, 20 Oct 2019, Rich Shepard wrote:
Ah, something got screwed up again.
Yep. Somehow mount got confused.
Unmounting /mnt/backup, checking with 'fdisk -l', and remounting /mnt/backup
cleared that up:
[root@salmo ~]# ls /mnt/backup/
lost+found/ salmo-data/ salmo-home/ salmo-opt/
On Sun, 20 Oct 2019, Ben Koenig wrote:
The error you are getting is for dirvish, not mount so I wonder if your
fstab is correct, but dirvish is upset about something. Make sure that the
partition is mounted through non-dirvish means to verify that your fstab
file is accurate.
Ben,
Yes, it's
The error you are getting is for dirvish, not mount so I wonder if your
fstab is correct, but dirvish is upset about something. Make sure that the
partition is mounted through non-dirvish means to verify that your fstab
file is accurate.
run mount ( with no arguments) or ls the contents of
On Sun, 20 Oct 2019, Rich Shepard wrote:
└─sdb3 093ae060-fd8d-48d2-9f77-acc5dab0fc56
sdc
└─sdc1 6e95864b-6291-4148-acd3-627542c8318f
sr0
Corrected.
Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
On Sat, 19 Oct 2019, Ben Koenig wrote:
you want the UUID, not the PARTUUID. A simpler way to get this info
quickly would be to use 'lsblk -o name,uuid' so that you can avoid the
extra information.
Ben,
I had tried the disk UUID and the partition UUID. None worked.
How do you have this
you want the UUID, not the PARTUUID. A simpler way to get this info quickly
would be to use 'lsblk -o name,uuid' so that you can avoid the extra
information.
How do you have this declared in fstab?
On Sat, Oct 19, 2019 at 3:25 PM Rich Shepard
wrote:
> On Sat, 19 Oct 2019, Rich Shepard wrote:
On Sat, 19 Oct 2019, Rich Shepard wrote:
The UUID for that external drive is:
985E2846-9500-4C25-844C-05B6806381E5
Now I'm totally confused. The UUID for that drive depends on how I ask for
it:
fdisk -l:
Disk /dev/sdc: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 *
21 matches
Mail list logo
