RSS Atom Add a new post titled:
Expediently migrating Gentoo to Funtoo

Become root and follow these steps:

  1. As root, Run:

    cd /usr
    mv portage portage.old
    git clone https://github.com/funtoo/ports-2012 portage
    
  2. Make these changes to /etc/portage/make.conf:

    SYNC="https://github.com/funtoo/ports-2012"
    # These were suddenly needed when migrating to Funtoo.
    # You can pick any version of python that's available in the portage tree.
    # Once portage is upgraded, /etc/portage/make.profile/parent should take care of these.
    USE="$USE python_abis_2.7 python_abis_3.3"
    PYTHON_ABIS="2.7 3.3"
    
  3. Upgrade portage:

    emerge -1 portage
    
  4. Edit selected profiles in /etc/portage/make.profile/parent . This is normally done using eselect profile, but that's not possible at this stage of the process.

    gentoo:funtoo/1.0/linux-gnu/arch/x86-64bit
    gentoo:funtoo/1.0/linux-gnu/build/stable
    gentoo:funtoo/1.0/linux-gnu/flavor/core
    
  5. Upgrade everything else. This will likely intially fail, unless the installed packages haven't been upgraded in some time.

    emerge -auND --autounmask-write @world
    
  6. If the above fails because of conflicts, look at them and asses whether they're unlikely to cause problems, since they're very close (version-wise) or non-essential. If so, just add --nodeps to the above command and rerun.

  7. If that also fails, re-edit /etc/portage/make.profile/parent and try using "current" or "experimental" instead of "stable", then retry the subsequent steps.

Here be Dragons

The preceding is a simplistic rendition of the process I actually underwent. If you want to attempt it, be prepared for the horror of the dependency-hell you're about to enter. If you manage to endure the experience, I can assure you that by the end, you'll have a much better understanding of emerge/portage.

Migrating the Win7 Bootloader

Here's a common scenario I encounter: I copy the contents of the Win7 installation ISO to a small ntfs partition on the disk I intend to install Windows to, boot into Windows setup, and install. During setup, Win7 uses this ISO partition as the boot partition that chainloads the real system partition. While this configuration boots, one can not install Win7SP1, for instance, because "bcdedit /enum" can't find the BCD entries.

Changing this without booting to WinPE is almost completely undocumented; the prevailing solution is to delete the ISO partition and repair using the DVD. This is 2013. I'm not going to use a DVD or any other boot media. Expecting that getting "bcdedit /enum" to not fail outright would fix this condition led me to a solution that doesn't require booting into another environment.

My solution, briefly:

  1. Copy the \boot from the ISO partition (e,g, D:) to c:\boot
  2. Destroy the ISO partition
  3. Use bcdedit /store c:\boot\bcd to tweak the values (Chiefly, fix the boot partition from D: to C:).
  4. In regedit, load c:\boot\bcd as a hive named BCD00000000 in HKLM
  5. Add to the regkey "HKLM\BCD00000000\Description" a value: name "TreatAsSystem", type REG_DWORD, value 0x1
  6. In HKLM\SYSTEM\CurrentControlSet\Control\hivelist, add value: name "\REGISTRY\MACHINE\BCD00000000", type REG_SZ, value "\Device\HarddiskVolume1\boot\bcd", where HarddiskVolume is the correctly numbered (see sibling values for hints).
  7. Test that "bcdedit /enum" works
  8. Reboot to C: rather than D: (I was using grub anyway)

(I discovered that the changes to hivelist are not persisted; I need to find out why)

The Windows boot process is madness. Here's hoping UEFI relegates all this nonsense.

Booting a Physical Win7 Installation in VMware Workstation

Assuming you've got a VM configured with the physical disks mapped in as LSI SCSI, these are the registry entries you need to tweak:

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LSI_SAS]
"Start"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LSI_SAS2]
"Start"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LSI_SCSI]
"Start"=dword:00000000

YMMV; Basically, just set "Start"=0 to enable boot-time loading for as many LSI/SCSI drivers that might seem necessary. Probably only 1 or 2 of these are essential, I just guessed this set on my first attempt. This will prevent the lovely BSOD STOP 7B errors Windows loves to throw at you when booting the VM.

Steam for Linux in Debian

In short, the easiest way is to use debootstrap to setup a ubuntu precise chroot environment, then use that to run Steam. I got this working in the actual "wheezy" distribution of Debian.

Prerequisites:

  • resolvconf installed in base OS (chroot env will depend on the resolv.conf file it maintains in /run)
  • DRI enabled in xorg.conf

Steps:

  1. apt-get install debootstrap
  2. sudo debootstrap precise ubuntu_steam_chroot http://mirrors.xmission.com/ubuntu
  3. for x in dev sys proc run tmp; do sudo mount -o bind /$x ubuntu_steam_chroot/$x; done
  4. sudo chroot ubuntu_steam_chroot, and within it:

    a. echo 'deb [arch=i386] http://repo.steampowered.com/steam precise steam' > /etc/apt/sources.list.d/steam.list a. apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F24AEA9FB05498B7 a. apt-get update a. apt-get install steam language-pack-en. The language pack just eliminates annoying locale errors. a. exit

  5. sudo chroot ubuntu_steam_chroot steam to launch. Remember to redo the bind mounts every reboot!

Call to Arms

Men of War was one of my favorite RTS games. Now the same devs are crowdfunding the modern-day sequel: http://www.digitalmindsoft.eu/products/call-to-arms . It goes without saying that I'd like to see it get funded. The series has never really had a very well-balanced, competitive multiplayer, but the realism and environmental destruction combined with the direct control mechanic has distinguished it from mainstream RTS offerings and made it a lot of fun to play casually. The coop was always enjoyable too, overcoming ridiculous odds and turning the enemy's resources against them.

This blog is powered by ikiwiki.