how to get from tinycore to microcore-64?

[gojirasan]

I just finished installing tinycore from a multicore CD with the install guide here: http://distro.ibiblio.org/tinycorelinux/install.html. I added the boot options: local=sda7, home=sda7, opt=sda7, and norestore during the CD install. I have no idea where the boot loader config file is, and I have looked everywhere I can think of. I seem to be running grub4dos as a boot loader. I also have a few versions of windows installed in their own partitions. My ext3 Linux partition is logical.

I downloaded bzimage64 and microcore64.gz, but I don't know where to put them. I don't know where the "installed" 32 bit versions are either. Even if I could find my bootloader config file (menu.lst?), I'm not sure exactly what to change in it. Do I just substitute "microcore64.gz" for "tinycore.gz" and "bzimage64" for "bzimage" and that's all? Since xvesa is not 64 bit compatible do I have to make some config file changes to not start xvesa? Maybe even uninstall it? Would it be easier just to try to install microcore-32 first and then change to microcore-64 from there?

[Guy]

If you are using grub4dos (there are 2 installers, the other uses extlinux/syslinux) menu.lst should be in sda1 (if not, look in the Windows partition, and other primary partitions). That is /mnt/sda1 (not /mnt/sda1/boot or any other directory).

[Guy]

I have never installed the 64 bit version, but here is some info on installing microcore.

http://wiki.tinycorelinux.net/wiki:install_microcore

[gojirasan]

Well, menu.lst was in /mnt/sda1, which is an ntfs windows xp partition. The problem was that it wasn't mounted. I had looked there before and just found an empty directory which confused my linux noob brain. After I mounted sda1 all was well. In the process of searching my Linux partition for menu.lst I also stumbled upon my bzImage and tinycore.gz files. They are both in the /mnt/sda7/tce/boot/ directory. So now I know where the important files go in my system in a default, follow-the-tutorial, tinycore install. I guess it's time to start thinking about starting over with a standard microcore install and then try to do the 'ol swaparoo with the core files.

[gojirasan]

Well it seems to have worked, with some caveats. I couldn't edit menu.lst. It is located on sda1 and sda1 is an ntfs filesystem, which seems to be mounted as read only by tinycore. I tried to mount it myself with "mount -t ntfs-3g /dev/sda1 /mnt/sda1, but it gave me a "no such device" error. fdisk -l clearly lists the drive as /dev/sda1. Not sure what to make of that. Since I couldn't modify the menu.lst file I had to rename bzImage64 to bzImage so that the references in menu.lst were correct. That seems to have worked.

So the (undocumented) procedure seems to be something like this:
1. install from multicore CD with tcg option and the local=sdxy, home=sdxy, opt=sdxy (in my case sda7) options (for a persistent install).
2. mount whatever partition contains bzImage64 and microcore64.gz.
3. run the grub4dos install procedure as per the install tutorial except choose the "microcore" option and select microcore64.gz from a mounted partition where it is located.
4. because you did a persistent install you should actually have a tce/boot directory. Copy bzImage64 there and rename it to "bzImage".
5. reboot, remove the CD, and bask in the glory of 64 bits!

I first tried it without the persistence boot code options on the iniitial CD install and there was nowhere to copy the bzImage64 file to. There was no tce/boot directory. Now I just need to get x and a window manager running. I will ask for help with that in the microcore section. Many thanks to guy for his assistance.

[maro]

I typically use sudo ntfs-3g /dev/sda1 /mnt/sda1 and that "just works" (tm).

Since the Core only contains the read-only NTFS kernel module and if the filesystem in question is the one with the 'tce' directory, a 'umount' / 'mount' sequence might not be possible. IIRC the best solution is therefore to remaster the initrd to include the 'ntfs-3g' extension (to get out of the "catch-22" situation).

Looking at the boot codes of "local=sdxy home=sdxy opt=sdxy" I can only hope you understand what you are doing. Quick question: Have you updated '/opt/.filetool.lst' (or '/opt/.xfiletool.lst') to suit your situation? If not, I highly recommend you search through the wiki and this forum here to find the out what you are getting yourself into. In most cases these boot codes have lead for new users to "tears" (i.e. they did not get what they thought they would). Many new users don't realize what these boot code do, so read up on it.

Unless you really want it for a specific reason to begin with most users in your situation (i.e. MC installed on a fixed hard disk) are fine without any of those. At most you could use 'tce=sda7' to guide the detection mechanism for the 'tce' directory, but if you have only one 'tce' directory in the root of all your attached storage devices even that would not be required.

