06.06.2015 10:39, Erich Titl пишет: > 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. > /etc/modules.conf - just add `blacklist modulename` >> - 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
------------------------------------------------------------------------------ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel