Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[soulsource]

Edit: Please disregard this post, it'd probably not be a good idea as WSL uses rather new library versions, and dynamically linking against those would likely cause issues on older distributions. Thanks, Quietust, for pointing this out.

Old post, left here for reference:

Windows Subsystem for Linux should definitely be an option for compilation.
You can also run the Linux build of Dwarf Fortress just fine within Windows Subsystem for Linux, by either setting PRINT_MODE:TEXT, or by using an external X11 server.
I just tried both:

• PRINT_MODE:TEXT simply works within the Windows Subsytem for Linux bash shell window without any additional prerequisites.
• By using MobaXTerm as external X11 server I could launch the graphical Dwarf Fortress window using the following command line in the Windows Subsytem for Linux bash window: DISPLAY=:0 ./df

[Rose]

In order to read the Linux drive on windows, you will need to install extra drivers for reading Linux partitions.

As for booting from the drive, no idea, but it's worth a shot once you have the enclosure.

[funkydwarf]

Sometimes clearing the CMOS/uefi can get something like that going again. If clearing the cmos doesnt get it going, maybe replace the coin cellnbattery or just try with it out the battery.  Cmos battery coulda died while sitting and corupted cmos data hence the clearing maybe working.   

Was it plugged in all year? Small Possibility is a power surge or something damaged the power supply. But you'd think other stuff would have been damaged.

To clear CMOS/uefi
There is usually a jumper you move over one pin, hold in the power button(at leastbi like to do that), then replace the jumper on the original place and then its reset and good to go. You may have to enter the CMOS/uefi settings and set a few things for it to boot all the way up, but probably work with stock reset settings. You can look up the computer model  for a manual to find the jumper.

[tkamat29]

So any update on this? I'm dying to try out the new release :/

[rmblr]

Others have mentioned a virtual machine, which is probably a good long-term solution.

But to recover the disk, the drive could be connected to your PC, and even though windows won't be able to read the filesystem, you can connect the device to the virtual machine and linux will happily read it. Virtualbox supports this.

[Khym Chanur]

I have backups of the linux DF itself, but it's still a major pain to get that system built again, as we've experienced in the past.

If you can save the drive you should get someone to clone it and keep the cloned drive safe, so when the old drive fails you can just swap in the cloned spare.

If you can't save the drive, then you should document exactly all the steps you need to take to get the Linux computer to the state where it can do a build.  That way when/if this happens again the recovery will be a lot easier and faster.

[Shashu]

I'm less than 2 hours away from you, and I could donate a functional desktop PC for you to plug the drive into. Or I can donate an old USB hard drive enclosure with Parallel ATA interface. The PC has SATA cables. Let me know if either of those sound useful. This offer is available all weekend.

Do you know what kind of interface the hard drive has?

[Maolagin]

Others have mentioned a virtual machine, which is probably a good long-term solution.

But to recover the disk, the drive could be connected to your PC, and even though windows won't be able to read the filesystem, you can connect the device to the virtual machine and linux will happily read it. Virtualbox supports this.

+1 to this -- there's no real reason Toady should have to maintain multiple physical workstations for building/testing Windows vs Linux. He'd be better served with one reasonably powerful and up-to-date machine running his OS of choice with the other one in a VM. In principle it could also be easier to maintain two Linux installs this way than the 32-bit Linux chroot, too.

For OSX I'll concede it's probably simpler to bite the bullet and use real Apple hardware, though.

[Rose]

For what it's worth, I have all three operating systems on a single desktop, so that's perfectly doable, if inconvenient.

[Pirate Bob]

If the machine was plugged in, it might be worth unplugging it, letting it sit overnight, and then trying again.  I'm not sure exactly why this works, but I've had several old PCs resuscitated this way.  Allows stray capacitance to discharge or something?

Probably Toady has already tried this or similar, but it's easy to do and costs nothing so I thought it would be worth mentioning.

[Max™]

I needed windows for some school stuff, in particular testing software required it at one point so I just slapped a w7 iso into vbox and had it run as an overlay, doing the opposite with linux should be possible.

[funkydwarf]

If its a laptop, it does sometimes happen that they hold a latent charge and get stuck spinning fans with just a black screen when turned on. The specific brands and models have different procedures for this but its usually along the lines of take the battery out and hold the power button for a a full minute, or a key combo.

[BenLubar]

I'm not exactly sure -- MSVC in Windows will happily chug away on 3GB with the incremental linker, but I don't know if it needs to be doing that, or what it was doing in Linux.  I should have taken some notes.  Not sure if experienced Linux people can tell me offhand if 1GB would be fine for a reasonable bulky project.

The DFHack build server for Linux and Mac (yes, they're the same machine) has 3GB of RAM split between all the stuff I run on there, and right now there's a DFHack build running and htop looks like this:



That's the highest the RAM usage has been this whole time I've been watching it - usually it's between 300MB and 700MB for the whole system. 1GB should be fine, and as long as you have some swap space, your build process won't crash if you use more than the gigabyte of physical RAM.

If you're running Windows 10, you can enable a Linux kernel emulator by going to Control Panel\All Control Panel Items\Programs and Features, selecting Turn Windows features on or off, and checking the box for Windows Subsystem for Linux (Beta). That has the advantage of sharing a memory manager with Windows, so unlike a virtual machine it won't use up memory and not release it until the virtual machine shuts down.

[grotball]

I'd try another monitor if possible to rule out the monitor being an issue. Then I'd check the GPU card if there one present and make sure it's firmly in. I don't know if it's still a problem nowadays, but if a PC isn't booted very often the CMOS battery can die and need replacing (pretty cheap), and you won't get far into booting without that. Actually I'd just wheel it down to the local PC shop, they generally have all the tools and know-how required (just keep an eye on any disks they clone or suck data off for backup purposes).

There is a bootable Linux distribution called Knoppix with a c/c++ compiler baked in:

  http://www.knopper.net/knoppix/index-en.html

It might be worth burning an ISO to CD/DVD or a bootable USB stick and trying to boot from that to see if the hard disk is fscked (or as another person mentioned try and swap the hard drive from the Linux PC into the Windows one, but fiddling around with things like that can end in tears). I think ongoing it'd be easiest to install the free Virtualbox (virtualbox.org) software on Windows, and create a Linux VM on your main computer... possibly with something like http://clonezilla.org/ to facilitate the disk copying process. But I think it's worth checking the local PC people first before fiddling too much.

Edit: Or there are sometimes "Dial-A-PC" type people in your local suburb that can diagnose PC issues and help out on the spot, which might be better in terms of keeping an eye on the source code/disk.

[Lightman]

It might be worthwhile to use Docker and simply set up a 32-bit and 64-bit environment, if the required libraries clash.