Hi KP Am 06.06.2015 um 01:34 schrieb kp kirchdoerfer: > Hi Erich; > > ...sorry for being late. > > Am Dienstag, 2. Juni 2015, 10:44:39 schrieb Erich Titl: >> Hi KP >> >> I am somewhat online again and I would like to get the upgrade thing >> running (again). Looking at the packages repo I only see 5_0 and 5_1. > > I haven't changed anything since your tests. Looking at git commit logs it > should be 5.1.4. > > Could you try to cleanup the packages repo before 5.2? Or even add some notes > (e.g. the wiki) how to deal with the repository so it could be used to update > from via a command line tool?
Mhhh... never dealt with a Wiki as I hate the technology. > As-Is is a bit confusing (yes I know it is mainly for testing now). > >> What is the actual content (5.1.x) of 5_1? >> Will there be a 5_2 (5.2.x) sometime soon? > > I just added 5.2-rc1 images to FRS at sourceforge. > > Hopefully end of month a final version will be available. > > It looks pretty stable, but I hope we can solve questions/issues I found, > that would be worth to be solved before the final version, although they are > no > showstoppers: > > - do we need modules.tgz anymore? It adds a few MB to images... I just needed modules.tgz to get the modules missing in the distros. > > - hwdetect seems to search every time at boot the sqfs file and copies the > modules to /lib/modules. I don't like this idea at all. Takes a long time to boot, and I prefer that after > first boot and saving modules, it won't be searching any longer at boot. How > do > we deal with additions in /etc/modules then? Currently (5.1.4) the file is > used > by hwdetect to find drivers in moduls.tgz, copies to /lib/modules, saved by > the > user to modules.lro and they are available at next boot. Much too complicated IMHO. I still believe in moddb. hwdetect is fine, but fine tuning should be possible. I might not even want to load certain drivers even if the hardware is there. > > - documentation of the boot process annd how to add modules etc should be > written for the wiki. > I can help to make it into the wiki, but some more insights about using sqfs > would be better given by Andrew or you. I am using the sqfs as I would use the modules tarball, just that it remains compressed and thus fits also on a rather small architecture. I somehow lost the old mail concerning upgrade and need to work from memory (or the code) but it is rather simple. In order to use upgrade we need a repository which holds the necessary information in architecture, version, e.t.c. It is not really much, but the actual package repository just does not provide it. I used branches in the package repository to represent versions, as this does not use any more space. I used files with information about latest and stable releases and I rearranged the packages in the respecive branches to bettter access a certain release. I also need kernel and initrd files present in the package repository for upgrade. If you have a current package repository you will see that it is rather simple. Upgrade just takes what is installed on a machine and tries its best to use upgrade to the requested level. When you build the packages there should be a squashfs built along, I don't know now how it is named. The most important thing about upgrade is stability in the naming convention, we don't have one :-( > > - will you be able to add your update stuff in time? It was added and running until Andrew decided to do a name change to the squashfs. Now I don't know. Right now I am fighting with my hardware which does not want to access the flash card reader from the virtual box environment, so I might not be able to do much testing. I used to think virtual machines were useful :-( cheers ET ------------------------------------------------------------------------------ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
