Cognitive Tools

After spending an extraordinary amount of time trying to figure out why I couldn’t get NTFSResize to work, I finally found Seppe vanden Broucke’s log entry. For posterity, I’ll record what I did, here, following partly the instructions in the original post and one commenter’s modification:

1. Get the SysRescCD ISO image. (Any live linux CD should work, including Knoppix.)
2. Create a new (larger) VirtualBox disk image (*.vdi) from within VirtualBox.
3. In the VirtualBox Details tab for your Windows instance, set your original VDI as the IDE Primary Master.
4. Set the new (empty) VDI as the IDE Primary Slave.
5. And set the linux ISO as the CD/DVD IDE Secondary Master.
6. Ensure that the instance is set to boot from the CD/DVD first in System->Boot Order.
7. Boot the instance.
8. At the command line, run
   fdisk -l /dev/sda
   You should see a partition there of type 7, NTFS.
9. Then run
   fdisk -l /dev/sdb
   You should see an error message that says there is no partition on that device.
10. Then run the command:
    dd if=/dev/sda of=/dev/sdb
    This will take a long time. It means copy from the input file /dev/sda to the output file /dev/sdb.
11. Shutdown the system with:
    shutdown -h now
12. Change the Storage->IDE Secondary Master (CD/DVD) from the ISO image to your regular optical drive, or remove it completely so that it will boot into the original (small) Windows image.
13. In Windows, select Start->Run… and type:
    diskpart.exe
14. Type:
    select disk 1
    to select the (large) disk.
15. Type:
    list disk
    to see that you’ve selected the right one with the right size.
16. Type:
    select partition 1
    to select the 1st partition on that disk.
17. Type:
    list partition
    to see that you’ve selected the right partition.
18. Type:
    extend
    to extend the volume all the way to the end of the device.
19. Turn off the virtual instance and select the new (larger) VDI as the Storage->IDE Primary Master.
20. Boot the instance again and you should have a larger system (C:) disk.

Foobarred is Normal

Recently I started using my linux laptop as my primary avr-usb development environment. When I upgraded the laptop to the current Ubuntu-LTS release (10.4 aka Lucid lynx) a bunch of stuff was broken including all of the wonderful udev rules provided by my linux savvy friends at dorkbotpdx.

I mean jeesh even lsusb was broken.

$ lsusb -vd "03eb:"|grep iM
cannot read device status, Operation not permitted (1)
iManufacturer           1

When I started looking at what changed and how to adjust, the web dead ended to a lot of threads like the one at http://ubuntuforums.org/showthread.php?t=1360412 ; where two people declared that having to escalate privileges to root in order to talk to a user device was “normal”. Even when the developer said it wasn’t normal the ubuntu folk redeclared it normal (apparently after Bush you just have to repeat something blatantly stupid for it to be true). As an administrator the last thing you want is everything and its dog requiring root privileges.

Hanging around the #ubuntu channel was a lot like having people repeat the searches on the web that provided me with the same dead ends that I joined the channel trying to resolve.

Cherchez la femme (look at the squeeze)

This was getting stupid. All I wanted to do was to have devices that I could plug in and program and then communicate with them using ruby or perl or some other haphazzardly thrown together scripts without having to be root. Then I realized once again that ubuntu is really focused on making the users life easier and that this leads to a lot of non technical help. So I asked my friends what the nick name was for the Debian release that was the basis for the Ubuntu release nick named “Lucid” and then re did all of my dead ended web queries replacing “Ubuntu Lucid” with “Debian Squeeze”.

The results were heavy on the technical detail and light on social skills.

More importantly I quickly found the solution that I needed in the middle of this link (http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=blob_plain&f=README&hb=HEAD) what I was missing was the difference between the new and the old udev rules.

“If you are running a newer version of udev (as in Debian Squeeze and
Ubuntu 9.10), you need to adapt the rules-file to the new udev-version:
sed -i -e ’s/TEMPNODE/tempnode/’ -e ’s/SYSFS/ATTRS/g’ -e ’s/BUS/SUBSYSTEMS/’ \
/etc/udev/rules.d/xusbdfwu.rules”

One line of sed was all I needed and it had taken me a week of asking about lucid when i should have been asking about squeeze. With this I also was able to find the changes to the lay out of the /dev and /proc trees and the new tools to monitor udev and diagnose issues.

All-Your-Atmel-Belong to Us

I really just wanted to change the permissions so I could use my devices. Adding the following udev rule to your system will do just that.  You will also need to restart the udev service. Both of these will require you to be root.

# cat >/etc/udev/rules.d/98-all-your-atmel-belong-to-us.rules<<EOF
#------------------------/etc/udev/rules.d/98-all-your-atmel-belong-to-us.rules
#
# Make atmel devices (dfu, LUFA, obdev) accessible in userland
# 
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", MODE="0666"
EOF
# service udev restart

To actually own all my atmel I could have also added ‘ ,USER=”don” ‘ after the mode part but I just wanted to talk my Atmel usb-avr devices and the open source firmware I was developing. And the above rule made things “just work”.

$ lsusb -vd "03eb:"|grep iM
iManufacturer           1 mycompany.com
$

This rule fixed all of my LUFA based devices including the my open source arduino programmer as well as the dfu programmer.used to code them. Hopefully it will be a while before I have to go through this again.

I remember when the kids decided that they wanted to adapt the unnecessarily complicated system V init system and I kissed the simple days goodbye (sometimes I miss early bsd/freebsd and sometimes i miss it alot). Nowadays even the sysv-init isnt complicated enough. We gotta have upstart.

So after upgrading two systems to Lucid, I can tell you that most of the details have been well paid attention to, and a few problems we were having with 9.10 and hardy actually got solved. But there is still stuff that wasn’t broken that the kids just had to fix. So without further adeau I will tell you how to get gdm (and X) to go away after you have installed sysv-rc configured it to runlevel 3 (multiuser - no x) and its still there.

Setting the runtime.

If you have a working inittab the existing scripts will reference it so you can skip to how to get rid of gdm.

if you don’t you will find that the default runlevel is set to 2 (linux’s ‘user defined’ graphical runlevel since rc5 wasnt good enough for some reason) in /etc/init/rc-sysinit.conf. This should be changed to look like this.

# Default runlevel, this may be overriden on the kernel command-line
# or by faking an old /etc/inittab entry
env DEFAULT_RUNLEVEL=3

rebooting and typing “runlevel” should verify the change.

Why is gdm/X still running?

Beats the begebes out of me. But if you want it to stop you need to edit the /etc/init/gdm.conf and comment out the “start on” conditions and change them so that they correspond to the appropriate runlevel.

#start on (filesystem
#          and started dbus
#          and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
#               or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
#               or stopped udevtrigger))
start on runlevel [24]
stop on runlevel [0136]

Grubby.

If you don’t want gdm/x you probably don’t want the splash junk either. While /boot/grub/menu.lst allows you to set default options like nosplash every kernel upgrade i have done in the past year explicitly asks for quiet and splash way out at the end of each “kernel” line so just plan on hand editing the darned thing after each kernel update. I am sure you can uninstall splash but I prefer configuring things to keeping track of what needs to be uninstalled for a system to run correctly.

Damned Kids.

Hope this saves you some of your precious hair. All and all lucid (server and desktop) seems pretty sane and stable but they are still fixing things whether or not they were broken.

Dont even get me started on last weeks apparmor configuration update busting our dns.