unRAID Server Release 6.0-beta8-x86_64 Available


limetech

Recommended Posts

  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

All seems to be working great, just re-downloading images now. Thanks!

 

I wasn't 100% sure of the update order but i did the following.

 

Deleted docker plg from plugins.

Updated unraid to beta8 & reboot

Ran btrfs subvolume delete

Started docker and added new img path

Ran  CP for existing template move

Deleted -boot/config/plugins/dockerMan.plg - /Docker-startup.plg  - /dockerMan-2014.08.28.tar.gz

 

I ahve to agree with this post. if you read the upgrade OP it isnt actually clear the correct order to do stuff. I suggest the above is validated and the OP updated ASAP so avoid any problems.

 

Nice work.

Link to comment

Sorry for the question, but I have been out of the loop and don't quite understand it yet.

 

On beta 4 I used a Linux vm on my cache disk and did all my downloading there. I wrote new downloads to the cache disk and mover then did it's job.

 

Now with the new .img for docker, could I buy a, say, 64GB SSD and use that for the img storage and use my current cache disk as the download location?!

So I would have the SSD just for docker and the 500GB cache as cache and download location.

 

Would you recommend that procedure, or do you have any suggestions?!

Am I understanding that right?

 

I am not interested in cache pooling.

 

Link to comment

So as I understand it - We do not need a BTRFS formatted device anomore - It is handled by the image file created. correct?

That is correct!  But if you want redundancy in the 'cache' it has to be btrfs.

 

For redundant cache do I need same size drives? if I use different size drives will I be limited to the smaller size drive? is it like raid 1?

 

Link to comment

What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1?

 

In the posted notes, under 6.0-beta7-x86 64 it states the following.

emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

  This will be put back in next release.

 

I guess there are more important things to work on.  This cannot be that difficult.  Why cant the commands be posted so we can extend the partitions ourselves?

Link to comment

Great job Tom!

 

One question for you... how are the instructions different for those of us who had a dedicated disk outside of the array for Docker (i.e. not cache drive).

 

Right, if you enter the block device partition (eg, /dev/sdg1) in the field for "Docker image file" it will mount that btrfs partition onto /var/lib/docker.

 

Kept that capability just for you, btw.  Not recommended.

 

This seems a rather fragile solution.

 

The device designation could change boot to boot.

 

Would there be a danger if the device changed and suddenly the device (e.g., /dev/sdg1) is assigned to an array disk or the parity disk or whatever?

 

I currently have this in my go file ...

 

#-------------------

# mount btrfs (SSD)

#-------------------

mkdir -p /mnt/btrfs

mount /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSCF31xxxxx-part1 /mnt/btrfs

 

Could this be altered to do the equivalent of the configuration above in a more boot friendly way?

Link to comment

I'm a tad confused. Right now I have /mnt/cache/docker and in there I have a directory called "appdata". In my docker apps, I use appdata as the "host path" for container volume.

 

The instructions call to delete /mnt/cache/docker, but I'd like to keep my databases and configuration. Can I continue to use /mnt/cache/docker/appdata as the host path for container volumes or should I be migrating to something else?

Link to comment

What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1?

 

In the posted notes, under 6.0-beta7-x86 64 it states the following.

emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

  This will be put back in next release.

 

It seems like this question wasn't spotted with all the focus and excitement on docker.

 

LimeTech, jonp, can you please indicate if this release beta8 has the ability to resize drives on rebuild if using ReiserFS?

Link to comment

What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1?

 

In the posted notes, under 6.0-beta7-x86 64 it states the following.

emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

  This will be put back in next release.

 

I guess there are more important things to work on.  This cannot be that difficult.  Why cant the commands be posted so we can extend the partitions ourselves?

 

CAVEAT EMPTOR:

 

I am not certain about this, but I think this you'd have to do so on the /dev/md# device while the /dev/disk# are unmounted.

 

If your filesystem is ReiserFS, you can grow the filesystem using: /sbin/resize_reiserfs . The default behavior is to grow to use the available space and be verbose to show extra progress status messages. This must be done on an unmounted filesystem.

 

If your filesystem is ext2, ext3, or ext4, you can grow the filesystem using: /sbin/resize2fs -p .  The default behavior is to grow to use the available space. The -p option [lowercase p] means to be verbose to show extra progress status messages. This must be done on an unmounted filesystem.

 

If your filesystem is btrfs, you can grow the filesystem using:  btrfs .

btrfs filesystem resize [<devid>:][+/-]<newsize>[gkm]|max <filesystem>

Resize a filesystem identified by <path>. The <size> parameter specifies the new size of the filesystem. If the prefix + or - is present the size is increased or decreased by the quantity <size>. If no units are specified, the unit of the <size> parameter defaults to bytes. Optionally, the size parameter may be suffixed by one of the following the units designators: 'K', 'M', or 'G', kilobytes, megabytes, or gigabytes, respectively.