Finally, whilst renaming of kernel and initrd files might work, it is IMHO not necessary. One could either edit the boot loader config file from a different OS (e.g. Windows) or (if the remastered initrd is not yet ready) boot for a one-off session from the CD with boot codes "base norestore" (to avoid the auto-detection of the 'tce' directory in the NTFS target file system, which would otherwise mount said file system), install 'NTFS-3g.tcz', mount the target file system, and make the intended adjustments.

[Guy]

I suggest,

Don't use local=sdxy, home=sdxy, opt=sdxy

Use tce=sdxy home=sdxy opt=sdxy


You can just remove menu.lst from the ntfs partition, and put it in an ext2, ext3 or ext4 (or fat32) partition. You can then edit it easily. I believe grub4dos searches for it, so if you move it to another partition, grub4dos should still work. If you ever delete or reinstall Windows, you also need the file grldr. If I am wrong, let me know.


A bit more information on something mentioned in the previous post.

All files and directories listed in /opt/.filetool.lst will be backed up. Since you have persistent home and opt, you don't need to backup anything in the home or opt directories (backup slows down start up and shut down time, +).

The simplest way to overcome this is to include the "norestore" boot option in menu.lst. So you will then have "tce=sdxy home=sdxy opt=sdxy norestore"

If you want to backup something in the future, remove the norestore boot option, remove all references to the home and opt directories from /opt/.filetool.lst, and list files and directories you want backed up.

I don't use backup. There are other ways to save things, such as making extensions for settings. It is explained in the wiki.

Backup is designed to minimize writing to a usb drive, and prolong its life. Everything is saved when you turn the computer off. It is not necessary to minimize writing to a hard drive.

[Guy]

Robert

I suggest modifying the grub4dos installer, so grub4dos is installed in the tinycore partition, to avoid this issue.

[gojirasan]

I typically use sudo ntfs-3g /dev/sda1 /mnt/sda1 and that "just works" (tm).

I'll have to try that. Although I think moving the boot loader to my ext3 partition would be a better long term solution if I can figure out how to do it. Grub4dos has already messed up my windows boot anyway by overwriting the MBR. I already had a boot manager there (boot-us). So I was already looking for an alternative solution.

Looking at the boot codes of "local=sdxy home=sdxy opt=sdxy" I can only hope you understand what you are doing.

Actually I don't. Or rather I only have the most basic, fuzzy understanding. I don't mean to be critical of tinycore, but the documentation isn't exactly extensive or detailed. Of course I read http://distro.ibiblio.org/tinycorelinux/concepts.html or wouldn't have even known about the local= boot option. http://wiki.tinycorelinux.net/wiki:persistence_for_dummies goes on at length about tce= and home= and opt= but doesn't say a thing about local= or whether it may conflict with the other options. I did a forum search for local= and found some interesting tidbits here and there, but nothing that really makes the whole system clear to me. Some of the forum posts did seem to imply that using all of the persistence options may not be the best idea however.

Frankly, as a Linux noob, I have enough trouble understanding the basic directory tree without having to worry about stuff magically disappearing on reboot. I like the idea of running as much as possible in RAM. I do have 8 gigs of it. But I'd also like a system that boots as fast as possible and that is as easy to understand as possible. So I wanted to go for as much data persistence as possible. That is, I wanted to try to make tinycore as much like a standard Linux install as possible. I am using tinycore because I love the idea of an operating system that is as small as possible in terms of size on the hard drive. Tinycore makes Arch Linux seem extremely bloated. I am not so interested in the anti 'data rot' aspects of it. I like the malware-proof-ness of the idea, but my understanding is that malware is more or less nonexistent (in the wild) for Linux at the present time, which, incidentally, is why I have decided to start multibooting with Linux in the first place.

Quick question: Have you updated '/opt/.filetool.lst' (or '/opt/.xfiletool.lst') to suit your situation?

I was hoping that I didn't have to mess with filetool.lst due to using the local= option. Should I get rid of opt=, home=, and even tce= in that case?

If not, I highly recommend you search through the wiki and this forum here to find the out what you are getting yourself into. In most cases these boot codes have lead for new users to "tears" (i.e. they did not get what they thought they would). Many new users don't realize what these boot code do, so read up on it.

Thanks for the warning. I'll try to do some more research on the topic. Or maybe I'll just do some experimenting. My first guess would be to get rid of all the persistence related boot codes except for "local=sda7".

Unless you really want it for a specific reason to begin with most users in your situation (i.e. MC installed on a fixed hard disk) are fine without any of those. At most you could use 'tce=sda7' to guide the detection mechanism for the 'tce' directory, but if you have only one 'tce' directory in the root of all your attached storage devices even that would not be required.

