unRAID Server Release 6.0-beta3-x86_64 Available


limetech

Recommended Posts

Tom,

 

In v5 you updated smartmontools to version 6.2 as requested (smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build))

 

In v6Beta 3 smartmontools is version 5.43 (smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.10.24p-unRAID] (local build))

 

Can't update HD DB (/usr/sbin/update-smart-drivedb)

 

Please update for v6 Beta 4.

Link to comment
  • Replies 661
  • Created
  • Last Reply

Top Posters In This Topic

When setting NTP to Yes and specifying same internal NTP server as set in production v5 server, time is 12 minutes ahead on the v6 server. I can click apply (NTP page) on both servers, v5 has the same time as clients and NTP source, v6 is 12 minutes ahead. Reboot of v6 Beta3 server still 12 minutes ahead.

 

Update (day later):

Created a VM under esxi to test unRIAD v6b3, set same NTP, time was correct.

Booted up physical unRAID v6b3 server again this evening to start some more test, first thing i check on was the time, now it is correct. Not sure what the gitch was on the first day, and reboots did not help.

Link to comment

In v6 Beta3 upon booting (physical hardware, no XEN boot, array not set to auto start) I have no tmpfs?

 

v5 I see tmpfs: df -aTh

Filesystem    Type    Size  Used Avail Use% Mounted on

proc          proc      0    0    0  -  /proc

sysfs        sysfs      0    0    0  -  /sys

tmpfs        tmpfs    2.0G  8.5M  2.0G  1% /var/log

/dev/sdb      vfat    3.8G  136M  3.6G  4% /boot

 

In v6B3 i dont see a tmpfs?

Filesystem    Type  Size  Used Avail Use% Mounted on

proc          proc      0    0    0    - /proc

sysfs          sysfs    0    0    0    - /sys

/dev/sda1      vfat  7.5G  86M  7.4G  2% /boot

 

v5 rc.S

