Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
First, I know this will seem to not concern Linux, but it does. Really.
I have a situation where an NTFS file system error needs CHKDSK to fix, but I have no way to run CHKDSK, since Windows will not run at all. Always shoots itself in the foot with a BSOD showing the horrid 0x24 (NTFS.SYS-related) error code.
I already knew the file system on my Windows partition was damaged, Microsoft. Good Job! Now, I've got to somehow manage to run CHKDSK or its close equivalent outside of Windows to correct the errors in the file system. There's only one problem: No apparent way to actually do what I need to do. Booting from a Win7 Recovery Console CD (or Win7 Home Premium SP1 x64 DVD) leads to the exact same BSOD (the one I've described) every time.
All of the tools I've seen thus far correct boot errors. This partition (attempts to) boot, but can't. The HDD's MBR is good, since I get into Linux Mint 17.1 (which I am using right now to type this) just fine. Spinrite 6 certified the HDD hardware to be error-free, so this problem isn't hardware-related.
Running NTFS4DOS does nada. Even their variant of CHKDSK fails to run. If anyone can help, I'd be appreciative. One extremely-frustrated computer tech here.
Now, I've got to somehow manage to run CHKDSK or its close equivalent outside of Windows to correct the errors in the file system.
Nope. Proprietary filesystem - the open source tools can only go so far. If it needs CHKDSK, it needs CHKDSK.
Go find another Win box and plug the drive in to that - "CHKDSK D: /f" (or whatever) will work - may require another boot to get all the handles closed.
You should be able to boot the MS Windows Install media to get to a command line to perform the 'chkdsk /f' on the filesystem via instructions at; An Overview of System Recovery Options for Windows 7 and selecting the repair computer option that will then get you to the command line selection. Once you have the command line then you can perform maintenance on the filesystem.
You should be able to do the same for other versions.
Okay, what does this have to do with my request for assistance? Seriously...
I personally have had zero trouble from dual-booting. In fact, I'm using the Linux-side of the dual boot to respond to this thread. (Heck, I started this thread in Linux...)
I was afraid I'd get the consensus I have with this. The problem I'm running into is, quite simply, Windows BSOD's with every boot, no matter if I use a Recovery Console CD (x64, of course) or an installation DVD. While UBCD does launch, it does not have the tools I need to correct this. Was hoping I'd not have to tear the machine down. Toshibas are notorious for being difficult to tear down and put back together, but it looks like that's the best choice right now. Unless I can manage to find a USB sync cable that allows my machine to be seen as a HDD by another Windows box.
I personally have had zero trouble from dual-booting
- until now !
In my experience with dual booting Linux and Windows, exactly the same thing that has happened to you with NTFS happened to me, inevitably.
Another factor was with Linux distro upgrades, which I found could be finicky and concluded that the best way to handle distro upgrades was to strip the drive and start from scratch - which meant doing the whole dual boot thing over again, and then the invariable NTFS blue screen of death.
It may be worth the effort for you, but for someone like me who uses Windows only when they have to - like once a month, I found it was much easier to just single boot, and put Windows in VirtualBox..
Dual Boot just wasn't worth it.
If I was into games on a desktop computer, I'd have two separate physical drives, one Linux one Windows and select the boot drive in the BIOS.
Microsoft OS's behave as if they are the only OS that modifies the MBR, and they don't seem to behave well in that regard.
There is my two cents - it is a PITA for me, maybe not for you
I use Slackware Gnu/Linux with a secondary drive for my MS Windows install. I only use MS Windows when a client needs assistance. Never have a dual boot issue. Only issue for me was hardware failures but that can be easily handled. Filesystem corruption can happen on any OS, just less likely with a properly dismounted filesystem. On Linux I have the need to perform maintenance on occasions but with MS Windows it has happened more than I care to mention.
Maintenance for MS Windows is easily done by using the install media or recovery disk set. You can use the automated repair or get to the command line to perform the disk utilities such as 'chkdsk /f'. You can use the help system while at the command line for syntax & semantics for a command. The link that was posted earlier; An Overview of System Recovery Options for Windows 7 does provide good instructions for making repairs on a filesystem.
What happened when you tried the suggestion above by onebuck? Do you have a windows installation disk?
Yes, I did, and it shows the exact same BSOD error code (0x24). It's frustrating, because I know the drive hardware is fine, dual-booting had nothing to do with the NTFS filesystem getting messed up (I have my suspicions of what actually caused it, but the company whose utility was involved has not gotten back with me on the issue.), and I was truly hoping a USB cable that allowed my machine to be read as a HDD would be a key, but someone else has already stated "It doesn't work like that." Granted, I think they're incorrect, but there isn't a way to test the theory as yet, since I don't have a USB-A to USB-A cable yet. You see, when I first got this machine, I had such a cable, and the old laptop's hard drive was seen by this machine as just another drive because the two machines were linked via said cable. That is why I believe that if that is the case, I should be able to run CHKDSK on this box from another box.
Now, if I can manage to get VirtualBox to allow me to (temporarily) install Win7 (any flavor), that might prove a solution, but I have my doubts on that, too. I somewhat doubt that a VB-installed OS can actually run filesystem checks on the host drive.
Distribution: K/Ubuntu 12.04/14.04, Scientific Linux 6.3/6.4, Android-x86, Pretty much all distros at one point...
Usually, USB cable connections making a drive available on a foreign system are essentially using the native OS to re-interpret the drive as a mass storage device... So, yeah,... Your friends are correct,... It doesn't work like that.
Your best bet with an NTFS screw-up is to physically mount the drive to a Win 7/8/8.1/10 system and fix it from there. Linux support of NTFS is a reverse engineered hack (for reasons outside of Linux hackers' control),... You need drive management tools that are native to the OS to fix it.
In the future,... DON'T run Windows on bare metal. Run it in a VM instead. If you have to run it native,... Run it on a separate machine, and just connect it to your POSIX-based network...