Well my specific reasons would be that I don't fully understand what is going on with the application backup/restore features of tinycore and thus didn't trust it at least until I had done an initial install that is as close as possible to a standard Linux install that I understand better. I also get the impression that the default install trades boot/shutdown time for runtime performance (and memory footprint) and I'm not sure if that tradeoff is acceptable to me. I guess one way to find out would be to try it and time the boots to see what the difference is. I assume the more applications I have installed the greater the difference will be.

Finally, whilst renaming of kernel and initrd files might work, it is IMHO not necessary. One could either edit the boot loader config file from a different OS (e.g. Windows) or (if the remastered initrd is not yet ready) boot for a one-off session from the CD with boot codes "base norestore" (to avoid the auto-detection of the 'tce' directory in the NTFS target file system, which would otherwise mount said file system), install 'NTFS-3g.tcz', mount the target file system, and make the intended adjustments.

Editing menu.lst from Windows seems so obvious now that you mention it. I don't know why I didn't think of it.

[gojirasan]

I suggest,

Don't use local=sdxy, home=sdxy, opt=sdxy

Use tce=sdxy home=sdxy opt=sdxy

Any particular reason that you suggest this? I am beginning to get the idea that "tce=sda7 home=sda7 opt=sda7" is redundant with "local=sda7". So it sounds like I should choose between the 2 sets of options. But the "hybrid install" described in the core concepts page sounded like the most appropriate for me. What I don't understand is how local= data persistence is different from tce/home/opt = data persistence. Is it just that the applications are stored in different directories? I do get that not all tinycore applications are compatible with the PPI local= method. So that could be seen as a disadvantage. That reason alone would be enough reason for me to abandon it. But will the tce/home/opt = method keep all of my data stored between boots without the additional overhead of copying from RAM to disk on shutdown and from disk to RAM on boot?

You can just remove menu.lst from the ntfs partition, and put it in an ext2, ext3 or ext4 (or fat32) partition. You can then edit it easily. I believe grub4dos searches for it, so if you move it to another partition, grub4dos should still work. If you ever delete or reinstall Windows, you also need the file grldr. If I am wrong, let me know.

I would like to move my bootloader to my linux partition, but I am thinking that I would like to switch to Grub or even Grub2 while I'm at it, which I am not really sure how to do. More experimentation I guess. In order for the typical OS independent bootloaders to work (boot-us, bootit-ng/bm, osl2000) the linux bootloader needs to be loaded onto a partition and not into the mbr itself. I made that mistake on my first install of Arch Linux and had to reinstall Grub to sda1 instead of just sda. One advantage of a Linux installation compared to Windows is that it doesn't inherently clobber your boot sector. Unfortunately that is exactly what the default grub4dos installation does.

A bit more information on something mentioned in the previous post.

All files and directories listed in /opt/.filetool.lst will be backed up. Since you have persistent home and opt, you don't need to backup anything in the home or opt directories (backup slows down start up and shut down time, +).

The simplest way to overcome this is to include the "norestore" boot option in menu.lst. So you will then have "tce=sdxy home=sdxy opt=sdxy norestore"

If you want to backup something in the future, remove the norestore boot option, remove all references to the home and opt directories from /opt/.filetool.lst, and list files and directories you want backed up.

I don't use backup. There are other ways to save things, such as making extensions for settings. It is explained in the wiki.

Backup is designed to minimize writing to a usb drive, and prolong its life. Everything is saved when you turn the computer off. It is not necessary to minimize writing to a hard drive.

When you use the term "backup" here are you using it in the usual sense of creating redundant data elsewhere in case something unexpected happens? Or are you using it to describe the process of transferring data from volatile storage to non-volatile storage so that the data persists through reboots?

[Guy]

If you use tce=sdxy, apps are downloaded as read-only tcz extensions. So you get the the anti 'data rot' benefit of apps.

If you use local=sdxy, apps are extracted to a filesystem. So you loose the anti 'data rot' benefit of apps. Also some apps do not work with local=sdxy.

If you don't include either tce=sdxy or local=sdxy bootcodes, the tce method will be used by default, and tinycore will search for the tce directory. This may add a small amount of time when booting.


I think you can have read-only access to the ntfs partition from tinycore. You could copy and paste it to an ext2, ext3 or ext4 partition. Then run Windows, and rename it to oldmenu.lst (in case you want to access it again).

[maro]

