unRAID Server Release 6.0-beta7-x86_64 Available

[MSattler]

Upgraded from Beta5 with no issues.

 

My Xen Windows 8 VM ran fine in Beta 5 with PCI Passthrough.  In Beta 6 it would not start even without PCI passthrough and I reverted back to Beta 5.  In Beta 7 it will run without PCI Passthrough but not with.

 

Was anything Xen wise updated in Beta7?

 

Also, how do we request things to be added to the roadmap?  Such as multiple array's per tower?  Didn't see it listed in the 6.1/6.2/Unscheduled forums.

 

Thanks!

[jonp]

Upgraded from Beta5 with no issues.

 

My Xen Windows 8 VM ran fine in Beta 5 with PCI Passthrough.  In Beta 6 it would not start even without PCI passthrough and I reverted back to Beta 5.  In Beta 7 it will run without PCI Passthrough but not with.

 

Was anything Xen wise updated in Beta7?

 

Also, how do we request things to be added to the roadmap?  Such as multiple array's per tower?  Didn't see it listed in the 6.1/6.2/Unscheduled forums.

 

Thanks!

 

I don't believe Xen was manipulated at all for this release.  The Linux kernel has been upgraded though.

 

Xen still has issues here and there with ongoing support/compatibility I think.  We've had much better success and more consistent results with VMs running under KVM.

[MSattler]

Upgraded from Beta5 with no issues.

 

My Xen Windows 8 VM ran fine in Beta 5 with PCI Passthrough.  In Beta 6 it would not start even without PCI passthrough and I reverted back to Beta 5.  In Beta 7 it will run without PCI Passthrough but not with.

 

Was anything Xen wise updated in Beta7?

 

Also, how do we request things to be added to the roadmap?  Such as multiple array's per tower?  Didn't see it listed in the 6.1/6.2/Unscheduled forums.

 

Thanks!

 

I don't believe Xen was manipulated at all for this release.  The Linux kernel has been upgraded though.

 

Xen still has issues here and there with ongoing support/compatibility I think.  We've had much better success and more consistent results with VMs running under KVM.

 

Yeah, just don't feel like starting from scratch and spending the time to rebuild the VM for KVM.  That one VM is what I use for most of the work I do at home.  So I don't really like having downtime for it, especially since I use it remotely from work as well.

 

I've disabled PCI passthrough for now.

[jonp]

Yeah, just don't feel like starting from scratch and spending the time to rebuild the VM for KVM.  That one VM is what I use for most of the work I do at home.  So I don't really like having downtime for it, especially since I use it remotely from work as well.

 

I've disabled PCI passthrough for now.

 

How are you assigning the devices for PCI passthrough before starting the VM?  Do you have a go script for assigning them or what?  Also please share with me what you have in your syslinux.cfg.  Lastly, please try making the following changes to your VM config file:

 

CHANGE "memory" to ~3GB:

memory = '3072'

 

Remove these lines or comment them out:

device_model_version="qemu-xen-traditional"
sdl = '0'
vnc = '1'
vnclisten = '0.0.0.0'
vncpasswd = 'army1234'
stdvga = '0'
usb = '1'
usbdevice = 'tablet'

 

FYI, you can use the VNC stuff and usb tablet if you're not doing GPU pass through.  If you need remote access to your VM with GPU pass through enabled, I'd suggest installing a VNC client in the VM or enabling Windows Remote Desktop.

 

Send me back a syslog after trying this stuff.

 

[jbrodriguez]

wanted to share my experience ...

 

upgraded from 5.0.4 to 6b7 and everything went pretty smooth

 

couple of notes

- Plugin Status

i'm not sure what the status of plugins/system services (not docker "plugins") is right now. i need to run powerdown, openssh, screen and rsync as daemon.

i installed powerdown via a plg in /boot/config/plugins

openssh, screen and the associated utempter don't have a plg, so i copied the slacwkware packages (txz) to /boot/extra (initially i installed the 32bit versions, which obviously didnt work).

i also need to have a script that sets up the rsync daemon the way i need it to be

for these kind of "services" what is the preferred way to install/configure them going forward ?

 

- Docker

i dont have a btrfs drive yet, so the docker daemon is not running (saw something along those lines in the syslog)

i understand that having a btrfs drive is a prerrogative ?

i'm not really thinking of running containers in this machine, but it's good to know that it's available if needed

 

 

- Speed

i just made a quick test with a small mkv (1.5gb or so) and write speed was through the roof (when writing directly to the disk share).

