Jump to content

jaclaz

Member
  • Posts

    21,300
  • Joined

  • Last visited

  • Days Won

    53
  • Donations

    0.00 USD 
  • Country

    Italy

Everything posted by jaclaz

  1. ...and just in order to make you worry a bit (before doing nothing ), remember that if you create/move/resize partitions from Windows 7 and later you try to change the active status of a primary one through XP disk management, you are likely to fall into this nicely set trap : http://reboot.pro/9897/ jaclaz
  2. NOT really "necessarily", tools like Mydefrag (there may be others ): http://www.mydefrag.com/ use similar techniques and - more than that - allow to experiment with different approaches thorugh a scripting-like language: http://www.mydefrag.com/Manual-Scripts.html As always, tests need to be conducted but I wouldn't swear that the MS built-in strategy (whatever it is) is actually the "best possible", there may be room for further optimizations. jaclaz
  3. I presume you are talking of two version of the SETUP to be run FROM USB. If yes, there is an ongoing thread here: with pointers to already known to be working ways (the object of the thread is a bit more "narrow", as it requires to have not "double" files. If you have not this requisite, this will do: http://www.rmprepusb.com/tutorials/firawiniso jaclaz
  4. Yep , two different steps, using two different tools/approaches: taking my 2003 CD's and adding Service Pack 2 to the installation and then to append the PERC 6/i controller driver to the installation->nlite making it one ISO in a dvd format.->http://flyakite.msfn.org/ An intermediate step of testing each nlited/integrated SINGLE .iso's/CD's BEFORE attempting to make an AIO out of them is however strongly suggested. jaclaz
  5. Good. And mind you, NOT to be the bearer of bad news, as it is a remote possibility, but let's say - only an example - that you (or your younger brother, etc.) find an old PE CD made out of XP before SP1: http://support.microsoft.com/kb/303013/en-us and inadvertedly you decide to do some partition/disk operation (like an innocuous defrag or chkdsk) from it.... Or you decide to try a Windows 2000 wiithout SP3 integrated: http://support.microsoft.com/kb/305098/en-us What could happen? No, there are several versions of it, and some only differ in "the other" sectors of it. Yep, a 2K/XP MBR (and FAT32 PBR) should have no problem in getting to NTLDR/NTDETECT.COM/BOOT.INI with the Partition Type set to 0B (as long as geometry in the PBP is correct, which in your case is). Reason being (JFYI) connected to this: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/determining-filesystem-type.html what a BIOS or a (oldish) version of grub4dos may do is another thing. Let's first see what happens "as is" and with the 0B set to 0E. jaclaz
  6. It's a common kind of "misunderstanding" . You want to make X. You think that to make X you need Y. You then ask: "How do I use Y to make X?" or (worse) "How do I use Y?" Whilst the actual question should be: "How do I make X?" Put down the chocolate-covered banana and step away from the European currency systems! http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html If tthe actual question is "how do I make an AIO?", then a good answer is here : http://flyakite.msfn.org/ jaclaz
  7. I like to have my partitions "look" good . You have two partitions using for start CHS address 1023/0/1 and ending on 1023/254/63 (which is one of the two conventions to say "don't look for CHS" - the "old" one) and one that use for start CHS address 1023/254/63 and ending on 1023/254/63 (which is the other convention to say "don't look for CHS" -the "new" one). In theory, there is no problem whatsoever. In reality it is possible that some BIOSes or partition related tools ONLY know about the "old" convention and don't "like" the "new" one or viceversa. Since the partitioning has evidently been made with the "old" approach of respecting cylinder boundary, it would make sense to have also partition #2 to have the "old" style 1023/0/1 as start address. Additionally (and this greatly depends on the actual OS you are running or plan to run on that system), the "P5" is crossing the 128 Gb LBA28 boundary, and this may provoke issues if - for any reason - the BIOS or an OS you try on it doesn't fully comply with LBA48. Finally - in my simplicity - the sheer thought of a single 873 Gb partition makes me shiver, besides some of the possible issues above listed, how looooong does it take to defrag or CHKDSK that partition? Or, the latter seen in another way, let's analyze probabilities of a (very limited) software or hardware failure, that wipes or makes unreadable (for any reason) 200 sectors. MBR and each single PBR, if affected by such an issue can normally be recovered in no time, using information gathered here and there from other parts of the disk. The various $MFT's are another matter, and the amount of recoverability of data with a failed or missing $MFT depends on too many factors (BTW a complete defragging does make a difference) Please follow me, this is just theory, but you never know. Out of the whole disk, you have more than 90% of it's capacity "in the hands" of a single $MFT. In total you have 5 $MFT's. Chances that the "200 sectors" hole will happen on this particular $MFT are pretty much low, to simplify we can divide the hard disk in 100 sectors "parts" and we can say that if any of two "parts" covering the beginning of a $MFT are "hit", then you lose a $MFT, so 2*5/2,178,815,688/100=1/217,881,568.8=4,5896493471548750845968757316934e-9 If you divide the huge partition in (say) 8 smaller partitions, the probability is obviously (5-1+8=12): 2*12/2,178,815,688/100=24/217,881,568.8=1,1015158433171700203032501756064e-7 this is obviously far more probable, actually 24/5=almost 5 times more probable, but only apparently so in terms of data. IF disaster happens with your current partitioning, you have on average (rounded data): (2,1%+1,6%+2,1%+0.3%+94%)=100 and 100/5=20% but if (once every five disasters ) you hit the last partition, you have a peak of 94%. With a more segmented partitioning scheme, you would have: (2,1%+1,6%+2,1%+0.3%+11,75%+11,75%+11,75%+11,75%+11,75%+11,75%+11,75%+11,75%)=100 and 100/12=8,34% In the worst case, you would lose only -at the most -11,75% of the data. Which strategy would you choose? Do you like better to have 1/5 probabilities but risk the peak or to have 5 more times the probability but risk less than 1/10 in size? If you prefer, there are NO real issues , BUT there are the "seeds" for a possible future disaster . Back to topic. Both the MBR partiition table and the bootsectors look "ok" for a 16/63 geometry . The partition type is 0B that means FAT32 CHS mapped, due to a number of reasons too long to list here, it is possible that there is a conflict about this partition type. The partition in itself is NOT accessible through CHS addressing (the boundary for CHS addressing on a 16/63 geometry being 1024*16*63*512=528,482,304 bytes). So first thing I would try would be to change the 0B at 0x01C2 in the MBR to 0E 0C (FAT 32 LBA mapped) and see what happens. The report of the grub4dos 0.4.4 you posted clearly shows how it is "confused": you see, 1024*16*63 is actually 1032192, but 1032192*512 is the 528,482,304 bytes, whilst we know how your disk contains at least 63+7,831,089=7,831,152*512=4,009,549,824 bytes. The MBR CODE is the grub4dos one, so you are expecting it to load directly the grldr and have it load menu.lst, right? This is normally allright (but I personally find it not advised with "pesky" BIOSes), using a more "tested" MBR CODE (and having it "self contained" in the MBR and not - like the grub4dos one spread over the first few sectors) would be IMHO "better", at least initially. So, right now you have just grldr and menu.lst inside the partition, right? Try booting "as is" and report EXACTLY what happens. Then try changing just the 0B to 0E 0C, try booting and report EXACTLY what happens (if different form the previous). jaclaz
  8. Try again . The *whatever* MBR you posted is of a (badly ) multipartitioned 1 TB hard disk, with a first NTFS "hidden partition": Entry Type Boot bCyl bHead bSect eCyl eHead eSec StartSector NumSectors #0 17 0 0 1 1 1023 254 63 63 40965687 #1 7 0 1023 0 1 1023 254 63 40965750 30716280 #2 7 80 1023 254 63 1023 254 63 71682030 40965750 #3 5 0 1023 0 1 1023 254 63 120840930 1832679135 two additional NTFS primary partition and a (huge) Extended partition. The bootsector *seems* like it. jaclaz
  9. This means that the DHCP is @ Shaw. http://whois.domaintools.com/64.59.144.80 And also the gateway: http://whois.domaintools.com/174.6.24.1 A strange setting , but possible. You have something similar to this, right?: http://www.broadbandreports.com/forum/r23427979- Most probably the thingy has also a secondary address in the mentioned 192.168.0.x or 192.168.1.x range. Try running netscan with these two ranges, limit the scanned range to (say) 192.168.0.0 to 192.168.1.255. jaclaz
  10. There are two "ways" (at least for cfadisk.sys and dummydisk.sys). One is to install the driver for *all* USB sticks, the other one is to "hook" it to just a single device. Some info is given here (and related links): starting from around here: page__st__46 The diskmod.sys has been tested on a "per device" basis: : http://reboot.pro/9461/ http://reboot.pro/9461/#entry86619 All the instructions are for "manual" integration/install, cannot say how nlite or any other software would manage these . jaclaz
  11. doveman You are doing a lot of tests/changes (some needed, most unneeded ), and every time you introduce at least two changes, this way the probability of success (if any ) are REDUCED greatly. Usually the issue with attempting to help other peeps on the Forum is that they completely fail to provide the barely needed info, in your case it is the opposite, you are posting far more info than needed and thus you are counterproductively "polluting" the reports. Right now I am overwhelmed by lots of info 75% (say) of which are UNNeeded . Your issue is with the BIOS of the VL400 and with that CF card. There is NO NEED to do tests on the Gigabyte PC. There is NO NEED to test another CF card. There is NO NEED to know how *any* other BIOS sees the hard disk. IF your problem is booting the 4 Gb CF card on the VL400, what you need is just: the 4 Gb CF card the VL400 the utilities/tools suggested (and NOT other ones) performing the tests suggested (and NOT other ones) I left you on the reboot.pro thread: http://reboot.pro/16737/ in a situation where: you had no access to the VL400 you went "astray" doing all kind of tests on other hardware, mixing versions of grub4dos, introducing RMPREPUSB and Bootice, mixing files and versions and what not Has this changed? The suggestion is to start again from scratch. Choose one version of grub4dos (and only one). Choose ONLY the 4 Gb card (or the 16 Gb card). Choose ONLY the VL400. Forget ANY other tool if not explicitly suggested. Please provide this info (and nothing else): What is your final goal? (like booting what OS from what media on what machine) How exactly does the VL400 see the chosen card geometry? How exactly the chosen version of grub4dos (please name it) on the VL400 see the chosen card (please specify which one you chose) geometry? How exactly the chosen card is currently partitioned/formatted? (under which OS with which settings, etc.) Since I don't trust you (much ) on #4 above, please get HDhacker: http://dimio.altervista.org/eng/ and use it to make a backup of the MBR (first sector of the PhysicalDrive) and of the PBR (first sector of the logical device), then zip the two resulting files togegther and attach the archive to your next post. jaclaz
  12. I presume it is "SHIFT+F10" -> get a command prompt Type: SET PROG [ENTER] You should get the values of %PROGRAMDATA% %SystemDrive%\ProgramData %PROGRAMFILES% %SystemDrive%\Program Files %PROGRAMFILES(X86)% %SystemDrive%\Program Files (x86) (only in 64-bit version) http://en.wikipedia.org/wiki/Environment_variable http://ss64.com/nt/syntax-variables.html or possibly running reg.exe: http://support.microsoft.com/kb/556009/en-us BTW NOT on the suggested: HKLM\SYSTEM\CurrentCongtrolSet\Control\Session Manager\Envirornment. More: http://superuser.com/questions/68452/detect-windows-server-version-32-64-bit-in-cli I don't think there is WMI available in the PE setup , but maybe this other way is handy: http://social.technet.microsoft.com/Forums/nl/ITCG/thread/8e38d98e-e67f-429c-a98f-da34346f1480 more: http://superuser.com/questions/321988/how-do-i-determine-if-my-windows-is-32-bit-or-64-bit-using-a-command jaclaz
  13. OT , but JFYI. Many, many years ago, the world motocross champion was a belgian guy, named Georges Jobé: http://en.wikipedia.org/wiki/Georges_Jobé http://web.archive.org/web/20091211201410/http://jobe-racing.com/en/georges/index.html To a journalist that asked him how he prepared himself phisically (which kind of exercises, jogging, gym, etc.) for the races he replied something like: Well, he was right : jaclaz
  14. NOT strictly related to your problem, just "common knowledge" to get network addresses but there are several utilities that can scan a network and find devices attached to it. 192.168.0.x and 192.168.1.x are the two most common addresses among the "internal" reserved ones (as an example I personally use another one in the range 10.0.0.0 –10.255.255.255) and most equipment will default to it: http://en.wikipedia.org/wiki/Reserved_IP_addresses Then you have a "mask", the most common used is 255.255.255.0. Given that you already have the correct settings in your OS (and if on the network there is any other piece of equipment that is or acts as DHCP server and you have "dynamic" IP settings) it's just a matter of running such utilities and in a few seconds you will get the address of all pieces of equipment connected to the network. (if you have to scan several address ranges it will take some time). A good software (freeware) for this is: http://www.softperfect.com/products/networkscanner/manual/ If the piece of equipment you are looking for is actuall acting as DHCP server, as Tripredacus said an IPCONFIG /ALL will do. Back to the actual issue. If I were you I would try : http://communityforums.rogers.com/t5/forums/forumtopicpage/board-id/Getting_connected/thread-id/3047/page/3 http://troyfontaine.com/geek/2011/11/05/cisco-dpc3825-from-shaw-clearer-answers/ login: cusadmin password: password or "empty". It is perfectly possible that the password has been entered incorrectly and does not corresponds to the serial on the box You should be able to reset it anyway via console: https://supportforums.cisco.com/thread/2018285 http://www.cisco.com/en/US/products/hw/routers/ps274/products_password_recovery09186a0080094774.shtml jaclaz
  15. For NO apparent reason , view_bs_008 . It should be almost working, still a couple options missing . Still no kids willing to play with me though . jaclaz view_bs_008.zip
  16. IF FAT based (and OT ), you may find something of use in the spreadsheets posted here (shameless plug): page__view__findpost__p__988732 Are you meaning that seeing me elsewhere would not be nice? jaclaz
  17. I cannot say specifically, but it is not the first time that something that worked allright with a given "level" becomes non-working after a SP (or some particular update) is applied. As an example we had this issue with fujianbc fast installer: http://reboot.pro/10126/ http://reboot.pro/10126/page__st__250#entry135150 http://reboot.pro/14186/ And, as another example, this issue with BOOTMGR and ramdisk entries: http://reboot.pro/index.php?showtopic=11442 So, as already said, your next step should be to try replicating (hopefully successfully) what has been already tested (to the T, and this means WITHOUT *any* change of *any* type) with an older source, and from it check the differences when you re-do, still without any change with the "new" source. If you insist of introducing a change, any one, even a teeny tiny one, there is simply no way to find what exactly the issue is. What I always recommend is - when attempting to replicate a tutorial like the one linked to - to (temporarily) forget everything you know or learned from other sources and simply do what is written, if something is not clear, do not "invent" a way to overcome the difficulty, stop and ask for clarifications instead. The primary quality of a tutorial is that it is (or should be) replicable exactly as it is. Please also note how Steve6375 posted a couple of questions to which you have yet to reply . Generally speaking questons and advice are posted in order to actually try and help you, and it would be nice if you could reply/comply to them . jaclaz
  18. This (here) is (look at the top of the page): http://www.msfn.org/board/forum/82-multi-boot-cddvds/ MSFN Forum <- this is good > Unattended Windows Discussion & Support <- is your thingy to be unattended? NO! > Multi-Boot CD/DVDs <- is a USB stick a CD/DVD? NO! Try here: http://www.msfn.org/board/forum/157-install-windows-from-usb/ MSFN Forum <- still good > Member Contributed Projects <- ok, this may make not much sense > Install Windows from USB <- are you wanting to install Windows from USB? YES! jaclaz
  19. Sure we agree on this . The question was aimed at DiracDeBroglie, meant as a hint towards the fact that Atto is not the "ideal" benchmark for a SATA III drive with NCQ . jaclaz
  20. Yes , leave it alone, since the tool is seemingly a risky one (canoot say if "in itself" or "in your hands only " ) You can always install a filter driver, as said in the main thread it has worked and works for lots of people, I see no reason why it shouldnt' work for you, though I have NO idea what is the "winkit" you mentioned at the time. jaclaz
  21. The "traditional" method to add a specific driver that is not already included in a NT based system. See: Typical is a Mass Storage device driver. When you start a NT setup you are asked to press F6 to add the driver through a floppy disk. At least in XP (cannot say in 2k) is possible (on motherboard that provide both Legacy IDE emulation and AHCI) to install "normally" and then install and switch the driver: jaclaz
  22. For even less apparent reasons , a set of batch files to test some of the "queer" behaviour of the mouse. At the moment just a very rough, experiemental assembly of half-@§§ed batches. You will need a couple external apps: Nircmdc, part of Nircmd from Nirsoft: http://www.nirsoft.net/utils/nircmd.html (greetings and thanks to MarkTheC for pointing me to the sendmouse move capabilities of the above. MAT (Mouse Acceleration Toggler): http://skwire.dcmembers.com/wb/pages/software/mat.php Put the batches in the same directory nircmdc and MouseAccelToggler.exe, open a command prompt and navigate to that folder. Read the quick instructions that appear when you run any of them. jaclaz mousecmd.zip
  23. JFYI, the "old school" method was to create a dedicated partition (possibly on another disk) to ONLY hold the pagefile. If on another disk, when "hit", it will be way faster than on System partition (or than other partition on same disk). In any case it will be hit seldom (please read as "never" ) if you have RAM in quantity adequate to the OS and applications you are running. jaclaz
  24. @RickRollNW I am not sure to understand your last report. If I get it right you have discovered that the actual "base" .iso is "botched"? (it doesn't work also on DVD?) Can you try with another source (possibly, in order to replicate, a SP0 one)? jaclaz
×
×
  • Create New...