jaclaz

DHCP should use ports 67 and 68. jaclaz

Maybe it is related to DNS cache? Usually - I believe - should be set at 1day intervals, but it is possible to change that through the Registry. Settings should be under HKLM\CurrentControlSet\Services\Dnscache\Parameters See this (possibly it applies to NT4 as well): https://www.itprotoday.com/cloud-computing/how-can-i-configure-how-long-dns-cache-stores-positive-and-negative-responses jaclaz

Statement of facts: Nuhi (Dino Nuhagic, the Author of both Nlite and NTlite) is a longtime (and much esteemed) member of MSFN, and MSFN has always been the official support forum for nlite. The original nlite was finalized in 2008 or so, and then put "on hold" as Nuhi had lots of things to do in his "real" life. Nlite is/was completely freeware and support was largely through the MSFN forum. It actually had a license limiting its use to personal use, and while many people ignored it and used it anyway in corporate environments, others asked for a commercial license. Several years later (circa 2014) he developed NTlite choosing a "limited-free" version + different commercial versions, and setup a dedicated forum for support on his site (though we do have a section for ntlite on msfn). He isn't around on MSFN since 2020: https://msfn.org/board/profile/8552-nuhi/ AFAICR comments, critics, opinions (positive and negative) and discussions on his programs have often been posted on MSFN and (again AFAICR) they have never been moderated unless -maybe - when/if they broke the general Forum Rules. jaclaz

That is not really a "fork" and it is not Subergrub2", it is actually "Supergrub (2) disk" it is a (nice BTW) project that provides a working, pre-compiled/pre-made boot disk (CD but can be deployed to USB stick) capable (in most cases) to boot a machine where the local install of Grub (or other bootmanager/bootloader) has been corrupted/doesn't boot the OS anymore: https://www.supergrubdisk.org/ https://github.com/supergrub/supergrub if you prefer it is a practical implementation of GRUB2. Maybe you were thinking of GRUB2WIN, though that is also not really a "fork" but rather a set of programs to make GRUB2 more accessible to Windows users: https://sourceforge.net/projects/grub2win/files/ jaclaz

I think it is already past that point, particularly because as soon as you exit the "common, normal" situations (and working BIOS/UEFI) you have very little documentation and (not that I have much experience with GRUB2) the concept of installable modules is in theory a very smart thing, but in practice make things very complicated, the way it is installed (or created/compiled) is - to say the least - confusing. The update mechanism (and having a settings fie that you should NOT edit) is only the tip of the iceberg. BTW the only clear explanation of the mechanism for grub.cfg I could find is on dedoimedo: https://www.dedoimedo.com/computers/grub-2.html https://www.dedoimedo.com/computers/grub-2.html#mozTocId542243 If you installl a Linux distro everything is automated, but when/if you need anything outside what the good guys putting together the distro decided to include/pre-set/etc. things become problematic. I believe that the good people of GRUB2 (or of the various distros) read the U in grUb more as Unique than as Unified. jaclaz

OT anecdata, but I know a few ophthalmologists, and they all sport glasses. There must be a reason. jaclaz

Yes, sometimes it is a hit and miss game, and you have to try *everything* before finding something that does work, GRUB2 (besides a couple of IMHO stupid development decisions, such as the new grub.cfg syntax and the update mechanism) is fine, though it has (when it comes to non-linux) less features than grub4dos, but again, unless you need some "advanced" features any will do (whatever works is good enough), what I would try to avoid if possible is multiple chainloading of different loaders as it tends to be more prone to errors, but when and if is needed, it is needed, just as an example in some cases PloP works when both grub4dos and GRUB2 have issues, in many cases (in my experience) the issue is with installing the initial loader to the MBR+hidden sectors. jaclaz

