Printable View
By the way virtualbox need to rebuild it's kernel module driver for a target kernel, and this can be done by doing once after installation :-
# /etc/init.d/vboxdrv setup
This will compile the kernel driver needed to run vb if you have the proper kernel header.
I think you are referring to OSE version - Knoppix is preinstalled with OSE version if I am not mistaken. But if you are using PUEL version, it should be at par with VMplayer.Quote:
Originally Posted by utu
I think utu has used it under Windows? But it may seem that the OSE version isn't that much to brag about, plus there is a dependency maze sometimes. Still, it may be a strategical tool to care about for us?Quote:
Originally Posted by kl522
@ Capricorny
Rather than put all your stuff in with Win7 as 'just another file'
why not at least first segregate the section you use into a Virtual Hard Drive?
That is a built-in capability of Win7 Home Premium that would seem
to offer some protection from lousing up Win7 when using its resources.
I still don't get why you want to do this so terribly complicated!Quote:
Originally Posted by utu
Please tell me the chance of corrupting the whole Win7 file system by using my method. It's close to nil. We are not deleting, relocating, using metadata, not anything except for creating a few files at one point of time, and doing random access on them, mostly ro, later. If this had been very risky, I think we should have had reports about it.
Using virtual hard drives might well offer some protection, but I simply don't trust Windows concepts before I have seen them thoroughly tested, and the extra level of complexity must be well motivated by some actual problems.
BTW, I wonder if these VHD's are not simply loop-mounting coming to Windows. In which case we would get an extra, unnecessary level of indirection using them. But I may be wrong.
Your idea is attractive, it's new to me, I'd like to see it succeed.Quote:
Originally Posted by Capricorny
Glad you are willing to use your own Win system to see if it
works out.
I won't risk mine so willingly until I see more folks doing it with
no ill effects. I'm no Windows hater, I like Windows, I just like
linux better.
Lots of luck to you.
There is certainly some confusion here.Quote:
Originally Posted by utu
case 1:
When Knoppix poor-man install is made to a NTFS file system, and when Knoppix is booted, it is accessing the NTFS via fuse/ntfs-3g. The risk is about fuse/ntfs-3g.
If you created a VHD on NTFS using Win7 capability, now assuming Knoppix is somehow about to boot, what is the driver you are going to use to access the (Win7) VHD on NTFS on ***LINUX*** ? Assuming that you could find such a driver, that will have to be a Linux driver. Certainly the risk of higher than using fuse/ntfs-3g !!!
case 2:
Then assuming that you are not running Knoppix natively, ie you are running Knoppix in Virtual Machine under Win7, then when Knoppix accessing it's harddisk, it goes through Linux file system drivers in the guess OS then it passes on to drivers on the virtual machine on the Host OS. The virtual machine may access it via it's proprietary driver ( eg Virtualbox .vdi ) or if you are lucky, it might understand Win7 virtual HD format. Whatever it is, assuming Linux file system driver is safe to use ext3/cloop/etc, then the risk is entirely on the virtual machine. Now it is matter of you want to trust the proprietary file system driver of the virtual machine, or you want it to trust the virtual machine able to also understand win7 VHD.
Whatever is the configuration, I would say in conclusion by having Win7 VHD, you are adding complexity and RISKs, especially case 1 above.
Sure, we all have to choose the level of risk taking, and there IS some risk involved. I would not do this on mission-critical machines, BUT:Quote:
Originally Posted by utu
1. The correct thing to do is keeping a sharp as possible distinction between program and data re disk use. Now, Windows makes this hard in a completely meaningless way by not letting you shrink NTFS partitions by more than ca 50%. But if you are serious about your system, you have a system partition of a few GB, which is easily restored from backup, plus one (or several) larger data partitions which you backup to external media, typically USB harddisks. Corrupting either of these, you get back by a few simple commands.
Therefore, if using Knoppix poses a great risk for you, that's just an indication of wrong system design. I would in fact say, not really serious. But yes, that's what Windows arranges for.
2. To me, your worry is a bit similar to walking in the fast lane on a highway and being very concerned about being hit by an helicopter. Harddisks start developing failures after some time, inevitably. And with a running laptop, it is not that difficult to inflict damage. It's not for fun that my new Toshiba R830 has a movement sensor and a utility (under Windows) that kicks in and parks the harddisk head whenever movement is detected. Furthermore, NTFS is a somewhat errantly moving target, and guess who has the most problems with that. Yes, of course M$ themselves. A good portion of all disk corruptions seem to stem from software bugs. But the most important, is the malware aspect. Check the percentage of Win computers being infected to some degree.
3. If you do the really relevant comparison here: What kind of use is assocated with the highest risk of corruption per hour of use, I think poor man's Knoppix may turn out the safest way to use your Windows computer. In particular if you run it off the SD card or the smartphone, but also from hard disk. So, when you insist on running Knoppix in a VM, that seems much more of a safety hazard to me, because of Windows, than running it natively. I do it the other way round, and it is much, much simpler. And as I demonstrated, itcan easily be done off a NTFS partition. (Now I have made that store.img file 120 GB.)
You have no 'sdb2' partition; and where does the directory '/local' comes from?Code:# mount /media/sda2
# rsync -ax /mnt-system/KNOPPIX /media/sda2 &
# dd if=/dev/zero of=/media/sda2/store.img bs=1M count=60000 &
60000+0 records in
60000+0 records out
62914560000 bytes (63 GB) copied, 682.558 s, 92.2 MB/s
# losetup /dev/loop6 /media/sda2/store.img
# mkfs.ext4 /dev/loop6
# losetup -d /dev/loop6
# mkdir /store
# mount -o loop=/dev/loop6 /media/sda2/store.img /store
# mount /media/sdb2
# rsync -ax /media/sdb2/local/ /store &
And then you wrote:After starting from HD whith my Windows 7 installed on it, I don't know, how to mount with the tools from Windows7-tools this new image file. And where is the "rc.local" of Windows 7?Quote:
After starting from HD, I can manually mount this new image file, or I can add the commands to rc.local.
Or do you need changes of Windows 7 bootloader or are fiddling with VMServer? If so, I can not see the big advantage of your method in comparison with remastering in a virtual machine on a virtual drive.
I should have given more details! Thank you for calling attention to it! :)Quote:
Originally Posted by Werner P. Schulz
The situation was, that I booted from an external USB SSD harddisk, with a (partial) copy of the /store partition on /local. That is one of the ways I keep things in semi-sync between computers, and also quickly test out things on new hardware.
My install is based on booting into Knoppix from external media - optical drive, USB etc. When booting without fromhd= cheat code from a USB stick with this KNOPPIX directory in place on the NTFS partition, Knoppix will find that first, and run from it, "auto-mounting" NTFS. So, just copying the KNOPPIX files and choosing an external boot option with Knoppix, this whole thing will get started. When up and running, we can modify the /etc/rc.local of running Knoppix to automount the /store image.
In fact, Windows doesn't need to know about this at all! No changes to bootloader, nothing in the system setup.
Later on, we may create a /boot partition and install grub - still no change to Windoze bootloader. Setting Win7 as default in grub menu, it will come up as usual - been doing that for years, several computers mostly in WIndows use. I don't want to go into booting Linux from Win bootloader - it can be quite easily done also with Win7, but I don't think it's the best way to proceed.
Remastering is the next step, think I hinted at that. For that purpose, I create another loop-mounted store, 10-35GB according to project, and mount it on a directory /tmp/knx_remaster. Then running a version of Forester's script. But I'll get back to that, it's basically the procedure described by Forester, but run with loop-mounted images off NTFS. It's simple and relatively quick.