grub4dos.gz

[newbody]

Thanks

may I ask

What I need is to make the ntfs drive read write
now it is still set as read only.
Can I not do that manually in Terminal without running the  tc-grub4dos?

I mean in case that program mess up some mbr or something. Which it wanted to do and what Lee confirmed it did so I was lucky that it failed to install on my computer. I did try to ask this before though!

edited subject title to reflect new name

[stevesr0]

I have grub4dos on one computer booting between two versions of Puppy and WinXP.  I recall that it was fairly simple to manually add an additional choice in menu.lst (?), following the directions at the lin'n'win website (http://www.icpug.org.uk/national/linnwin/step00-linnwin.htm).

Can the same manual procedure be used to add the new tiny core linux option to the boot menu?

Steve

[Guy]

Yes, if you have grub4dos already, you can add Tiny Core commands to menu.lst.

[newbody]

Yes I did that but the HDD is still read only and I need to make it read write. How does one do that?

you can add Tiny Core commands to menu.lst

Does that mean I can set the sda3 as read write in that code?

[jur]

Note: Files that have changed and are likely in your backup:
.profile

Shouldn't .xsession also be mentioned? There are perhaps many who use persistent HOME, so no new .profile and .xsession gets generated in these cases either

[Rich]

Hi newbody
You need to install  ntfs-3g.tcz 

[Lee]

You need to install  ntfs-3g.tcz

I did a frugal install on a WinXP system (booting from ntfs on /dev/sda1) according to the instructions at

http://www.computing.net/answers/linux/remounting-fs-as-readwrite/27942.html

because the wiki article mentioned in the HOWTO in the grub4dos extension (and in the tc wiki) doesn't display for me (blank page - can others see it?).

The install was -ridiculously- easy.  I like it.  

I put tce/optional/ntfs-3g.tcz in the root of the NTFS boot partition and referenced it in tce/onboot.lst

TC boots and loads the extension.  As expected, sda1 is mounted read-only because it had to be mounted before the extension was loaded.

Code: [Select]

sudo rebuildfstab
yields an entry in /etc/fstab like:

/dev/sda1   /mnt/sda1   ntfs-3g  noauto,users,exec,   0 0 # Added by TC

But...

Code: [Select]

sudo mount -n -o remount,rw /mnt/sda1
doesn't work - no errors, but sda1 is still mounted ntfs instead of ntfs-3g and is still ro.

I suspect that the remount function doesn't do a complete umount but just resets some flags.  I'm sure if I could just umount the fs and remount is again but I can't.  It says "...device or resource busy".

... OK. tested that...

If I boot base norestore, manually mount sda1, copy ntfs-3g* to /tmp/tce/optional/, manually umount sda1, tce-load -i ntfs-3g, I can get r/w access to sda1 - but now none of my shtuff is loaded.

So, I can have all my extensions and data conveniently loaded and have r/o access to the storage - or- I can get r/w storage but I have to manually restore my backup and load my extensions.

Is there an easy work around where I can have both?  W/O remastering or using other storage?  ( I actually have fat and ext2 as well as ntfs filesystems on this drive, but supposing I didn't... )

Other notes:

During all this testing, I sometimes forgot to use sudo with umount and it worked anyway (as user tc).

I can't seem to force a read-only mount using ntfs-3g.

[Lee]

Hmmm... no, I didn't read ntfs4tinycore.sh yet.  Oops.   

[roberts]

I see no one has done a fresh installation of Tiny Core on a pristine XP system,
What is requested is a simple installation for newbies but what is attempted is not!

Again, all the questions are on how to back into a installation with an existing grub4dos
remix or remaster.

The automated script is not trying to support complex exiting grub4dos with Puppy or remixes.

That will require manual editing and copying of files. I have no interest to try to setup every
conceivable combination of Linux distributions trying to maintain how they, other distributions,
are setup.

The automated script installs a ntfs-3g.gz into the tce/boot directory alongside bzImage and tinycore.gz and creates a proper boot menu item with initrd loading both tinycore.gz and ntfs-3g.gz as well as specifying the tce directory.  

Such achieves the desired result.

Essentially what is missing in those who are backing into an existing grub4dos setup is:

1. Use Load Starter Pack to navigate to and load  tc-grub4dos.gz
2. If Windows drive is mounted. Use mount tool to unmount it.
3. Use Load Starter Pack to navigate to and load /tmp/ntfs-3g.gz
4. Use mount tool to mount Windows drive.
5. copy /tmp/ntfs-3g.gz to /tce/boot directory along with tinycore.gz and bzImage on Windows drive.
6, edit grub4dos menu.lst with the entry for tinycore to be as follows.

title Tiny Core Linux
find --set-root /tce/boot/bzImage
kernel /tce/boot/bzImage quiet tce=hda1
initrd /tce/boot/tinycore.gz /tce/boot/ntfs-3g.gz

Reboot your computer.

You must specify your tce directory via the tce= boot option, as auto-scanning ntfs partitions is not
supported in the base.

Do not also install the ntfs-3g.tcz extension its function is replaced by ntfs-3g.gz

[Guy]

Things are getting better all of the time.

Installing Tiny Core on a ntfs partition with Windows works.

and you can load the starter packs from ntfs.

[Guy]

There is a minor thing which may confuse users

When installation starts, you see

Applying grub4dos using bootlace.com .......

There is a pause

Then you see

success

Then there is another pause

Installation is not complete, but some users may think it is when they see success.

They may turn off the computer (I know they would need to be quick). On low performance computers it may take longer.

I suggest, "success" be changed to something else, for example, "continuing installation"

[Guy]

There is a bug which occurs sometimes (not always) when you use Run Application.

You may start typing something, for example, tc-install or tc-grub4dos. It is sometimes automatically completed with something else, such as tc-terminal-server, or watch.

[Guy]

A very minor thing. I don't know if it is realistic. Not important if you don't want to change it.

If possible, it would be nicer if the line spacing between comments during installation was more consistent.

I know there are various options, which complicates it.

[maro]

@Robert: I did a test installation of TC 3.7rc2 in a Win2k VM (with NTFS) using the 'tc-grub4dos.gz' starter-pack. This seemed to have worked just fine, as I was able to boot both OS (i.e. Win2k as well as TC) via the new (changed) boot loader.

Mind you without reading the instructions in your OP (in particular the need for the 'tce=...' boot code) I could have made a mistake. So maybe the 'tce=...' boot code should be presented in the respective GUI screen as a default value (which should still leave the option for the user to remove it and pay the price for it). Therefore maybe a bit of information (in the GUI) that (and why ?) this boot code might be required would be useful to users.

I've got to admit that I've done zero further testing and the VM is now "lost" again. To do this quick test I used a basic VM I already had for VirtualPC 2007 and as I used the "Undu Disks" option the changes were not written back to the VHD.


@Lee: I also wanted to try to replicate the problem you've reported in reply #6. I therefore removed the '/mnt/hda1/tce/boot/ntfs-3g.gz' part from the 'menu.lst' boot stanza and (initially) ended up after a reboot with a read-only NTFS. I emulated your situation via sudo loadpack.sh /mnt/hda1/tce/boot/ntfs-3g.gz (which seemed to somehow trigger a rebuild of '/etc/fstab', so I did not have to do one explicitly).

I can confirm that a sudo mount -o remount,rw /dev/hda1 did not work (but also did not fail, as $?==0). Nevertheless umount /mnt/hda1 && sudo mount /mnt/hda1 worked instead and lead to a writable NTFS.

BTW, I've noticed that on "real HW" umount -l /mnt/sda1 works for me where '/dev/sda' is a USB stick I've just used to boot TC from. Without the '-l' (i.e. "lazy umount") option I've also only had "...: Device or resource busy" refusals.



EDIT: Adjusted the reply number as this thread had been split off another one.

[Lee]

I see no one has done a fresh installation of Tiny Core on a pristine XP system

Wellll... this system lost its "pristine" virginity long before TC came along.  

You're right and I apologize for being somewhat selfish there.

So...
This is a WinXP Pro 32 bit system with 1 physical HD with several partitions.  For now, we'll pretend there's only one and that's sda1, formatted ntfs.

From the rc2 changelog (above):

Typical instructions for tc-grub4dos.gz via Windows from a base no network Tiny Core boot.

1. Use Windows to access and download tc-grub4dos.gz typically this is save to:
    Documents and Settings/user/Desktop
2. Boot from Tiny Core CD or unetbootin pendrive. This results in a base norestore (cloud) mode.
3. Use mount tool to mount your Windows drive.
4. Use Control Panel -> Load Starter Pack to navigate Windows drive to load tc-grub4dos.gz
5. Use Run icon and type tc-grub4dos. Program begins...

1) Ok, I was really using tc, but the effect of the file download is essentially the same.  Got the file, tc-grub4dos.gz.
2) I already had bzImage and tinycore.gz on sda1 in boot/tc3.7rc2 ( I actually already had them booting by invoking grldr from boot.ini - sort of the opposite of what I ended up with below ).  Booted with "base" and "norestore" to simulate booting from CD.
3) Used mnttool to mount sda1
4) Used Control Panel -> Load Starter Pack to navigate Windows drive to load tc-grub4dos.gz
5) Used the "Run" tool to run tc-grub4dos

Step 5 didn't work the first time I tried it, but it did the second time so I suppose I had just fat-fingered it... or maybe related to the issue Guy mentioned above?

Worked through the GUI installer - no problems.  There's room for improvement in the prompts/labels - a little more reassurance for the underconfident, maybe - but overall it just worked.

Since I had already fiddled around w/grub4dos manually and installed it to be called from the Windows boot loader, I expected this process to give me a third entry in boot.ini.  I was only a little surprised to see grub come up -before- the Windows boot loader.  Of course the Windows boot loader is still able to invoke my original grub menu, which makes for a very -unusual- sequence of menu screens!    While I've done some serious geekery on the test system in the recent past, I'm relatively confident that none of that affected the validity of the results of the current test.

At the end of the whole process, the bottom line is "the install process with grub4dos.gz just plain works and you couldn't ask for it to be a whole lot easier".  Another well deserved "Thank you", roberts.

In contrast, my manual efforts worked, but not 100% correctly, and were only easy for me because I'm a geek and have been fooling with TC for a long time.

I'll be away from computers until after the weekend but at the next opportunity I will try the installation on an XP system that, while again "not pristine" has had any OS but XP on it.