If 'max' is passed, the filesystem will occupy all available space on the volume(s).

 

Link to comment

What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1?

 

In the posted notes, under 6.0-beta7-x86 64 it states the following.

emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

  This will be put back in next release.

 

I guess there are more important things to work on.  This cannot be that difficult.  Why cant the commands be posted so we can extend the partitions ourselves?

 

CAVEAT EMPTOR:

 

I am not certain about this, but I think this you'd have to do so on the /dev/md# device while the /dev/disk# are unmounted.

 

If your filesystem is ReiserFS, you can grow the filesystem using: /sbin/resize_reiserfs . The default behavior is to grow to use the available space and be verbose to show extra progress status messages. This must be done on an unmounted filesystem.

 

If your filesystem is ext2, ext3, or ext4, you can grow the filesystem using: /sbin/resize2fs -p .  The default behavior is to grow to use the available space. The -p option [lowercase p] means to be verbose to show extra progress status messages. This must be done on an unmounted filesystem.

 

If your filesystem is btrfs, you can grow the filesystem using:  btrfs .

btrfs filesystem resize [<devid>:][+/-]<newsize>[gkm]|max <filesystem>

Resize a filesystem identified by <path>. The <size> parameter specifies the new size of the filesystem. If the prefix + or - is present the size is increased or decreased by the quantity <size>. If no units are specified, the unit of the <size> parameter defaults to bytes. Optionally, the size parameter may be suffixed by one of the following the units designators: 'K', 'M', or 'G', kilobytes, megabytes, or gigabytes, respectively.

If 'max' is passed, the filesystem will occupy all available space on the volume(s).

 

 

Thanks.  I appreciate this.  However, Tom has posted several times that he will post the "supported" procedure for doing this.  I'm going to wait for him to do so.

Link to comment

I'm at a loss here, everything was well in Beta 7, now this docker move fiasco and everything is broken!

 

I likely did everything wrong, didn't properly backup, and likely lost my MariaDB database.

 

So help is appreciated.

 

This is what I have at this point, a basically fresh Beta 8 install.

Under extensions I have docker, it does nothing.

If I click start, it does not.

In that page it says docker image /mnt/disk1/docker.img

I don't have one there, no clue if I'm supposed to put one there?..

So I hit start, it does nothing. Do I need to put an image there, was it supposed to do this automatically and I fucked it up?

Damn did this all work well before prior to this upgrade!

 

It states that

"When you visit the Extensions/Docker page you will notice a box to enter a Docker image file.  When you click 'Start' the file name you specify will be created and a btrfs file system will be created inside that file.  Next the file is loop mounted onto /var/lib/docker.  You are also able to resize the file (expand only, shrink not supported yet), and scrub (check) the file system.  The default size of "10" (meaning 10GB) seems reasonable to start with."

 

I never get an option to "enter a docker image file" it is listed as disk 1 and greyed out. When I hit start it does nothing, nada..

 

Link to comment

I never get an option to "enter a docker image file" it is listed as disk 1 and greyed out. When I hit start it does nothing, nada..

 

That text you see greyed out is called a "placeholder" - it's just an example of what you can type.  Click in the box and you will see it turn blank and you can enter filename path such as

/mnt/disk1/docker.img  [will be created in root of /mnt/disk1]

or

/mnt/disk1/docker/docker.img [directory, aka share, docker must already exist]

 

You don't have to use /mnt/disk1.  Could use /mnt/disk2 or /mnt/cache.

 

You don't have to name it docker.img.  Could be docker1.img or my-docker.img or test-docker.img

 

You don't have to give it an img extension.  Could give it any extension or no extension.

 

RIGHT this could be implemented a bit clearer - I'm not a fan of the 'placeholder' attribute because of this exact possible confusion.

 

BUT this is BETA software.  Rough edges are to be expected and some understanding and willingness to look at some code (eg. /etec/rc.d/rc.docker) goes a long way to understand what the s/w is trying to achieve.

 

Edit: the reason an actual default is not in that 'Docker image' field is because upon first boot it would use it!  And maybe you don't want it that way.  Also if you leave the field blank it effectively disables docker - it won't load at all - for those who don't want Docker.

Link to comment

I never get an option to "enter a docker image file" it is listed as disk 1 and greyed out. When I hit start it does nothing, nada..

 

It's grayed out as an example. Click on the box and type your path to wherever you want your docker img to be located (I have mine on my cache drive (that I don't use as cache), as I didn't see the point of having it on the array) Hit start, follow the rest of the directions. If you've already deleted your docker directory on the cache drive, then yeah, you probably lost your database and whatever else you were previously using unless you have a copy on the array.

 

