Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #205644 > unrolled thread

Swapping Drives - Sanity Check

Back to article view | Back to linux.debian.user

Contents

  Swapping Drives - Sanity Check "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-02-22 14:20 +0100
    Re: Swapping Drives - Sanity Check songbird <songbird@anthive.com> - 2019-02-22 15:20 +0100
      Re: Swapping Drives - Sanity Check David Christensen <dpchrist@holgerdanske.com> - 2019-02-23 09:00 +0100
        Re: Swapping Drives - Sanity Check songbird <songbird@anthive.com> - 2019-02-23 13:10 +0100
          Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 19:00 +0100
              Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-23 20:20 +0100
                Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 23:00 +0100
                Re: Swapping Drives - Sanity Check Felix Miata <mrmazda@earthlink.net> - 2019-02-23 23:40 +0100
                  Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-24 16:50 +0100
                    Re: Swapping Drives - Sanity Check Felix Miata <mrmazda@earthlink.net> - 2019-02-24 18:40 +0100
        Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 14:00 +0100
          Re: Swapping Drives - Sanity Check rhkramer@gmail.com - 2019-02-23 15:50 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 17:00 +0100
              Re: Swapping Drives - Sanity Check rhkramer@gmail.com - 2019-02-23 17:30 +0100
                Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 18:10 +0100
                  Re: Swapping Drives - Sanity Check mick crane <mick.crane@gmail.com> - 2019-02-23 22:00 +0100
                    Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 22:10 +0100
                Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 19:10 +0100
            Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 17:00 +0100
              Re: Swapping Drives - Sanity Check rhkramer@gmail.com - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check John Hasler <jhasler@newsguy.com> - 2019-02-23 18:00 +0100
          Re: Swapping Drives - Sanity Check David Christensen <dpchrist@holgerdanske.com> - 2019-02-23 23:20 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 23:40 +0100
    Re: Swapping Drives - Sanity Check Dan Ritter <dsr@randomstring.org> - 2019-02-22 15:20 +0100
      Re: Swapping Drives - Sanity Check "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-02-22 15:30 +0100
        Re: Swapping Drives - Sanity Check David Wright <deblis@lionunicorn.co.uk> - 2019-02-22 16:10 +0100
          Re: Swapping Drives - Sanity Check "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-02-22 17:40 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-22 20:20 +0100
            Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-22 20:30 +0100
              Re: Swapping Drives - Sanity Check David Wright <deblis@lionunicorn.co.uk> - 2019-02-23 03:00 +0100
                Re: Swapping Drives - Sanity Check Jimmy Johnson <field.engineer@gmail.com> - 2019-02-23 09:00 +0100
                  Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 09:40 +0100
            Re: Swapping Drives - Sanity Check Felix Miata <mrmazda@earthlink.net> - 2019-02-22 23:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#205696

[Multipart message — attachments visible in raw view] — view raw

Thanks for the explanation!

On Saturday, February 23, 2019 10:49:56 AM tomas@tuxteam.de wrote:
> On Sat, Feb 23, 2019 at 09:41:27AM -0500, rhkramer@gmail.com wrote:
> No. Imagine a data pin at +5V while the power rails are still in an
> undefined state. Not good for electronics.
> 
> > I guess I am behind the times (and I will have to find some Plug-n-PLay
> > device and look at the connectors).
> 
> Have a look at an USB connector (the traditional one, e.g. Type A):
> the outer "pins" (rather stripes) are longer (those are 0 and +5V).
> The middle ones (data) are shorter.

[toc] | [prev] | [next] | [standalone]

#205693

[Multipart message — attachments visible in raw view] — view raw

On Sat, Feb 23, 2019 at 11:11:18AM -0500, Michael Stone wrote:
> On Sat, Feb 23, 2019 at 09:41:27AM -0500, rhkramer@gmail.com wrote:
> >On Saturday, February 23, 2019 07:53:23 AM Pascal Hambourg wrote:
> >>Le 23/02/2019 à 08:53, David Christensen a écrit :
> >>> Understand that if you disconnect the power cable to a motherboard,
> >>> drive, peripheral, etc., but not all the other cables (e.g. SATA cable),
> >>> you can fry electronics.
> >>
> >>Right. This is why power pins are longer than data pins in plug&play
> >>connectors, so that they are connected first and disconnected last.
> >
> >Hmm, that surprises me -- I guess I would have expected that you want the data
> >pins connected first (while no power is applied), and disconnected last (again,
> >while no power is applied).  Interesting,
> 
> You generally want ground connected first.

