Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: mbertrand on August 10, 2012, 08:59:49 AM
-
I have a controller that has 2 hard drives. The first one haves Tiny Core installed and the plan is to have the second drive used for
all our logging. What would be the best way to auto mount this second drive.
-
Hi mbertrand
I would just add a mount command to /opt/bootlocal.sh , example:
mount /mnt/sdb1
-
I'm fairly new to Linux. Am I garantied that my second drive will be sdb*. For exemple if user left a usb stick and rebooted the controller could the usb be sdb1 and my second drive sdc1?
Why is it htat in the command "mount /mnt/sdb1" I don't need to specify the device? Does this have to do with fstab?
Also, When is or was fstab created and the /mnt/* folders created?
Is this done on each reboot or during installation?
Sorry for bombarding with questiones I just think I need a better understanding how this is working in Tiny Core.
-
Just realized the fstab is regenerated on each boot as well as mount points create in /mnt.
Is it a script that does this?
-
Hi mbertrand
No, there is no guarantee that devices won't move if you plug in a USB drive. Find out what the device is currently
called, then use the blkid command to find the UUID, here's an example:
tc@box:~$ blkid -s UUID /dev/sda5
/dev/sda5: UUID="6789140d-3ba7-473c-8482-56b96be213f0"
tc@box:~$ You can now guarantee you will get the same drive mounted by using:
mount `blkid -U 6789140d-3ba7-473c-8482-56b96be213f0`
This is not a standard Linux thing as far as I know.
-
Hi mbertrand
I almost forgot, an example to retrieve just the device itself:
tc@box:~$ blkid -U 6789140d-3ba7-473c-8482-56b96be213f0 | cut -c6-
sda5
tc@box:~$
-
Ok, but the problem here is that I'll be producing an image of the primary drive and this will be restored on many controllers.
-
Hi mbertrand
and this will be restored on many controllers.
I take it you mean many different machines.
-
Yes
-
Hi mbertrand
OK, first of all, you will need some way to uniquely identify the target drive, otherwise all bets are off. I'm betting
you are going to say that adding a volume label to drive is inconvenient and that when you perform a restore
the drive may or may not already be partitioned. So here are some sample commands with results from my
machine which uses IDE drives. If you have SATA, you may have to make some changes. Either way, the
target drive must always be on the same port.
tc@box:~$ ls -l /dev/disk/by-path/*
lrwxrwxrwx 1 root root 9 Aug 10 11:42 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 Jun 6 09:50 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jun 6 09:50 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jun 6 09:50 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Aug 10 11:42 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 Aug 2 12:06 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug 10 11:42 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part6 -> ../../sda6
lrwxrwxrwx 1 root root 9 Aug 10 11:42 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:1:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 Aug 10 11:41 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:1:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 Jun 6 09:50 /dev/disk/by-path/pci-0000:00:1f.1-scsi-1:0:0:0 -> ../../sr0
lrwxrwxrwx 1 root root 9 Jun 6 09:50 /dev/disk/by-path/pci-0000:00:1f.1-scsi-1:0:1:0 -> ../../sr1
lrwxrwxrwx 1 root root 9 Aug 10 12:09 /dev/disk/by-path/pci-0000:00:1f.2-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdd
lrwxrwxrwx 1 root root 10 Aug 10 12:09 /dev/disk/by-path/pci-0000:00:1f.2-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 9 Aug 10 11:42 /dev/disk/by-path/pci-0000:00:1f.2-usb-0:2:1.0-scsi-0:0:0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 Aug 10 11:36 /dev/disk/by-path/pci-0000:00:1f.2-usb-0:2:1.0-scsi-0:0:0:0-part1 -> ../../sdc1
tc@box:~$ To retrieve the first IDE drive:
tc@box:~$ ls -l /dev/disk/by-path/* | grep -v "usb" | grep "0:0:0:0" | cut -d ">" -f 2 | cut -d / -f 3 | grep -v [1-9]
sda
tc@box:~$ The ls -l /dev/disk/by-path/* command lists all the drives including the link to their device name.
The first grep excludes any lines containing the word usb
The next grep includes any remaining lines containing the string 0:0:0:0
The first cut command splits those lines into two fields using > as a delimiter, returning the second field (the link)
The next cut splits what remains into three fields using / as a delimiter, returning the third field (the device name)
The last grep eliminates any results containing the number 1 through 9, which in this case leaves sda
-
Thanks I'll look at it on Monday and give you feedback.
Thanks again for your time.
-
Hi mbertrand
No problem. By the way, string 0:0:0:0 identifies this drive as being on IDE port 0 channel 0 (first drive). The second
through fourth drives would be 0:0:1:0, 1:0:0:0, and 1:0:1:0
-
Note that if you mount a partition dedicated to logging with bootlocal.sh of course any logging having started in an earlier stage will not automatically be output to that partition.
-
Hi Rich, I had a look at what you wrote to me on Friday and understand it.
Thanks. In a previous post you suggested to use "mount /mnt/sdb1" . I believe that this folder is created by Tiny on each boot and when fstab is regenerated?
Can I rely on this? The reason is that on each boot I need my second drive mounted because my application is on the first drive and it absolutely needs this drive for reading all of its configuration files and to write. Should I create a script that first verifies if the mount point exists and create it if it does not and then execute the mount command? Or can I rely on Tiny Core?
-
If the drive is there, TC will create the mountpoint. But you really should use a label, uuid or the disk path as mentioned above.
-
Thanks