i was generally getting around 30-35 MB/s with 5.0.4.

while copying this file i was seeing bursts in excess of 100MB/s, and in the end it got transferred at an average of 78.56 MB/s.

this is awesome !! will test further, but definitely looks promising

 

 

- Filesystem choice

this is more of a question: can you mix fs ? all disks with reiserfs, but as they die, are replaced with a new disk under btrfs? or xfs?

 

all in all, it looks like an awesome release !

[jumperalex]

I hope this is where you want stuff like this Tom / Jon

 

Upgrading from 6.0b5a

Add-ons:

- Xen Arch VM with

  -- Transmission 2.84

  -- Plex Media Server 9.9.16

  -- Transmission-rss

- apcupsd 3.14.12

- powerdown-2.06-noarch-unRAID

- "modprobe it87" for sensors with custom config

 

Results:

- Arch VM started fine

- Plex starts and plays just fine

- Xen VM shuts down fine (gui still fails to update without manual refresh)

- Xen VM restarts fine

- apcupsd seems to be working fine

"- modprobe it87" and sensors working

- Gui reboot seems to stop the Xen VM cleanly and restart on boot

- Running a bunch of torrents in transmission isn't generating network errors (WOOT!)

- built-in htop is working fine

- streaking a video from plex (lots of network activity) working fine

 

!!! I hope it is just coincidence but my router just rebooted for the first time ever.

 

about 10 minutes in:

Aug 23 14:56:58 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 19 slots
Aug 23 14:58:34 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
...
Aug 23 15:01:45 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 19 slots
Aug 23 15:01:45 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
...
started another torrent
...
Aug 23 15:19:00 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
Aug 23 15:19:00 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots

 

I used to get a few of these in the past i think so this isn't too bad.

 

It is still early days, but I would say beta7 and Xen are pretty stable.

 

 

[jonp]

wanted to share my experience ...

 

upgraded from 5.0.4 to 6b7 and everything went pretty smooth

 

Glad to hear it!

 

- Plugin Status

i'm not sure what the status of plugins/system services (not docker "plugins") is right now. i need to run powerdown, openssh, screen and rsync as daemon.

 

Many things that were formally installed as plugins can now install as Containers through Docker.  However, things that modify how the system operates such as powerdown and the others are not all yet available as Containers and may not be appropriate to live in a container either.  You'll need to check the forums for the plugins you've been using to see if the author has made an unRAID 6 (64-bit) variant is available.  SSH is built into unRAID 6.  Telnet access is available by default without a password.  SSH requires you to set a password to your root username right now to user it.

 

for these kind of "services" what is the preferred way to install/configure them going forward ?

 

Some may become upgraded exactly as they have been, rolled into core features, or possibly replaced by a Docker Container or a Virtual Machine.  There are numerous ways to achieve what you want with unRAID 6, but remember, this is still beta.

 

- Docker

i dont have a btrfs drive yet, so the docker daemon is not running (saw something along those lines in the syslog)

i understand that having a btrfs drive is a prerrogative ?

 

Use of Docker on unRAID 6 requires the installation to go to a BTRFS formatted device (cache or pool).

 

- Speed

i just made a quick test with a small mkv (1.5gb or so) and write speed was through the roof (when writing directly to the disk share).

i was generally getting around 30-35 MB/s with 5.0.4.

while copying this file i was seeing bursts in excess of 100MB/s, and in the end it got transferred at an average of 78.56 MB/s.

this is awesome !! will test further, but definitely looks promising

 

How many devices are in your system?  You may be seeing the benefits of Turbo Write in action...

 

- Filesystem choice

this is more of a question: can you mix fs ? all disks with reiserfs, but as they die, are replaced with a new disk under btrfs? or xfs?

 

Yes, you can mix.  When you go to rebuild a disk, it will rebuild it with the filesystem that was previously formatted on that disk.

 

all in all, it looks like an awesome release !

 

Thanks for your feedback and I highly suggest trying out Docker!

[jonp]

I hope this is where you want stuff like this Tom / Jon

 

Upgrading from 6.0b5a

Add-ons:

- Xen Arch VM with

  -- Transmission 2.84

  -- Plex Media Server 9.9.16

  -- Transmission-rss

- apcupsd 3.14.12

- powerdown-2.06-noarch-unRAID

- "modprobe it87" for sensors with custom config

 

Results:

- Arch VM started fine

- Plex starts and plays just fine

- Xen VM shuts down fine (gui still fails to update without manual refresh)

