Print

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

[Lightman]

Running the 64-bit version. Got past world gen, started adventure mode.
Everything seems to be okay.

[MehMuffin]

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

[noparse]

Code: [Select]

[/noparse]

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.

irrelevant now, but probably the result of the linux VM setting UTC based on timezone-adjusted windows time.

also just tested creating a world and starting a fort in it and everything went smoothly

[Toady One]

Okay, very good, I'm glad it is more-or-less working.

Right now, I don't quite feel comfortable cloning my linux partition over to my laptop since it would eat a good portion of the space I have left on the drive.  I'm not remotely using the 500GBs of the main Linux partition, but I also have no idea if there's a way to remove some of the free space from that so that the partition becomes manageable as a movable critter.  I'm of course, quite, quite interested in Not screwing up my existing Linux partition in the short term, having just got this release working, but it also makes sense to get this off of hardware in a way I can back up reliably (since the physical drive is gonna go at some point).

cloud suggestions: Just not putting it online, unfortunately.

[Max™]

https://www.gnu.org/software/parted/manual/parted.html

I'm not sure how comfortable you are juggling a system from a barebones cli so I wouldn't mess with trying to figure out which fsck or resize2fs or whatnot you need to screw with, but there are bootable versions of gparted which will show how much you're using and let you shrink it down and slap it onto another drive easily.

[thewonderidiot]

Right now, I don't quite feel comfortable cloning my linux partition over to my laptop since it would eat a good portion of the space I have left on the drive.  I'm not remotely using the 500GBs of the main Linux partition, but I also have no idea if there's a way to remove some of the free space from that so that the partition becomes manageable as a movable critter.

That's actually not too much of a concern -- modern virtual machine disk formats grow to fit the size actually used, so a disk image shouldn't be anywhere near 500GB. You can try to create one with the following command:

VBoxManage convertfromraw \\.\PhysicalDrive2 D:\VirtualMachines.vdi --format vdi

(substituting out the drive number and paths, of course)

edit: changed vmdk to vdi, since vdi is VirtualBox native, but either should work.

edit2: looks like I might be wrong, and Miuramir is right; the growing-size files might not work with images created from physical disks.

[Miuramir]

Right now, I don't quite feel comfortable cloning my linux partition over to my laptop since it would eat a good portion of the space I have left on the drive.  I'm not remotely using the 500GBs of the main Linux partition, but I also have no idea if there's a way to remove some of the free space from that so that the partition becomes manageable as a movable critter. 

*If* CloneZilla will recognize all the parts of your setup correctly, it has options to create a compressed backup file that only takes up space based on the actually used space of a partition.  This is not perfect in several respects, but it's a good option to quickly get a disaster recovery backup someplace other than that one physical (external) drive.  This would avoid any fiddling around with the working drive (read-only process); the parted (gparted) option mentioned above is theoretically possible, but riskier. 

Going forward, the obvious options are to get the drive's setup migrated to a VM, or to set up a Docker arrangement for the process.  Migrating a physical drive to a VM usually requires as much space as the original drive by default, so getting a backup before fiddling around with parted is a good idea. 

[Khym Chanur]

cloud suggestions: Just not putting it online, unfortunately.

For backup purposes you could encrypt the drive image before putting online, if you're worried about other people getting your hands on the source.  And speaking of that, I hope you've already done something like that for offsite backup of the source code.

[thewonderidiot]

So if you have 500GB of free space available to create the image in the first place, it appears to be possible to compact a VDI disk image after you make it.

VBoxManage.exe modifymedium --compact c:\path\to\thedisk.vdi

It works best if the unused space is explicitly zeroed from inside the VM before running that command; discussion for how to do so can be found here:
https://superuser.com/questions/529149/how-to-compact-virtualboxs-vdi-file-size?answertab=votes#tab-top

[soulsource]

Regarding the latest Linux build: The archive includes the file df_linux/libs/libstdc++.so.6, which shouldn't be packaged together with software, as doing so causes compatibility problems with system libraries linked against a newer libstdc++ version. In other words: On distributions built against a newer libstdc++ ABI, one needs to delete said file from the dwarf fortress installation (or use some other way to force the game to use the system installed libstdc++, like LD_PRELOAD) in order to get the game to work.

It might be a good idea to force the build to use an older ABI instead of bundling libstdc++. See the documentation for details.

[Max™]

The only thing arch needs is the df executable, libgraphics.so, and--a hotlink to the probably already installed--libpng.so.3 to work just fine. I'm not sure why libstdc++ or libgcc are in there at all, which goes for the entire g_src folder too.

I just copied over the new df and libgraphics.so files into my old .df libs folder, the index stuff in data, and made the raw changes.

[Insert_Gnome_Here]

Code: [Select]

df_linux/libs/Dwarf_Fortress: /home/charlie/df_linux/libs/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /lib64/libGLU.so.1) 
Anyone know how I fix this? The file's there in the correct folder.

[ShimmerFairy]

Code: [Select]

df_linux/libs/Dwarf_Fortress: /home/charlie/df_linux/libs/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /lib64/libGLU.so.1) 
Anyone know how I fix this? The file's there in the correct folder.

It's kinda funny to see this problem come up right after the previous couple of posts. Anyway, try deleting the libstdc++.so.6 library from df_linux/libs. The fact that it comes with DF is honestly a mistake, and it should never be there.

[Insert_Gnome_Here]

Thanks. Solved now.

[Lightman]

It's probably best to leave things alone until next year. After things settle down, you can look into a permanent VM or a Docker setup.

cloud suggestions: Just not putting it online, unfortunately.

In my humble opinion, that's a wise decision and not unfortunate.

[lethosor]

Regarding the latest Linux build: The archive includes the file df_linux/libs/libstdc++.so.6, which shouldn't be packaged together with software, as doing so causes compatibility problems with system libraries linked against a newer libstdc++ version. In other words: On distributions built against a newer libstdc++ ABI, one needs to delete said file from the dwarf fortress installation (or use some other way to force the game to use the system installed libstdc++, like LD_PRELOAD) in order to get the game to work.

The problem is that on distributions with an older libstdc++, DF needs that included or it won't work at all. (At least that was the case back in the 0.31 days, which is why that was included in the first place.)