Installation Trouble - a heads-up for people with older systems.

[Arek]

Not sure if this is the right place to post this, but I think it's relevant here and maybe it'll help someone else having a similar problem.  I ran into a problem when installing Sparky GameOver a few minutes ago:  the sparky installer insists on copying the entire contents of the boot media to /tmp before mounting /target.  This is fine on systems with plenty of RAM (and maybe swap - think 8G+ total, tho, which is uncommon for people with less ram), but will cause the installer to hang and many other programs to stop working when /tmp (which is in ram and limited to 50% of your system's memory) fills up on systems with less memory.

I got around this by mounting my old /home to /mnt, creating /mnt/tmp, and bind-mounting /mnt/tmp to /tmp, which allows the install to go on unhindered (tho I haven't booted into it yet), but I figured I'd post it since I'm unlikely to be the only person affected.

Here's hoping this can be fixed for the next version of Sparky. :)

--Arek

Edit:  Rebooting didn't work, possibly because sparky didn't actually format my old partition.  Time to try again. :/

[pavroo]

Hi
Just quick replay: on "old" machines try to use the old installer:

Code Select Expand

sudo sparkylinux-installer
or

Code Select Expand

sudo sparkylinux-installer gui

[Arek]

Thanks for the reply...the new installer does work, if you set up a disk-backed /tmp first and make sure you pre-format whatever's gonna go on /target before running the installer.  Thanks for the info about the "old" installer, tho.  If I have to do it again, I'll try it.

--Arek

[MoroS]

I'm doing a x86 GameOver (3.4-i486) installation right now. The environment is strict: 512MB RAM, 8GB hard drive, no swap. Nothing has been copied to /tmp. Everything is directly copied to /target.

/tmp directory disk usage (in KB):

Code Select Expand

live@live:/tmp$ du -sk
468     .

/target mounted:

Code Select Expand

live@live:/tmp$ mount | grep /target
/dev/sda2 on /target type ext4 (rw,relatime,data=ordered)

Memory usage (in KB):
- total: 513052
- used: 507156 (cache: 212860)
- free: 5896 (ignoring the cached memory: 300192);

Installation proceeding without problems. Everything looks normal (except for the IO wait operations, which are at almost 100% CPU, but that's kind of normal in a rogue, low-resource environment like this - not much memory for file caching, so everything is practically going directly disk-to-disk). That however doesn't mean that the installer doesn't have a special condition for doing anything close to what @Arek said. There's no easy way around this: I'll have to dig into the installer code.

[tyerker]

I have been having an issue, using YUMI 2.0.0.5 and installing 3.4 Base, E18, LXDE, and Game Over
They all let me do the whole configuration, user setup, all that. Then they all hang on "Calculating File Indexes" (or it may be "Creating" I'm not 100% and I'm currently at work). I've let it sit for hours, and it doesn't make any progress.

Is this the kind of issue this post is referring to? The initial system in question had 4GB of RAM, but I also tried it on my desktop, which has 16GB of RAM, and got the same thing. I'll start my own topic if this is not the same issue, but I'm thinking it may be.

[MoroS]

I have been having an issue, using YUMI 2.0.0.5 and installing 3.4 Base, E18, LXDE, and Game Over
They all let me do the whole configuration, user setup, all that. Then they all hang on "Calculating File Indexes" (or it may be "Creating" I'm not 100% and I'm currently at work). I've let it sit for hours, and it doesn't make any progress.

Is this the kind of issue this post is referring to? The initial system in question had 4GB of RAM, but I also tried it on my desktop, which has 16GB of RAM, and got the same thing. I'll start my own topic if this is not the same issue, but I'm thinking it may be.

Judging by the hardware config you're using the x86_64 (AMD64) version of Sparky (I don't see any sense in using x86 with more than 3GB of RAM). Also Arek never mentioned which step was the installer on visually. I think it's a different issue.

Anyway both @Arek and @tyerker: as it's not obvious, I won't be ranting about it, but I would be easier if you two supplied some log files from the installation. As for now there isn't any utility that would do this automatically (there will be - to at the very least speed thing up a bit), so if you have the willpower to go over the installation again I would like to ask you to attach the logs:
- output of the "dmesg" command or the /var/log/dmesg file (although it's less detailed than the command output);
- the /var/log/syslog file;
- the /var/log/messages file;
- output of the "mount" command;
- output of the "ls -laR /tmp" command;

You can do that during the installation in using the following commands (I'll make a script for it and some more detailed stuff later):

Code Select Expand

$ echo "DMESG: " > ~/output.log
$ dmesg >> ~/output.log
$ echo "SYSLOG: " >> ~/output.log
$ cat /var/log/syslog >> ~/output.log
$ echo "MESSAGES: " >> ~/output.log
$ cat /var/log/messages >> ~/output.log
$ echo "MOUNTS: " >> ~/output.log
$ mount >> ~/output.log
$ echo "TMP contents: " >> ~/output.log
$ ls -laR /tmp >> ~/output.log
$ gzip ~/output.log
You can then post the output.log.gz file from the /home/live directory here.

[Arek]

I have been having an issue, using YUMI 2.0.0.5 and installing 3.4 Base, E18, LXDE, and Game Over
They all let me do the whole configuration, user setup, all that. Then they all hang on "Calculating File Indexes" (or it may be "Creating" I'm not 100% and I'm currently at work). I've let it sit for hours, and it doesn't make any progress.

Is this the kind of issue this post is referring to? The initial system in question had 4GB of RAM, but I also tried it on my desktop, which has 16GB of RAM, and got the same thing. I'll start my own topic if this is not the same issue, but I'm thinking it may be.

No, it's not.  My issue was with the installer copying files to /tmp before actually mounting /target.  No mention of File Indexes at all that I saw during the failed installs.

Also Arek never mentioned which step was the installer on visually.

It's not obvious in my post above, but it's there.  To reiterate: When my issue happens the installer says something like "Mounting /dev/sda5 on /target".

Anyway both @Arek and @tyerker: as it's not obvious, I won't be ranting about it, but I would be easier if you two supplied some log files from the installation. As for now there isn't any utility that would do this automatically (there will be - to at the very least speed thing up a bit), so if you have the willpower to go over the installation again[...snip...]

I've just gotten GameOver set up the way I want it, so I won't be reinstalling anytime soon.  That said, if you really need it I might try shrinking my / partition and re-testing the install later.

One thing I just thought of that's probably relevant:  My computer isn't EFI-based (too old), but I do use GPT for partitioning rather than MBR (I find GPT a LOT less cumbersome to work with than MBR, and it will make for a smooth transition to EFI once I get there).

--Arek

[pavroo]

Code Select Expand

"Mounting /dev/sda5 on /target"
That's the point of matter.
The installer mounts a partition you choosen to install the system to (sda5) in /target directory of live system.
Then the installer is copping all the files straight to /target which is /dev/sda5.

[Arek]

Not in the unsuccessful install, it wasn't.  At that point, /target was mounted iirc, but the files were getting copied to somewhere under /tmp for some reason.  It was only after I went to the trouble of setting up LVM in the install environment so that I could mount my /home partition and then create /home/tmp and mount --bind /home/tmp /tmp  that the installer (finally) worked.  Until I did that, the installer would just fill up /tmp and hang.

The step where it actually copies files says what files it's copying at any given time, btw, which is how I knew that the installer had started working after I backed /tmp with a disk.

--Arek