09.04.2015 16:32, Erich Titl пишет: > Am 09.04.2015 um 14:25 schrieb Andrew: >> 09.04.2015 14:35, Erich Titl пишет: >>> Am 09.04.2015 um 11:12 schrieb Andrew: >>>> Hi. >>>> >>> ... >>> >>>> For me, it's much easier to update just one file instead of hundreds of >>>> modules on persist storage. Esp. when one broken (non-updated) module >>>> can break system. >>> You can't be serious. If we upgrade, we upgrade the kernel, initrd, >>> initmod and of course the kernel modules plus all installed user level >>> packages. This is what upgrade does. Nobody is forced to use it. And, >>> btw. broken modules exist even inside tarballs :-( >> You proposed to fetch all 1236 modules (5.1 branch, i686 release) during >> upgrade file-by-file? I think that it's a really bad idea. > I never said that. > >> Or you proposed to fetch only modules that are currently loaded by >> kernel? This is also a bad idea, it'll cause a great headache in future, >> when somebody will try to install new wireless (or other) card to his box. > We already discussed this. I will reiterate. > > 1) An upgrade function does _not_ imply hardware modifications. > 2) A small box _cannot: hold all modules. It will always be configured > with the _necessary_ subset of modules. > >>>> So let's leave modules updating for tiny embedded systems which can't >>>> fit module package. >>> Why should we? Just because you don't like a directory tree? >> Let's calculate. 1236 files on FS with cluster size=4kb will result in >> average 2kb per file overhead, or more than 2MB wasted storage space. > I don't care about 2MB on the server, I care for the space wasted on the > embedded system.
So let's store both packed modules + unpacked on server side, as we decided earlier. Packed modules will be suitable for routers with enough storage space; unpacked - for tiny systems. I just voting against excluding packed modules in prefer to unpacked tree. It'll break usability in many cases. > Or more. >> Then, if wget fails on some enough critical module (for ex., library) - >> you'll get a broken module dir (modules are here, but part of them are >> unusable because one dependent module is compiled for other kernel) and >> a big headache if this module is required by driver for NIC that is >> connected to Internet. > No, because > > 1) upgrade detects a failure and notified the user > 2) upgrade is an add on to a cloning tool which allows to reboot from > another partition Ok. >>> We can either use the unpacked tarball (then I doubt the necessity of >>> the tarball as a whole) or use a squashfs. If we decide for the squashfs >>> then we ned to adapt a few more things. The unpacked tarball is easier >>> because a trained monkey can handle it. You have a directory tree before >>> it is tarballed and compressed (which I consider work) Let's not forget, >>> this is a programmable computer. >> How many people will require custom kernel modules? > Ask aroung in the user list, I would guess less than 10. > >> How many of them will get this module from 3rd-party sources, not by >> compiling module for their kernel? > See above > >> And for that people we can (ad must) leave moddb - just shrink from >> moddb all modules from squashfs. > I am building moddb of course, and for the people requiring extra > modules they will be able to include them easily. I mean moddb save/load logic. It'll be unneeded in most cases and empty, but it'll leave possibility to load custom modules. >>>>> On the downside squashfs needs adaptation of busybox and the kernel. >>>>> Also we need to create the squashfs files when building the package >>>>> directory on the server. >>>> Just kernel. AFAIK squash file doesn't need something special for it's >>>> mount. >>> That is just part of the story. Busybox mount squashfs needs to be enabled. >>> >>>>> We need to decide >>>>> >>>>> - do we really need a single file for the modules on the server? >>>>> - is a compressed tarball or a squashfs the right solution if there is >>>>> to be a single file? >>>> Is there a better alternatives than tarball/squashfs for single modules >>>> package? >>> I don't care for either. I can live with a squashfs, but it means that >>> you can only access these files on a system that supports it. I can live >>> with that, can everybody? >> Why not? Custom modules may (and should) be placed into r/w package like >> moddb. > They are, but of course they cannot be replaced automatically if they > are not in either the tarball, the squashfs or in the modules directory. They'll be in modules directory because they'll be in moddb. As I said, I expect that squash will be mounted on boot on /lib/modules/<kernel version>, then - modules probing will be ran, then - modules will be copied to /etc/modules, exclusions for them will be added to moddb (to not store these modules in moddb), and then - unmount squash and re-probe modules from /etc/modules (for loading custom modules). > No method in the world can do this. And this is not a question of > flavour. We are talking here about the storage of a few binary files, > not how a system can or cannot be upgraded. I have proven that I can, at > least with the hardware I have for testing and I am pretty confident > that my method is pretty generic. > > Upgrade warns the user on failure. At that moment he can still decide if > he wants to fix the problem. You can of course brick a system if you > continue on a broken upgrade. It is the users decision, it is like a red > traffic light, you can always ignore it. > > As I said, I would like a tool to save and restore the whole operating > system plus settings on en external system and I am probably going to > write one. Right now I save my system to a second partition on the flash > disk and I can select at boot time which partition I want to boot from. > This has saved me from a lot of grief. > > So.... > > - I understand you want to have your tarball, that is fine. > - I need access to the modules and I don't want to be restricted by too > little space, so I either need the modules directory or a squashfs file. > I don't think this is too difficult, it is just utterly redundant. > > IMHO not bundling the files is the easiest way, but it appears there is > a lot of opposition against it and I am too lazy to fight. > > To avoid redundany we need to replace the tarballs with squashfs files. > This forces us to add squashfs support to the kernel and Busybox and of > course buildimage and the build environment. There may be other > scenarios, but I don't believe they are any better. For me, squashfs will be also better than tarball. It'll remove need of module autoprobing, and it'll make system upgrade easier than with tarball (esp. for system with NICs that aren't in moddb). > In the end I just want to reach an agreement on the storage of a few > files on a server, not if my ideas are bad or not. > > "eppur si muove" (Gallilei) > > ET > ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
