at 04:17:11PM +0200 schrieb hw:
> > > > > Hi,
> > > > >
> > > > > I have an entry in the fstab to mount an NFS share via IPv6. For
> > > > > unknown reasons, the entry is being ignored on boot, so after booting,
> > >
On Mon 23 Oct 2023 at 17:28:54 (+0200), hw wrote:
> On Mon, 2023-10-23 at 10:30 -0400, Greg Wooledge wrote:
> > On Mon, Oct 23, 2023 at 04:17:11PM +0200, hw wrote:
> > > I have an entry in the fstab to mount an NFS share via IPv6. For
> > > unknown reasons, the entry i
Am Mon, Oct 23, 2023 at 05:57:28PM +0200 schrieb hw:
> On Mon, 2023-10-23 at 17:40 +0200, hw wrote:
> > On Mon, 2023-10-23 at 16:53 +0200, Christoph Brinkhaus wrote:
> > > Am Mon, Oct 23, 2023 at 04:17:11PM +0200 schrieb hw:
> > > > Hi,
> > > >
> >
Am Mon, Oct 23, 2023 at 05:40:54PM +0200 schrieb hw:
> On Mon, 2023-10-23 at 16:53 +0200, Christoph Brinkhaus wrote:
> > Am Mon, Oct 23, 2023 at 04:17:11PM +0200 schrieb hw:
> > > Hi,
> > >
> > > I have an entry in the fstab to mount an NFS share via IPv6. For
On Mon, 2023-10-23 at 17:40 +0200, hw wrote:
> On Mon, 2023-10-23 at 16:53 +0200, Christoph Brinkhaus wrote:
> > Am Mon, Oct 23, 2023 at 04:17:11PM +0200 schrieb hw:
> > > Hi,
> > >
> > > I have an entry in the fstab to mount an NFS share via IPv6. For
>
On Mon, 2023-10-23 at 16:53 +0200, Christoph Brinkhaus wrote:
> Am Mon, Oct 23, 2023 at 04:17:11PM +0200 schrieb hw:
> > Hi,
> >
> > I have an entry in the fstab to mount an NFS share via IPv6. For
> > unknown reasons, the entry is being ignored on boot, so after booti
On Mon, 2023-10-23 at 10:30 -0400, Greg Wooledge wrote:
> On Mon, Oct 23, 2023 at 04:17:11PM +0200, hw wrote:
> > I have an entry in the fstab to mount an NFS share via IPv6. For
> > unknown reasons, the entry is being ignored on boot, so after booting,
> > I have to lo
Am Mon, Oct 23, 2023 at 04:17:11PM +0200 schrieb hw:
> Hi,
>
> I have an entry in the fstab to mount an NFS share via IPv6. For
> unknown reasons, the entry is being ignored on boot, so after booting,
> I have to log in as root and do a 'mount -a' which mounts the
On Mon, Oct 23, 2023 at 04:17:11PM +0200, hw wrote:
> I have an entry in the fstab to mount an NFS share via IPv6. For
> unknown reasons, the entry is being ignored on boot, so after booting,
> I have to log in as root and do a 'mount -a' which mounts the share
> without p
Hi,
I have an entry in the fstab to mount an NFS share via IPv6. For
unknown reasons, the entry is being ignored on boot, so after booting,
I have to log in as root and do a 'mount -a' which mounts the share
without problems.
The entry in the fstab looks like this:
[fd53::11]:/s
On Sun 23 Apr 2023 at 01:14:05 (-0700), David Christensen wrote:
> On 4/22/23 21:11, David Wright wrote:
> > On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:
> > > "Back in the day", people running Linux had computers with limited
> > > amounts of storage and memory. I imagine an i
On Sun, 23 Apr 2023 01:14:05 -0700
David Christensen wrote:
> On 4/22/23 21:11, David Wright wrote:
> > On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:
...
> >> "Back in the day", people running Linux had computers with limited
> >> amounts of storage and memory. I imagine an
David Wright wrote:
...
> That must be nice. I don't know what it might have cost. I'm afraid
> I only use cast-offs. The oldest has ½GB memory.
i have some older memory sticks and chips that i will gladly
send to anyone who has older machines. the only condition i
would have for the gift is
e process may find a new and in-use something at that path which
belongs to another process.
My conclusion was that the safest approach would be for the OP to
restore the fstab(5) entry for /tmp and reboot. This keeps file
descriptors and file paths consistent -- both during shutdown and du
On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:
> On 4/22/23 08:24, David Wright wrote:
> > On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
> > > On 4/21/23 08:12, Max Nikulin wrote:
> > > > On 20/04/2023 04:03, David Christensen wrote:
> > > > > * What if root att
On 4/22/23 08:24, David Wright wrote:
On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
On 4/21/23 08:12, Max Nikulin wrote:
On 20/04/2023 04:03, David Christensen wrote:
* What if root attempts to remove everything under /etc, in
anticipation of mounting a file system at /etc,
arly init, I believe, it is safer
> > to run "update-initrams -u" just to avoid surprise due to changes
> > in fstab several days or weeks later when kernel update will
> > arrive. It would be much harder to associate boot failure with
> > fstab restored from backup
Am 22.04.2023 um 08:33 schrieb Max Nikulin:
> On 21/04/2023 00:43, songbird wrote:
>> Max Nikulin wrote:
>>> On 20/04/2023 19:10, songbird wrote:
one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.
>>
>> i know what all yo
On 21/04/2023 00:43, songbird wrote:
Max Nikulin wrote:
On 20/04/2023 19:10, songbird wrote:
one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.
i know what all you've written below but
it does not apply to what i want or how
believe, it is safer to run
"update-initrams -u" just to avoid surprise due to changes in fstab
several days or weeks later when kernel update will arrive. It would be
much harder to associate boot failure with fstab restored from backup
instead of "broken" kernel package.
Jeremy Ardley wrote:
...
> I have not used these, but there seem to be some work-arounds for
> storing metadata in/with git
>
> lfs has the ability to script xattr handling
>
> https://git-lfs.github.com/
i'll look at that one and see if it brings things to mind
that i've already messed with it
certain moment I thought that original issue was due to attempt to
really mount another partition to /etc (e.g. for easier backups). Later
an entry for /tmp was added to fstab on mounted partition, perhaps new
version of fstab even propagated to initramfs. However after reboot
there was no an entry
On Fri, Apr 21, 2023 at 04:59:36AM -0400, rhkra...@gmail.com wrote:
> On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> > sudo cp -r from the live usb.
>
> Recently I've been trying to get in the habit of using cp -aru because those
> options do what I usually want:
>
>* -a pr
On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> sudo cp -r from the live usb.
Recently I've been trying to get in the habit of using cp -aru because those
options do what I usually want:
* -a preserves dates (and ownership and permissions), and doesn't follow
(copy from) sym
On Thu, Apr 20, 2023 at 11:29:26PM -0500, David Wright wrote:
> On Thu 20 Apr 2023 at 22:16:56 (+0700), Max Nikulin wrote:
> > On 20/04/2023 19:05, songbird wrote:
> > > Default User wrote:
> > > > And when partitions were named /dev/hda5, not
> > > > 6a105a72-f5d5-441b-b926-1e405151ee84.
>
> With
to go back to those
device names, because the way the buses work, the internal drives
can be assigned different names according to what's plugged into
the computer.
> >i use labels on all of my partitions and give them a
> > legible name. those are what i use in my
On 4/20/23 14:51, songbird wrote:
David Christensen wrote:
...
Please describe your use-case(s), what the requirements are and why, and
how Git is failing.
i require maintaining an accurate record of the
file and it's attributes - i consider that a part of
the reason the file exists to begi
On 21/4/23 05:41, songbird wrote:
Stefan Monnier wrote:
songbird
I have not used these, but there seem to be some work-arounds for
storing metadata in/with git
lfs has the ability to script xattr handling
https://git-lfs.github.com/
These applications work directly with metadata and
Stefan Monnier wrote:
...
> BTW, the `bup` tool does add some of the needed functionality
> (e.g. storing metadata), but it's not developed with an eye towards
> merging some of that extra functionality into Git, and it doesn't aim to
> be a "generic file storage tool" either :-(
i tried bup for
David Christensen wrote:
...
> Please describe your use-case(s), what the requirements are and why, and
> how Git is failing.
i require maintaining an accurate record of the
file and it's attributes - i consider that a part of
the reason the file exists to begin with (otherwise
why have a diff
On 4/20/23 05:10, songbird wrote:
David Wright wrote:
...
I see nothing unreasonable. The only oddity to me is that the listings
you give (which are from the backups, I assume) have today's date,
which means that the backup method is not preserving the file metadata.
(If you've not used partitio
>> It could be a sister project of Git.
> there are other attempts which are done for it and
> process flows for me but i'd really prefer just a
> simple flag or environment variable i could set which
> would do it instead so then i'd be able to get rid of
> the gyrations.
AFAIK the Git maintai
Stefan Monnier wrote:
...
> FWIW, I think it makes perfect sense for Git to ignore such metadata
> in the context of the intended use of Git (i.e. tracking source code).
it didn't make sense to me then and still doesn't
but whatever... :)
> But I wish there was a concerted effort to develop/
Max Nikulin wrote:
> On 20/04/2023 19:10, songbird wrote:
>>one of the worst design decisions i've come across in
>> the modern era was the lack of git respecting file metadata.
>
> In the case of git you can get commit time from git log.
i do not want commit time, i want the file attributes
On 20/04/2023 19:10, songbird wrote:
one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.
In the case of git you can get commit time from git log.
Version control systems update modification time on operations like "git
checkout
On 20/04/2023 19:05, songbird wrote:
Default User wrote:
And when partitions were named /dev/hda5, not
6a105a72-f5d5-441b-b926-1e405151ee84.
i use labels on all of my partitions and give them a
legible name. those are what i use in my fstab and also
in any grub or refind configs.
i
tors
> > > remain on the original partition. However I do not expect that
> > > single
> > > user mode or booting from live image is required. Just restore
> > > original
> > > /etc/fstab and reboot.
> > >
> > > Perhaps upda
> one of the worst design decisions i've come across in
> the modern era was the lack of Git respecting file metadata.
>
> i got bit by this a few weeks ago yet again. i hate using
> Git because of it destroying my file meta data.
FWIW, I think it makes perfect sense for Git to ignore such m
On 20/4/23 20:10, songbird wrote:
aside rant,
thank gitification for that IMO.
one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.
i got bit by this a few weeks ago yet again. i hate using
git because of it destroyi
, and Gnome 3. And when partitions were named /dev/hda5, not
> 6a105a72-f5d5-441b-b926-1e405151ee84.
>
> Sigh.
...
i use labels on all of my partitions and give them a
legible name. those are what i use in my fstab and also
in any grub or refind configs.
i hate UUIDS. i do understan
davidson wrote:
...
> Consider the -a option to cp for backup/backdown operations, to
> preserve all attributes (including timestamps), recursively copy
> directories, and more. Read the manual for details.
that's what i use by default for all copies. saves me
a lot of wondering where something
David Wright wrote:
...
> I see nothing unreasonable. The only oddity to me is that the listings
> you give (which are from the backups, I assume) have today's date,
> which means that the backup method is not preserving the file metadata.
> (If you've not used partition 5 for a while, the dates sh
;> user mode or booting from live image is required. Just restore
>> original
>> /etc/fstab and reboot.
>>
>> Perhaps update-initramfs is necessary after restoring of /etc/fstab
>> in
>> any chosen approach.
>>
>>
>
>
> Well, now I am totally conf
> > > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20
> > > > > .X1025-
> > > > > lock
> > > > > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20
> > > > > .X11-
> > > > > unix/
> > > >
On 4/19/23 17:24, Default User wrote:
>>>>>> On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote:
>>>>>>> Perhaps update-initramfs is necessary after restoring of
>>>>>>> /etc/fstab in any chosen approach.
Looking at the Wikipedia p
t; > > > On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote:
> >
> > > > > > Perhaps update-initramfs is necessary after restoring of
> > > > > > /etc/fstab
> > > > > > in
> > > > > > any chosen approach.
&g
/tmp directory and
its
contents.
2) On the computer's internal ssd, delete the contents of the old
tmp
partition, but not the partition itself.
3) On the computer's internal ssd, replace /etc/fstab with
/etc/fstab.original, renaming it /etc/fstab. I have already made
a
copy
of the c
/etc/fstab
in
any chosen approach.
But, I cannot address Max's point about initrd(4).
At this point, I would run my daily backups, use an editor to put the
original /etc entry back into /etc/fstab, forget about messing with
/etc
on either file system, and reboot. After reboot, I would ru
On 4/19/23 14:26, Default User wrote:
On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote:
On 4/19/23 13:06, Default User wrote:
On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote:
Perhaps update-initramfs is necessary after restoring of
/etc/fstab
in
any chosen approach.
But, I
gt;
> > > > +1 I like that better than the reboot/ live drive idea I
> > > > posted.
> > >
> > > I think, it is the case when reboot is safer. Open file
> > > descriptors
> > > remain on the original partition. However I do not exp
that.
+1 I like that better than the reboot/ live drive idea I posted.
I think, it is the case when reboot is safer. Open file descriptors
remain on the original partition. However I do not expect that single
user mode or booting from live image is required. Just restore
original
/etc/fstab
w nothing about bind or mount --bind. I looked them up
> > > briefly, and decided that they are too difficult and maybe
> > > dangerous to
> > > try to learn and use under the current circumstances.
> > >
> > > So here is what I am thinking of doing:
> >
s to
> > try to learn and use under the current circumstances.
> >
> > So here is what I am thinking of doing:
> >
> > While running from within the Debian Stable 11.6 Live/install usb
> > thumb
> > drive, as root user:
> >
> > 1) On the computer
e drive idea I posted.
>
> I think, it is the case when reboot is safer. Open file descriptors
> remain on the original partition. However I do not expect that single
> user mode or booting from live image is required. Just restore
> original /etc/fstab and reboot.
I was merely post
ng from within the Debian Stable 11.6 Live/install usb thumb
> drive, as root user:
>
> 1) On the computer's internal ssd, delete the /tmp directory and its
> contents.
>
> 2) On the computer's internal ssd, delete the contents of the old tmp
> partition, but not the
Default User wrote:
>
> Well, now I am totally confused.
>
> I had hoped for, and really expected, an easy, obvious, intuitive
> solution. But I guess that may be a distant memory of the good old
> days, before [insert string of four-letter words here] like dbus,
> systemd, and Gnome 3. And wh
do not expect that single
> user mode or booting from live image is required. Just restore
> original
> /etc/fstab and reboot.
>
> Perhaps update-initramfs is necessary after restoring of /etc/fstab
> in
> any chosen approach.
>
>
1) Would there be anything actually wr
do not expect that single
> user mode or booting from live image is required. Just restore
> original
> /etc/fstab and reboot.
>
> Perhaps update-initramfs is necessary after restoring of /etc/fstab
> in
> any chosen approach.
>
>
Well, now I am totally confused.
I h
case when reboot is safer. Open file descriptors
remain on the original partition. However I do not expect that single
user mode or booting from live image is required. Just restore original
/etc/fstab and reboot.
Perhaps update-initramfs is necessary after restoring of /etc/fstab in
any
On 4/18/23 20:16, Stefan Monnier wrote:
You can also do
mount --bind / /mnt
and then look at /mnt/tmp.
No need to reboot into single-user mode for that.
+1 I like that better than the reboot/ live drive idea I posted.
David
On Tue, Apr 18, 2023 at 10:15:30PM +0100, Tom Furie wrote:
> On Tue, Apr 18, 2023 at 09:00:00PM +0200, to...@tuxteam.de wrote:
> > Since Debian erases /tmp at each boot anyway: wouldn't it be
> > much easier to set up an entry in fstab along the lines of
> >
&g
> So—I would clean /tmp as best you can before you close down, then
> boot in single user mode, clean anything still remaining in /tmp,
> edit your fstab, and then reboot.
You can also do
mount --bind / /mnt
and then look at /mnt/tmp.
No need to reboot into single-user mode
wait until tomorrow and ponder the options, before
> performing "surgery".
If you're prepared to reboot, it should be straightforward, but there
is one factor I haven't seen mentioned, and that's to do with cleaning.
If you add the "lost line" back into fstab
previous posts:
On 4/18/23 07:59, Default User wrote:
> Current /etc/fstab:
> #
>
> UUID=4fdd4399-6267-404a-a292-
> cdc7761df3c9 / ext4errors=remount-ro 0 1
> UUID=26EE-0EF5 /boot/efi vfatumask=0077 0 1
> UUID=00
On Tue, 18 Apr 2023 21:12:33 -0400
Default User wrote:
> (Not so) fun fact: Clonezilla always refuses to back up swap
> partitions. I don't know why.
Because there is no reason to do so. It has nothing in it of any value,
except possibly to a cracker, and even that is stale.
--
Does anybody re
/proc/sys/fs/binfmt_misc
> 33 /dev/hugepages
> 34 /sys/fs/fuse/connections
> 35 /sys/kernel/config
> 39 /samba/dpchrist
> 40 /samba/groupshare
> 42 /run/user/13250
> 50 /run/user/0
> 2049 /boot/efi
> 2050 /boot
> 65024 /
> 65026 /scratch
>
>
> That said
solution posted by Greg Wooledge.
(And BTW, the current /etc/fstab must have been written by some
program, not manually by me. I would never have edited /etc/fstab to
look like that!) My best guess is that I may have done a system restore
using Timeshift on 2023-04-03, to back out of some unremembere
On Tue, Apr 18, 2023 at 05:42:52PM -0400, Default User wrote:
> stat -c %d / /tmp
> 66306
> 66306
> (I am not sure what that means - is that saying that /tmp is mounted
> under / on the / partition?)
Yes. And by the way, "df /tmp" is a much more intuitive way to get
that same answer.
unicorn:~$
k=0077,dmask=0077,codepage=437,iocharset=ascii,sho
> > rtna
> > me=mixed,utf8,errors=remount-ro)
> > tmpfs on /run/user/1000 type tmpfs
> > (rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,ui
> > d=10
> > 00,gid=1000,inode64)
> > gvfsd-fuse on /run/us
On Tue, Apr 18, 2023 at 09:00:00PM +0200, to...@tuxteam.de wrote:
> Since Debian erases /tmp at each boot anyway: wouldn't it be
> much easier to set up an entry in fstab along the lines of
>
> tmpfs/tmptmpfsdefaults,noatime,mode=1777 0 0
>
> (assuming
type fuse.gvfsd-fuse
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
Current /etc/fstab:
#
UUID=4fdd4399-6267-404a-a292-
cdc7761df3c9/ ext4errors=remount-ro 0 1
On Tue, Apr 18, 2023 at 09:37:51AM -0600, Charles Curley wrote:
> On Tue, 18 Apr 2023 10:59:19 -0400
> Default User wrote:
>
> > What to do?
>
> I suspect that what you need to do is:
>
> 1) Preserve the current contents of /tmp,
>
> 2) Adjust fstab to i
On 18/04/2023 22:37, Charles Curley wrote:
1) Preserve the current contents of /tmp,
2) Adjust fstab to include the /tmp partition,
3) Mount the /tmp partition
4) Restore the contents of /tmp
Some issues may arise due to files (regular ones, already deleted,
sockets, fifos) opened by running
Default User wrote:
...
> What to do?
if the tmp partition exists then put it back in your
fstab and see if you can mount it manually. it may or
may not mount. if it doesn't you can reboot and it
should then mount.
of course, make sure you have the mount point defined.
> And
On Tue, 18 Apr 2023 10:59:19 -0400
Default User wrote:
> What to do?
I suspect that what you need to do is:
1) Preserve the current contents of /tmp,
2) Adjust fstab to include the /tmp partition,
3) Mount the /tmp partition
4) Restore the contents of /tmp
You should probably do all
now, then
shutdown and boot from an ISO in order to have a "cold" system on disk.
Then mount both tmp places to check, if there is anything worth
keeping/consolidating. Otherwise clear the mountpoint and uncomment the
/tmp line from your fstab. Rebooting should then just mount it as you wan
,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
Current /etc/fstab:
#
UUID=4fdd4399-6267-404a-a292-
cdc7761df3c9/ ext4errors=remount-ro 0 1
UUID=26EE-0EF5 /boot/efi vfat
On 2022-11-04 01:52, mick.crane wrote:
On 2022-11-03 04:52, Ken Heard wrote:
A few days ago using vim I added to my desktop fstab file a line for a
new portable storage device. in the process I somehow managed to
screw up fstab. Unfortunately I saved the screwed up version of fstab
before I
On 2022-11-03 04:52, Ken Heard wrote:
A few days ago using vim I added to my desktop fstab file a line for a
new portable storage device. in the process I somehow managed to
screw up fstab. Unfortunately I saved the screwed up version of fstab
before I noticed the damage done to it.
01
Ken Heard wrote:
> A few days ago using vim I added to my desktop fstab file a line for a
> new portable storage device. in the process I somehow managed to screw
> up fstab. Unfortunately I saved the screwed up version of fstab before
> I noticed the damage done to it.
...
"Rick Thomas" writes:
> Sorry to hear of your mishap, Ken ...
> In regards to possibly making your system un-bootable, I have two suggestions:
> 1) First make a backup of everything ASAP! (and make plans for frequent
> regular backups into the future)
And for now, as the mounts are mounted and
stick, or whatever) and go into "rescue mode". From there you can chroot (it's
one of the menu options) into the root partition and fix whatever problems you
encounter with the fstab.
If you run into problems with either of those, you can always come back to the
list with questi
A few days ago using vim I added to my desktop fstab file a line for a
new portable storage device. in the process I somehow managed to screw
up fstab. Unfortunately I saved the screwed up version of fstab before
I noticed the damage done to it.
As I had no fstab backup -- to correct later
assign /dev/sda to d-i USB installation media; in
spite of decades of standard practice of using the first drive node
for the target drive. Thus, the target drive may have been /dev/sdb
at installation time, resulting in "sdb" in crypttab(5) and/or
fstab(5) entries rather than the co
always assign /dev/sda to d-i USB installation media; in
> >> spite of decades of standard practice of using the first drive node
> >> for the target drive. Thus, the target drive may have been /dev/sdb
> >> at installation time, resulting in "sdb" in cryptta
Hi,
David Wright wrote:
> > Dec 13 03:02:16 kernel: [3.155962] sd 0:0:0:0: [sda] Attached SCSI
> > removable disk
> > Dec 13 03:02:48 cdrom-detect: CD-ROM mount succeeded: device=/dev/sda1
> > fstype=iso9660
> > Dec 13 03:02:48 cdrom-detect: CD-ROM mount succeeded: device=/dev/sda1
> > fsty
standard practice of using the first drive node
>> for the target drive. Thus, the target drive may have been /dev/sdb
>> at installation time, resulting in "sdb" in crypttab(5) and/or
>> fstab(5) entries rather than the conventional "sda".
> This is news t
6d6d-6782-4be3-b979-0cb595ef1a48 /backupDisk ext4 defaults 0 0
> >
> > Well, damned if it didn't work. And I had all of my non-root fstab entries
> > with singular defaults too. Thanks vastly, David.
>
> YW.
>
> One character present, absent, or differen
On 5/8/22 15:00, ghe2001 wrote:
On Sunday, May 8th, 2022 at 3:51 PM, David Christensen wrote:
My bad -- default options is spelled 'defaults'.
UUID=301d6d6d-6782-4be3-b979-0cb595ef1a48 /backupDisk ext4 defaults 0 0
Well, damned if it didn't work. And I had all of my
On Mon 09 May 2022 at 09:34:56 (+1000), David wrote:
> The only reason to that =defaults exists is so that
> a non-default value can be specified for either or ,
> while not specifying any non-default .
>
> Because there can't be a fifth or sixth column unless there is
> also a fourth column. "d
On Mon, 9 May 2022 at 05:30, ghe2001 wrote:
> The fstab:
> #
>
On Mon, 9 May 2022 at 08:00, ghe2001 wrote:
> > My bad -- default options is spelled 'defaults'.
> >
> > UUID=301d6d6d-6782-4be3-b979-0
o use the PARTUUID).
>
> But I get the same failure from "default" whether I use
> /dev/sdX, UUID, or LABEL. And lest systemd is involved,
> I followed all my fstab changes with:
> # systemctl daemon-reload.
> So I don't know where your:
>
> /dev/sde1 /backupDisk ex
0
>
> Well, damned if it didn't work. And I had all of my non-root fstab entries
> with singular defaults too.
My proof reading of the options was obviously worse than your
pasting of the UUID (I thought you might have accidentally
chosen to use the PARTUUID).
But I get the same fail
Well, damned if it didn't work. And I had all of my non-root fstab entries
with singular defaults too. Thanks vastly, David.
--
Glenn English
-BEGIN PGP SIGNATURE-
Version: ProtonMail
wsBzBAEBCAAGBQJieD1fACEJEJ/XhjGCrIwyFiEELKJzD
On 5/8/22 14:25, ghe2001 wrote:
--- Original Message ---
On Sunday, May 8th, 2022 at 3:11 PM, David Christensen
wrote:
What happens if you put the following into /etc/fstab?
UUID=301d6d6d-6782-4be3-b979-0cb595ef1a48 /backupDisk ext4 default 0 0
"wrong fs type..." L
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
--- Original Message ---
On Sunday, May 8th, 2022 at 3:31 PM, Greg Wooledge wrote:
> Is it possible that ext4 is the wrong file system type for that partition?
Nope, unless gparted is bent -- just looked.
--
Glenn English
-BEGIN
On Sun, May 08, 2022 at 09:25:21PM +, ghe2001 wrote:
> On Sunday, May 8th, 2022 at 3:11 PM, David Christensen
> wrote:
>
> > What happens if you put the following into /etc/fstab?
> >
> > UUID=301d6d6d-6782-4be3-b979-0cb595ef1a48 /backupDisk ext4 default 0 0
&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
--- Original Message ---
On Sunday, May 8th, 2022 at 3:11 PM, David Christensen
wrote:
> What happens if you put the following into /etc/fstab?
>
> UUID=301d6d6d-6782-4be3-b979-0cb595ef1a48 /backupDisk ext4 default 0 0
"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
--- Original Message ---
On Sunday, May 8th, 2022 at 2:09 PM, Kamil Jońca wrote:
> > UUID=301d6d6d-6782-4be3-b979-0cb595ef1a48 /backupDisk ext4 default 1 1
>
>
> Are you sure you have good uuid here?
Yes. Read it a few times.
> I
, bad option, bad superblock on /dev/sde1,
missing codepage or helper program, or other error.
What happens if you put the following into /etc/fstab?
UUID=301d6d6d-6782-4be3-b979-0cb595ef1a48 /backupDisk ext4 default 0 0
David
1 - 100 of 868 matches
Mail list logo
