From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 17 Sep 2015 06:21:58 -0700 (PDT) From: Donald Allen To: voidlinux Message-Id: <3b26f0f1-033f-451b-b5ec-50a1d20a2962@googlegroups.com> In-Reply-To: References: Subject: Re: System startup tries to fsck noauto file-systems MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_884_1087986661.1442496118200" ------=_Part_884_1087986661.1442496118200 Content-Type: multipart/alternative; boundary="----=_Part_885_1214581572.1442496118200" ------=_Part_885_1214581572.1442496118200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Thursday, September 17, 2015 at 7:41:29 AM UTC-4, Donald Allen wrote: > > I have several USB drives that I use for backups and archives. I have > mount-points in my home directory and fstab entries that look like this: > > LABEL=Primary /home/dca/Primary > ext2 rw,noauto,user 0 1 > > Note the 'noauto' option. > > After adding these entries to the Void system's fstab (I routinely use > this on my Arch systems), I could not boot the system, getting an error > message of the form > > fsck.ext2: Unable to resolve 'Label=Primary' > > for those drives that are not physically plugged into the system. The > whole point of this is to permit these drives to come and go, to be plugged > into the system and mounted when I need them. Again, this works as expected > on Arch. It looks to me like the Void startup code is trying to fsck > everything mentioned in fstab, including noauto file-systems. I think this > is a bug. > The solution to this is to add the 'nofail' option to the fstab entries. I was fooled by Arch not complaining about missing file-systems without 'nofail'. I withdraw my comment above that Void's behavior is incorrect; with the added option, it works correctly. ------=_Part_885_1214581572.1442496118200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Thursday, September 17, 2015 at 7:41:29 AM UTC-4, Donald Allen w= rote:
I have s= everal USB drives that I use for backups and archives. I have mount-points = in my home directory and fstab entries that look like this:

LABEL=3D= Primary=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /home= /dca/Primary=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ext2=C2=A0=C2=A0=C2=A0 rw,= noauto,user=C2=A0 0 1

Note the 'noauto' option.

After= adding these entries to the Void system's fstab (I routinely use this = on my Arch systems), I could not boot the system, getting an error message = of the form

fsck.ext2: Unable to resolve 'Label=3DPrimary'
for those drives that are not physically plugged into the system. The= whole point of this is to permit these drives to come and go, to be plugge= d into the system and mounted when I need them. Again, this works as expect= ed on Arch. It looks to me like the Void startup code is trying to fsck eve= rything mentioned in fstab, including noauto file-systems. I think this is = a bug.

The solution to this is to add the &#= 39;nofail' option to the fstab entries. I was fooled by Arch not compla= ining about missing file-systems without 'nofail'. I withdraw my co= mment above that Void's behavior is incorrect; with the added option, i= t works correctly.
------=_Part_885_1214581572.1442496118200-- ------=_Part_884_1087986661.1442496118200--