map --hook and map --rehook, it depends, for a period of time (in 0.4.2, 0.4.3, and possibly 0.4.4 versions) subsequent hooks needed to use the rehook command, later (but cannot really say when) you can use always the "normal" hook (to be fair, it is a rare case that you need to hook and then hook again the mappings). There are quite a few added features in 0.4.5 most notably the dd command is reliable, small files on NTFS are accessible, and grub4dos batches are possible, but additionally there are lots of bug fixes (mainly for particular usage or on particular motherboards/setups and/or OS combinations). A few examples of possibly useful grub4dos batches: http://reboot.pro/index.php?showtopic=17728 http://reboot.pro/index.php?showtopic=22739 http://reboot.pro/index.php?showtopic=22554 For "basic" use any version that works for your OS if fine, when/if you need some advanced features, you will see the improvements in 0.4.5 over 0.4.4. Normally you can "switch" to another version of grub4dos easily, by chainloading the grldr or using grldr.exe as argument of the linux directive, so you can have more versions in different directories to experiment with. You are seemingly always loading DOS first then either go on loading Win9x or go to GRUB2 (why?) to load XP. Generally speaking the loading of grub.exe from DOS is more prone to issues, in your setup I would (mind you these are only personal preferences) rather have on the CF card: 1) the "normal" DOS/Win9x MBR code[1] 2) a (FAT) bootsector loading grldr on the active partition (on the CF card) 3) in menu.lst the choice between chainloading IO.SYS on the CF card and chainloading (after remapping disks if needed) the NTLDR on the SATA disk + (if needed) whatever entry for Linux(es) You don't really *need* GRUB2 at all, let alone GRUB ("legacy") jaclaz [1] this is really only a pet peeve of mine, I personally do not like to have code written to the first few "hidden sectors", so I try to avoid using grldr.mbr code where possible.

That 0.4.4 version 2009-12-03 is probably fine, as it is later than the 16 october one (which is the most tested/used), and it fixed a nasty dd issue, introduced BTW after the 2009-10-16 version: And yes, that is the latest 0.4.5 version, you should use that one if you need the added features that 0.4.4 misses. The 0.4.6 is the version in development BUT at a certain point (some time after the 0.4.5c 2016-01-18) new features and more than a few changes were introduced in it, and this has reportedly caused some compatibility issues with older motherboards and old OSes. The suggestion (for your case use) is: 1) try using 0.4.4 2009-10-16, you don't need any of the features added in later versions, but if for *any reason* you have issues, then 2) try using 0.4.5c 2016-01-18, you don't need any of the features added in later versions, but if for *any reason* you have issues, then 3) try using latest 0.4.6a Generally speaking, the older versions have been tested more extensively with older OS such as DOS/Win9x/Me, and while the good grub4dos developers are usually very fast in correcting issues, due to the continuous evolution of 0.4.6a, it is well possible that bugs with older OSes exist and have not been found simply because they were not tested in a given combination of hardware/Bios+old Os. Cannot say about the partial boot you are having with Win9x, if you post your setup (which hd numbers and partitions you get in grub4dos and which commands you are using) maybe I can suggest some variations to try. I am not sure to understand what you mean, linux is not a grub4dos command (it is a GRUB2 one), you use kernel instead, initrd is there alright. jaclaz

Well, you are not really remapping anything with: no offence intended, but in grub4dos those are "wrong". You probably want instead : map (hd0) (hd1) map (hd1) (hd0) map --hook root (hd0,0) chainloader +1 the key here is the "map --hook" that makes the exchange of the drive visible outside grub4dos. Then you want to normally use root (and not rootnoverify) if the target is an actual bootsector (such as (hd0,0)). The makeactive directive is not needed for XP AFAICR (it may be needed for DOS/Win9x, though). If you are not hooking the map in the DOS/WIndows 9x menu.lst, it may boot but what was passed to the IO.SYS by grub4dos may not be the same thing the BIOS provides when the OS later rand it is likely to be at least part of the issue you were having. I am not sure to understand: There could be a number of issues both connected to your speciific machine or commands you are using, but also to the specific version of grub4dos you are using. 0.4.4 version 16 October 2009 should be the only one of the 0.4.4 series that can be used (earlier versions had several bugs) If you are using the 0.4.5c, use the latest available. 0.4.6 (any version) is not recommended as quite a few things were changed in it and not much testing has been done with DOS/W9x/Me, mind you if it works it is fine. jaclaz

