Hello - I just finished with my first two gentoo installations (well, one, but I started over about half way through. My first time through, when I installed portage, I used the suggested options to tar. I have untarred many files, but this seemed quite slow. I eventually stopped waiting and went to my other PC to go read documents, and was able to get a lot of reading done. I wasn't sure exactly why it was so slow. When I realized that I didn't want to do a stage 2 install, and started over with stage 3, I had a hunch about untarring the portage - I removed the "v" option, and it was done after a brief delay, as I would expect for a file of its size (only 17M, bzipped). During the other parts of the install, when large amounts of text were displayed, I paid more careful attention, and it does appear that there is a top speed for scrolling text. In fact, it reminded me of operating a server over a 9600 baud serial console, although slightly faster. The fb console display speed is another matter, for another bug, but it is still a reality that makes tar with -v undesirable. The speed issue itself may or may not be important to anyone - if it's just a bunch of scrolling text, why should it be able to move any faster than you can read it anyway? By the same token, I would expect compilation to have much slower moving text, i.e. teh text display would not become a limiting factor, but perhaps it would be a good idea to suggest that users pipe the standard output (if not standard error) to a file instead of displaying it all on screen. Reproducible: Always Steps to Reproduce: 1. Follow the liveCD install instructions in the handbook 2. install on an x86 machine, such that one has the cute purple background behind the shell text; this may be hardware dependant but I do believe my situation is not unique. 3. continue until the "installing portage" section 4. start_time=`date` 5. tar jxvf portage....tar.bz2 6. Watch the text scroll by; it is quick but perhaps not quick enough 7. compare $start_time with current time. 8. date; tar jxf portage....tar.bz2; date; 9. compare the time difference Actual Results: I just tried running this test again, and I let it go for 9 minutes, and it had only gotten to portage/metadata/cache, then interrupted it. I repeated without the v, and it completed in one minute and 25 seconds. Expected Results: The doc should indicate that using "v" option with tar, for the ports tree, while on a system console is a bad idea, because many system consoles are very slow. emerge isn't installed yet when I do this part of the installation, but if you like, I can get this for you after the install is complete
This is a tip that's hugely depending on the performance of your environment as well. A quick test on a slow system (P-100) revealed no remarkable improvement on execution time. Either way, you can use screen if you want to detach the output, or pipe it to /dev/null, ... We rather not document every single possible trick that can be done during the installation.
Hi, You might want to make a note though, some architectures (in particular, MIPS) use Busybox for their images. The 'tar' in busybox does not support the -v option. So it may not necessarily be a matter of speed, but rather whether it is supported or not. I have a patch against my tree here that adds a note reguarding Busybox-based images as well as taking out the -v.
Created attachment 50497 [details] Patch: s/tar -xvjpf/tar -xjpf/g and add a couple of notes on the topic.
Created attachment 50501 [details, diff] s/thatit/that it/ -- also I've discovered the hard way that Bugzilla doesn't like gzipped patches.
I thought I'd point out briefly that using a full-blown bootsplash will introduce a minor slowdown on text drawing. This really isn't noticable except on things like an initial emerge --sync on a newly unpacked stageball, and I imagine on some lower-end systems, x86 included, this can increase the time of an initial emerge --sync a wee bit. Probably the bigger concern is the same initial emerge --sync on a 9600 serial console -- which I have done before on mips installs. I will state for a fact that *really* bogs things down. Therefore, it is perhaps best to give some consideration for a mention of these types of effects in a <note> tag, probably in a generic statement, or informing the user how to pipe output to /dev/null properly.
