July 2013 - openSUSE Users - openSUSE Mailing Lists

Re: [opensuse] Machine spec for 3d art
by Dylan 28 Jul '13

28 Jul '13

On 28/07/13 08:17, Dylan wrote: > On 28/07/13 03:19, Dirk Gently wrote: >> Dylan wrote: >>> Hi All, >>> >>> I'm helping a friend replace his old Windows Vista machine which died >>> in the heatwave. He does a lot of 3d art with blender (which has been >>> terminally slow under vista.) I've provided a temporary Linux box >>> (actually my testbed machine: AMD Athlon 64 >>> X2 4400+ with 2G ram, which is already faster than his old quad core >>> with 4G) and I'm hoping that by the time he gets a new machine he >>> won't want Windows on it... >>> >>> The 3d art is a hobby and the budget is limited. I'll be using his >>> existing graphics card and 'on-board' sound will be more than >>> adequate. So, which aspects of the spec are likely to have the most >>> impact? I'm assuming more cores and more memory, but >>> which would have the most impact for cost? Is there an appreciable >>> difference between AMD and Intel chips? Are there any other aspects of >>> the motherboard that might have a bearing on rendering speeds? >>> >> >> 1. Memory >> 2. CPU speed (cores * GHz) >> 3. Multiple disk availability (home directory & data on different >> physical disk than OS and apps) >> 4. Disk rotation speed. >> >> Current AMD chips are bit slower (in GHz) than current Intel chips, but >> you can use the >> money saved to buy more MEMORY and a 2nd Disk drive. > > Well, having been able to do some empirical testing thanks to some > friends I can confidently say that memory capacity has barely any effect > at all (rendering using consistently <500MB and no swap). HD > characteristics similarly seem negligible in their relevance since there > is no appreciable disk activity during the render cycle. All in all, > doubling the cores halves the render time (approximately) so I'll be > specifying "as many cores as you can afford". > > Dylan > >> >> >>> Any and all comments welcome. >>> >>> Dylan >> >> > -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

Re: [opensuse] Expand user's encrypted home image file
by Marco Vittorini Orgeas 28 Jul '13

28 Jul '13

