You are not logged in.

#1 2009-09-20 04:49:21

thetrivialstuff
Member
Registered: 2006-05-10
Posts: 191

aif bug reports

I'm just trying out the 2009.08 install CD and am not having much luck. I was a big fan of /arch/quickinst, so I'm trying out the new aif system. I've filed four bug reports for aif so far; if I run into any more issues I'll add those as well.

I hate to be a stick in the mud (and after my last few posts I'll probably get a reputation for being change-resistant tongue), but can we please have quickinst back until aif has been more thoroughly tested and ironed out?

Offline

#2 2009-09-20 14:13:48

Daenyth
Forum Fellow
From: Boston, MA
Registered: 2008-02-24
Posts: 1,244

Re: aif bug reports

The quickinst script was even less tested and less robust than AIF.. I don't know why you'd want it back.

Offline

#3 2009-09-20 16:30:44

thetrivialstuff
Member
Registered: 2006-05-10
Posts: 191

Re: aif bug reports

It worked really well for me. Actually, maybe not -- I think the way I used it involved killing it after package installation and then doing the rest manually. My installation procedure was:

- manually run cfdisk to partition
- manually create filesystems
- manually mount all filesystems under /mnt
- run quickinst ftp <mirror url> /mnt
- kill quickinst
- run grub, do setup to main hard drive myself from the grub shell (no annoying floppy drive detection, grub-install getting confused about RAID, trying to install to the wrong drive, etc.)
- reboot

The advantage to that over aif (in my opinion) was that at each of the three critical manual steps in the beginning, I could check and double-check to be damn sure I was partitioning the right drive, running mkfs in the right place with the right filesystem type, etc.

Using aif you sort of have to define the partitions twice (in the PARTITIONS and BLOCKDATA variables) and I already know that one day I'm going to forget to touch up the second part. Also, aif seems incapable of using existing partitioning, which makes it dangerous in my opinion (it has to nuke the drive every time).

I could be wrong about that, but as there's no documentation yet I don't know.

Also, the number of TODO's in the code kind of gives me the willies.

(Note: Yes, I'm completely discounting the interactive installation method. All I want is something that installs the core packages quickly into the new system; I prefer to sort out the rest later after the system boots. I don't really like navigating the menus; I always preferred quickinst to them, and now I guess I prefer aif -p automatic.)

Edit to remark: the quickinst script was more robust than aif simply by virtue of being a lot SIMPLER. aif is large and complex compared to quickinst -- I could read and understand the entire quickinst script in a few minutes (which is how I knew when to hit ctrl+c and proceed manually smile ); after browsing the code for aif I definitely can't say the same for it.

Last edited by thetrivialstuff (2009-09-20 16:33:29)

Offline

#4 2009-09-21 12:01:08

Dieter@be
Forum Fellow
From: Belgium
Registered: 2006-11-05
Posts: 2,000
Website

Re: aif bug reports

thetrivialstuff wrote:

The advantage to that over aif (in my opinion) was that at each of the three critical manual steps in the beginning, I could check and double-check to be damn sure I was partitioning the right drive, running mkfs in the right place with the right filesystem type, etc.

you can always create a config file for the automatic procedure that overrides the partitioning and filesystem creation function.
but the reason it is preferred to let aif handle it, is because if you use it's facilities, you get fstab, rc.conf, grub installation etc for free.

thetrivialstuff wrote:

Using aif you sort of have to define the partitions twice (in the PARTITIONS and BLOCKDATA variables) and I already know that one day I'm going to forget to touch up the second part. Also, aif seems incapable of using existing partitioning, which makes it dangerous in my opinion (it has to nuke the drive every time).

You do not have to "sort of" define partitions twice.  You define the partitions in $PARTITIONS, then you reference them using their names in $BLOCKDATA to define the filesytems you want on them.  This separation is needed because filesystems and blockdevices (partitions) are really different concepts, and doing it like this enables many possibilities while being still relatively easy to parse/work with.
aif is perfectly capable of using existing partitions and filesystems.  both in the automatic and interactive procedure.

thetrivialstuff wrote:

I could be wrong about that, but as there's no documentation yet I don't know.
Also, the number of TODO's in the code kind of gives me the willies.

You're right that the documentation is limited.  There is the official installation guide and the README, but they can be improved.  Especially the readme can use a lot of work.

thetrivialstuff wrote:

(Note: Yes, I'm completely discounting the interactive installation method. All I want is something that installs the core packages quickly into the new system; I prefer to sort out the rest later after the system boots. I don't really like navigating the menus; I always preferred quickinst to them, and now I guess I prefer aif -p automatic.)

Edit to remark: the quickinst script was more robust than aif simply by virtue of being a lot SIMPLER. aif is large and complex compared to quickinst -- I could read and understand the entire quickinst script in a few minutes (which is how I knew when to hit ctrl+c and proceed manually smile ); after browsing the code for aif I definitely can't say the same for it.

Well you can mimic the quickinst behavior (see first quote).  Personally I think doing it all automated is better.  It's maybe a bit more work to do the initial testing/configuring but it pays off imho.  And examples are provided that you can use as-is or with minimal editing (e.g. http://github.com/Dieterbe/aif/blob/mas … all-on-sda )
You're right that aif -p automatic is more complicated.  But it's also a lot more powerfull.  And if you look at the source code of the automatic procedure (http://github.com/Dieterbe/aif/blob/mas … /automatic) and start your journey there it won't be that hard too understand what's going on.  Either way I think your issues are mainly caused by lack of documentation.   There are two reasons for incomplete documentation and work-in-progress (the TODO's you mentioned) code:
1) aif is still a moving target. things are changing. especially the way partitions/filesystems are referenced is ugly for now.
2) lack of input/contributions from the community

However: don't let the amount of todo's and such fool you.  the old installer didn't have todo's but it's code was a mess and certainly had many bugs that were fixed in aif.  I think it's safe to say aif is less buggy then the old installer.

I hope this answer is meaningfull to you. I certainly don't mean to critisize/avoid your remarks/comments.  It's discussions like these that lead to better insights for all of us, and hopefully improvements in the code and documentation.

Last edited by Dieter@be (2009-09-21 12:07:25)


< Daenyth> and he works prolifically
4 8 15 16 23 42

Offline

Board footer

Powered by FluxBB