Re: backb losing its mount point
Sharon Kimble wrote: > Thanks for replying Darac. ... >> It might be helpful to see the relevant lines from your /etc/fstab. >> > - --8<--- current fstab ---start->8--- > /dev/sda2 /mnt/backb ext4defaults,nofail,x-gvfs-show 0 > 2 > /dev/sdb2 /mnt/backa ext4defaults,nofail,x-gvfs-show 0 2 > - --8<---cut here---end--->8--- > > because the system originally showed this > > - --8<--- original fstab ---start->8--- > /dev/sda2 /mnt/backa ext4defaults,nofail,x-gvfs-show 0 > 2 > /dev/sdb2 /mnt/backb ext4defaults,nofail,x-gvfs-show 0 2 > - --8<---cut here---end--->8--- > > but for some reason it mounted backb on /dev/sda2 so to regain access I > changed it to what is currently showing in fstab. um, that is a prime example of why UUIDs or LABELS should be used instead of what you have there because /dev/sdXY names can change after a reboot or a device gets disconnected and reconnected. ... you can use blkid to give you the UUID and if you've given the partition/filesystem a LABEL it will also report that. update your fstab to use either of those. songbird
Re: backb losing its mount point
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Darac Marjal writes: > On 31/03/2021 09:32, Sharon Kimble wrote: >> >> I'm hoping that you folks can help me with a problem that is now >> happening reasonably regularly, actually twice. >> >> I have 2 data drives on my system /mnt/backa and /mnt/backb. Both are >> 4tb drives, with backa being 2.74tb and backb 2.81tb. > > It might be helpful to see the relevant lines from your /etc/fstab. > > >> >> Backb is now regularly losing its mount point when I reboot, meaning >> that only backa is mounted, and backb holds my restic backup. >> >> To regain access to backb I'm having to 'sudo e2fsck -y -b 32768 >> /dev/sdc2' which rebuilds the mount point such that I can mount it on >> reboot, as backb. > > Firstly, it's usually better to run the "fsck" frontend, which will > determine which filesystem you've got and run the appropriate backend, > but I can see that you're passing advanced parameters here, so jumping > straight to e2fsck isn't that unusual. > > Secondly, you're specifying "-b 32768" which is telling fsck to use a > secondary superblock. Why is this? Generally, the primary superblock > should be "good enough" to repair a filesystem. The man page does state > that the primary superblock *should* be updated after the fixes are > complete, so this shouldn't be necessary. So, why are you having to use > a secondary superblock? Do you know what's wrong with the primary one? > > >> >> So how do I stop it happening again please? And what is the cause of it >> all? Should I physically unmount the drives before rebooting? > > The answers you seek should already be logged somewhere. Try the following: > > $ journalctl -b -u mnt-backb.mount # > This will show output from > attempts to mount /mnt/backb since the current bootup > > $ journalctl -b -g sdc2 # This will grep > the journal for all messages containing "sdc2" since the current bootup > Following on from my previous posting - - --8<---cut here---start->8--- sudo journalctl -b -g sdc2 [sudo] password for boudiccas: - -- Journal begins at Thu 2021-02-18 12:51:54 GMT, ends at Wed 2021-03-31 12:31:04 BST. -- Mar 31 08:21:47 london kernel: sdc: sdc1 sdc2 sdc3 sdc4 sdc5 sdc6 sdc7 Mar 31 12:29:51 london sudo[323326]: boudiccas : TTY=pts/28 ; PWD=/home/boudiccas ; USER=root ; COMMAND=/usr/bin/journalctl -b -g sdc2 Mar 31 12:31:04 london sudo[437870]: boudiccas : TTY=pts/30 ; PWD=/home/boudiccas/.emacs.d/org ; USER=root ; COMMAND=/usr/bin/journalctl -b -g sdc2 - --8<---cut here---end--->8--- and also - --8<---cut here---start->8--- sudo journalctl -b -u /mnt/backb.mount - -- Journal begins at Thu 2021-02-18 12:51:54 GMT, ends at Wed 2021-03-31 12:31:50 BST. -- - -- No entries -- - --8<---cut here---end--->8--- and - --8<---cut here---start->8--- sudo journalctl -b -u mnt-backb.mount - -- Journal begins at Thu 2021-02-18 12:51:54 GMT, ends at Wed 2021-03-31 12:36:23 BST. -- Mar 31 08:21:54 london systemd[1]: Mounting /mnt/backb... Mar 31 08:21:54 london systemd[1]: Mounted /mnt/backb. - --8<---cut here---end--->8--- Thanks Sharon. - -- Debian 10.9, fluxbox 1.3.7, emacs 28.0.50, org 9.4.5 -BEGIN PGP SIGNATURE- iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmBkXvQbHGJvdWRpY2Nh c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbofUP/iFtIe+2LZhZC3oc5i3W YV2RrbSBvTBdKfe64hU80cjEVUxErEqLmUGTKiQOFDlQ8ZHX2hJpNSK9XE3P0e3W vBComrmnkauK6KTxRrUeC+rDE///g5NjRC9zz/l3b9+EmUQ8YM/3Ty68dZAumZzl MlqYjgx/30GDu45YHj2wW8zbUGUxqJOv5eXwU8Hf8/aEs9awyJbfg7iYFXVMh4OQ WO9NJC6uafpPLNilbY6HjxPqjeFQiVKVfHMN9uYCJSA6ticCc9e0Zn1m0e+MFOu7 n82quc94NLk3BswUvNjqBlIBPvX5MNmoGJ0SF9NhDCp1YJpdW5Xc96B7QuE4NFZl a6Kfa5Khx/y3ESShG0MAO/kNOadRw4Ljc05h3YJI2U50vB9Yw9yew3lYBRlGWfOR ZSWUXyJM7dR9cQNfwhPEHlAEPOzoT45xnG0rZKNwjQHnCSmjjrheSFwpT9TyJNHr 4Me0bVa86L3trjooPbZQJFndhU0NvyKViJ0wQWGFsemE1DRxBu0x19nfcQtfBMip 57PzawFX2RL/oHyWQVnm+MqupnjqUwiKxMctl2aD6HEal8G3TXJfmyXjj9QV6aDB zRRpZvmSibN05/ByJsdnqPAorjwR+MTrptfgyYHUwMhsH2S3+cJHWtjULi6EsIdS Hme93jkQZENDw0u9Qt/0woMa =T1eN -END PGP SIGNATURE-
Re: backb losing its mount point
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Darac Marjal writes: Thanks for replying Darac. > On 31/03/2021 09:32, Sharon Kimble wrote: >> >> I'm hoping that you folks can help me with a problem that is now >> happening reasonably regularly, actually twice. >> >> I have 2 data drives on my system /mnt/backa and /mnt/backb. Both are >> 4tb drives, with backa being 2.74tb and backb 2.81tb. > > It might be helpful to see the relevant lines from your /etc/fstab. > - --8<--- current fstab ---start->8--- /dev/sda2 /mnt/backb ext4defaults,nofail,x-gvfs-show 0 2 /dev/sdb2 /mnt/backa ext4defaults,nofail,x-gvfs-show 0 2 - --8<---cut here---end--->8--- because the system originally showed this - --8<--- original fstab ---start->8--- /dev/sda2 /mnt/backa ext4defaults,nofail,x-gvfs-show 0 2 /dev/sdb2 /mnt/backb ext4defaults,nofail,x-gvfs-show 0 2 - --8<---cut here---end--->8--- but for some reason it mounted backb on /dev/sda2 so to regain access I changed it to what is currently showing in fstab. > >> >> Backb is now regularly losing its mount point when I reboot, meaning >> that only backa is mounted, and backb holds my restic backup. >> >> To regain access to backb I'm having to 'sudo e2fsck -y -b 32768 >> /dev/sdc2' which rebuilds the mount point such that I can mount it on >> reboot, as backb. > > Firstly, it's usually better to run the "fsck" frontend, which will > determine which filesystem you've got and run the appropriate backend, > but I can see that you're passing advanced parameters here, so jumping > straight to e2fsck isn't that unusual. > > Secondly, you're specifying "-b 32768" which is telling fsck to use a > secondary superblock. Why is this? Generally, the primary superblock > should be "good enough" to repair a filesystem. The man page does state > that the primary superblock *should* be updated after the fixes are > complete, so this shouldn't be necessary. So, why are you having to use > a secondary superblock? Do you know what's wrong with the primary one? > When the problem originally occurred this is what i did - --8<---cut here---start->8--- 2184 2021-03-18 13:32:51 sudo mount /mnt/backb 2185 2021-03-18 13:39:33 mount 2186 2021-03-18 13:43:32 fdisk -l 2187 2021-03-18 13:43:46 sudo fdisk -l 2188 2021-03-18 13:48:05 sudo lshw 2189 2021-03-18 13:54:04 sudo fdisk /dev/sdc 2192 2021-03-18 14:10:04 sudo mount /mnt/backb 2193 2021-03-18 14:11:58 sudo fsck /mnt/backb 2194 2021-03-18 14:12:48 sudo e2fsck -b 32768 /mnt/backb 2195 2021-03-18 14:13:10 sudo e2fsck -b 32768 /dev/sdc 2196 2021-03-18 14:13:58 sudo e2fsck -b 8193 /dev/sdc 2197 2021-03-18 14:18:46 sudo mke2fs -n /dev/sdc2 2198 2021-03-18 14:19:16 sudo mke4fs -n /dev/sdc2 2199 2021-03-18 14:19:54 sudo mke2fs -n /dev/sdc2 2202 2021-03-18 14:02:17 glances 2203 2021-03-18 14:19:33 man mke2fs 2204 2021-03-18 13:54:51 sudo fdisk /dev/sdc2 2205 2021-03-18 13:31:11 sudo gparted 2210 2021-03-18 14:32:49 sudo mke2fs -n /dev/sdc2 2211 2021-03-18 14:34:32 sudo e2fsck 2212 2021-03-18 14:35:14 sudo e2fsck p 2213 2021-03-18 14:35:31 sudo e2fsck /dev/sdc -p 2214 2021-03-18 14:29:51 sudo gparted 2215 2021-03-18 14:36:28 sudo e2fsck -b 32768 /dev/sdc2 2216 2021-03-18 14:45:56 man e2fsck 2217 2021-03-18 14:46:38 sudo e2fsck -y -b 32768 /dev/sdc2 - --8<---cut here---end--->8--- > >> >> So how do I stop it happening again please? And what is the cause of it >> all? Should I physically unmount the drives before rebooting? > > The answers you seek should already be logged somewhere. Try the following: > > $ journalctl -b -u mnt-backb.mount # > This will show output from > attempts to mount /mnt/backb since the current bootup - --8<---cut here---start->8--- journalctl -b -u mnt-backb.mount Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. - -- Journal begins at Wed 2021-02-24 17:51:13 GMT, ends at Wed 2021-03-31 11:08:09 BST. -- - -- No entries -- - --8<---cut here---end--->8--- > > $ journalctl -b -g sdc2 # This will grep > the journal for all messages containing "sdc2" since the current bootup > - --8<---cut here---start->8--- journalctl -b -g sdc2 Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. - -- Journal begins at Wed 2021-02-24 17:51:13 GMT, ends at Wed 2021-03-31
Re: backb losing its mount point
On 31/03/2021 09:32, Sharon Kimble wrote: > > I'm hoping that you folks can help me with a problem that is now > happening reasonably regularly, actually twice. > > I have 2 data drives on my system /mnt/backa and /mnt/backb. Both are > 4tb drives, with backa being 2.74tb and backb 2.81tb. It might be helpful to see the relevant lines from your /etc/fstab. > > Backb is now regularly losing its mount point when I reboot, meaning > that only backa is mounted, and backb holds my restic backup. > > To regain access to backb I'm having to 'sudo e2fsck -y -b 32768 > /dev/sdc2' which rebuilds the mount point such that I can mount it on > reboot, as backb. Firstly, it's usually better to run the "fsck" frontend, which will determine which filesystem you've got and run the appropriate backend, but I can see that you're passing advanced parameters here, so jumping straight to e2fsck isn't that unusual. Secondly, you're specifying "-b 32768" which is telling fsck to use a secondary superblock. Why is this? Generally, the primary superblock should be "good enough" to repair a filesystem. The man page does state that the primary superblock *should* be updated after the fixes are complete, so this shouldn't be necessary. So, why are you having to use a secondary superblock? Do you know what's wrong with the primary one? > > So how do I stop it happening again please? And what is the cause of it > all? Should I physically unmount the drives before rebooting? The answers you seek should already be logged somewhere. Try the following: $ journalctl -b -u mnt-backb.mount # This will show output from attempts to mount /mnt/backb since the current bootup $ journalctl -b -g sdc2 # This will grep the journal for all messages containing "sdc2" since the current bootup > > Thanks > Sharon. > OpenPGP_signature Description: OpenPGP digital signature
backb losing its mount point
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm hoping that you folks can help me with a problem that is now happening reasonably regularly, actually twice. I have 2 data drives on my system /mnt/backa and /mnt/backb. Both are 4tb drives, with backa being 2.74tb and backb 2.81tb. Backb is now regularly losing its mount point when I reboot, meaning that only backa is mounted, and backb holds my restic backup. To regain access to backb I'm having to 'sudo e2fsck -y -b 32768 /dev/sdc2' which rebuilds the mount point such that I can mount it on reboot, as backb. So how do I stop it happening again please? And what is the cause of it all? Should I physically unmount the drives before rebooting? Thanks Sharon. - -- Debian 10.9, fluxbox 1.3.7, emacs 28.0.50, org 9.4.5 -BEGIN PGP SIGNATURE- iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmBkM4YbHGJvdWRpY2Nh c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbUBUQAKwLJ8YF6/Bw13MKQqwZ peDg6r7fnxXSQ4NrknjYEgSh51p9uOyY23klVYb9jSNTyKLh0XAudnq/Gv1EjVy4 7IEDl6vfSqKd+x3nPJJvsBQ9+AilOcb0PXJo2vARyuRl99y4OBFuVY+A7nNLG1Y4 lp6Sn5JvAEMf77z0mr9yDKHggg8Mdd0LGCP8L+TYEaNU3CQmVHQvQ32UQ4xnNdTv k2jj1swMigasR8WwmZibN7m4b03OUcSpe5kH1sH/twdUHIoNzDKyIDx5ExsOfpwe kMNrU8i9Iq+XcSLTUIZcJa7VOeIJJQ33rLRr3tLULsA/5uXlKS5PEuqI6lY/oiRD FF1EfNnkWVrh7W2RUzXz0CbI/5UhIg+V1DvThtdQBu3nwTqmu3Ya+Os3gEYlPK/6 3WP2/Acyiq3miUVqrFvg49X2zh+as53bOwVhaCfCO6jG4MOXY+F+AZBlx1YoNlNu YfeCakYDfk0dr5fUqs91nR554FRpPTz21MqFBP7L4FtQ9frIYRMRJuYfETEG9LM/ /hyeTP6hftUr2+W/jBU9np6VqriLMRv0qltpYLD/IQPCIz4fjDIs9KFiqAd0uaiQ dgnjsaXyq96wp98J9dn9deZk8FyRSjMUhsxJfMn+I/YVPrHhX/xXm9nGRJEajLOD PHcDi1mhmNKg0p7o651VclyP =WT1I -END PGP SIGNATURE-