On Saturday, July 27, 2013 04:32:22 PM Jan Ritzerfeld wrote: > Am Samstag, 27. Juli 2013, 14:56:07 schrieb Marco Vittorini Orgeas: > > [...] > > At this point I guess I would be more lucky if I cross post this to the > > dev mailing list, hoping someone there could shed some light over the > > issue? > > Okay, I looked at the source code myself, starting at line 499: > https://github.com/yast/yast-users/blob/master/src/UsersRoutines.pm > YaST simply calls cryptconfig with the enlarge-image option that enlarges > the disk image and the file system. Fine, reading the source code of > cryptconfig, I see that the enlarge-image option enlarges the image by > simply adding a single 0 byte at the new(!) end position effectively > creating a sparse file. Then it checks and resizes the filesystem using > resize2fs for ext* or resize_reiserfs for reiserfs. > > So, I think that the enlargement done by YaST will increase the used space > by 1 byte during the whole process and in the end. Maybe resize2fs will need > some additional space. > > However, try on your own risk! > > Gruß > Jan Thank You! I had the time to make some tests in a virtualized environment and those are the results: | Before resizing | =============== | File: ‘/home/test.img’ | Size: 104857601 Blocks: 15728 IO Block: 4096 regular file | Device: 802h/2050d Inode: 278951 Links: 1 | Access: (0600/-rw-------) Uid: ( 1001/ test) Gid: ( 0/ root) | Access: 2013-07-27 23:45:45.424951970 +0200 | Modify: 2013-07-27 23:45:45.418951967 +0200 | Change: 2013-07-27 23:45:45.418951967 +0200 | Birth: - | | After expansion | =============== | File: ‘/home/test.img’ | Size: 209715202 Blocks: 21688 IO Block: 4096 regular file | Device: 802h/2050d Inode: 278951 Links: 1 | Access: (0600/-rw-------) Uid: ( 1001/ test) Gid: ( 0/ root) | Access: 2013-07-27 23:55:27.061452340 +0200 | Modify: 2013-07-27 23:55:27.051452341 +0200 | Change: 2013-07-27 23:55:27.051452341 +0200 | Birth: - | | After shrinking | =============== | File: ‘/home/test.img’ | Size: 209715202 Blocks: 21688 IO Block: 4096 regular file | Device: 802h/2050d Inode: 278951 Links: 1 | Access: (0600/-rw-------) Uid: ( 1001/ test) Gid: ( 0/ root) | Access: 2013-07-27 23:55:27.061452340 +0200 | Modify: 2013-07-27 23:55:27.051452341 +0200 | Change: 2013-07-27 23:55:27.051452341 +0200 | Birth: - I feel confident to state that after the expansion, as you can see, the i-node is the same, so the file is still the old one. However, after a bit of gymnastic with "strace" I also have isolated the related syscalls (the size are different in respect to the previous output because I needed to fine tune strace and I had to kept expanding the file with yast): | mmap2(NULL, 26242, PROT_READ, MAP_SHARED, 3, 0) = 0xb7031000 | close(3) = 0 | futex(0xb72d3fc8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 | access("/home/test.img", F_OK) = 0 | open("/home/test.img", O_WRONLY|O_LARGEFILE) = 3 | flock(3, LOCK_EX) = 0 | _llseek(3, 10485760, [272629763], SEEK_END) = 0 | write(3, "\0", 1) = 1 | close(3) = 0 | access("/dev/mapper/_home_test.img", F_OK) = 0 | write(2, "The map device for this image is"..., 40) = 40 This confirm yast "stretches" the file size by writing that '\0' at the new position (old size + increase). I am not sure if this automatically create a sparse file because: 1. The file originally is not created as such. 2. Effectively the file size is reported by (according to 'ls') counting also the padded zeros bytes, before and after the re-sizing. The choice to not create a sparse file could be questionable - https://en.wikipedia.org/wiki/Sparse_file - but seen the nature of the file (the home directory!) it could be that devs have chosen *not* to run any risks? The resize2fs stage should not create "space" problems (or at least not big problems).In fact, accordingly to http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/resize/resize2fs.c | /* | * Resizing a filesystem consists of the following phases: | * | * 1. Adjust superblock and write out new parts of the inode | * table | * 2. Determine blocks which need to be relocated, and copy the | * contents of blocks from their old locations to the new ones. | * 3. Scan the inode table, doing the following: | * a. If blocks have been moved, update the block | * pointers in the inodes and indirect blocks to | * point at the new block locations. | * b. If parts of the inode table need to be evacuated, | * copy inodes from their old locations to their | * new ones. | * c. If (b) needs to be done, note which blocks contain | * directory information, since we will need to | * update the directory information. | * 4. Update the directory blocks with the new inode locations. | * 5. Move the inode tables, if necessary. | */ | Apart from 2, to me it seems like the bulk of the work is done over the i-node table. Some comments: The Yast gui/cli interface is broken: in both I can slide the home size upwards *and* downwards.*But* while a bigger size is honoured by effectively enlarging the file, a smaller size is perfectly ignored: that is confirmed by looking at that "sub CryptHome" in https://github.com/yast/yast-users/blob/master/src/UsersRoutines.pm which ignores the case where $org_size > $home_size. You don't get any warnings that it won't succeed and Yast even give the impression to actually processing the request. The "stat" output confirm this. I wonder why should be ignored such a thing?Creating a smaller image file and copying in the old content is quite linear, on the lines of how Yast already manages an image file "decryption" request, line 360 https://github.com/yast/yast-users/blob/master/src/UsersRoutines.pm. If implemented, this could represent a big advantage over the "Ubuntu" ecrypt-fs approach which deal directly with partitions and would actually make justice to the image file approach! Remain the fact that at the moment that slide shouldn't allow to go downwards! Maybe a related bug issue should be open. I will proceed with the actual re-sizing as soon I will have a backup and will post the result here. -- Marco -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

Re: [opensuse] Expand user's encrypted home image file
by Marco Vittorini Orgeas 27 Jul '13

27 Jul '13

On Saturday, July 27, 2013 10:18:15 AM Jan Ritzerfeld wrote: > Am Mittwoch, 24. Juli 2013, 01:23:34 schrieb Marco Vittorini Orgeas: > > [...] > > Is a well know scenario in the openSUSE community with the procedure known > > as bug free? > > You should always have backups! And do not forget to test the backup before > you enlarge your home. There is no bug free software. Or hardware. Power may > fail while resizing, your kernel may crash... > Of course, I will have backup of the relevant LOGIN.img and LOGIN.key files *before* starting the yast re-sizing procedure. Moreover, in this case with the openSUSE approach backing up is piece of cake, as you have to deal with just 2 files opposed to the works of dd/tar an entire physical partition. > > Gave the situation I'm worrying about how it will re-size the file to > > accommodate the new size? > > I guess by creating a new image file with the new size encrypted with the > > same key, and then copying all the "old" image file contents, eventually > > deleting the "old" one at the end? > > [...] > > I do not know. However, the documentation says: > | The advantage of encrypted container files over encrypted partitions is > | that they can be added without repartitioning the hard disk. They are > | mounted with the help of a loop device and behave just like normal > | partitions. > > I would expect that resizing the encrypted cointainer file is as easy as > unmounting the container, adding some extra bytes to the end of the image > file, remounting the container and resizing the filesystem. If so, there is > no need for an extra image file while resizing. > > I would be relieved knowing that would be the case.Also in that case I should be doing the procedure with root as the image file as to be unmounted, shouldn't I? Still in any case my (original) problem here is knowing *for sure* which approach is employed: a copy + delete requires twice the currently LOGIN.img size physical space.My LOGIN.img is currently too big to permit that and I have no time to cherry-picking to save space.Still I do need space. I am not trying the procedure because I'd like to know beforehand if the thing will succeed or not, saving myself any surprises and extra work, because of lacking of time. At this point I guess I would be more lucky if I cross post this to the dev mailing list, hoping someone there could shed some light over the issue? Thanks again. -- Marco -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] problem starting opera
by Bob Rea 27 Jul '13

