Off-Topic > Starter Packs
grub4dos.gz
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:
--- Quote ---I see no one has done a fresh installation of Tiny Core on a pristine XP system
--- End quote ---
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):
--- Quote ---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...
--- End quote ---
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! ;D 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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version