# tmm - Move /var/log to a tmpfs
mv /var/log/* /var/empty
mount -t tmpfs -o size=128m tmpfs /var/log
mv /var/empty/* /var/log

 

v6 rc.S

# If /run exists, mount a tmpfs on it (unless the
# initrd has already done so):
if [ -d /run ]; then
  if ! grep -wq "tmpfs /run tmpfs" /proc/mounts ; then
    /sbin/mount -v -n -t tmpfs tmpfs /run -o mode=0755
  fi
fi

...

# Check the root filesystem:
if [ ! $READWRITE = yes ]; then
....
else
# limetech - root filesystem is in RAM so always is read/write
#  echo "Testing root filesystem status:  read-write filesystem"
#  echo
#  echo "*** ERROR: Root partition has already been mounted read-write. Cannot check!"
#  echo
#  echo "For filesystem checking to work properly, your system must initially mount"
#  echo "the root partition as read only. Please modify your kernel with 'rdev' so that"
#  echo "it does this. If you're booting with LILO, add a line:"
#  echo
#  echo "   read-only"
#  echo
#  echo "to the Linux section in your /etc/lilo.conf and type 'lilo' to reinstall it."
#  echo
#  echo "If you boot from a kernel on a floppy disk, put it in the drive and type:"
#  echo "   rdev -R /dev/fd0 1"
#  echo
#  echo "If you boot from a bootdisk, or with Loadlin, you can add the 'ro' flag."
#  echo
#  echo "This will fix the problem *AND* eliminate this annoying message. :^)"
#  echo
#  echo -n "Press ENTER to continue. "
#  read junk;
# limetech - move /var/log to a tmpfs
  mv /var/log/* /var/empty
  mount -t tmpfs -o size=128m,mode=0755 tmpfs /var/log
  mv /var/empty/* /var/log
fi # Done checking root filesystem

 

Link to comment

In Confirmation Preferences, if you set "Uncommitted changes warning:" to "Yes"

Main Page: When checking off "Yes I want to do this" for Power Down or Reboot the web gui notify's you that "You have uncommitted form changes" (small bug)

If you don't commit to Power Down or Reboot and uncheck "Yes I want to do this", the same notification occurs.

 

 

 

Link to comment
Haven't tried this version of unRAID yet but wonder if it's something to do with this particular CPU. As it is one of the few Core2Duo ones that lists VT-d support.

 

It's a shot in the dark, but you could try disabling CPU C-states. At work we did that for an older version of Xen.

Link to comment

Tom,

 

In v5 you updated smartmontools to version 6.2 as requested (smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build))

 

In v6Beta 3 smartmontools is version 5.43 (smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.10.24p-unRAID] (local build))

 

Can't update HD DB (/usr/sbin/update-smart-drivedb)

 

Please update for v6 Beta 4.

Done.

Link to comment

When setting NTP to Yes and specifying same internal NTP server as set in production v5 server, time is 12 minutes ahead on the v6 server. I can click apply (NTP page) on both servers, v5 has the same time as clients and NTP source, v6 is 12 minutes ahead. Reboot of v6 Beta3 server still 12 minutes ahead.

 

Update (day later):

Created a VM under esxi to test unRIAD v6b3, set same NTP, time was correct.

Booted up physical unRAID v6b3 server again this evening to start some more test, first thing i check on was the time, now it is correct. Not sure what the gitch was on the first day, and reboots did not help.

Clicking 'Apply' just sets up config info for ntp; ntp sometimes takes a while to actually update the time.

Link to comment

Tom,

 

In v5 you updated smartmontools to version 6.2 as requested (smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build))

 

In v6Beta 3 smartmontools is version 5.43 (smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.10.24p-unRAID] (local build))

 

Can't update HD DB (/usr/sbin/update-smart-drivedb)

 

Please update for v6 Beta 4.

Done.

 

Thank you sir!

Link to comment

When setting NTP to Yes and specifying same internal NTP server as set in production v5 server, time is 12 minutes ahead on the v6 server. I can click apply (NTP page) on both servers, v5 has the same time as clients and NTP source, v6 is 12 minutes ahead. Reboot of v6 Beta3 server still 12 minutes ahead.

 

Update (day later):

Created a VM under esxi to test unRIAD v6b3, set same NTP, time was correct.

Booted up physical unRAID v6b3 server again this evening to start some more test, first thing i check on was the time, now it is correct. Not sure what the gitch was on the first day, and reboots did not help.

Clicking 'Apply' just sets up config info for ntp; ntp sometimes takes a while to actually update the time.

Oh ok, thanks for the info.

Link to comment

Rather a minor issue, but has anyone been able to get FTP to work?

 

Tom,

 

It seems that the latest version of vsftp sets the 'listen' parameter to 'YES'.

 

If I put this line into the vsftpd.conf file:

listen=NO

 

my ftp is working again.

 

You should probably add this to the default vsftpd.conf file you distribute.

 

EDIT: Just found it and some other changes in the provided script.  I looked it over and missed it the first time.

 

Confused by this post... ftp seems to be working ok.  Do I have an action-item here?

Link to comment

In v6 Beta3 upon booting (physical hardware, no XEN boot, array not set to auto start) I have no tmpfs?

If you type

 

cat /proc/mounts

 

the tmpfs shows up there.  Not sure why the 'df' command is not showing it...

Its not showing up under the 'mount' command either?

 

here is cat /proc/mounts from my v5.0.4, v6b3 VM, v6b3 Phy (maybe it will help you? I dont get it.)

 

unRAIDv5.0.4:

 

rootfs / rootfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
tmpfs /var/log tmpfs rw,relatime,size=2072972k 0 0
/dev/sda1 /boot vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0

 

unRAIDv6 VM:

 

rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /run tmpfs rw,relatime,mode=755 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1982016k,nr_inodes=495504,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
cgroup /sys/fs/cgroup cgroup rw,relatime,perf_event,blkio,freezer,devices,memory,cpuacct,cpu,debug,cpuset 0 0
tmpfs /var/log tmpfs rw,relatime,size=131072k,mode=755 0 0
/dev/sda1 /boot vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0

 

unRAID v6 Physical:

rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /run tmpfs rw,relatime,mode=755 0 0
devtmpfs /dev devtmpfs rw,relatime,size=4010044k,nr_inodes=1002511,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
cgroup /sys/fs/cgroup cgroup rw,relatime,perf_event,blkio,freezer,devices,memory,cpuacct,cpu,debug,cpuset 0 0
tmpfs /var/log tmpfs rw,relatime,size=131072k,mode=755 0 0
/dev/sda1 /boot vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0

 

Just tried: mount -t tmpfs -o remount,size=50% tmpfs /var/log

Command succeeded, still not showing up with 'df' or 'mount', but /proc/mounts does display the change in size to tmpfs /var/log size.

 

Link to comment

Rather a minor issue, but has anyone been able to get FTP to work?

 

Tom,

 

It seems that the latest version of vsftp sets the 'listen' parameter to 'YES'.

 

If I put this line into the vsftpd.conf file:

listen=NO

 

my ftp is working again.

 

You should probably add this to the default vsftpd.conf file you distribute.

 

EDIT: Just found it and some other changes in the provided script.  I looked it over and missed it the first time.

 

Confused by this post... ftp seems to be working ok.  Do I have an action-item here?

 

No.  My bad.  I missed some new parameters in the distributed ftp config that I needed to copy to my custom one.  All taken care of.

Link to comment

In Confirmation Preferences, if you set "Uncommitted changes warning:" to "Yes"

Main Page: When checking off "Yes I want to do this" for Power Down or Reboot the web gui notify's you that "You have uncommitted form changes" (small bug)

If you don't commit to Power Down or Reboot and uncheck "Yes I want to do this", the same notification occurs.

 

The assignment of the change event needs to be more selective.

 

Before

 

<?if ($confirm['warn']):?>

  $('form').each(function() {$(this).change(function() {$.jGrowl ...

<?endif;?>

After

 

<?if ($confirm['warn']):?>

  $('form').find('select,input[type=text]').each(function() {$(this).change(function() {$.jGrowl ...

<?endif;?>

 

This would exclude all elements except select and text input. I.e. the fields a user would change in a settings page.

Link to comment

@bonienl, that sounds right. It's no show stopper, but this is finally the best OOB WebGui I've seen come with unRAID, many welcomed small additions the community requested in the past and so far the only small bug I noticed thus far (haven't test a few thing like how new permission's is displayed yet, system info seems to be off when unRAID runs in a VM, will post that later).

 

So if the code in your post is the fix to help polish this up, would be nice to get it into Beta 4.

 

Link to comment

Tom have a bug for you.

 

It didn't occur to me at first, but everytime I rebooted v6b3 (default boot not XEN) on physical HW or Virtual Machine I received a different IP from DHCP (should not be the case as the lease wasn't expired, but dint think anything off it at first). So later on I decided to make a DHCP reservation on the mac address (like i have for a dev v5 vm), thats when I saw the problem.

 

v6b3 generates a new mac address (unique identifier) with each reboot and it isnt the traditional six groups of two hexadecimal digits, its 36 hexadecimal digits in total? The console shows the 12 hexadecimal digits (for eth0) but thats not what is being transmitted. The last 12 digits of the 36 digit Unique Identifier is the mac address of the nic.

 

See screenshot of the v6b3 vm on my dev vlan 10.10.150.x

 

See screenshot of the v6b3 physical host on my prod vlan

 

Secondary (i think), I wondered what if I release the dhcp address and renewed it, that worked so it generates a new Unique Identifier only per reboot. But while testing a release/renew 'dhcpcd -n' on v6b3 it brings up other network interfaces (gre0, ip_vti0, tunl0) that are hidden/dormant upon first booting up and show them self upon issuing the command:

 

Default boot (not Xen)

root@Tower6Dev:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.150.7  netmask 255.255.255.0  broadcast 10.10.150.255
        ether 00:50:56:98:59:66  txqueuelen 1000  (Ethernet)
        RX packets 75  bytes 14009 (13.6 KiB)
        RX errors 0  dropped 4  overruns 0  frame 0
        TX packets 120  bytes 19336 (18.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 62  bytes 5708 (5.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 62  bytes 5708 (5.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@Tower6Dev:~# cd ..
root@Tower6Dev:/# cd boot/config
root@Tower6Dev:/boot/config# cat network.cfg
# Generated settings:
USE_DHCP="yes"
IPADDR="10.10.150.112"
NETMASK="255.255.255.0"
GATEWAY="10.10.150.1"
DHCP_KEEPRESOLV="no"
DNS_SERVER1="10.10.50.151"
DNS_SERVER2="10.10.50.150"
DNS_SERVER3=""
BONDING="no"
BONDING_MODE="1"
BRIDGING="no"
BRNAME="br0"
root@Tower6Dev:/boot/config# dhcpcd -n
dhcpcd[1309]: version 6.0.5 starting
dhcpcd[1309]: gretap0: up_interface: Cannot assign requested address
dhcpcd[1309]: forked to background, child pid 1310
root@Tower6Dev:/boot/config# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.150.7  netmask 255.255.255.0  broadcast 10.10.150.255
        ether 00:50:56:98:59:66  txqueuelen 1000  (Ethernet)
        RX packets 192  bytes 29889 (29.1 KiB)
        RX errors 0  dropped 8  overruns 0  frame 0
        TX packets 215  bytes 31336 (30.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

gre0: flags=193<UP,RUNNING,NOARP>  mtu 1476
        unspec 00-00-00-00-FF-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (U
        RX packets 2  bytes 764 (764.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 724 (724.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ip_vti0: flags=193<UP,RUNNING,NOARP>  mtu 1500
        tunnel   txqueuelen 0  (IPIP Tunnel)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 2  dropped 0 overruns 0  carrier 2  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 62  bytes 5708 (5.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 62  bytes 5708 (5.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tunl0: flags=193<UP,RUNNING,NOARP>  mtu 576
        tunnel   txqueuelen 0  (IPIP Tunnel)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 3  dropped 0 overruns 3  carrier 0  collisions 0

 

Default Boot v5, same exact commands as above.

root@Tower5Dev:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:56:98:2b:ed
          inet addr:10.10.150.110  Bcast:10.10.150.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67 errors:0 dropped:12 overruns:0 frame:0
          TX packets:100 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:26156 (25.5 KiB)  TX bytes:15074 (14.7 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)

root@Tower5Dev:~# cd ..
root@Tower5Dev:/# cd boot/config
root@Tower5Dev:/boot/config# cat network.cfg
# Generated settings:
USE_DHCP="yes"
IPADDR="10.10.150.110"
NETMASK="255.255.255.0"
GATEWAY="10.10.150.1"
DHCP_KEEPRESOLV="no"
DNS_SERVER1="10.10.50.151"
DNS_SERVER2="10.10.50.150"
DNS_SERVER3=""
BONDING="no"
BONDING_MODE="1"
root@Tower5Dev:/boot/config# dhcpcd -n
dhcpcd[1552]: version 5.2.7 starting
dhcpcd[1552]: forked to background, child pid 1553
root@Tower5Dev:/boot/config# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:56:98:2b:ed
          inet addr:10.10.150.110  Bcast:10.10.150.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:183 errors:0 dropped:16 overruns:0 frame:0
          TX packets:186 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:42534 (41.5 KiB)  TX bytes:26135 (25.5 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)

 

v6b3-UI-MAC.png.bd399a16c032ee42555b62593fff5f28.png

v6b3-physical-UI-MAC.png.5a2e092df9bdcf6ce780fcc309e1d560.png

Link to comment

Tom have a bug for you.

 

It didn't occur to me at first, but everytime I rebooted v6b3 (default boot not XEN) on physical HW or Virtual Machine I received a different IP from DHCP (should not be the case as the lease wasn't expired, but dint think anything off it at first). So later on I decided to make a DHCP reservation on the mac address (like i have for a dev v5 vm), thats when I saw the problem.

 

v6b3 generates a new mac address (unique identifier) with each reboot and it isnt the traditional six groups of two hexadecimal digits, its 36 hexadecimal digits in total? The console shows the 12 hexadecimal digits (for eth0) but thats not what is being transmitted. The last 12 digits of the 36 digit Unique Identifier is the mac address of the nic.

 

 

I brought a new v6b3 test box online today and I too noticed this issue.

Link to comment

Tom have a bug for you.

 

It didn't occur to me at first, but everytime I rebooted v6b3 (default boot not XEN) on physical HW or Virtual Machine I received a different IP from DHCP (should not be the case as the lease wasn't expired, but dint think anything off it at first). So later on I decided to make a DHCP reservation on the mac address (like i have for a dev v5 vm), thats when I saw the problem.

 

v6b3 generates a new mac address (unique identifier) with each reboot and it isnt the traditional six groups of two hexadecimal digits, its 36 hexadecimal digits in total? The console shows the 12 hexadecimal digits (for eth0) but thats not what is being transmitted. The last 12 digits of the 36 digit Unique Identifier is the mac address of the nic.

 

 

I brought a new v6b3 test box online today and I too noticed this issue.

 

Quite now you mention it this is a problem in my vmware test box. Assumed it was a vmware gotcha but sounds like it isnt

Link to comment

Tom have a bug for you.

 

Right, I've noticed some strange things with MAC addresses as well - but haven't really looked into yet.  I am going to release -beta4 and then I have to release 5.0.6, and then I can get to this.

 

I do have a theory though: I think it has to do with the bonding driver.  When you have two or more NIC's bonded then the bonding driver is going to "appropriate" the MAC address of whichever ethernet port comes on-line first.  This creates a race condition and results in differing MAC addresses getting assigned at boot time.  Probably there's a way to configure bonding driver to always prefer a certain MAC address.

 

The dhcpcd -n command I think is also trying to renew on "all" network I/F's (/etc/rc.d/rc.inet1 invokdes dhcpcd with a single explicit port).  Probably you shouldn't use 'dhcpcd -n' unless you also specify a port, e.g., 'dhcpcd -n eth0'.

 

Anyway, thanks for posting this & as mentioned earlier, I'll be able to look at it after these releases get out.

Link to comment

Tom have a bug for you.

 

Right, I've noticed some strange things with MAC addresses as well - but haven't really looked into yet.  I am going to release -beta4 and then I have to release 5.0.6, and then I can get to this.

 

Understood, I assumed you where close to getting beta 4 out, so it would have to be after. Would be good to nip this in the bud before it comes out of beta. I will add some comments later as I don't have time today and have to run. Thanks for the acknowledge reply.

 

If you saw @bonienl webgui code a few posts back in this thread and can add to beta 4 for testing that would be great, if not please don't lose track of it for following beta; so there's no nagging involved later. Thanks.

Link to comment

One more bug or something missing on B3 ?

 

From my syslog, if complete syslog is necessary, I can add this.

 

8 10:31:49 tower kernel: xen-acpi-processor: Uploading Xen processor PM info
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU1
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU2
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU3
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU4
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU5
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU6
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU7
Mar  8 10:31:49 tower kernel: xen-acpi-processor: (_PXX): Hypervisor error (-38) for ACPI CPU8

 

 

 

Link to comment

Anyone know if it's already possible to do USB passthrough? Running an Ubuntu 1310 installation + custom kernel (for TV).

I have pretty much everything working now EXCEPT passthrough of my USB Smartreader (Smargo Smartreader V2). When i try xm usb-add <domain> <host:0403:6001> (my USB ID) i get the following error message:

 

Error: Unable to connect to xend: No such file or directory. Is xend running?

 

Also tried editing the .cfg for the image by adding usb=1 and the usb id but no dice there either.

 

edit: using xm as i couldn't find any info on usb passthrough and xl :(

edit2: Which seems to be because xl doesn't support it yet :S

edit3: For now got it "solved" by compiling oscam for Unraid 6 itself.. :)

Link to comment

Anyone know if it's already possible to do USB passthrough? Running an Ubuntu 1310 installation + custom kernel (for TV).

I have pretty much everything working now EXCEPT passthrough of my USB Smartreader (Smargo Smartreader V2). When i try xm usb-add <domain> <host:0403:6001> (my USB ID) i get the following error message:

 

Error: Unable to connect to xend: No such file or directory. Is xend running?

 

Also tried editing the .cfg for the image by adding usb=1 and the usb id but no dice there either.

 

edit: using xm as i couldn't find any info on usb passthrough and xl :(

edit2: Which seems to be because xl doesn't support it yet :S

edit3: For now got it "solved" by compiling oscam for Unraid 6 itself.. :)

 

I just passed through the pci usb controller.  I don't know if this will work for you but I thought I should mention it.

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.