- Xen VM restarts fine

- apcupsd seems to be working fine

"- modprobe it87" and sensors working

- Gui reboot seems to stop the Xen VM cleanly and restart on boot

- Running a bunch of torrents in transmission isn't generating network errors (WOOT!)

- built-in htop is working fine

- streaking a video from plex (lots of network activity) working fine

 

!!! I hope it is just coincidence but my router just rebooted for the first time ever.

 

about 10 minutes in:

Aug 23 14:56:58 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 19 slots
Aug 23 14:58:34 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
...
Aug 23 15:01:45 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 19 slots
Aug 23 15:01:45 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
...
started another torrent
...
Aug 23 15:19:00 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
Aug 23 15:19:00 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots

 

I used to get a few of these in the past i think so this isn't too bad.

 

It is still early days, but I would say beta7 and Xen are pretty stable.

 

Hmm, those are the errors we are looking to find and were hoping were squashed.  Let me know if they persist and how they affect your VMs.  Also post your config for the VM and your network.cfg settings.  Need to see some details to help diagnose.

[heffe2001]

Just updated to b7 (also added in a old LSI controller and a few drives), and the system booted back up fine, found the new controller and drives without any problem (preclearing those drives now as sort of a stress-test for that controller/drive combo, all 3 at once).  I'm running a good many dockers at the moment, and have the extended docker config page plugin installed.  I'm currently running:  Couchpotato, Deluge, duckdns, headphones, lazylibrarian, Maraschino (for plex), NZBDrone, NZBGet and PlexMediaServer.  I noticed at startup that Plex couldn't access any media files (my volume maps weren't working), so it appears that with them set to auto-start, they get started before the array came online.  A stop/start of each of them fixes the issue though..  I'll also post this in the proper forum, just wanted to post it in case anybody else saw it in this thread..

 

[jonp]

Just updated to b7 (also added in a old LSI controller and a few drives), and the system booted back up fine, found the new controller and drives without any problem (preclearing those drives now as sort of a stress-test for that controller/drive combo, all 3 at once).  I'm running a good many dockers at the moment, and have the extended docker config page plugin installed.  I'm currently running:  Couchpotato, Deluge, duckdns, headphones, lazylibrarian, Maraschino (for plex), NZBDrone, NZBGet and PlexMediaServer.  I noticed at startup that Plex couldn't access any media files (my volume maps weren't working), so it appears that with them set to auto-start, they get started before the array came online.  A stop/start of each of them fixes the issue though..  I'll also post this in the proper forum, just wanted to post it in case anybody else saw it in this thread..

 

Thanks for letting us know!  Glad to hear you upgraded with great success here!  Let us know how your continued use of the system goes!

[MSattler]

Yeah, just don't feel like starting from scratch and spending the time to rebuild the VM for KVM.  That one VM is what I use for most of the work I do at home.  So I don't really like having downtime for it, especially since I use it remotely from work as well.

 

I've disabled PCI passthrough for now.

 

How are you assigning the devices for PCI passthrough before starting the VM?  Do you have a go script for assigning them or what?  Also please share with me what you have in your syslinux.cfg.  Lastly, please try making the following changes to your VM config file:

 

CHANGE "memory" to ~3GB:

memory = '3072'

 

Remove these lines or comment them out:

device_model_version="qemu-xen-traditional"
sdl = '0'
vnc = '1'
vnclisten = '0.0.0.0'
vncpasswd = ''
stdvga = '0'
usb = '1'
usbdevice = 'tablet'

 

FYI, you can use the VNC stuff and usb tablet if you're not doing GPU pass through.  If you need remote access to your VM with GPU pass through enabled, I'd suggest installing a VNC client in the VM or enabling Windows Remote Desktop.

 

Send me back a syslog after trying this stuff.

 

FWIW, in Beta5 I could allow VNC to be enabled in the config, and still be able to passthrough video with no issues.  I typically use RDP to access the VM, however, when enabling passthrough in beta5, it was helpful to see what the OS was doing if it wasn't coming up.

 

I've tried what you suggested, just as I did with beta6, and although it at least runs with pci passthrough disabled, I just get continued reboots when I try to enable it.

 

Syslinux.cfg:

 

default /syslinux/menu.c32

menu title Lime Technology

prompt 0

timeout 50

label unRAID OS

  kernel /bzimage

  append initrd=/bzroot

label unRAID OS Safe Mode (no plugins)

  kernel /bzimage

  append initrd=/bzroot unraidsafemode

