Spectrum
-
Posts
236 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Spectrum
-
-
ANNNNND epic faceapalm!
I was compressing to xz not to lzma. Sometimes it pays to step back and take a break and have fresh eyes take a peek.Appreciate it brit!
-
Does anyone know how to compress the bzroot with lzma/xz? I've tried using the same syntax as gzip but it's not working
decompression with
xzcat /path/to/bzroot | cpio -i -d -H newc --no-absolute-filenames
works fine but compression using the assumed
find . | cpio -o -H newc | xz > /path/to/newbzroot
or
find . | cpio -o -H newc | xz --stdout - > /path/to/newbzroot
creates a new archive but chokes on reboot when trying to extract the initramfs.
The boot chokes with:
VFS: Cannot open root device"(null)" or unknown-block(8,2) Please append a correct "root=" boot option" here are the available partitions:
compressing the same data using gzip works fine though. Makes me think I'm doing something goofy with the compression
Using 5.0rc3 and I've attached a screenshot of the kernel puking all over the place.
-
There is an md5deep package available in unmenu. It does exactly what you are looking for.
-
That looks like the info from a separate boot partition. Try mounting /dev/sdc2
-
Well that's what I get for posting things with my phone! 55000 KB/s is ~430 Mb/s so that's really not so bad. Sorry if I sent you on a wild goose chase.
-
What Joe said
I wil add in that iperf is only measuring raw bandwidth. Any disk activity will slow things down. That said your numbers are very low. 55 KB/s is < 1 Mbps; based on your results I think there is definitely something wrong. I would start with the cables and/or try diff machines to try to isolate the problem. -
That method works but it's using a shotgun to treat the symptom instead of resolving the problem. If you are fine with not being able to retain hidden/system attributes than it's not a problem though.
As an example, if you copied your user profile from a windows machine to a share after gutting samba's ability to map attributes then copied the profile back there would be a plethora of files/directories that would be restored incorrectly. Not the end of the world but beware when running like this you may not (depends on how you use your array) get the expected result when you copy files on/off the array.
-
Because .zip != .tgz
You need to unzip the file using unzip which I don't think is installed by default. Easy solution is to unzip the archive from another machine. If you have unRAID up and running and haven't monkeyed with the defaults yet the flash drive will be at \\tower\flash and you can just unzip the file over the network.
-
Congrats. Not sure why you got that bad superblock error (and I'm not about to start tinkering with my live array to figure it out) but it's working and that's what counts
Just an FYI in case you haven't already found it, the configuration tutorial is at http://lime-technology.com/wiki/index.php?title=Configuration_Tutorial and it may help you along now that you have the system working.
-
Yep Joe's radar is much more attuned than mine. That is the problem indeed. On the unraid box type
e2label /dev/sda1 UNRAID
You can verify the change by using the ls command. After that a reboot should have you up and running.
-
Put the flash drive back in the unraid box and type
ls -l /boot/
If you see syslog.txt listed then you'll have to seek help from someone with some mac knowledge to figure out whats going on on the desktop side of things. If you don't see it listed then syslog was not actually copied. In that case, copy the file again then verify it copied using the ls command. If it still doesn't copy I'd be suspect of the flash drive.....
-
Not sure what it takes for OSX to resolve names via NETBIOS, it's doable but I have no idea where to even begin but someone else here may be able to point you down the right track. In the mean time running it with a static IP or setting up a DHCP reservation on the DHCP server would be advisable. Then you could use the host file to map the name to the IP address. The instructions for the host file are in this article. Should be /etc/hosts on a mac...
-
http://lime-technology.com/forum/index.php?topic=9880.0
Copy the file to your flash drive as per that post then put the flash in your mac and upload it here
-
The problem is not ownership, it's how samba maps unix file permissions to windows file attributes. Because the world executable flag is set Samba is showing setting the hidden attribute. You can set windows to show hidden/system files to confirm. The solution is to remove the world executable permission but I'm not sure what effect this will have on the ftp server....
Pick a file to test with and execute
chmod 644 /path/to/file
then see if you can view the file by browsing to the share with windows. If so, the samba mapping is definitely your problem and you will need to figure out what the permissions need to be to allow reading/writing via windows and ftp. Once you have that it's pretty easy to script changing the permissions on everything all at once.
-
This sounds right:
ifconfig eth1 192.168.X.X netmask 255.255.255.0Add a line like this to your go file to survive reboots.
Close but if the interface is currently down ifconfig will leave it down.
ifconfig eth1 x.x.x.x netmask y.y.y.y up
will set the parameters and bring up the interface. This will only work if the driver module has been loaded in the kernel. If both nics use the same driver module this won't be an issue, but unRaid may not load the kernel module for the 2nd nic and if that happens you would have to use modprobe to insert the module first. Regardless, putting the commands in the go file should work and give you a fully multi-homed system that survives reboots.
-
Looks like you don't have a network.cfg file in /boot/config/ (the config directory on your flash drive). If that is indeed the case, create one and paste in the following
# Generated network settings USE_DHCP=yes IPADDR= NETMASK= GATEWAY=
You can do it from your windows machine or you can create/edit the file directly using vi or medit from a console on the unRAID box. After a reboot it should use DHCP to get an IP address.
If that doesn't work, please attach a syslog so we can get more in depth info about what is going on
-
If you don't want to mess with setting up your shares as NFS, there is a simpler "hack" I came across: just enable "Internet Sharing." You can even turn off your AirPort after setting up Internet Sharing through your AirPort.
I was getting over 40MB/s both reading and writing just by enabling "Internet Sharing" and connecting to smb://tower/ShareName
Interesting. Sounds like protocol overhead or implementation to me. I just made a test copy of of my array and I'm getting 60MB/s + sustained transfer writing to an SSD on my Win7 workstation. I tried copying from a WD green drive and a 7200 RPM drive and got about the same results.
OSX may be using the SMB protocol rather than the CIFS protocol. You could be losing some transfer speed to the overhead in the protocol. That kind of makes sense because you are getting much faster reads/writes using NFS. NFS is a Unix derived file system and OSX does indeed play nice with it. That's the route I would go sense you are running a Mac
You are correct that AFP may be a good solution for you if when V5 stabilizes and gets out of beta.
Here are some links if you want to read up on file systems:
A bunch more that you've never heard of
Glad the iperf package helped you out
-
Log into the console and type
ls -l /path/to/share/with/files
and replace the path string with the actual path on your system. Post the results (or a subset with a few files/directories) back here. Odds are the problem is with how Samba is mapping the perms.
-
Yeah, it's not about the age. It's about how well the negative or interpositive has been stored and preserved, how well it has been restored and how well it has been mastered.
There are plenty of Blu-ray transfers of films from the 80s and even 90s that look worse than The Wizard of Oz on Blu-ray, which is now 72 years old and one of the first colour films.
It's amazing how broad the quality is on DVD/BD transfers. Some are great and some are pure garbage. The Wizard of Oz BD transfer is amazing considering the source and the age.
-
You got me. Even with the smbd process being terminated abnormally, the config shouldn't have gotten jacked and since you've removed the world execute bit there's no reason for samba to mark the files as hidden. Hopefully someone else has another idea. I am curious to know what the problem ends up being...
-
Map hidden and map system are both enabled so having the file perms set to 777 would definitely cause the files on the cache share to be exposed as hidden files to a windows box. Try mounting the cache/Backups share as a drive on the windows box
net use x: \\MICRO\cache\Backups
then get the attributes of some of the files
attrib Firefox*
and post the result. I'm guessing your going to see something like
A SH Z:\newfile.txt
showing the hidden and system flags set. You shouldn't need to restart samba for the permissions to change but you do need to refresh your view (F5) if you had the share open in an explorer window.
-
Post the output of
testparm -s
If the permissions changed when you ran the find commands, samba should be exposing the files, if the permissions didn't change you got other problems.
Official support is via email, Limetech monitors the boards some but it you want official support you have to request it.
-
root@MICRO:/mnt/cache# ls -l /mnt/cache/Backups/ total 178786 -rwxrwxrwx 1 root root 60327668 2011-03-21 18:37 Firefox\ 3.6.14\ (en-US )\ -\ 2011-03-21.pcv* -rwxrwxrwx 1 root root 55216833 2011-03-29 18:34 Firefox\ 3.6.14\ (en-US )\ -\ 2011-03-21.rar* -rwxrwxrwx 1 root root 67347021 2011-03-31 16:40 Firefox\ 4.0\ (en-US)\ -\ 2011-03-31.pcv*
I'm guessing it's a problem with how samba is mounting the cache drive.
The cache drive is 320GB, so this is wrong:
Yep it's the way Samba is mapping the file permissions to Windows file attributes (I really need to write a wiki article on this!). Background on what is happening is available here.
Note the below commands will reset the permissions for ALL files and directories on your cache drive. If that is not acceptable (ie some directories/files need different permissions) you need to know that before running those commands as there is no undo and modify the commands as appropriate...
To fix current files:
for files:
find /mnt/cache/ -type f -exec chmod 700 {} +for dirs:
find /mnt/cache/ -type d -exec chmod 711 {} +I'm not sure what caused the file permissions to get changed on your drive, this usually crops up when mounting a drive via CIFS/SMB on the unRaid server and copying files over. Anyway once you run those commands above the file permissions should look like
-rwx------
and similar for directories.
Windows can't get network drive sizes right to save its life. MS should just give up on showing the number considering it is wrong 99.9999999% of the time
-
Post the output of
ls -l /mnt/cache/Backups/
I was compressing to xz not to lzma. Sometimes it pays to step back and take a break and have fresh eyes take a peek.
I wil add in that iperf is only measuring raw bandwidth. Any disk activity will slow things down. That said your numbers are very low. 55 KB/s is < 1 Mbps; based on your results I think there is definitely something wrong. I would start with the cables and/or try diff machines to try to isolate the problem.
LZMA bzroot compression
in General Support (V5 and Older)
Posted
It could have to do with the default compression level. Not sure what Limetech uses when he compresses the kernel. Any compression with lzma will end up better than .gz though