It is possible that some of the passages you go through alter something in the BIOS drive table. Are you really using GRUB1 (so-called "legacy")? Or are you using grub4dos? If not, first thing I would suggest you is to try the grub4dos, which is essentially a "better" GRUB, with a number of features dedicated to DOS and Windows booting. If you are already using grub4dos, post the contents of the menu.lst entry you are using, maybe something needs to be corrected. jaclaz

Most computers are usually set to use DHCP network settings, there are only two possibilities: 1) DHCP assigned IP and network parameters 2) Statically (manually assigned) IP and network parameters As I tried to explain earlier, what happens in your case is that when you boot (with the wired connection active) or anyway when you connect the network cable, your computer makes a DHCP request on the network and a DHCP server on the network replies setting (among other things) the IP address of your network card, the net mask to be used, the gateway IP. So, initially, you have not any IP address, network mask or gateway (as a matter of fact in windows OS if these parameters cannot be determined because they are not set manually or received from the network a "default" address of 169.254.x.x, a so-called APIPA address): https://superuser.com/questions/238625/why-is-windows-default-ip-address-169-xx-xx-xx https://learn.microsoft.com/en-us/windows-server/troubleshoot/how-to-use-automatic-tcpip-addressing-without-a-dh If (which is what happening to you) a DHCP request is made and answered correctly, your network interface gets the addresses/data from the network. When you delete the gateway from the route table, you are (indirectly) modifying the data that the network sets. When the (50% usually of) lease time has elapsed a new DHCP request is made on the network and the network DHCP re-sends all the info, the IP address (usually the same as before), the net mask and the gateway are re-sent and (in order to allow you the "normal" connection) the gateway is re-added to the routing table. There is no way you can permanently delete the gateway from the routing table, because it is periodically re-added to it automatically. What you can do is: 1) disable DHCP and manually set the IP address, net mask and gateway (so-called static IP addressing[1]) <- in your case you don't need to enter the gateway address at all, or enter it to test and then delete it from the interface 2) route the gateway address to *something else* <- this has to be tested, it may or may not work There is another possibility (more complex and that will need to be tested as well) to make some automatic periodical re-deleting of the gateway I hope the above helps in let you understand how it works. jaclaz [1] In Windows 7: https://www.pluralsight.com/blog/it-ops/windows-7-ip-addressing

I am not familiar with that software (Softether) but what you reported as an issue seems like being something that happens before and outside the VPN. Let's see if I can detail what I imagine is happening. You connect your PC to the ethernet (wired or wireless), it is set as DHCP, so it knows nothing about: 1) the IP it should have 2) the network mask it should have 3) the gateway it should use to get internet so it issues a DHCP request on the network and soon the DHCP server on the network replies with these data that are attributed to the interface. Then, you start your VPN software and (either automatically or manually) you add a route to the new, VPN gateway (thus overwriting the setting for the previous, local, gateway). Then, when you close your VPN you have no internet access as the gateway is still the VPN one. But after some times passes, the DHCP (50% of) lease time expires and a new DHCP request is issued and the gateway is restored to the original, local IP, so internet connection (outside the VPN) is re-established. Now, if the issue is that you do not want internet connection (if not through the VPN) what you can try doing is to add a route pointing the gateway to another address (localhost?). Example: DHCP assigned IP: 192.168.1.200 DHCP netmask: 255.255.255.0 DHCP gateway: 192.168.1.1 Now if you add a route: route ADD 192.168.1.1 MASK 255.255.255.255 192.168.1.200 What happens? (this may depend on the OS you are running and possibly on a number of other variables). jaclaz

Smallville didn't seem so expensive, or is that Metropolis? jaclaz