label Memtest86+

  kernel /memtest

label Xen/unRAID OS

  menu default

  kernel /syslinux/mboot.c32

  append /xen dom0_mem=2097152 --- /bzimage xen-pciback.hide=(01:00.1)(01:00.0)(07:00.0)(00:1b.0) --- /

bzroot

label Xen/unRAID OS Safe Mode (no plugins)

  kernel /syslinux/mboot.c32

  append /xen dom0_mem=2097152 --- /bzimage --- /bzroot unraidsafemode

 

 

VM Config file:

 

name = 'myvm'

builder = 'hvm'

vcpus = '4'

memory = '3072'

#device_model_version="qemu-xen-traditional"

disk = [

        'file:/mnt/vmdisk/MybedroomDT.img,hda,w',

]

vif = [ 'mac=00:16:3E:51:20:4E,bridge=xenbr0,model=e1000' ]

on_poweroff = 'destroy'

on_reboot = 'restart'

on_crash = 'destroy'

#gfx_passthru=1

boot = 'cd'

acpi = '1'

apic = '1'

viridian = '1'

xen_platform_pci='1'

#sdl = '0'

#vnc = '1'

#vnclisten = '0.0.0.0'

#vncpasswd = ''

#stdvga = '1'

#usb = '1'

#usbdevice = 'tablet'

# ATI Config

pci = ['01:00.0','01:00.1','00:1b.0']

 

tail on syslog:

 

Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: offline type_if=vif XENBUS_PATH=backend/vif/17/0

Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: brctl delif xenbr0 vif17.0 failed

Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: ifconfig vif17.0 down failed

Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge offline for vif17.0, bridge xenbr0.

Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: remove type_if=tap XENBUS_PATH=backend/vif/17/0

Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge remove for vif17.0-emu, bridge xenbr0.

Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0

Aug 23 15:42:24 Tower kernel: device vif18.0 entered promiscuous mode

Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.

Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: Writing backend/vif/18/0/hotplug-status connected to xenstore.

Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/18/0

Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vif18.0-emu, bridge xenbr0.

Aug 23 15:42:24 Tower kernel: device vif18.0-emu entered promiscuous mode

Aug 23 15:42:24 Tower kernel: xenbr0: port 4(vif18.0-emu) entered listening state

Aug 23 15:42:24 Tower kernel: xenbr0: port 4(vif18.0-emu) entered listening state

Aug 23 15:42:25 Tower kernel: xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0

Aug 23 15:42:25 Tower kernel: xen_pciback: vpci: 0000:01:00.1: assign to virtual slot 0 func 1

Aug 23 15:42:25 Tower kernel: xen_pciback: vpci: 0000:00:1b.0: assign to virtual slot 1

Aug 23 15:42:39 Tower kernel: xenbr0: port 4(vif18.0-emu) entered learning state

Aug 23 15:42:54 Tower kernel: xenbr0: topology change detected, sending tcn bpdu

Aug 23 15:42:54 Tower kernel: xenbr0: port 4(vif18.0-emu) entered forwarding state

Aug 23 15:43:25 Tower kernel: xenbr0: port 4(vif18.0-emu) entered disabled state

Aug 23 15:43:25 Tower kernel: device vif18.0-emu left promiscuous mode

Aug 23 15:43:25 Tower kernel: xenbr0: port 4(vif18.0-emu) entered disabled state

Aug 23 15:43:25 Tower avahi-daemon[7594]: Withdrawing workstation service for vif18.0-emu.

Aug 23 15:43:26 Tower kernel: xenbr0: port 3(vif18.0) entered disabled state

Aug 23 15:43:26 Tower avahi-daemon[7594]: Withdrawing workstation service for vif18.0.

Aug 23 15:43:26 Tower kernel: device vif18.0 left promiscuous mode

Aug 23 15:43:26 Tower kernel: xenbr0: port 3(vif18.0) entered disabled state

Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: offline type_if=vif XENBUS_PATH=backend/vif/18/0

Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: brctl delif xenbr0 vif18.0 failed

Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: ifconfig vif18.0 down failed

Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge offline for vif18.0, bridge xenbr0.

Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: remove type_if=tap XENBUS_PATH=backend/vif/18/0

Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge remove for vif18.0-emu, bridge xenbr0.

Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/19/0

Aug 23 15:43:30 Tower kernel: device vif19.0 entered promiscuous mode

Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif19.0, bridge xenbr0.

Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/19/0/hotplug-status connected to xenstore.

Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/19/0