And Vcc before signal. Always. The order of ground and Vcc is actually not
*that* critical (although if I had a choice, I'd start with ground).

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#205695

On Sat, Feb 23, 2019 at 09:41:27AM -0500, rhkramer@gmail.com wrote:
>On Saturday, February 23, 2019 07:53:23 AM Pascal Hambourg wrote:
>> Le 23/02/2019 à 08:53, David Christensen a écrit :
>> > Understand that if you disconnect the power cable to a motherboard,
>> > drive, peripheral, etc., but not all the other cables (e.g. SATA cable),
>> > you can fry electronics.
>>
>> Right. This is why power pins are longer than data pins in plug&play
>> connectors, so that they are connected first and disconnected last.
>
>Hmm, that surprises me -- I guess I would have expected that you want the data
>pins connected first (while no power is applied), and disconnected last (again,
>while no power is applied).  Interesting,

You generally want ground connected first.

[toc] | [prev] | [next] | [standalone]

#205700

rhkramer writes:
> Hmm, that surprises me -- I guess I would have expected that you want
> the data pins connected first (while no power is applied), and
> disconnected last (again, while no power is applied).

Data pins can supply current.  They have to in order to charge and
discharge load and transmission line capacitance and drive load
resistance.  If you connect a data pin that has voltage on it to an
input of an integrated circuit that's part of an unpowered device
current will flow into the input, through the IC, and out the power pin
to the rest of the device.  This current may exceed the maximum that the
input can handle.

There has to be a return path, of course.  This could be the common,
another data pin, or, worst of all, chassis ground in which case you
will be subjecting both systems to whatever hum and/or ground loop
current is present.

All external connections to a device should incorporate protection, but
this not only adds cost: it slows data.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#205713

On 2/23/19 4:53 AM, Pascal Hambourg wrote:
> Le 23/02/2019 à 08:53, David Christensen a écrit :
>>
>> As other readers have noted, using UUID's for the fstab first field 
>> (fs_spec) is okay.  Newer Linux kernels offer more meaningful options, 
>> such as GPT labels and drive make/ model/ serial number (ID) strings.
> 
> AFAIK, these options have nothing to do with the kernel. They are 
> provided by libblkid. The only related option added to "newer" (it was 
> 3.x so not really new) kernels is the ability to specifiy the root 
> filesystem by PARTUUID instead of device node name or major:minor 
> numbers when not using an initrd or initramfs to mount the root filesystem.

Okay.  (I should have said "Newer Linux distributions".  And yes, those 
features were added a while ago.)


David

[toc] | [prev] | [next] | [standalone]

#205716

Le 23/02/2019 à 23:13, David Christensen a écrit :
> On 2/23/19 4:53 AM, Pascal Hambourg wrote:
>> Le 23/02/2019 à 08:53, David Christensen a écrit :
>>>
>>> As other readers have noted, using UUID's for the fstab first field 
>>> (fs_spec) is okay.  Newer Linux kernels offer more meaningful 
>>> options, such as GPT labels and drive make/ model/ serial number (ID) 
>>> strings.
>>
>> AFAIK, these options have nothing to do with the kernel. They are 
>> provided by libblkid. (...)
> 
> Okay.  (I should have said "Newer Linux distributions".  And yes, those 
> features were added a while ago.)

/dev/disk/by-part{uuid,label} and the ability to use PARTUUID and 
PARTLABEL in /etc/fstab were added in Debian Jessie. /dev/disk/by-id is 
older, maybe as old as /dev/disk/by-{uuid,label}.

[toc] | [prev] | [next] | [standalone]

#205648

Stephen P. Molnar wrote: 
> My Debian Stretch system has three HD's. I want to remove one of the HD's
> (not sda) and replace it with a new HD..
> 
> What I need to be sure of is, if I remove the old drive from the fstab and
> delete the mount point will the system boot after I put in the new HD. so
> that I can edit the fstab and create a mount point for the new drive?
> 
> Hence, the request for the sanity check.
> 

The system needs the following to boot:

- the BIOS or UEFI needs to know which drive has a boot loader.

- that drive needs a boot loader (usually grub)

- the boot loader needs to know where to load the kernel and
  possibly an init filesystem from

- the kernel needs to be able to mount /, the root partition.


Typically, all of those things will be on one drive, and that's
usually /dev/sda. However, it's possibly to change all of them.

You're probably safe. If you want to be sure, run a test:

- shutdown to power off
- unplug power from the drive you're going to replace
- try to boot

If that succeeds, shut down again and go ahead with the
replacement. If it fails, you need to trace the boot process
above and find out what's on the drive you're replacing,
and arrange for that to be changed or copied.

-dsr-

[toc] | [prev] | [next] | [standalone]

#205650

On 02/22/2019 09:13 AM, Dan Ritter wrote:
> Stephen P. Molnar wrote:
>> My Debian Stretch system has three HD's. I want to remove one of the HD's
>> (not sda) and replace it with a new HD..
>>
>> What I need to be sure of is, if I remove the old drive from the fstab and
>> delete the mount point will the system boot after I put in the new HD. so
>> that I can edit the fstab and create a mount point for the new drive?
>>
>> Hence, the request for the sanity check.
>>
> The system needs the following to boot:
>
> - the BIOS or UEFI needs to know which drive has a boot loader.
>
> - that drive needs a boot loader (usually grub)
>
> - the boot loader needs to know where to load the kernel and
>    possibly an init filesystem from
>
> - the kernel needs to be able to mount /, the root partition.
>
>
> Typically, all of those things will be on one drive, and that's
> usually /dev/sda. However, it's possibly to change all of them.
>
> You're probably safe. If you want to be sure, run a test:
>
> - shutdown to power off
> - unplug power from the drive you're going to replace
> - try to boot
>
> If that succeeds, shut down again and go ahead with the
> replacement. If it fails, you need to trace the boot process
> above and find out what's on the drive you're replacing,
> and arrange for that to be changed or copied.
>
> -dsr-
>
Thanks for the reply.

The OS is on dev/sda.  The disk I changing is /dev/sdc

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

[toc] | [prev] | [next] | [standalone]

#205653

On Fri 22 Feb 2019 at 09:19:53 (-0500), Stephen P. Molnar wrote:
> On 02/22/2019 09:13 AM, Dan Ritter wrote:
> > Stephen P. Molnar wrote:
> > > My Debian Stretch system has three HD's. I want to remove one of the HD's
> > > (not sda) and replace it with a new HD..
> > > What I need to be sure of is, if I remove the old drive from the fstab and
> > > delete the mount point will the system boot after I put in the new HD. so
> > > that I can edit the fstab and create a mount point for the new drive?
> > > Hence, the request for the sanity check.
> > > 
> > The system needs the following to boot:
> > - the BIOS or UEFI needs to know which drive has a boot loader.
> > - that drive needs a boot loader (usually grub)
> > - the boot loader needs to know where to load the kernel and
> >    possibly an init filesystem from
> > - the kernel needs to be able to mount /, the root partition.
> > 
> > Typically, all of those things will be on one drive, and that's
> > usually /dev/sda. However, it's possibly to change all of them.
> > 
> > You're probably safe. If you want to be sure, run a test:
> > - shutdown to power off
> > - unplug power from the drive you're going to replace
> > - try to boot
> > 
> > If that succeeds, shut down again and go ahead with the
> > replacement. If it fails, you need to trace the boot process
> > above and find out what's on the drive you're replacing,
> > and arrange for that to be changed or copied.
> > 
> Thanks for the reply.
> 
> The OS is on dev/sda.  The disk I changing is /dev/sdc

I think we're assuming that you have something better than
/dev/sdaX in your /etc/fstab, UUIDs or LABELs. With modern
PCs, you can be surprised by how these device names are
assigned.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205656

On 02/22/2019 10:02 AM, David Wright wrote:
> On Fri 22 Feb 2019 at 09:19:53 (-0500), Stephen P. Molnar wrote:
>> On 02/22/2019 09:13 AM, Dan Ritter wrote:
>>> Stephen P. Molnar wrote:
>>>> My Debian Stretch system has three HD's. I want to remove one of the HD's
>>>> (not sda) and replace it with a new HD..
>>>> What I need to be sure of is, if I remove the old drive from the fstab and
>>>> delete the mount point will the system boot after I put in the new HD. so
>>>> that I can edit the fstab and create a mount point for the new drive?
>>>> Hence, the request for the sanity check.
>>>>
>>> The system needs the following to boot:
>>> - the BIOS or UEFI needs to know which drive has a boot loader.
>>> - that drive needs a boot loader (usually grub)
>>> - the boot loader needs to know where to load the kernel and
>>>     possibly an init filesystem from
>>> - the kernel needs to be able to mount /, the root partition.
>>>
>>> Typically, all of those things will be on one drive, and that's
>>> usually /dev/sda. However, it's possibly to change all of them.
>>>
>>> You're probably safe. If you want to be sure, run a test:
>>> - shutdown to power off
>>> - unplug power from the drive you're going to replace
>>> - try to boot
>>>
>>> If that succeeds, shut down again and go ahead with the
>>> replacement. If it fails, you need to trace the boot process
>>> above and find out what's on the drive you're replacing,
>>> and arrange for that to be changed or copied.
>>>
>> Thanks for the reply.
>>
>> The OS is on dev/sda.  The disk I changing is /dev/sdc
> I think we're assuming that you have something better than
> /dev/sdaX in your /etc/fstab, UUIDs or LABELs. With modern
> PCs, you can be surprised by how these device names are
> assigned.
>
> Cheers,
> David.
>
Many thanks to those have answered my cry for a 'sanity check'

It has become obvious to me that I am having problems.

Before I elaborate, I am using the UUID's for the Drives. Here is my fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type> <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=ce25f0e1-610d-4030-ab47-129cd47d974e /               ext4 
errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=a8f6dc7e-13f1-4495-b68a-27886d386db0 none            swap 
sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0 0

UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro 
0       1

UUID=d65867da-c658-4e35-928c-9dd2d6dd5742 /sdc1 ext4 errors=remount-ro 
0       1

UUID=007c1f16-34a4-438c-9d15-e3df601649ba /sdc2 ext4 errors=remount-ro 
0       1

And I have the corresponding mount points.

Now, as to what is happening.



Before disconnection the power to the drives, I edited out their lines 
in fstab. I disconnecting the power to sdb and sdc and started the 
computer.  It booted for a few lines until it encountered the line 
starting with 'start job fgfor device disk by . . .' (at least that what 
i jotted down). then t\iot Then it through the three HD's, two of which 
had the power unplugged) for 1 minute and 30 seconds and then went on to 
tell me that I could log on as root or ctrl-D to continue.  Ctrl-D 
didn't work so I logged oh as root

