Extensions not loading on boot in MC 4.0.2 (using ISO in VMware)

[nim108]

So I am testing some methods of extension loading in TC and MC using VMware (I just point VMware to the ISO file to test it) and am running into interesting results. When I download the TC 4.0.2 ISO, add a /tce/optional directory with my extensions (with onboot.lst and copy2fs.flg in /tce), these extensions load up just fine in TC, as expected. With this same exact setup booting the MC 4.0.2 ISO, the extensions fail to load ... it just says OK but seems to skip them all. For now, I am stuck running TC in text mode, but would much prefer MC working as it should, since I have no need for X tools. Am I missing something here?

For the record, I've tried renaming /tce to /cde with no luck, and I've also tried booting MC with boot options such as waitusb or embed, but still no go. It's just interesting that the same exact folder structure I have loads the extensions in TC, but fails to in MC. Is MC looking for another folder name for extensions?

[Rich]

Hi nim108
When you say MC are you referring to Microcore or Multicore?

[nim108]

Hi nim108
When you say MC are you referring to Microcore or Multicore?

Err sorry Rich, I forgot there was Multicore too ... I'm referring to Microcore.

On a side note, I did get the ISO to finally work, but it was with /cde and /cde/optional directories and booting up with the cde boot option. Is this a bug or was Microcore made to boot this way? How come TC boots with the normal /tce and /tce/optional directories with nothing specified as boot parameters? I'm happy it works now, but I want to know why both distributions (TC and Microcore) seemingly work in different ways.

[Rich]

Hi nim108
Not being a Microcore user myself I was unaware that it might not use /tce for extensions.
Maybe it was done so that when it searches for the extension directory it would not try to load
extensions from a Tinycore install which would require X to be running?

[curaga]

There is no difference between TC and MC in this regard. I suspect a timing issue or something similar.

[nim108]

There is no difference between TC and MC in this regard. I suspect a timing issue or something similar.

curaga, that's what I thought as I did not see any difference in the init scripts. Do you have any other suggestions for me to try? I'd like to get Microcore working (in terms of loading extensions on boot) the way Tinycore is.

[curaga]

Now that I checked, as of 4.0.1 the cde dir & bootcode should be used, and a tce dir on the cd shouldn't work. That it did would be a bug, though not one we need to absolutely chase down.

[roberts]

Your subject title is very mis-leading! Many of us use microcore and extensions load as expected.

Your particular situation is directly running from an iso, not a physical cdrom, but an emulated one in vmware.

Regardless an iso is read-only and therefore having a tce directory recognized therein would prevent normal use.
That is why a cde directory is used. That way extensions, albeit, "frozen" will load upon boot while allowing also allowing a normal writable tce directory.

[nim108]

Your subject title is very mis-leading! Many of us use microcore and extensions load as expected.

Your particular situation is directly running from an iso, not a physical cdrom, but an emulated one in vmware.

Regardless an iso is read-only and therefore having a tce directory recognized therein would prevent normal use.
That is why a cde directory is used. That way extensions, albeit, "frozen" will load upon boot while allowing also allowing a normal writable tce directory.

Thanks robert! I did not intend to mislead anyone, I apologize for the vague title. This makes sense though. It is quite odd though, that TC will only work with /tce and MC will only work with /cde with cde as a bootcode (again, this may just be due to the weird nature of loading the ISO up in VMware and odd timing that curaga was referring to).

I am assuming that this strange behavior is why MC nor TC cannot restore the mydata.tgz file I have in /tce (or in /cde, as I've tested both)? It never catches it. Any ideas for that? Obviously this situation is not ideal, I agree, but this is the best way I've found to test it before I am ready to pxe boot these images.

Edited my title to make it more transparent in case anyone else was having the same issue.

[curaga]

Right, the cde code does not check for backups currently. You may be able to force it via restore=sr0 and having mydata.tgz in the root of the iso.

Having a read-only backup device isn't an end-user-friendly situation either though.

[Rich]

Hi nim108
Since you are virtualizing this anyway, why don't you just put Microcore on a small virtual hard drive?
Then your /tce directory will be writable.

[ixbrian]

Your subject title is very mis-leading! Many of us use microcore and extensions load as expected.

Your particular situation is directly running from an iso, not a physical cdrom, but an emulated one in vmware.

Regardless an iso is read-only and therefore having a tce directory recognized therein would prevent normal use.
That is why a cde directory is used. That way extensions, albeit, "frozen" will load upon boot while allowing also allowing a normal writable tce directory.

Thanks robert! I did not intend to mislead anyone, I apologize for the vague title. This makes sense though. It is quite odd though, that TC will only work with /tce and MC will only work with /cde with cde as a bootcode (again, this may just be due to the weird nature of loading the ISO up in VMware and odd timing that curaga was referring to).

I am assuming that this strange behavior is why MC nor TC cannot restore the mydata.tgz file I have in /tce (or in /cde, as I've tested both)? It never catches it. Any ideas for that? Obviously this situation is not ideal, I agree, but this is the best way I've found to test it before I am ready to pxe boot these images.

Edited my title to make it more transparent in case anyone else was having the same issue.

In case it helps, you can use ezremaster (available in the repository or in MultiCore) to easily create a remaster that will have your mydata.tgz file integrated directly in to the tinycore.gz (initrd).   You can use this custom tinycore.gz for netbooting as well.   Depending on how many extensions you need you can also use ezremaster to integrate extensions into the initrd (the more extensions added there, the more memory needed.)

[roberts]

Both tce directory and mydata.tgz need to be located on a writable storgage device and not in a read-only iso. Having either one or both will cause much grief as normal expected operations will fail. As they should.

Either use Rich's suggestion of an emulated disk, or ixbrian's suggestion of using ezremaster and place your needed extensions into initrd as well as any needed initial data files, (the mydata.tgz) that you referenced.

[nim108]

Thanks all, will consider the suggestions posted, appreciate the prompt responses. I love how you can keep the main initrd (tinycore.gz or microcore.gz) untouched, and chainload the extensions and initial data files as a separate initrd ... genius architectural design. I will certainly make use of this when it's time to pxe boot. It makes sense that testing ISOs in VMware is not an ideal situation so instead, I will use an emulated disk in the future as Rich suggested.