How to attach and detach additional volumes to an existing C1 server | Scaleway


#21

Could you please share the link to the CentOS 7 guide?


#22

Same information also top on this page.

Guide : https://www.scaleway.com/docs/attach-and-detach-a-volume-to-an-existing-server/


#23

any chance of getting actual working guide ?


#24

Now it works on Ubuntu Xenial without the nobootwait.
/dev/nbd1 /mnt/data auto defaults,errors=remount-ro 0 2

I believe that previously it didn’t work due to some kernel issues, but I doubt we’ll ever have any official confirmation.


#25

Damn I am awake until 5 am just because of nobootwait


#26

I had found this working guide for Ubuntu 16.04 http://pastebin.com/print/6CAHkyns
And it is really working.


#27

The fstab mounting problem with new distributions is caused by the following:

  • fstab parsed and mounted by systemd
  • systemd waits on device activation from udev
  • udev doesn’t activate device because its initialized by scaleway prior to boot

To fix the problem you need to tell udev that the device is already initialized. You can do this by creating the following udev rule.
File Name:
/etc/udev/rules.d/99-x-fix-mount.rules
File Content:
KERNEL=="nbd1", ENV{SYSTEMD_READY}="1"

fstab option nobootwait is not required with this workaround


#28

Scaleway, what are you doing here ?

Your clients need to know how to mount a volume on boot, please make that official with a clear documentation.

My Debian Jessie host never reboot after the modifications…


#29

This is particularly insidious because these instructions will work to mount a new volume on a server that’s already up and running, but it will cause it to hang the next time it’s rebooted, which may be much later.

After trying pretty much all of the above suggestions, none of which worked for me, I hassled scaleway support about this (who denied it was their problem), and they finally gave me a link to this page.

It shows how to attach volumes using systemd, without using fstab, and following that example worked. I think the idea is that it mounts the volume later in the boot sequence, at which point all the necessary parts of the system are available.

If you’re doing this in recovery mode, you need to bear in mind that when you see directions about editing files in /etc, then you do so in your mounted system volume, not in the system you’re booted into, i.e. in /mnt/volume0/etc/..., not /etc/..., and you don’t need to run the sysctl commands until after you’ve booted back into your system.


#31

Note that the “noobootwait” option has been removed in ubuntu 16


#32

Thanks Synchro !
Now my /dev/nbd1 is mounted at each reboot, cool !
I leave fstab empty, I use your link [Automatic mounting of additional volumes using systemD on Ubuntu]

It worked for me (Debian 8 Jessie)


#33

This works for me, using fstab:

root@gitlab:~# lsb_release -irc
Distributor ID:	Debian
Release:	8.7
Codename:	jessie
root@gitlab:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
none            7.4G     0  7.4G   0% /dev
tmpfs           1.5G   22M  1.5G   2% /run
/dev/vda         46G   17G   27G  39% /
tmpfs           7.4G  4.0K  7.4G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.4G     0  7.4G   0% /sys/fs/cgroup
root@gitlab:~# cat /etc/fstab 
# UNCONFIGURED FSTAB FOR BASE SYSTEM
root@gitlab:~# fdisk -l
Disk /dev/vda: 46.6 GiB, 50000000000 bytes, 97656250 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/vdb: 46.6 GiB, 50000000000 bytes, 97656250 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/vdc: 93.1 GiB, 100000000000 bytes, 195312500 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@gitlab:~# blkid
/dev/vda: UUID="e3ecda16-f2b2-4c8d-bc51-eb34824099ee" TYPE="ext4"
/dev/vdb: UUID="6713f247-989d-4365-9880-f0ef5b715dca" TYPE="ext4"
/dev/vdc: UUID="e77a4025-786b-482a-aa0d-781ce85b4487" TYPE="ext4"

or

root@gitlab:~# ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 9 Apr 16 06:33 6713f247-989d-4365-9880-f0ef5b715dca -> ../../vdb
lrwxrwxrwx 1 root root 9 Apr 16 05:46 e3ecda16-f2b2-4c8d-bc51-eb34824099ee -> ../../vda
lrwxrwxrwx 1 root root 9 Apr 16 06:33 e77a4025-786b-482a-aa0d-781ce85b4487 -> ../../vdc

Attach and automount storage:

root@gitlab:~# mkdir /home/git
root@gitlab:~# echo "UUID=6713f247-989d-4365-9880-f0ef5b715dca /home/git ext4 errors=remount-ro 0 1" >> /etc/fstab
root@gitlab:~# mount /home/git/

root@gitlab:~# mkdir /var/chroot
root@gitlab:~# echo "UUID=e77a4025-786b-482a-aa0d-781ce85b4487 /var/chroot ext4 errors=remount-ro 0 1" >> /etc/fstab
root@gitlab:~# mount /var/chroot/

root@gitlab:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
none            7.4G     0  7.4G   0% /dev
tmpfs           1.5G   22M  1.5G   2% /run
/dev/vda         46G   17G   27G  39% /
tmpfs           7.4G  4.0K  7.4G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.4G     0  7.4G   0% /sys/fs/cgroup
/dev/vdb         46G   52M   44G   1% /home/git
/dev/vdc         92G   60M   87G   1% /var/chroot