Aug 23 15:43:30 Tower kernel: device vif19.0-emu entered promiscuous mode

Aug 23 15:43:30 Tower kernel: xenbr0: port 4(vif19.0-emu) entered listening state

Aug 23 15:43:30 Tower kernel: xenbr0: port 4(vif19.0-emu) entered listening state

Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vif19.0-emu, bridge xenbr0.

Aug 23 15:43:30 Tower kernel: xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0

Aug 23 15:43:30 Tower kernel: xen_pciback: vpci: 0000:01:00.1: assign to virtual slot 0 func 1

Aug 23 15:43:30 Tower kernel: xen_pciback: vpci: 0000:00:1b.0: assign to virtual slot 1

Aug 23 15:43:45 Tower kernel: xenbr0: port 4(vif19.0-emu) entered learning state

Aug 23 15:44:00 Tower kernel: xenbr0: topology change detected, sending tcn bpdu

Aug 23 15:44:00 Tower kernel: xenbr0: port 4(vif19.0-emu) entered forwarding state

Aug 23 15:44:31 Tower kernel: xenbr0: port 4(vif19.0-emu) entered disabled state

Aug 23 15:44:31 Tower kernel: device vif19.0-emu left promiscuous mode

Aug 23 15:44:31 Tower kernel: xenbr0: port 4(vif19.0-emu) entered disabled state

Aug 23 15:44:31 Tower avahi-daemon[7594]: Withdrawing workstation service for vif19.0-emu.

Aug 23 15:44:31 Tower kernel: xenbr0: port 3(vif19.0) entered disabled state

Aug 23 15:44:31 Tower avahi-daemon[7594]: Withdrawing workstation service for vif19.0.

Aug 23 15:44:31 Tower kernel: device vif19.0 left promiscuous mode

Aug 23 15:44:31 Tower kernel: xenbr0: port 3(vif19.0) entered disabled state

Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: offline type_if=vif XENBUS_PATH=backend/vif/19/0

Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: brctl delif xenbr0 vif19.0 failed

Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: ifconfig vif19.0 down failed

Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge offline for vif19.0, bridge xenbr0.

Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: remove type_if=tap XENBUS_PATH=backend/vif/19/0

Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge remove for vif19.0-emu, bridge xenbr0.

Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/20/0

Aug 23 15:44:36 Tower kernel: device vif20.0 entered promiscuous mode

Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif20.0, bridge xenbr0.

Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/20/0/hotplug-status connected to xenstore.

Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/20/0

Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vif20.0-emu, bridge xenbr0.

Aug 23 15:44:36 Tower kernel: device vif20.0-emu entered promiscuous mode

Aug 23 15:44:36 Tower kernel: xenbr0: port 4(vif20.0-emu) entered listening state

Aug 23 15:44:36 Tower kernel: xenbr0: port 4(vif20.0-emu) entered listening state

Aug 23 15:44:36 Tower kernel: xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0

Aug 23 15:44:36 Tower kernel: xen_pciback: vpci: 0000:01:00.1: assign to virtual slot 0 func 1

Aug 23 15:44:36 Tower kernel: xen_pciback: vpci: 0000:00:1b.0: assign to virtual slot 1

Aug 23 15:44:51 Tower kernel: xenbr0: port 4(vif20.0-emu) entered learning state

Aug 23 15:45:06 Tower kernel: xenbr0: topology change detected, sending tcn bpdu

Aug 23 15:45:06 Tower kernel: xenbr0: port 4(vif20.0-emu) entered forwarding state

 

qemu-dm-myvm.log contains this:

 

[00:06.0] xen_pt_pci_config_access_check: Error: Failed to access register with invalid access size alignment. (addr: 0x0e, len: 4)

 

If I comment out the PCI, and uncomment device_model_version="qemu-xen-traditional" it boots fine.  If I try and boot without qemu-xen-traditional it will not boot, and just continues to reboot over and over.

 

Thanks!

 

[jumperalex]

This will give you the ability to create share "snapshots".

 

droool, this will be sweet.

[jumperalex]

I hope this is where you want stuff like this Tom / Jon

...

about 10 minutes in:

Aug 23 14:56:58 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 19 slots
Aug 23 14:58:34 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
...
Aug 23 15:01:45 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 19 slots
Aug 23 15:01:45 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
...
started another torrent
...
Aug 23 15:19:00 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots
Aug 23 15:19:00 arch_vm kernel: xen_netfront: xennet: skb rides the rocket: 20 slots

 

