[11:07] <fivetwentysix> The russians are abusing my postfix server
[11:11] <fivetwentysix> YES! I win!
[11:11] <fivetwentysix> postqueue -p
[11:11] <fivetwentysix> Mail queue is empty
[11:12] <fivetwentysix> Down from 23430424 emails
[11:12] <fivetwentysix> lol
[11:24] <Sachiru> LOL
[11:24] <Sachiru> GJ
[16:28] <Valduare> hmm
[16:29] <Valduare> if I make an image of a drive will it do just the used space or the entire drive partition size
[16:29] <qman__> imaging takes an exact bit copy of everything, including free space
[16:29] <qman__> imaging is rarely if ever required and usually not the best choice
[16:30] <Valduare> k ty
[16:58] <Valduare> qman__: I got a windows laptop here thats got a failing hard drive
[16:59] <Valduare> still readable data
[16:59] <Valduare> takes half hour to boot to windows so I was thinking of taking a copy of the hd before going further
[17:00] <qman__> Valduare: you should use gnu ddrescue
[17:00] <cfhowlett> Valduare, stop booting.  it's failing with each read/write.  get thee to a backup solution immediately
[17:00] <qman__> get a new hard drive to copy it to, or take an image if you have to, but use gnu ddrescue to make a recovery image
[17:00] <Valduare> im booted into ubuntu live cd atm
[17:00] <Valduare> havnt heard of gnu ddrescue
[17:00] <Valduare> looking it up now
[17:01] <Valduare> is it a direct 1to1 solution
[17:01] <Valduare> ie I need to have the new hd available
[17:01] <qman__> the short of it: ddrescue -f -n /dev/sda /dev/sdb /tmp/rescue.log
[17:01] <qman__> you should, that's the best way to do it
[17:01] <qman__> but you don't have to, you can do to a file if required
[17:02] <qman__> it won't be compressed though
[17:02] <qman__> and it will be an exact 1:1 copy of everything it was capable of recoverin
[17:03] <Valduare> just the used space right?
[17:03] <qman__> all the space, total size of the disk
[17:03] <Valduare> prob with these huge 1 terabyte hds lol
[17:03] <Valduare> damn
[17:04] <Valduare> so what if im wanting to go from a 1 terabyte platter drive to a 256 ssd
[17:04] <qman__> can't do it
[17:04] <Valduare> there’s only 71 gigs used space on the 1 terabyte drive
[17:04] <cfhowlett> qman__, as you're clearly better informed than I ... I buy a new computer.  I'm going to do some experimental things.  I want to image the drive in case I need to restore it to virginal status.  How to proceed?  does the backup include the empty space on the drive?
[17:04] <qman__> the recovery drive must be as large or larger than the failing drive
[17:04] <qman__> once you have recoered the data, you can then move it to a smaller drive
[17:05] <qman__> the recovery tools are filesystem agnostic, because they have to be
[17:05] <qman__> so they cannot recognize what matters and what doesn't
[17:06] <qman__> you should turn off the system with the failing drive and wait until you can get a same size or larger drive to recover to
[17:07] <qman__> cfhowlett: imaging is not a good backup solution, file backups are more space efficient, faster to take, faster to recover, and avoid fragmentation
[17:07] <Valduare> its fine to have it booted up into ubuntu live cd
[17:07] <Valduare> hd isnt accessed
[17:07] <qman__> no, it isn't
[17:08] <qman__> as long as that drive is spinning, it could die completely
[17:08] <qman__> shut down, unplug the drive
[17:08] <Valduare> we’re not completely sure “what kind of dieing” the hd is
[17:08] <cfhowlett> Valduare, yep.  this ^^^
[17:08] <qman__> it doesn't matter what kind
[17:08] <qman__> cut power until you can recover
[17:08] <qman__> that's the safest bet, always
[17:08] <cfhowlett> Valduare, assume the worst kind, assume the worst time and proceed from there.
[17:11] <qman__> cfhowlett: imaging is best for forensics, and as you see here, recovering from a failing hard drive
[17:12] <cfhowlett> qman__, fair enough.  I'll research more.  my goal was to restore "reset" to pre-me mucking about status.
[17:12] <qman__> cfhowlett: an image will be a 100% bit-for-bit copy, including fragemntation, noise in your free space, your empty free space, and all
[17:12] <Valduare> read error rate 136
[17:13] <qman__> Valduare: stop messing with it, shut down, and unplug the disk until such time as you have another 1TB or larger disk to recover to; every second you spend with it spinning increases chances of total failure
[17:13] <Valduare> its doing a compressed backup to an external hd atm
[17:17] <qman__> cfhowlett: if it has to be _exactly_ the same, an image is the way to go, but be aware of the downsides; most of the time, things don't actually need to be exactly the same
[17:17] <cfhowlett> qman__, thank you much.
[17:31] <Valduare> looks like 1 terabyte platter drive 85 at best buy
[17:31] <Valduare> guess i’ll go that route instead of the ssd for their laptop heh
[17:44] <RoyK> gnu ddrescue rocks
[17:44] <RoyK> I once got a drive from a user that couldn't be mounted on any OS i tried it on
[17:45] <RoyK> it took gnu ddrescue a little less than a week to recover 99,8% of the data
[17:47] <cfhowlett> RoyK, 24 x 7 for a week?  hardcore!
[17:47] <RoyK> 500GB
[17:48] <RoyK> 24x5.5 or thereabouts
[17:48] <RoyK> (24x7 for a week doesn't make sense - a week for a week :P)
[17:52] <qman__> yeah, I had one that kept turning off
[17:52] <qman__> but if I power cycled it, it would spin back up
[17:52] <qman__> repeated that for about a week and a half, got well over 99% of the data, enough to recover
[17:53] <qman__> less than a megabyte was lost
[21:15] <blaaa> I have just restarted a server remotely after a firmware update, but the network is not coming up. I have no terminal unfortunately.... the only thing I can see is the network interfaces are actually coming up at post, but they are shut down at some point while ubuntu is booting
[21:16] <bekks> you need some terminal or console access to investigate that issue.
[21:18] <blaaa> bekks: that's probably true, but some hypothesis on what could have caused this would be nice... before I'll be on my way.
[21:18] <blaaa> bekks: I think maybe the issue is caused by renamed interfaces after the fw update
[21:19] <blaaa> i think NIC interface names might not be persistent if some enumeration has changed, is that right?
[21:29] <qman__> blaaa: the interface names are based on MAC address
[21:30] <qman__> blaaa: a boot failure is much more likely - by default, if it fails to boot once, grub will wait indefinitely the second time around
[21:30] <qman__> blaaa: an fsck or failure to mount something could also be at issue
[21:39] <blaaa> qman__: thanks, i'll have to go and see I suppose. After the firmware update the computer booted fine (but I had not tested the network, not even attached it....) and it did a clean acpi shutdown after a complete boot
[21:43] <RoyK> qman__: do you know how to configure grub to stop that nonesense?
[21:44] <RoyK> nonsense, even
[21:44] <blaaa> RoyK: there is some option in the config
[21:44] <blaaa> RoyK: don;t remember what it is right now though
[21:45] <blaaa> had looked it up when setting up the server...
[21:46] <qman__> RoyK: I have, I looked it up before
[21:46] <qman__> It was causing me issues with some ebayed supermicro servers that rarely boot the first time
[21:46] <qman__> http://askubuntu.com/questions/178091/how-to-disable-grubs-menu-from-showing-up-after-failed-boot
[21:46] <blaaa> was it GRUB_RECORDFAIL_TIMEOUT ?
[21:47] <qman__> yes
[21:47] <blaaa> yes, apparently
[21:47] <RoyK> qman__: thanks
[22:16] <blaaa> lucky the server is not far away...
[22:17] <blaaa> apparently the interface name had changed
[22:17] <blaaa> from p1p2 to eth0
[22:17] <blaaa> p2p1...
[22:18] <blaaa> but I have no idea why, except for a fw update and reboot-cycle nothing had changed
[22:18] <blaaa> and I believed the point of the new naming scheme was to have persistent names...
[22:32] <furkan> i've got a question about grub: i'm running 14.04 in a VM, and i modify /boot/grub/menu.lst to add a virtual serial port so that i can console in with virsh, and whenever there's a new kernel installed it likes to update menu.lst and overwrite my 2 lines - any way i can avoid this?
[22:32] <furkan> these are simply the 2 lines that i put in:
[22:32] <JanC> furkan: sre
[22:32] <furkan> serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
[22:33] <furkan> terminal --timeout=10 serial console
[22:33] <JanC> sure
[22:33] <furkan> JanC: i'm all ears :)
[22:34] <furkan> i noticed the /etc/grub.d/40_custom file but wasn't sure if that was the right place to put it since it said custom menu entries
[22:34] <JanC> it's explained in the manual AFAIK, but you need to put it in a script in /etc/grub.d/
[22:35] <JanC> those scripts get run as part of update-grub
[22:36] <furkan> so when i run update-grub is it supposed to get copied into menu.lst?
[22:36] <furkan> since i just tried putting it there and it doesn't seem to do that
[22:36] <JanC> the output of those scripts gets copied to menu.lst
[22:37] <JanC> so yes, you need to run update-grub
[22:38] <furkan> man i'm confused, on my desktop 14.04 i've got grub2 but i guess the server version is still using the old one
[22:38] <JanC> oh
[22:38] <JanC> you sure?
[22:38] <JanC> Amazon?
[22:38] <furkan> no well this used to be a 12.04 VM
[22:38] <furkan> and then i upgraded to 14.04
[22:38] <furkan> is grub2 default in ubuntu server 14.04?
[22:39] <JanC> grub2 was the default in 10.04 and before
[22:39] <furkan> hmm maybe because i used vmbuilder
[22:40] <JanC> but IIRC there is/was some issue with Amazon cloud images not working with that (never needed that)
[22:40] <furkan> ya this is on our own server, not amazon
[22:41] <furkan> we've got a bare metal running 14.04 + a few 14.04 VMs running some services
[22:41] <JanC> it's still possible that it is/was used in cloud images though?
[22:42] <furkan> i built the image with vmbuilder for 12.04... so whatever that does by default i guess
[22:43] <furkan> but yeah i guess this is sort of odd since /etc/grub.d seems to be for grub2 only
[22:43] <JanC> that's right
[22:44] <furkan> i wonder if anything will break if i upgrade
[22:47] <furkan> so for grub2 it looks like the right place to put the serial console stuff is in /etc/default/grub
[22:47] <furkan> unless that's the same thing as just putting it in the custom file
[22:49] <JanC> not the same thing
[22:49] <JanC> the variables you set in /etc/default/grub are used by the scripts in /etc/grub.d/
[22:50] <furkan> ah i see, interesting
[22:50] <furkan> thanks for the info :)
[22:53] <JanC> it's interesting to read those scripts in /etc/grub.d/ some time  :)