I kept my previous cache/docker host container directories and asked the question about it a few posts up (not answered yet) because it isn't very clear. I think they assume your docker's data is stored on the array, which obviously isn't the case for everyone.

 

I thought I'd add that after moving over my existing templates and re-downloading, everything works as well as before. If the benefit of having the loopback image is for ease-of-backup, I'm not convinced of the benefits vs just allowing us to add an additional "non-cache non-array data drive" in unraid. I still have to deal with container volumes and host paths that are outside of the image - unless I should be using host paths IN the image.

Link to comment

So as I understand it - We do not need a BTRFS formatted device anomore - It is handled by the image file created. correct?

That is correct!  But if you want redundancy in the 'cache' it has to be btrfs.

 

For redundant cache do I need same size drives? if I use different size drives will I be limited to the smaller size drive? is it like raid 1?

 

A google search and a little reading goes a long way:

https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_space_do_I_get_with_unequal_devices_in_RAID-1_mode.3F

 

Link to comment

Thank you to the both of you, and I apologize for my frustration.

I understand the "beta" part, and also understand the need for the change even though I didn't experience the out of space issues yet.

 

The greyed out area was odd, it took me a couple of clicks and it allowed me to type.

I assumed the initial place for /mnt/disk1 when I hit start would do something, however it just changed for a second and went back to stopped.

This must be because it is merely a suggested place, and not actually typed as the location. So when I hit start, it didn't have a location to go to so it failed.

 

Now that I was able to type /mnt/cache/docker.img it created it just fine, did it's thing, and now it is running!!!

 

I did backup the programs I had as far as the directory, and I also have their templates.

I will now continue to attempt to get them back setup.

 

Link to comment

Great job Tom!

 

One question for you... how are the instructions different for those of us who had a dedicated disk outside of the array for Docker (i.e. not cache drive).

 

Right, if you enter the block device partition (eg, /dev/sdg1) in the field for "Docker image file" it will mount that btrfs partition onto /var/lib/docker.

 

Kept that capability just for you, btw.  Not recommended.

 

This seems a rather fragile solution.

 

The device designation could change boot to boot.

 

Would there be a danger if the device changed and suddenly the device (e.g., /dev/sdg1) is assigned to an array disk or the parity disk or whatever?

 

I currently have this in my go file ...

 

#-------------------

# mount btrfs (SSD)

#-------------------

mkdir -p /mnt/btrfs

mount /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSCF31xxxxx-part1 /mnt/btrfs

 

Could this be altered to do the equivalent of the configuration above in a more boot friendly way?

 

I think you should be able to use '/dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSCF31xxxxx-part1' as the 'Docker image:' - did you try it?

Link to comment

What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1?

 

In the posted notes, under 6.0-beta7-x86 64 it states the following.

emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

  This will be put back in next release.

 

I guess there are more important things to work on.  This cannot be that difficult.  Why cant the commands be posted so we can extend the partitions ourselves?

 

If it's reiserfs and it's that critical to you, you can boot -beta6, let it do it's thing, then put -beta8 back on.

Link to comment

I'm a tad confused. Right now I have /mnt/cache/docker and in there I have a directory called "appdata". In my docker apps, I use appdata as the "host path" for container volume.

In your case you shouldn't delete /mnt/cache/docker if you have your app data in there too.

 

The instructions call to delete /mnt/cache/docker, but I'd like to keep my databases and configuration. Can I continue to use /mnt/cache/docker/appdata as the host path for container volumes or should I be migrating to something else?

Personally I would have a share named 'appdata', then you can put it anywhere that makes sense.

Link to comment

Alright, I'm calm now and good to go!

 

The only docker I really cared about was MariaDB and my XBMC library.

Once I transferred it's template I installed it, stopped the newly made docker, replaced the new folder with my old (backed up) MariaDB program folder, and it started and worked perfectly!!

 

I apologize for my frustration, it was frustrating and I always think "I've got this, no problem" and, well, ... nope. I should backup better just in case in the future.

All is well..

Link to comment

All seems to be working great, just re-downloading images now. Thanks!

 

I wasn't 100% sure of the update order but i did the following.

 

Deleted docker plg from plugins.

Updated unraid to beta8 & reboot

Ran btrfs subvolume delete

Started docker and added new img path

Ran  CP for existing template move

Deleted -boot/config/plugins/dockerMan.plg - /Docker-startup.plg  - /dockerMan-2014.08.28.tar.gz

 

Ran this same process, so far so good. Yet to test anything on it though (plex, etc.). But I was able to re-download images just fine using my previous templates.

 

Did a reboot with all docker images set to auto start, things came up like they did in beta6.

 

APC UPS appears to still be working, status is good in the UI (untested though by unplugging power to UPS).

 

Appreciate the walkthrough! I'll update once I've started using it for watching shows.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.