I used to get a few of these in the past i think so this isn't too bad.

 

It is still early days, but I would say beta7 and Xen are pretty stable.

 

Hmm, those are the errors we are looking to find and were hoping were squashed.  Let me know if they persist and how they affect your VMs.  Also post your config for the VM and your network.cfg settings.  Need to see some details to help diagnose.

 

Well like I said, I was seeing these in beta5a too I'm about 99% sure.  They never caused a problem because they were about as frequent as this.  I'll try to dig more into my old logs to confirm and of course let you know if I encounter problems.  I expect running more simultaneous torrents (with more open connections) might push it; I'll try that in a bit when I have things to download.

 

VM Config:

name = "arch"
memory = '4096'
vcpus = '8'
vif = [ 'bridge=xenbr0,mac=00:16:3E:1E:66:1F' ]
disk = ['file:/mnt/appdisk/vm/arch/arch.img,xvda,w','file:/mnt/appdisk/vm/arch/data.img,xvdb,w']
bootloader = "pygrub"

 

Network Config:

# Generated settings:
USE_DHCP="no"
IPADDR="10.0.0.4"
NETMASK="255.255.255.0"
GATEWAY="10.0.0.1"
DHCP_KEEPRESOLV="no"
DNS_SERVER1="10.0.0.1"
DNS_SERVER2=""
DNS_SERVER3=""
BONDING="no"
BONDING_MODE="1"
BRIDGING="yes"
BRNAME="xenbr0"
BRSTP="no"

 

Syslinux Config:

default /syslinux/menu.c32
menu title Lime Technology
prompt 0
timeout 50
label unRAID OS
#  menu default
  kernel /bzimage
  append initrd=/bzroot
label unRAID OS Safe Mode (no plugins)
  kernel /bzimage
  append initrd=/bzroot unraidsafemode
label Memtest86+
  kernel /memtest
label Xen/unRAID OS
  menu default
  kernel /syslinux/mboot.c32
#  append /xen dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=2048M,max:2048M --- /bzimage --- /bzroot
  append /xen dom0_mem=2048M,max:2048M --- /bzimage --- /bzroot
label Xen/unRAID OS Safe Mode (no plugins)
  kernel /syslinux/mboot.c32
  append /xen --- /bzimage --- /bzroot unraidsafemode

 

 

[BRiT]

Well reiserfs didn't get the most efficient changes for this - it works, but could be better.  The other problem is that as fewer and fewer people use reiserfs in the linux world, cases of little bugs that crop up due to kernel changes will be found/fixed slower.  Anyway, it's clear we needed to offer alternatives.

 

That same logic applies to using Slackware as a base distro.  Hopefully this is realized and becomes the top priority of an unRAID released after the items pushed off from 6.0 into 6.1 and 6.2 are completed.

 

Looking forward to putting 6.0 beta 7 through the paces sometime this week.

[SSD]

Ok - i have a precleared disk, and want to add it to the array and format it as XFS.

 

I stopped the array, added the disk to the next disk slot, and in the FS column it says reiserfs (I did not start the array).

 

So I backed off (removed the precleared disk from the array) to wait for instruction. What is the proper technique to add a precleared disk to the array with an XFS or BTRFS file system.

 

