Print

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

[rothen]

edit: Lost as to what is meant by "\\.\PhysicalDrive#"; Disk Management in Windows doesn't seem to list anything relevant for the USB drive aside from its assigned letter.  The main drive has "TIS0008000D (C:)", but the USB has " (E:)".  I can fill in the blank space, though I haven't tried to apply that.  I can right click them to get Bus Number (1 and 0, respectively)...  and various other event IDs.

Shares in Windows are referenced in the format \\<server_name>\<share_name>. So \\.\<drive> refers to a drive attached to the local computer. thewonderidiot has the correct command to list physical drive numbers.

https://www.tenforums.com/tutorials/87131-find-serial-number-hard-drive-windows.html#option2 shows exactly what the format should be, albeit with a slightly-different command.

[pnathan]

Good evening.

Figured I'd drop by to see what the situation was with my beloved Linux release (I don't visit the DF fora much). After all, there are dwarves that need to build fortresses and steal artifacts in my future...

Anyway. Build systems and build reproducibility in Linux are literally my professional specialty (seriously!).

Toady - if you would like, I can pull together guides and other material (i.e., examples), as well as make myself (freely) available for phone/email/google hangout consultation on how to use it, to the end that

- your VM configuration is stored in source code
- along with a guide for installing the tools to download and autoconfigure said VM.
- along with sufficient scripts to get your custom build system up and launched.

This will let you crash all the machines you like so long as you have your source code backed up. It is a bit of a hassle and an "oy vey! so much starting paperwork" kind of thing, but it pays off in spades down the road.

If that sounds cool, PM me - it should email me on PM, and I'll manually circle back to the forum/thread tomorrow sometime. If that's not cool, I won't be offended if you ignore me.

[Insert_Gnome_Here]

One possible cause for this, I guess, is if one had BIOS and the other has EFI. If your laptop has EFI, you might be able to find a BIOS compatibility setting in your setup -- booting from the drive might work after enabling that.

 
 
As someone who has dealt with setting up dual-booting on uncooperative EFI hardware, I must warn that it can become a massive time sink. 
Booting linux from USB/CD then chrooting into the relevant system may well be a reasonable workaround if you want to run a physical linux system temporarily. 
 
But if VirtualBox is working, stick with that.

[Toady One]

So the VirtualBox is working now...  and it's compiling...  but it is going very, very slowly.  It might be 10 hours at this rate?  I'm not sure what the factors are here.  If something about the USB is slowing it down, or the virtual machine, or if I need to add more memory?

If that sounds cool, PM me - it should email me on PM, and I'll manually circle back to the forum/thread tomorrow sometime. If that's not cool, I won't be offended if you ignore me.

It's difficult to take private help as there are so many issues specific to particular user setups, utility makers etc. and I have no idea what's going on myself, so I can't address them.  I don't even know what I need to cover.

[Max™]

The usb isn't the fastest link to read a drive off of, at least not older usb hardware, not sure about newer versions of the standard, if you could copy the relevant data over to a partition for vbox to use locally it would probably speed it up a lot.

[jecowa]

I think Linux makes special partitions for virtual memory. I wonder if it could be using a partition on the USB attached hard drive for virtual memory. Maybe it's also going at USB 2.0 speeds instead of at USB 3.0 speeds. How long does a compile normally take?

[rothen]

More RAM and CPU cores couldn't hurt. If you didn't mess with the settings, VirtualBox probably defaulted to using one core. Giving it a couple more should speed things along considerably.

[Toady One]

Yeaaah, I think it was probably doing virtual memory on the drive and over the USB or something -- which makes it seem like a miracle that it was able to build any of those objs.  It's screaming now that I've doubled to 2GB and given it 2 cores (the max for whatever reason, something about virtual vs. physical -- no idea what my laptop does but it pretends to have 4), and the drive is A Lot quieter.

Of course, it remains to be seen if this'll work!  Signs are okay now.

[Toady One]

Double-posting to say:  Linux release posted.  That may do it!  I played the 64 bit version from the VM and generated a world fine.  A few confirmations in here would be handy!

64 bits
32 bits

[Izanami]

No time to play at the moment but I loaded into Arena Mode and choked a wolf to death, so that's a good sign.

[Max™]

Working so far!