If that doesn't work (the idea is to add with -p switch a route to a non existing or not connected gateway address), the only way out you have, I believe, is to assign a static IP and net mask (and no gateway) to the interface and disable DHCP or increase the DHCP lease time (if you have access to the DHCP server). Very basically the DHCP server is hosted by some device on your network, usually the router or terminal adapter. When a device with dynamic IP address connects to the network it doesn't know anything about the network and sends a DHCP request, the DHCP server replies assigning a timed lease with the IP address assigned to the device, the net mask and the gateway. The lease can be anything from a couple hours to 24 hours or so, it depends on the settings in the DHCP server, usually it is renewed at half the lease time, the device asks the server to renew the lease, this is probably what happens in your setup: https://www.serverbrain.org/network-services-2003/how-the-dhcp-lease-renewal-process-works-1.html You could also try to put a higher metric manually to that gateway, but cannot say if it will work as when you kill the VPN it will remain the only gateway. jaclaz

It is likely that the issue lies in the renewing of the DHCP lease. See if you can use any of these suggestions: https://serverfault.com/questions/648603/prevent-windows-server-2012-from-using-dhcp-provided-default-gateway Or otherwise (cannot say if you can do this in your setup/OS) set static IP (disable DHCP). jaclaz

The idea is (should be) that through a "repair" or "wipe" or both, the defective sectors are added to the so-called "G-list" and are remapped onto spare sectors. The 25 (is it in parameter 187 or 198?) should be the number of sectors in this G-list, it shouldn't ever reset, the G in G-list seemingly stays for "Growing". It doesn't seem to me a bad situation, but the overall health of the disk drive can be (maybe) better guessed from other S.M.A.R.T. parameters: but as said there you never know for sure. The sanest approach (as I see it) is to use the disk and see if in a short time of use the "key" parameters change noticeably. jaclaz

The estimation seems like not particularly optimistic, but 77% of 500 GB in 40 minutes doesn't sound bad at all. jaclaz

And I never said you did (though you did attribute to me a recommendation): I have no problems, thankfully, though your exclamation mark, is - of course - a (minor) nuisance: https://en.wikipedia.org/wiki/Exclamation_mark#English jaclaz

Just in case, what jaclaz said is CLEARLY here: Nothing more, nothing less.[1] To be even more clear, I did not start anything, I was asked explicitly for something and answered to the best of my knowledge (on something that I don't use, never used and don't foresee using in the near future and that I neither recommend, endorse, nor judge, criticize or comment in any way). jaclaz [1] last character is a full stop or period.

Now that you have the data saved, you should run the manufacturer test (the "extended" one) and see what results you get. jaclaz

Only as an example, SP2 removed PAE : In the case you had a "good" motherboard with "good" drivers and lots (at the time) of RAM XP SP2 was a "downgrade". But OP's procedure - unlike what the title suggests - does not actually install Office 2007 in SP1, it installs it on SP2 and then reverts back to SP1. It is unknown if anything "sticks" after uninstalling the service Pack 2. jaclaz

@AstroSkipper Not necessarily applying to this particular product (Vir.it), but being well known or popular is not always a proxi for anything but being well known or popular, and definitely not for quality or convenience. As an example, take DMDE (which I actually personally recommend[1]) as a program for data recovery, try finding it searching for a data recovery program, you will find that Recuva, Easeus and Wondershare are far more well known and popular, yet they - in the best case (if/when they work at all) - offer a fraction of the capabilities of DMDE. jaclaz [1] but that D.Draker cannot use because the programmer is Russian

I didn't "recommend" anything. I only provided - when asked - a link to it: No personal experience with it, all I can say is that it is VB100 certified (whatever relevance this may have) with a grade of D: https://www.virusbulletin.com/vb100/testing/tgsoft/vir-it-explorer-pro https://www.virusbulletin.com/uploads/vb100/test-reports/vb100-test-report-2023-04-21-vir-it-explorer-pro.pdf jaclaz

Do you mean that water is obtuse below 2,895 meters? jaclaz