27 Jul '13

When I try to run opera, I get this: bob@gandalf:~> opera Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files Failed to open file (please check with "ulimit") [fopen]: Too many open files opera: Failed to set up core. bob@gandalf:~> ulimit unlimited this is opensuse12.0 and a recent one of opera, can't get the version number at first I started getting google message saying the page I was trying to open was not available and I could restart and it would be okay for a while, but now this. What do I need to do? -- Bob Rea mailto:gapetard@stsams.org http://www.petard.us http://www.petard.us/blog http://www.petard.us/gallery Where is Bill Stringfellow now that we really need him? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 5

[opensuse] chown not permitted on NFS share??
by Greg Freemyer 26 Jul '13

26 Jul '13

All, I have a VM in cloud I'm building up. It has openSUSE 12.3 on it. I want /srv to be a large space so I can put a sftp chroot set of jails on it. I ordered a 100 GB NFS share from the hosting company today and they created it for me. They actually had 2 options for diskspace and I ordered the cheaper "backup" space (which may be my problem). I'm trying to mount the NFS share to it. (I haven't worked much with NFS.) Before mounting /srv is owned by root:root and its mode is 755 just as expected. After mounting the NFS share on /srv, I have this: # ls -ld srv drwxrwsrwx+ 6 cyrus 96 4096 Jul 26 2013 srv I don't like the owner, nor the permissions. Trying to change the permissions chmod claims to work, but doesn't # chmod 0755 srv # ls -ld srv drwxr-sr-x+ 6 cyrus 96 4096 Jul 26 2013 srv chown simply doesn't work # chown root:root srv chown: changing ownership of âsrvâ: Operation not permitted The problem is recursive, so as I place folder trees on the /srv they all have the same owner and permissions. This is the line I added to /etc/fstab: 10.200.3.230:/mnt/pacers1/kvm672/kvm672 /srv nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.200.3.230,mountvers=3,mountport=42425,mountproto=udp,local_lock=none,addr=10.200.3.230 0 0 I'm sure not all of that is needed, but I stole it! Is there anyway I can overcome this issue? Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 3

[opensuse] Dual boot OS12.3 and Vista
by Dylan 25 Jul '13

25 Jul '13

Hi All I need to set up a machine to dual boot OS12.3 and Windows Vista. I figure the process will be as follows: 1 - Install OS12.3 (During the process, create a partition for Vista) 2 - Install Vista into the prepared partition 3 - Boot from the OS12.3 install media to re-install GRUB with Windows added Are there any gotchas in the process I should be aware of? Thanks for any pointers Dylan -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 4

[opensuse] openSUSE 12.3. automount, /media
by Ruediger Meier 25 Jul '13

25 Jul '13

Hi, Since I've upraded to 12.3 I don't understand the automounting logic anymore. Some external medias are mounted in /media and some in /var/run/user/$USER. I want to have automount independent from any particular user. Usually there are none, one or many users logged in and it's not clear who has insterted the media and who wants to do use it. How can I set that always /media is used again? And how can set the permissions which should be used? cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 11

[opensuse] News for darktable users
by Togan Muftuoglu 25 Jul '13

25 Jul '13

Hi, For those using darktable package from either official openSUSE repos or factory, or from graphics repos, roughly a month ago, I have announced that the thumbnail compression will be removed. Now thanks to packman this option is back and all you have to is use the Multimedia repo and select darktable from packman. This version has the squish library enabled meaning thumbnails are compressed and smaller. Have fun Togan -- Life is endless possibilities -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2

[opensuse] Looking for TV viewer programs in Opensuse 12.3
by Terry Eck 25 Jul '13

25 Jul '13

Hello, Currently run 12.1 and wish to update to 12.3. Checked some of the rpms on the cdrom (under suse/i586) and cannot find xawtv (which I currently use) or any other rpm names that hint to being a program for watching TV. If I do update could I include xawtv.rpm for version 12.1? Thanks for any help in figuring out what to do. Terry PS: I have noticed that as newer versions of Opensuse occur more of my favorite programs are either missing or no longer work. -- OpenSuSE 12.1 -- Kernel 3.1.10-1.29-desktop --- 09:30AM --- Wed 07/24/13 There are 10 types of people, those who know binary and those who don't -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 4

[opensuse] Totem 3.6.3 stop play Divx/Wmv
by Marco Calistri 21 Jul '13

21 Jul '13

Hello OpenSusers, If someone like me faced a problem attempting to play a WMV or DIVX MPEG4 video using Totem, try to install this additional plugin and your problem will (should) be get resolved: sudo zypper in gstreamer-plugins-libav Cheers, -- Marco Calistri (amdturion) opensuse 12.3 (Dartmouth) 64 bit - Kernel 3.7.10-1.16-desktop Gnome 3.6.2 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0