IRC Logs for #crux-devel Thursday, 2012-06-28

*** horrorSt1uck has joined #crux-devel00:01
*** horrorStruck has quit IRC00:04
*** sepen has joined #crux-devel02:08
*** mike_k has joined #crux-devel03:56
frinnstjaeger: hah, nice05:10
frinnsta year or so ago I ordered hardware on a sunday evening. it arrived the following day05:10
frinnstwitchcraft!05:10
*** prologic has quit IRC05:28
*** prologic has joined #crux-devel05:28
juejaeger: the performance issue I saw with nvidia 302.17 was simply the enabled 'Sync to VBlank' setting ;)05:38
frinnstnew default setting?05:41
juenot sure, but with older version of the driver the settings doesn't work for my card, I always got the max. refresh rate with glxgears even though a start-message says that the FPS should be the same as the monitor refresh-rate05:51
juenow it works: 60 fps with sync setting, around 600 fps without05:52
jaegerjue: good to know :)08:07
*** deus_ex has joined #crux-devel08:40
jaegersepen: so what was your objection to the initramfs/iso squashfs stuff again? I didn't really get the point you were trying to make when we talked about it last09:05
jaegerI'm looking back at the logs at http://crux.morpheus.net/irc/?channel=crux-devel&date=06Jun201209:07
Romstersomething about arm not able to use squashfs?09:15
Romsteris about all i can recall.09:15
jaegerI understand wanting to keep the size of the boot environment small but I'm guessing the crux-arm version loses some things like the ability to do the installation over SSH09:19
sepenjaeger: well, I used telnetd for that09:21
sepenjaeger: anyways, I'm ok with our current iso+initramfs+squashfs09:22
Romsterwhich reminds me have they completed starwars telnet yet09:22
jaegerI did start to wonder if a tar.xz would be smaller than the squashfs for the ISO image, but even if it ends up smaller it would likely be way slower09:22
sepenjaeger: yep for ram09:23
sepenjaeger: just I was wondering about to use our crux-*.iso as a rescue and not only for installations, so for that we should hack a bit our initramfs09:23
sepenfor example I'd like to add more feature to busybox09:23
jaegerI already use it for some rescue operations but it could definitely do more09:24
jaegerThat runs counter to the crux minimalist idea, though, if we add too much09:24
sepeninitramfs < 4MB09:25
sepenhmm can't find the right words to explain that in english09:25
sepenpff09:25
jaegerI don't think we could keep it below 4MB while still including the module support that the current ISO has09:26
jaegerI haven't counted, though09:26
jaegerI imagine there are a lot less modules needed for ARM09:27
sepenjaeger: I don't have modules in crux-arm's initrd09:27
sepenmodules are in the media, which is found_and_mount09:27
sepenlike you know09:27
sepenwell, is another way to do things, don't pay me much attention09:28
jaegerI get that but the way the crux iso is set up is quite different09:28
jaegerI've got no objections to improving it, just trying to understand the improvement09:28
sepenwell, I've an improvement that should avoid setup.dependencies file (and the need of generating this file from iso.git/Makefile, etc.)09:29
jaegerIn the crux iso the point of the initramfs is to find and mount the installation media, to put it in simplest terms09:29
sepen^^ to do that just we should use pkg-get ;D09:29
jaegerOnce that is found a basic environment is installed in RAM to make it into a minimal live environment09:30
sepenpkg-get can manage deps, so we just should run pkg-get add instead of pkgadd for every port09:30
jaegerso things like SSH can work, or other things that need read-write space09:30
sepenyep09:30
sepenbut note that /tmp is tmpfs, rw too09:30
jaegerI suppose it could be limited to /tmp, /var/run, etc.09:31
sepenwe can do things like ln -s /tmp/lib/modules /lib/modules09:31
jaegeryeah, I've seen that in your rc file09:31
sepenjaeger: anyways, I'm still wondering about improvements, so don't take me too seriously for now09:32
sepenafter a deep research I'll talk with you again09:32
jaegeralright09:32
sepenjaeger: well there is one thing I'd like to have, I used to copy vmlinuz + initramfs + modules after installations09:33
jaegerI wonder how much of ISO_PACKAGES busybox could replace09:34
sepenso I configure lilo/grub to boot the default kernel image + initramfs, but our current initramfs requires crux-media to work09:34
sepenjaeger: nah, my POV was that I only need on the initramfs the minimal tools to boot,fdisk,mkfs,mount and setup09:35
jaegerwhich is similar to what I just said :)09:35
sepenso I have in my initram only busybox with some applets + ncurses/dialog09:35
jaegerI think busybox can replace a lot of the tools in coreutils, *fsprogs, etc.09:36
sepenyep, it is not an improvement though, just a different way to do things, but I'm still think that current iso its ok09:36
jaegerIt's ok but it could probably be more efficient09:36
sepenjaeger: are you talking about to use busybox (applets) + ncurses/dialog + pkgutils + openssh maybe?09:36
jaegerwill do some research and testing09:36
jaegeryeah, pretty much09:37
sepenI could help you to do that09:37
sepenproblem are non-static binaries09:37
sepensince you'll need nswitch's stuff and all ns libs09:37
sepenor it will fail to resolve names09:37
jaegercould build static binaries for those few things, or include the others09:37
sepenthat's a common task for busybox09:37
sepenjaeger: hmmm pkgutils is static iirc09:38
jaegerthere's already a bunch of that in the environment, it would just be trimming the packages that get installed from the $ISO_PACKAGES list and replacing some of them with busybox applets09:38
jaegerIt wouldn't be difficult to do either static or dynamic09:38
jaegerI've not done any work on this yet, just speculating right now09:40
sepenjaeger: http://crux-arm.nu/gitweb/?p=initrd.git;a=blob;f=Makefile09:40
jaegerI've been there already, heh09:40
sepenmake CC="gcc -static" does it for dialog09:40
jaegersome modules would still need to be in the initrd/initramfs (or built into the kernel)09:43
jaegerto find the media itself09:43
sepenyeah, this is the main problem I found09:43
jaegersince it could be usb, cdrom, mmc, sdX09:43
sepenat least block devices09:43
jaegeryeah09:43
sepenbut anyways I think that could be < 8MB09:43
jaegerIn the case of non-ARM crux that's a lot of modules09:43
jaegerfor scsi and raid controllers, etc.09:44
sepenby default the default size in kernel for ramfs09:44
sepenjaeger: size for all that modules?09:44
jaegernot sure, I'm going to check09:44
sepenjaeger: note that we only need some modules for find_and_mount the media installer and look for crux-media file09:45
sepenmaybe only the ones related to media installer devices, like usb, cdrom, ... others?09:45
jaegerthe initramfs itself is 6.8M, not too bad09:45
jaegeryes, that's what it does now... but that includes hard disks09:45
sepennowadays we could also use xz format for ramfs images09:46
jaegersome people like to install from an extra partition on their HDD or RAID or whatever09:46
sepenhmmm09:46
sepenyep, and +1 for that09:46
jaegerstill, 6.8M isn't bad, it's less than I remembered09:46
sepenthat means that also I could use the initramfs as a rescue rootfs09:46
sepennote that squashfs will dissapear09:46
jaegeryeah09:47
jaegerthere will be a tradeoff for replacing squashfs with modules.tar.xz or the like, though... might be less RAM needed but will take longer to uncompress09:47
sepenjaeger: another alternative instead of doing runtime decompressions to /tmp will be to use unionfs but thats another thing09:47
sepenah yeah09:48
sepen1 sec, boss here09:48
jaegerI would think in the case of an install/rescue environment that speed is a secondary concern, though09:48
sepen*Re09:54
sepenjaeger: I'll try to have sometime tonigh for tests09:55
jaegerThere's no rush at all, of course09:56
sepenI'll use initrd on my tests since don' need to create the cpio stuff09:56
sepenbut initramfs would be the same09:56
sepenah ok, just I want to play a bit with that09:56
jaegerI wonder if there's a memory advantage to initrd over initramfs or the other way09:56
sepenhere at office I'm trying to force an installation on some vortex86 ;D09:57
jaegerI'll be playing with it as well, just wanted to say that we don't have to hurry or anything :)09:57
sepenjaeger: hmmm, I need to read more about that09:57
jaegerThere ARE differences in initrd and initramfs but I wonder if one is better than the other for us09:58
sepennah, I don't have it09:58
sepenjaeger: since I'm not an expert for initrd/initramfs just I only noticed some diffs when creating09:58
jaegerhttp://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Introducing-initramfs-a-new-model-for-initial-RAM-disks/09:58
jaegersome info, not exhaustive09:58
sepenohh thanks09:59
jaegerI remember when I created this initramfs that I thought it was the preferred way but that's long enough ago that I don't remember for sure09:59
sepenjaeger: I started with both of them http://crux-arm.nu/gitweb/?p=initramfs.git;a=summary but was hard to maintain09:59
jaegerah10:00
sepenso I decided to go with one of them and later do more things and comparisons10:00
sepenjaeger: gen_init_cpio ...10:00
sepeniirc nowadays the initramfs.lst  could be created on the fly10:01
sepenanyways I used the way we have in crux's iso, a list file with inodes, etc.10:01
jaegerI didn't really find that hard to maintain but I don't mind changing it if there's an easier way that does not introduce bloat10:02
*** horrorStruck has joined #crux-devel10:02
jaegerI went with a specific list originally because there are lots of other modules that aren't needed10:02
jaegerdidn't want to include the unnecessary ones10:02
sepenjaeger: nah, I wanted to mean, that was hard to maintain both repos; initramfs.git and initrd.git for crux-arm10:02
jaegerAh, ok10:02
sepenjaeger: thats true10:02
*** horrorSt1uck has quit IRC10:04
jaegerin that document I linked the "initrd vs initramfs" section is interesting, even if it's short10:05
jaegerIt sounds like initramfs is the more memory-efficient model, from the article10:10
sepenyeah, but can't understand the idea explained about the real init, with PID 110:11
jaegerin the "ramdisk vs ramfs" section10:11
sepenyep10:11
jaegerwell, with initrd /linuxrc or /rc is *not* PID 1, so handling goes back to the kernel afterwards10:11
jaegerin an initramfs you can pass it to whatever you want because the /init is PID 1 and can exec another process10:12
sepenhmm /proc/sys/kernel/real-root-dev10:12
sepenso initramfs is the way to go10:12
jaegerI think the PID 1 thing is probably less important for us than the memory usage, though10:12
sepenyep10:12
jaegereither way initramfs sounds like a better implementation10:12
sepen+110:12
jaegerthis article is from 2006, it's probably what I read back then too :)10:13
sepenno idea why I decide to use initrd for crux-arm, maybe due to some ARM-bootloader restriction10:13
sepennote that we started to boot crux-arm from WinCE devices the first time10:13
jaegerno idea there, you know way more about ARM than I do :)10:14
jaegerI don't even have an arm device, though I'd like to get a raspberry pi10:14
sepenfor example, mkimage converts initrd.gz to uInitrd for u-boot, so I assumed (maybe I was wrong) that u-boot requires initrd10:15
sepennah, my fault10:15
sepenjaeger: rpi? that would be nice10:15
jaegerI tried to get genesi to donate me a netbook, too, but they didn't :)10:16
jaegerused to work with one of their people here10:16
sepenits hard with netbooks ;D10:16
jaegerthe rpi would be my preference, I love the small form factor10:16
sepenjaeger: I'd like to have the 'cubox' device10:16
jaegerI suppose technically I do own one arm device, an iphone 3G10:17
sepenyep10:17
sepenme too, nokia e7110:17
sepenbut it's hard to run from the bootloader to the Xvirtualkeyboard ;D10:17
jaegerheh10:18
sepenmy old phone http://crux-arm.nu/SupportedDevices/Htc-prophet10:18
sependonated by pitillo ;D10:18
sepensome screenshots: http://crux-arm.nu/files/screenshots/htc-prophet_blackbox.png10:19
sepenhttp://crux-arm.nu/files/screenshots/htc-prophet_pekwm_xvkbd_noborder.png10:19
sepenhttp://crux-arm.nu/files/screenshots/htc-prophet_e17_illume_vkbd_terminal.png10:19
jaegernice10:20
sepenfrom the days where we crosscompiled all ports10:20
jaegerthough one reason I like the rpi idea is that I can run it on an HDMI display :)10:20
sepenjaeger: cubox too10:20
jaegerI like the cubox though it is quite a bit more expensive10:22
jaegerIt does come with a power supply, SD card, and enclosure, at least10:22
sepenpfff here I waste all the day trying to run 2 old vortex86 devices10:35
sepento boot I used hacked-usbdisk images based on i586-2.7 iso contrib by jue10:36
sepenbut to avoid compiling a new kernel I'm trying to use the provided one in the iso, which worked fine but those little devices have only 128MB of flash-disc, pffffff10:37
sepenhttp://store.epatec.net/es/product_info.php?cPath=1&products_id=4610:37
jaegerneat10:39
sepenhehe I created a hack to have running the iso stuff on a harddisk, just created the crux-media file ;D10:41
jaeger:)10:45
sepenit's time to go home10:54
sepensee ya'10:54
*** sepen has quit IRC10:54
*** prologic is now known as Guest7770413:01
*** deus_ex has quit IRC13:06
*** deus_ex has joined #crux-devel13:09
*** deus_ex is now known as pedja13:21
jaegera good start... converting crux.squashfs to rootfs.tar.xz makes it 10MB smaller13:48
*** mike_k has quit IRC15:51
*** hawksbill has quit IRC16:30
*** hawksbill has joined #crux-devel16:32
*** _____________ma has quit IRC17:24
*** mavrick61 has joined #crux-devel21:37
*** mavrick61 has quit IRC23:23

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!