At that point I did 'journalctl -xb and got 1237 lines which were 
meaningless to me.  startx got me to the Root Desktop.

The only option open to me at that point was to logout as root, the 
options of restart and shutdown were grayed out as being unavailable.

At this point I admitted defeat did 'shutdown -h now' in a terminal and 
put the system back in its original state.

Obviously, I'm missing something!


-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

[toc] | [prev] | [next] | [standalone]

#205659

Le 22/02/2019 à 17:36, Stephen P. Molnar a écrit :
>>> On 02/22/2019 09:13 AM, Dan Ritter wrote:
>>>> Stephen P. Molnar wrote:
>>>>> My Debian Stretch system has three HD's. I want to remove one of 
>>>>> the HD's (not sda)

You can never know which drive will be sda at next boot.

>>>> The system needs the following to boot:
>>>> - the BIOS or UEFI needs to know which drive has a boot loader.

For UEFI, it is rather the other way around : it has a list of boot 
entries and searches each matching EFI executable in order on the 
drives. Only if none is available, then as a fallback mechanism it 
searches a special executable in EFI partitions.

> UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro  0       1
> 
> UUID=d65867da-c658-4e35-928c-9dd2d6dd5742 /sdc1 ext4 errors=remount-ro  0       1
> 
> UUID=007c1f16-34a4-438c-9d15-e3df601649ba /sdc2 ext4 errors=remount-ro  0       1