(Sorry if this has been posted but I didn't see it after a few minutes of searching).

 

Thanks!

[thestewman]

New User has questions about upgrading from 6.0-beta6 to 6.0-beta7

I was easily able to upgrade from 5.0.5 to Beta 6.0.3 and up previously.

Today I attempted to upgrade to 6.0Beta7 and followed the instructions in the ReadMe file

I could not get UnMenu to start so I started searching for the problem and found there were discrepancies on my upgraded flash drive.

The following folders and files on my Beta 6 Flash were missing.

Recycle Bin

Backup_files

Logs

Packages

Preclear_Reports

UnMenu

Preclear_disk.sh

.apddisk

I added them all and Unmenu started. Was this an oversight not to include these folders and files in the readme instructions?

Are all these folders and files needed in Beta 7 ?

 

I used the Main Menu to Stop the array and take it Off-line then powered it down from the Main Menu.

It still started a parity check when I restarted it. Normal ?

 

 

[SSD]

New User has questions about upgrading from 6.0-beta6 to 6.0-beta7

I was easily able to upgrade from 5.0.5 to Beta 6.0.3 and up previously.

Today I attempted to upgrade to 6.0Beta7 and followed the instructions in the ReadMe file

I could not get UnMenu to start so I started searching for the problem and found there were discrepancies on my upgraded flash drive.

The following folders and files on my Beta 6 Flash were missing.

Recycle Bin

Backup_files

Logs

Packages

Preclear_Reports

UnMenu

Preclear_disk.sh

.apddisk

I added them all and Unmenu started. Was this an oversight not to include these folders and files in the readme instructions?

Are all these folders and files needed in Beta 7 ?

 

I used the Main Menu to Stop the array and take it Off-line then powered it down from the Main Menu.

It still started a parity check when I restarted it. Normal ?

 

As per the readme, upgrading from a 6.0 beta requires only copying of four files from the zip file to the flash disk.

 

bzroot

bzimage

xen

readme.txt

 

Is that what you did? It would not have deleted anything from your flash disk.

 

If you rebuilt the flash from scratch - yes - you would expect that all of your addons including unmenu would be gone.

 

I just upgraded from 6b6 to 6b7. Instead of overwriting, I just renamed the old ones (e..g, bzroot -> bzroot6b6) and then copied the four files. Everything came up perfect. unmenu, dockers, screen, user shares, etc.

 

RTFM

[PeterB]

Has anything changed (since b5a) which would stop the fan_speed plugin working?

 

My fans appear to be running at full speed with no evidence of any control.

 

No.  Please post this in the new Defect Reports board.

http://lime-technology.com/forum/index.php?board=61.0

 

Okay, after some investigation, it would seem that this is not a defect, but definitely a change ...

 

I have had to amend the configuration of sensor/fan devices in the fan_speed plg file:

 

ARRAY_FAN=/sys/class/hwmon/hwmon1/device/pwm2

becomes

ARRAY_FAN=/sys/devices/platform/w83627ehf.2608/pwm2

 

and

 

ARRAY_FAN_INPUT=/sys/class/hwmon/hwmon1/device/fan2_input

becomes

ARRAY_FAN_INPUT=/sys/devices/platform/w83627ehf.2608/fan2_input

 

Since making these changes, fan speeds are being controlled again.

 

Obviously, these changes are specific to my own hardware configuration.  To assist with identifying what changes are required in your system, you can use the following commands:

find /sys -name pwm*
find /sys -name fan*

[jonp]

Well reiserfs didn't get the most efficient changes for this - it works, but could be better.  The other problem is that as fewer and fewer people use reiserfs in the linux world, cases of little bugs that crop up due to kernel changes will be found/fixed slower.  Anyway, it's clear we needed to offer alternatives.

 

That same logic applies to using Slackware as a base distro.  Hopefully this is realized and becomes the top priority of an unRAID released after the items pushed off from 6.0 into 6.1 and 6.2 are completed.

 

Looking forward to putting 6.0 beta 7 through the paces sometime this week.

Slackware is considered one of the most rock solid and stable distros you can use.

[jphipps]

Ok - i have a precleared disk, and want to add it to the array and format it as XFS.

 

I stopped the array, added the disk to the next disk slot, and in the FS column it says reiserfs (I did not start the array).

 

So I backed off (removed the precleared disk from the array) to wait for instruction. What is the proper technique to add a precleared disk to the array with an XFS or BTRFS file system.

 

(Sorry if this has been posted but I didn't see it after a few minutes of searching).

 

Thanks!

 

As the array is stopped and you add the disk to the slot, click on the disk name, such as "Disk7" and then there is a drop down to select the filesystem type.  It worked for me without any hitches..

[thestewman]

New User has questions about upgrading from 6.0-beta6 to 6.0-beta7

I was easily able to upgrade from 5.0.5 to Beta 6.0.3 and up previously.

Today I attempted to upgrade to 6.0Beta7 and followed the instructions in the ReadMe file

I could not get UnMenu to start so I started searching for the problem and found there were discrepancies on my upgraded flash drive.

The following folders and files on my Beta 6 Flash were missing.

Recycle Bin

Backup_files

Logs

Packages

Preclear_Reports

UnMenu

Preclear_disk.sh

.apddisk

I added them all and Unmenu started. Was this an oversight not to include these folders and files in the readme instructions?

Are all these folders and files needed in Beta 7 ?

 

I used the Main Menu to Stop the array and take it Off-line then powered it down from the Main Menu.

It still started a parity check when I restarted it. Normal ?

 

As per the readme, upgrading from a 6.0 beta requires only copying of four files from the zip file to the flash disk.

 

bzroot

bzimage

xen

readme.txt

 

Is that what you did? It would not have deleted anything from your flash disk.

 

If you rebuilt the flash from scratch - yes - you would expect that all of your addons including unmenu would be gone.

 

I just upgraded from 6b6 to 6b7. Instead of overwriting, I just renamed the old ones (e..g, bzroot -> bzroot6b6) and then copied the four files. Everything came up perfect. unmenu, dockers, screen, user shares, etc.

 

RTFM

 

I saw those instructions but  it reads only v1,2,3,4

This was very misleading.

 

Upgrade Instructions

====================

 

If you are currently running 6.0-beta1/2/3/4

--------------------------------------------

 

It is only necessary to copy these files from the zip file to the root

of your USB Flash device:

 

  bzimage

  bzroot

  xen

  readme.txt

 

So I ask again if I may do I need all these ?

 

Recycle Bin

Backup_files

Logs

Packages

Preclear_Reports

UnMenu

Preclear_disk.sh

.apddisk

 

And what caused the parity check to start ?

 

[MSattler]

Ok - i have a precleared disk, and want to add it to the array and format it as XFS.

 

I stopped the array, added the disk to the next disk slot, and in the FS column it says reiserfs (I did not start the array).

 

So I backed off (removed the precleared disk from the array) to wait for instruction. What is the proper technique to add a precleared disk to the array with an XFS or BTRFS file system.

 

(Sorry if this has been posted but I didn't see it after a few minutes of searching).

 

Thanks!

 

As the array is stopped and you add the disk to the slot, click on the disk name, such as "Disk7" and then there is a drop down to select the filesystem type.  It worked for me without any hitches..

 

If we upgrade from a 2TB to a 4TB disk, do we have the option to make the new 4TB disk XFS even if the old disk was ReiserFS?

 

 

[limetech]

Ok - i have a precleared disk, and want to add it to the array and format it as XFS.

 

I stopped the array, added the disk to the next disk slot, and in the FS column it says reiserfs (I did not start the array).

 

So I backed off (removed the precleared disk from the array) to wait for instruction. What is the proper technique to add a precleared disk to the array with an XFS or BTRFS file system.

 

(Sorry if this has been posted but I didn't see it after a few minutes of searching).

 

Thanks!

 

Click on the device link to bring up the device info page.  There select which file system you want, then go back to Main and Start array.  The device will have 'Unformatted' status and the FS column should indicate your previous FS choice which is what will be used when you click 'Format'.

 

Incidentally, if you select 'auto' then 'mount' command to device will have '-t auto'.  This means 'mount' will try to detect FS type and mount what it finds.  This is mainly to handle case where you executed a  'New Config' and you might not remember how all the devices were formatted. Once the FS type is known it will appear in the FS column.

[limetech]

Well reiserfs didn't get the most efficient changes for this - it works, but could be better.  The other problem is that as fewer and fewer people use reiserfs in the linux world, cases of little bugs that crop up due to kernel changes will be found/fixed slower.  Anyway, it's clear we needed to offer alternatives.

 

That same logic applies to using Slackware as a base distro.  Hopefully this is realized and becomes the top priority of an unRAID released after the items pushed off from 6.0 into 6.1 and 6.2 are completed.]

 

No it does not.  If you feel that strongly about which distro we use, please post in the Roadmap board.  No further discussion about this here please.

[Packalacky]

Haven't seen anyone mention this on the thread so here goes.

 

Updating from Beta4.

1. Copied the 4 files as mention on the readme.txt file (bzimage, bzroot, xen, readme.txt)

2. Start Unraid + Xen, everything works fine, no issues whatsoever, everything as expected including an ArchVM

3. Reboot

4. Start Unraid alone (no Xen)

5. Get error messages upon starting and then system reboots/shutdown.

 

Here are a few pictures of where it hangs up/shutsdown/reboots. These are the most common errors but sometimes it just reboots at random or hangs at a certain line, it's not always the same:

 

On these 2 errors, it simply hangs:

 

 

On this one it reboots:

 

 

After getting these errors, I got a different USB stick and used it to test a clean install of UnraidBeta6 and got exactly the same results. Unraid+Xen works perfectly fine, but Unraid by itself doesn't. Everything worked fine under the Unraid beta 4, including Unraid by itself. There were no hardware changes between the 2 betas.

 

This seems to be sorted now with Beta7. Loads just fine with or without Xen. Simply copied the update files over as per the README.txt instructions and restarted the server, nothing else changed.

 

Never managed to get it to work with Beta6.