Search Results: "ossama"

29 May 2017

Enrico Zini: Egg-walking with qemu-nbd and kpartx

I wanted to retrieve a file from a VirtualBox VDI image for this blog post. I followed these instructions and ended up here:
Once having used nbd0, only rebooting the system makes it possible to mount another image ... a little bit unpractical.
What happened was this:
# modprobe nbd  # NOO! Don't *EVER* do that!
# qemu-nbd -c /dev/nbd0 file.vdi
# kpartx -d /dev/nbd0
# mount /dev/nbd0  EHI! Where's /dev/nbdpp1 ??
# qemu-nbd -d /dev/nbd0
# rmmod nbd
rmmod: ERROR: Module nbd is in use
# kpartx -d /dev/nbd0
read error, sector 0
llseek error
llseek error
llseek error
# rmmod nbd
rmmod: ERROR: Module nbd is in use
# WHAT THE 
It turns out it's really modprobe nbd max_part=16, otherwise max_part defaults to, uhm, zero? really? and kpartx cannot create device mappings because there are not enough (as in, not even a single one) partition devices available. At this point, however, kpartx did create some mappings connected to, uhm, probably Ancient Beings from beyond spacetime, and because of those the device is in use and cannot be removed, and unmapping doesn't work either because the Ancient Beings from beyond spacetime are keeping the device busy by feeding on it. I energized the pentacle and tried a desperate ritual of banishment:
# # Reconnect nbd0 to the vdi file to Restore the Balance
# qemu-nbd --verbose -c /dev/nbd0 file.vdi
# # This works now
# kpartx -vd /dev/nbd0
del devmap : nbd0p5
del devmap : nbd0p2
del devmap : nbd0p1
# # This too, the Ancient Beings lie asleep yet again
# modprobe nbd -r
At this point I managed to get my file, almost:
# modprobe nbd max_part=16
# qemu-nbd --verbose -c /dev/nbd0 file.vdi
NBD device /dev/nbd0 is now connected to file.vdi
# kpartx -va /dev/nbd0
add map nbd0p1 (254:12): 0 60260352 linear 43:0 2048
add map nbd0p2 (254:13): 0 2 linear 43:0 60264446
add map nbd0p5 (254:14): 0 2648064 linear 43:0 60264448
# mount /dev/nbd0p1 /mnt
mount: /dev/nbd0p1 is already mounted or /mnt busy
# # WHAT NOW?!
# lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
 
nbd0                                        43:0    0    30G  0 disk
 nbd0p1                                    43:1    0  28.8G  0 part
 nbd0p2                                    43:2    0     1K  0 part
 nbd0p5                                    43:5    0   1.3G  0 part
 nbd0p1                                   254:12   0  28.8G  0 part
 nbd0p2                                   254:13   0     1K  0 part
 nbd0p5                                   254:14   0   1.3G  0 part
# # WHAAAT?!!
# kpartx -vd /dev/nbd0
del devmap : nbd0p5
del devmap : nbd0p2
del devmap : nbd0p1
# lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
 
nbd0                                        43:0    0    30G  0 disk
 nbd0p1                                    43:1    0  28.8G  0 part
 nbd0p2                                    43:2    0     1K  0 part
 nbd0p5                                    43:5    0   1.3G  0 part
# mount /dev/nbd0p1 /mnt
# # I got my file, my preciouss file!
# umount /mnt
# kpartx -vd /dev/nbd0
# qemu-nbd -d /dev/nbd0
# rmmod nbd
# # sit in a corner hugging my precious file and sobbing quietly
As can be seen from the multiple exclamation marks, those Ancient Beings from beyond spacetime did manage to have a bite on my sanity after all.

4 May 2006

Jonathan McDowell: Xinit considered harmful.

Last year Black Cat decided they wanted to be more organised about offering dedicated servers. We already had a rackful but they were all in use. So we looked around for a suitable supplier. Originally Dell were the front runner; although they have a bad reputation we already had a bunch of machines from them and they'd been reasonable reliable, did serial BIOS properly and were competitively priced. Dom pointed out that having hotswap drive bays would be a really good plan; we'd already specced the machines with dual drives to enable RAID1, but if they were hotswap then we could easily move drives into a spare chassis in the event something went wrong, meaning the customer could be back up and running again quickly while we investigated the old machine. Good plan. This started to push Dell into ridiculous pricing, so we had a look around. We had some machines from Xinit, which again we hadn't had issues with. They were able to give us a price that wasn't that different to the non hotswap Dells, so we decided to go ahead with them. Bad move. On September 6th I informed them we wanted to go ahead. They'd quoted us a 10-14 working day lead time. As we didn't have a credit account already set up with them and it was likely to take a while to sort out we said we'd pay up front in the interest of getting things moving as quickly as possible. By September 22nd we still hadn't heard anything from them, like even confirmation that payment had been received and an ETA for delivery. So I contacted them, received confirmation they'd received full payment by September 13th and was told we should see systems by September 30th or October 3rd at worst. On September 26th they emailed to say there was a problem with their shipment and we'd be receiving a part shipment with the rest to follow. 4 servers were delivered on October 12th. It turned out none of them had been configured as requested (serial console, 9600 8n1, all set to auto power on after power failure), so I ended up having to plug a monitor and keyboard into each machine before connecting it up to the serial console server and power cycler. I chased Xinit again on 24th October. They'd claimed a 5th server was to be delivered before that and still hadn't told me anything about the remaining 15. I was not impressed. A new contact got back in touch and made all manner of apologies and promises about keeping in better contact and keeping me up to date with what was happening. Suffice to say this didn't happen, and calls to the main Xinit number were of no use as no one could help, and the mobile number I'd been given for this contact was unanswered more often than not. On 1st November we received another 11 machines. These were at least configured as requested, but during our testing we discovered they had been misassembled. 5 machines had CPU heatsinks put on incorrectly; visually misaligned and such that any load caused a machine crash. Very unimpressive from a company who supposedly does full burn in tests on machines before shipping them (and indeed used this as an excuse for not shipping us machines sooner on occasion). Further chasing didn't have much effect, but we eventually received the remaining servers on December 5th. Nearly 3 months after we initially placed the order. While Xinit have happily provided many platitudes they have failed to address the numerous failings in their organisation. They are appalling at responding to phone calls or email. They continuously fail to make good on any of the promises they make. They can't provide realistic delivery dates and don't have the decency to get in contact and let you know when they're going to miss them. They have proved unable to assembly machines to any level of competence; most of what they do is buy in chassis and fit parts to them - this is not complicated and yet they managed to get it wrong on several of the machines we ordered. We were promised a machine or two in compensation, but of course these never arrived. In addition, they're so badly organised that in the middle of March we received a spam from one of their sales people who was completely unaware we'd been customers of them! I cannot stress how much you should never consider using this company. I've spoken to others who've bought machines from them or had dealings with them and I know I'm not alone in this. Really. Don't do it. You'll regret it. I suspect it would have taken less of my time and energy to buy all the parts and assemble the machines myself. I wish I'd done so instead. This does leave me lacking a hardware supplier however. We're in the position of needing more machines, but given recent power pricing increases Xeon LVs (the new Sossaman cores) look like the way forward. Except no one appears to have any stock. And even if they do, how do I know I won't get my fingers burned again?