Mount points which have device names that which may differ from the 
actual mounted device. This is so wrong... Fixed mount points should be 
named from the contents, not the container. This is what mounting is all 
about. /var contains variable data, regardless of its container.

> Before disconnection the power to the drives, I edited out their lines 
> in fstab. I disconnecting the power to sdb and sdc and started the 
> computer.  It booted for a few lines until it encountered the line 
> starting with 'start job fgfor device disk by . . .' (at least that what 
> i jotted down).

You need to post the complete line, and the surrounding lines related to 
the error.

[toc] | [prev] | [next] | [standalone]

#205661

On Fri, Feb 22, 2019 at 11:36:28AM -0500, Stephen P. Molnar wrote:
>Before disconnection the power to the drives, I edited out their lines 
>in fstab. I disconnecting the power to sdb and sdc and started the 
>computer.  It booted for a few lines until it encountered the line 
>starting with 'start job fgfor device disk by . . .' (at least that 
>what i jotted down). then t\iot Then it through the three HD's, two of 
>which had the power unplugged) for 1 minute and 30 seconds and then 
>went on to tell me that I could log on as root or ctrl-D to continue.  
>Ctrl-D didn't work so I logged oh as root

It sounds like you didn't actually comment them out of fstab.

[toc] | [prev] | [next] | [standalone]

#205675