This popped up but it could be because I slapped the libs folder+a couple other bits from data into my existing df folder:
Missing/broken TTF handle: 16776961

[Rose]

Now that you have something  working, you can try using something like clonezilla to copy the mounted USB hard drive onto a virtual disk image, that way you don't need to mess with the USB stuff every time.

Just have both the usb drive, and a new vmd image mounted into the virtualbox machine at the same time, and boot from the clonezilla iso. That will let you just copy the entire disk onto the virtual drive.

alternately just setup separate fresh virtual linux installations for 32 and 64 bit, and use those.

[SmileyMan]

If you do image the disk, I'd really recommend sticking this on a cloud service. AWS or Azure - take your pick. Firing up the machine to do builds and testing will cost a handful of dollars per year, and storage costs for a single virtual disk will be cents per decade.

All backed up and safe, and when you need to run it you'll be going on dedicated optimized hardware in a state-of-the-art datacentre.

If you wanted help setting that up I'd be more than happy to - it's literally my day job!

[ShimmerFairy]

In unzipping the tarball, I got a bunch of warnings about timestamps for the files being in the future. A small sample:

Code: [Select]

$ tar -xvjf df_44_02*bz2
df_linux/
df_linux/libs/
df_linux/libs/libstdc++.so.6
tar: df_linux/libs/libstdc++.so.6: time stamp 2017-11-28 10:40:52 is 13869.48383684 s in the future
df_linux/libs/libgcc_s.so.1
tar: df_linux/libs/libgcc_s.so.1: time stamp 2017-11-28 10:40:52 is 13869.47918709 s in the future
df_linux/libs/Dwarf_Fortress
tar: df_linux/libs/Dwarf_Fortress: time stamp 2017-11-28 10:40:52 is 13866.801833617 s in the future
df_linux/libs/libgraphics.so
tar: df_linux/libs/libgraphics.so: time stamp 2017-11-28 10:40:52 is 13866.669356568 s in the future
df_linux/df
tar: df_linux/libs: time stamp 2017-11-28 10:40:52 is 13866.668759155 s in the future
tar: df_linux/df: time stamp 2017-11-28 10:40:52 is 13866.668644268 s in the future
df_linux/raw/
df_linux/raw/objects/
df_linux/raw/objects/creature_large_tundra.txt
tar: df_linux/raw/objects/creature_large_tundra.txt: time stamp 2017-11-28 10:40:52 is 13866.667389798 s in the future
df_linux/raw/objects/creature_equipment.txt
tar: df_linux/raw/objects/creature_equipment.txt: time stamp 2017-11-28 10:40:52 is 13866.666718564 s in the future
df_linux/raw/objects/plant_garden.txt
tar: df_linux/raw/objects/plant_garden.txt: time stamp 2017-11-28 10:40:52 is 13866.66415976 s in the future
df_linux/raw/objects/material_template_default.txt
tar: df_linux/raw/objects/material_template_default.txt: time stamp 2017-11-28 10:40:52 is 13866.658754688 s in the future
df_linux/raw/objects/creature_tundra_taiga_new.txt
tar: df_linux/raw/objects/creature_tundra_taiga_new.txt: time stamp 2017-11-28 10:40:52 is 13866.658148476 s in the future
df_linux/raw/objects/creature_riverlakepool_new.txt
tar: df_linux/raw/objects/creature_riverlakepool_new.txt: time stamp 2017-11-28 10:40:52 is 13866.615237899 s in the future
df_linux/raw/objects/creature_temperate_new.txt
tar: df_linux/raw/objects/creature_temperate_new.txt: time stamp 2017-11-28 10:40:52 is 13866.597667506 s in the future                                                                                       
df_linux/raw/objects/descriptor_color_standard.txt                                                                                                                                                             
tar: df_linux/raw/objects/descriptor_color_standard.txt: time stamp 2017-11-28 10:40:52 is 13866.596898496 s in the future                                                                                     
df_linux/raw/objects/item_shield.txt                                                                                                                                                                           
tar: df_linux/raw/objects/item_shield.txt: time stamp 2017-11-28 10:40:52 is 13866.596768453 s in the future
This is likely just because the VM's timezone or date/time was set incorrectly. I have yet to run DF, but I don't think it will harm actually running it.

[Rose]

That's 3 hours. Not something that will have an effect for very long.