Manjaro Difference between pages "Fstab - Use SystemD automount" and "Some basics of MBR v/s GPT and BIOS v/s UEFI"

Difference between pages "Fstab - Use SystemD automount" and "Some basics of MBR v/s GPT and BIOS v/s UEFI"

From Manjaro
(Difference between pages)
imported>DeMus
 
imported>Aaditya
 
Line 1: Line 1:
=Introduction=
== MBR ==


I found a combination of systemd options (on the ArchWiki [https://wiki.archlinux.org/index.php/Systemd#Automount]) that can be used in the /etc/fstab when mounting storage devices --be they internal, external, or network shares.  
A master boot record (MBR) is a special type of boot sector at the very beginning of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.


The magic (to me) that these mount options bring is that if a network share or an external drive that is being called via /etc/fstab is not present, they save your machine from hanging for a minute or two during the boot process.
The MBR holds the information on how the logical partitions, containing file systems, are organized on that medium. Besides that, the MBR also contains executable code to function as a loader for the installed operating system—usually by passing control over to the loader's second stage, or in conjunction with each partition's volume boot record (VBR). This MBR code is usually referred to as a boot loader.


A device called this way via /etc/fstab is mounted the first time data is attempted to be accessed from it. Only on this first mount is there any (minor) noticeable delay, when compared to having the device mounted the "old" way.
The organization of the partition table in the MBR limits the maximum addressable storage space of a disk to 2 TB (232 × 512 bytes).[1] Therefore, the MBR-based partitioning scheme is in the process of being superseded by the GUID Partition Table (GPT) scheme in new computers. A GPT can coexist with an MBR in order to provide some limited form of a backwards compatibility for older systems.


<br clear="all"/>
From http://en.wikipedia.org/wiki/Master_boot_record
==A suitable problem example==


I have a ReadyNAS Duo v1, which is connected to my LAN. These days I quite often turn it off as it doesn't need to run perpetually.


A problem that this causes is that if I forget to comment out the NFS share(s) that I'm using from the /etc/fstab file, I have to wait for a minute or two during the boot process whilst the system repetitively tries to make a connection.
== GPT ==


I attempted to get AutoFS [https://wiki.manjaro.org/index.php?title=Using_autofs_(automount)_with_NFS]to work for me. I got close but I just wasn't allowed to see the files on the NFS NAS share.
GUID Partition Table (GPT) is a standard for the layout of the partition table on a physical hard disk, using globally unique identifiers (GUID). Although it forms a part of the Unified Extensible Firmware Interface (UEFI) standard (Unified EFI Forum proposed replacement for the PC BIOS), it is also used on some BIOS systems because of the limitations of master boot record (MBR) partition tables, which use 32 bits for storing logical block addresses (LBA) and size information.


So then I found the following extremely simple & effective solution. (Wish I had of done this one first, as it would have saved me a couple of hours of a loosing battle!)
MBR-based partition table schemes insert the partitioning information for (usually) four "primary" partitions in the master boot record (MBR) (which on a BIOS system is also the container for code that begins the process of booting the system). In a GPT, the first sector of the disk is reserved for a "protective MBR" such that booting a BIOS-based computer from a GPT disk is supported, but the boot loader and O/S must both be GPT-aware. Regardless of the sector size, the GPT header begins on the second logical block of the device.


<br clear="all"/>
From http://en.wikipedia.org/wiki/GUID_Partition_Table
 
==How do you do use it?==
 
Add the following to the beginning of the options section in your /etc/fstab, the numbers at the end are a time limit for how long it should try to make a connection before giving up & moving on:
 
noauto,x-systemd.automount,x-systemd.device-timeout=10
 
After I added the above to the following line in my fstab:
 
192.168.1.15:/media-2  /mnt/NAS-media-2 nfs    noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,hard,intr,noatime 0 0
 
I could boot Manjaro whilst the ReadyNAS' Cat-6 network cable was unplugged, & there was NO noticeable delay. After the system was booted, I plugged the cable in & then called the NFS share /media-2 in Worker & it read the drive & listed the contents.
 
After that I unplugged the drive, which had Worker (my file manager of choice) looking for it as I hadn't changed out of the the media-2 directory. When I plugged the cable back in, it took ~10 seconds or so & then Worker automatically re-listed the contents or this very large partition that has well over 2000 directories, each holding multiple files.
 
<br clear="all"/>
===Speed up your boot===
 
If you have a very large /home & the boot process is held up when a scheduled fsck takes place (really not a big problem if you are using ext4), you can add the '''x-systemd.automount''' section to the options section of the line in your fstab for /home like so:
 
UUID=<id.number> /home noauto,x-systemd.automount,ext4 defaults 0 1
 
This will allow services that do not depend on /home to start while /home is checked by fsck. Mounting /home when it is first accessed, the kernel will buffer all file access to /home until it is ready.
 
<br clear="all"/>
 
 
 
[[Category:Contents Page]]

Revision as of 03:11, 5 March 2014

MBR

A master boot record (MBR) is a special type of boot sector at the very beginning of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.

The MBR holds the information on how the logical partitions, containing file systems, are organized on that medium. Besides that, the MBR also contains executable code to function as a loader for the installed operating system—usually by passing control over to the loader's second stage, or in conjunction with each partition's volume boot record (VBR). This MBR code is usually referred to as a boot loader.

The organization of the partition table in the MBR limits the maximum addressable storage space of a disk to 2 TB (232 × 512 bytes).[1] Therefore, the MBR-based partitioning scheme is in the process of being superseded by the GUID Partition Table (GPT) scheme in new computers. A GPT can coexist with an MBR in order to provide some limited form of a backwards compatibility for older systems.

From http://en.wikipedia.org/wiki/Master_boot_record


GPT

GUID Partition Table (GPT) is a standard for the layout of the partition table on a physical hard disk, using globally unique identifiers (GUID). Although it forms a part of the Unified Extensible Firmware Interface (UEFI) standard (Unified EFI Forum proposed replacement for the PC BIOS), it is also used on some BIOS systems because of the limitations of master boot record (MBR) partition tables, which use 32 bits for storing logical block addresses (LBA) and size information.

MBR-based partition table schemes insert the partitioning information for (usually) four "primary" partitions in the master boot record (MBR) (which on a BIOS system is also the container for code that begins the process of booting the system). In a GPT, the first sector of the disk is reserved for a "protective MBR" such that booting a BIOS-based computer from a GPT disk is supported, but the boot loader and O/S must both be GPT-aware. Regardless of the sector size, the GPT header begins on the second logical block of the device.

From http://en.wikipedia.org/wiki/GUID_Partition_Table

Cookies help us deliver our services. By using our services, you agree to our use of cookies.