Very simply: trust me (and guy) when we recommend to not use 'local=...', i.e. the hybrid mode of operation. I could be wrong, but I guess nowadays fairly few users are going down that route. IMHO it is just there for more historical reasons and does not get much ongoing "love". One usage case might be on low RAM systems, but in your case with 8GB you are certainly not falling in this category. I can appreciate that a hybrid mode might sound closer to a traditional install (AKA 'scatter mode') and therefore might appeal, but (again) trust us at least until you better understand how TC (or MC) works.

To understand the other boot codes it's probably a good idea to use some virtual machines (e.g QEMU, or VirtualBox) to "play" around and get to experience the difference between the (default) backup and persistent 'opt' / 'home'. In my view it's much faster to grasp a concept on a smaller scale and after one better understands the purpose of each boot code then deploy it on the "real" system.

So instead of aiming to have everthing working at once on the host I'd go for several smaller (e.g. 50MB) virtual disks in which I'd setup different scenarios (e.g. one using standard backup and another one with persistent 'opt' / 'home'). This way you can run them all at the same time and compare the behaviour. A reboot takes less then 30 seconds but your host system is still up and provides you with the opportunity to have a working browser etc. Obviosly if you want to install a decent number of applications in those VMs you need larger (virtual) disks. But for "proof of concept" type scenarios 50 MB should be enough. I pretty much never try anything first on "real" hardware, as using VMs give me IMHO so much more options (to not screw up a host would be probably the most important aspect of it).

After a few hours (or days) you should be able to make an informed decission of which strategy to follow, and that with far fewer "tears".


EDIT: I forgot to add earlier on, with the 'ntfs-3g.tcz' extension installed the other option (due to a recently added little tweak) that "just works" is to use
    sudo mount /mnt/sda1

[Guy]

Backup is used in a different way to other operating systems.

If you use backup, files are saved to the hard drive when you run backup, which normally occurs when you turn off the computer.

If you don't have home=sdxy opt=sdxy, anything you save will only be saved in ram, so it can be saved to the hard drive when you turn off the computer.

If you use home=sdxy opt=sdxy, anything you save in the home or opt directories will be saved to the hard drive when you save it.

Backup is designed to minimize writing to a usb drive, and prolong its life. Everything is saved when you turn the computer off. It is not necessary to minimize writing to a hard drive.

I suggest using "tce=sdxy home=sdxy opt=sdxy norestore"

However, in the future you may, for example, install a printer. The printer configuration files are saved in /etc. Files in /etc will not automatically be saved. I recommend making a new extension to save printer configuration. Another option is to use backup, and list the appropriate directories in /opt/.filetool.lst. http://wiki.tinycorelinux.net/wiki:printer_setup_using_cups

[Guy]

Myself and maro are covering some of the same info, but here is some more.

You can have read-write access to the ntfs partition. To do this:

1. If you already have windows installed, and install tinycore with the grub4dos bootloader from the multicore cd, it should automatically install ntfs-3g.gz and give you read-write access to ntfs.

2. Another option is to install the 'ntfs-3g.tcz' extension using the App Browser.

Click on the Mount Tool and mount the ntfs partition. If you are running microcore without the wbar, you can mount it using commands, as explained by maro.


I believe ntfs-3g.gz gives you read-only access, and ntfs-3g.tcz gives you read-write access. Someone correct me if I am wrong.


Edit - Correction:

I think both ntfs-3g.gz and ntfs-3g.tcz give read-write access. (It was earlier versions where you got read-only access.)

[maro]

I believe ntfs-3g.gz gives you read-only access, and ntfs-3g.tcz gives you read-write access. Someone correct me if I am wrong.

I don't think so: AFAIK they both contain '/usr/local/bin/ntfs-3g' (and "friends") one needs for RW access. If one only needs RO access this could be provided by the 'ntfs.ko.gz' kernel module which is now included in the (standard) initrd of MC (and TC).

I'd therefore say that the difference is what type of archive is used: 'ntfs-3g.gz' is a (gzip-ed) cpio-archive, which could be used like an initrd file, whilst 'ntfs-3g.tcz' is a standard TC extension (i.e. a squashFS-archive). But they contain the same set of files.

I'd forgotten about 'ntfs-3g.gz' (must be a senior moment or something like that), as this would be an alternative way to include the 'ntfs-3g' at boot time without having to remaster: if the boot loader (like one of the SYSLINUX "family" or GRUB4DOS) supports the use of multiple initrd files then 'ntfs-3g.gz' could be specified in the boot loader configuration together with the Core initrd (e.g. 'microcore.gz'). That way the support for the RW access is present early enough in the boot process, which would therefore allow for the 'tce' directory to be placed on a NTFS files system (and avoid the "catch-22" I mentioned yesterday).