On Fri 22 Feb 2019 at 14:20:05 (-0500), Michael Stone wrote:
> On Fri, Feb 22, 2019 at 11:36:28AM -0500, Stephen P. Molnar wrote:
> > Before disconnection the power to the drives, I edited out their
> > lines in fstab. I disconnecting the power to sdb and sdc and
> > started the computer.  It booted for a few lines until it
> > encountered the line starting with 'start job fgfor device disk by
> > . . .' (at least that what i jotted down). then t\iot Then it
> > through the three HD's, two of which had the power unplugged) for
> > 1 minute and 30 seconds and then went on to tell me that I could
> > log on as root or ctrl-D to continue.  Ctrl-D didn't work so I
> > logged oh as root
> 
> It sounds like you didn't actually comment them out of fstab.

Well, that should be easy to check: reconnect the drives and boot
up the system "as normal". And while it's up, I would seriously
look at those mount point names; I agree, they are awful.
Create some nice new ones to use with your future disk(s).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205679

On 2/22/19 5:54 PM, David Wright wrote:
> On Fri 22 Feb 2019 at 14:20:05 (-0500), Michael Stone wrote:
>> On Fri, Feb 22, 2019 at 11:36:28AM -0500, Stephen P. Molnar wrote:
>>> Before disconnection the power to the drives, I edited out their
>>> lines in fstab. I disconnecting the power to sdb and sdc and
>>> started the computer.  It booted for a few lines until it
>>> encountered the line starting with 'start job fgfor device disk by
>>> . . .' (at least that what i jotted down). then t\iot Then it
>>> through the three HD's, two of which had the power unplugged) for
>>> 1 minute and 30 seconds and then went on to tell me that I could
>>> log on as root or ctrl-D to continue.  Ctrl-D didn't work so I
>>> logged oh as root
>>
>> It sounds like you didn't actually comment them out of fstab.

> Well, that should be easy to check: reconnect the drives and boot
> up the system "as normal". And while it's up, I would seriously
> look at those mount point names; I agree, they are awful.
> Create some nice new ones to use with your future disk(s).


I know little to nothing about a raid, but otherwise I would boot with 
the new drive installed and run "blkid" then make appropriate changes to 
the "fstab".
-- 
Jimmy Johnson

Slackware64 Current - Linux 4.19.23 - KDE 4.14.38 - AMD A8-7600 - EXT4 
at sda11
Registered Linux User #380263

[toc] | [prev] | [next] | [standalone]

#205680

Le 23/02/2019 à 08:49, Jimmy Johnson a écrit :
> 
> I know little to nothing about a raid

AFAICS, there is no RAID in this setup.

[toc] | [prev] | [next] | [standalone]

#205672

Stephen P. Molnar composed on 2019-02-22 11:36 (UTC-0500):
...
> # <file system> <mount point>   <type> <options>       <dump>  <pass>
> UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro  0       1
> UUID=d65867da-c658-4e35-928c-9dd2d6dd5742 /sdc1 ext4 errors=remount-ro  0       1
> UUID=007c1f16-34a4-438c-9d15-e3df601649ba /sdc2 ext4 errors=remount-ro  0       1
...
> Obviously, I'm missing something!

Sections of man fstab I suggest for reading (from Buster's version):
1-"The first field", third paragraph. (file system)
2-The example that preceeds "The first field"
3-"The sixth field" (pass)
4-"The fourth field" (mount options)

I've never tried including non-root filesystems in pass 1, so don't know what trouble
might result. Changing those three from 1 to 2 might be a good place to start.

I highly recommend assigning labels to filesystems, and assigning those labels based
upon expected usage and/or mount points and/or drive model. When this is done, fstab
can be much easier to understand, and when necessary, manage. Example:

LABEL=P01M120ESP 	/boot/efi	vfat	codepage=437	0 0
LABEL=p02m120swap		swap	swap	defaults	0 0
LABEL=p03m120res	/data/res	ext2	noatime,nofail	0 0
LABEL=p04m120usrlcl	/usr/local	ext4	noatime		0 2
LABEL=p05m120home	/home		ext4	noatime		0 2
LABEL=p06m120deb09	/data/stretch	ext4	noatime,nofail	0 0
LABEL=p07m120deb10		/	ext4	noatime,errors=remount-ro 0 1
LABEL=tosh06g-videos	/data/videos	ext4	noatime,nofail	0 0
LABEL=mblak02g-misc	/data/misc	ext4	noatime,nofail	0 0
LABEL=st500-01arch	/data/arch	ext4	noatime,noauto	0 0
LABEL=adata16g		/data/music	vfat	codepage=437,noauto 0 0
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web