[10:56] <ogra> hrm
[10:56] <ogra> with the latest dist-upgrade my babbage hangs somewhere in the init-bottom scripts
[11:37] <ogra> wow, i cant even chroot into the disk anymore from initramfs
[12:04] <armin76> you broke it
[12:06] <ogra> yeah, definately
[12:06] <ogra> no way to get it booting again
[13:21] <ogra> sigh
[13:24] <ogra> grrr and cdimage isnt reachable through rsync
[13:24]  * ogra goes mad
[13:35]  * persia provides ogra with a tea in which to dip himself
[13:55] <ogra> heh
[13:56] <ogra> i really dont get what broke it
[13:56] <ogra> looks like upstart hangs
[14:03] <persia> upstart hangs?
[14:03] <persia> Maybe set init to strace upstart? :)
[14:04] <ogra> well, if i boot without initramfs its hangs at Freeing init memory: 176K
[14:04] <ogra> no output afterwards at all
[14:09] <persia> OK.  What if you boot with init=/bin/bash without initramfs?
[14:09] <ogra> didnt try that yet, i'm just checking what updates come on a 1day old livefs
[14:09] <ogra> since it stopped booting after apt-get dist-upgrade
[14:10] <ogra> but there is nothing noticeable ...
[14:10] <ogra> i removed plymouth from disk already
[14:10] <ogra> busybox-initramfs cant be it since i did boot without initramfs
[14:10] <ogra> and the rest are desktop libs
[14:10] <persia> That shouldn't have done much: I heard it didn't work for non-intel FBs right now.
[14:11] <ogra> well, plars said he sees a splash
[14:11] <ogra> (on dove)
[14:11] <persia> I know.  I don't understand why.
[14:11] <persia> But slangasek said he didn't (on some non-intel x86 box)
[14:11] <persia> And that he was trying to sort it, and suspected it was intel-only.
[14:12] <persia> But my knowledge of plymouth stops after configure runs :)
[14:12] <ogra> http://paste.ubuntu.com/361263/ thats what apt-get dist-upgrade on a running livefs gets me
[14:12] <ogra> not sure what libbsd0 does
[14:13] <ogra> seems its in standard
[14:13] <persia> It's some random BSD-only stdlib stuff that doesn't appear in linux.
[14:14]  * ogra tries what happens if he uses the redboot setup from teh livefs to boot 
[14:14] <persia> I don't see anything there that should break it either :(
[14:16] <ogra> Begin: Running /scripts/init-bottom ...
[14:16] <ogra> Done.
[14:16] <ogra> hangs ...
[14:16] <ogra> the funbs stuff is, it doesnt actually hang hard or something
[14:17] <ogra> i have a cursor and pressing enter moves it on the screen
[14:18] <persia> Cool!
[14:18] <ogra> its just that init doesnt seem to proceed
[14:18] <persia> set -x ?
[14:18] <ogra> in init ?
[14:18] <ogra> its a binary, not a script
[14:18] <persia> Ah, I missed the "Done."
[14:19] <ogra> yeah
[14:19] <ogra> Freeing init memory: 176K doesnt show up if using an initramfs
[14:19] <ogra> i'll try /bin/bash
[14:20] <ogra> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
[14:20] <ogra> bash: no job control in this shell
[14:20] <ogra> root@(none):/#
[14:21] <ogra> works
[14:21] <persia> OK, so it's not the kernel.
[14:21] <ogra> no, else i wouldnt get into busybox either
[14:21] <ogra> i can properly break and the like
[14:22] <ogra> its also not uboot
[14:22] <ogra> since redboot shows the same bahavior
[14:22] <ogra> *be
[14:22] <persia> bootloader shouldn't be affecting anything post-kernel load anyway.
[14:23] <ogra> if the HW is wrongly initialized it does
[14:23] <ogra> else we wouldnt have issues with the NIC ion uboot :)
[14:23] <ogra> *in
[14:24] <persia> Well, that's HW interfaces.  I like to live in a happy little world where userspace apps just talk to each other.  Sometimes USB HID is permitted.
[14:25] <persia> But yeah, blame upstart.  See if there's some debug mode: perhaps you can get it to output which job it's trying when it hangs.
[14:26] <ogra> well, either upstart or the first script that runs or so
[14:26] <ogra> i dont get to fsck
[14:26] <ogra> and i dont see the mount /dev to none error message
[14:27] <persia> Right, but for both cases you need upstart debug messages.
[14:27] <persia> Or strace
[14:27] <ogra> gah, running dhclient in init=/bin/bash mode isnt such a good idea
[14:27] <persia> (can one strace init on boot?  That would be very helpful to determine the issue, since it's likely to be either exec(...) or some HW call.
[14:27] <ogra> no job control ... no ctrl-c
[14:27] <persia> heh.  No!
[14:28]  * ogra reboots
[14:28] <ogra> i think you can start init from bash in that setup somehow, Keybuk has magic commands for that
[14:28] <ogra> but i dont know them
[14:29] <ogra> oh
[14:29] <persia> `strace /sbin/init` ?
[14:29] <ogra> my mtab is totally messy
[14:30] <ogra> write(2, "init: Failed to connect to socke"..., 74init: Failed to connect to socket /com/ubuntu/upstart: Connection refused
[14:30] <ogra> ) = 74
[14:30] <ogra> pfft
[14:30] <persia> Try asking in #upstart.  Might be some leftover upstream around.
[14:31] <ogra> i can wait for monday too :)
[14:31] <ogra> i wouldnt see why upstart should suddenly stop working
[14:31] <ogra> especially since it works in the live image
[14:32] <persia> Are there any update-initramfs calls that happen with apt-get dist-upgrade?
[14:32] <ogra> yes, plymouth enforces them
[14:33] <ogra> but i'm currently booting a live initramfs
[14:33] <persia> Then get plymouth out before you upgrade, and see if that works.
[14:33] <ogra> already done
[14:33] <ogra> long ago
[14:33] <persia> mount, chroot :)
[14:33] <ogra> that was my first setp :)
[14:33] <ogra> *step
[14:33] <persia> Ah.
[14:33] <ogra> since indeed i did install plymouth yesterday
[14:33] <persia> But you've already messed up the initramfs.
[14:33] <ogra> and then ran a dist-upgrade later
[14:34] <persia> Thanks for that, by the way.  I'd think it'd be cool if it worked.
[14:34] <ogra> no, i have plenty of initramfses around
[14:34] <ogra> lots of backups
[14:34] <persia> Well, stuff in a working initramfs, and try to boot :)
[14:34] <ogra> its definately nothing in the initramfs
[14:34] <ogra> the live initramfs boots the live system just fine
[14:35] <ogra> so why shouldnt it boot my SATA disk
[14:35] <ogra> and in the livefs plymouth is the older version
[14:35] <persia> The *same* initramfs can't boot your drive?  Something is seriously wonky.
[14:35] <ogra> yes
[14:35] <ogra> but the issue has to be on the drive
[14:36]  * ogra removes the messy mtab
[14:36] <ogra> and rebbots ...
[14:37] <ogra> iirc the first thing that runs on boot is mountall
[14:38] <ogra> nope, mtab didnt help
[14:39] <asac_> hey ...
[14:39] <asac_> weekend reminder ;)
[14:39] <ogra> bah ..
[14:39] <ogra> fix my board and i can sleep tonight :)
[14:46] <ogra> root@(none):/# cat /etc/init/mountall.conf
[14:46] <ogra> root@(none):/#
[14:46] <ogra> hmm
[14:47] <persia> heh
[14:48] <asac_> ogra: you shouldnt have tried to upgrade just today ;)
[14:49] <asac_> j.k.
[14:49] <asac_> dont know whats going on
[14:49] <ogra> asac_, i left it running yesterday
[14:49] <asac_> still wrestling ffox
[14:49] <ogra> when i got up today i just wanted to take a look
[14:49] <ogra> Done.
[14:49] <ogra> mountall: Could not connect to Plymouth
[14:49] <ogra> fsck from util-linux-ng 2.16
[14:49] <ogra> e2fsck 1.41.9 (22-Aug-2009)
[14:49] <ogra> /dev/sda6: clean, 146974/2321984 files, 1007361/9277521 blocks
[14:49]  * ogra dances
[14:49] <ogra> finally !
[14:49] <asac_> cheers
[14:50] <asac_> https://edge.launchpad.net/ubuntu/lucid/+queue?queue_text=chromium-browser#
[14:50] <asac_> ;)
[14:50] <ogra> doesnt seem to move further though
[14:50] <asac_> archive admins are laggers :)
[14:50] <ogra> heh
[14:50] <asac_> 12h
[14:50] <asac_> ;)
[14:50] <ogra> hmm, i suspect there is more trashed in /etc/init/
[14:50] <ogra> crap
[14:55] <persia> asac_: None of the archive admins have signed up for saturday or sunday as archive admin days.  You'll probably have to wait until Monday.
[14:57] <asac_> i know
[14:58] <persia> So, how are they laggers?
[14:58] <persia> You could volunteer to be an archive admin :)
[14:58] <ogra> persia, they didnt approve it last night before finishing their day
[14:58] <persia> and then you could pick one of the unclaimed days ...
[14:58] <ogra> indeed they are laggers :)
[14:59]  * persia does a timezone check
[14:59] <ogra> it surely was in the queue for at least 1h before the last AA left :)
[14:59] <persia> Friday needs a backup archive-admin, it only has one.
[14:59] <persia> Tuesday would also qualify for a backup, but doesn't need one.
[15:20] <ogra> bah, i'll do a reinstall on monday ... there is more broken than i thought ...
[15:21] <ogra> always hitting the reset button when working on bootloaders doesnt do good to a filesystem :P
[15:21] <ogra> though i thought ext4 was more robust
[15:43] <asac_> ogra: what error are you getting?
[15:43] <asac_> my usb-storage issues also complained about ext4 issues
[15:44] <ogra> i havent got any errors
[15:44] <ogra> i have some zero byte files
[15:44] <ogra> but its to late now, i wiped the partition
[15:45] <ogra> i threatened the disk really hard the last two weeks though ... its no wonder that there are corrupted files
[15:45] <ogra> about 50 resets per day or so
[15:46] <ogra> never shot it down properly
[15:47] <ogra> asac_, our uboot installation will cause a lot more issues than we had yet btw
[15:48] <ogra> it just struck me that we need to teach ubiquity that /boot can *only* live on an SD card
[15:48] <ogra> i dont think there is any code in partman that could do that yet
[15:48] <ogra> that will be a huge task to implement
[15:49] <asac_> unless we also want to put the images directly to the boot floppy as a backup
[15:49] <ogra> well, still the "boot floppy" has to be the SD
[15:49] <asac_> no
[15:49] <asac_> well
[15:49] <asac_> yes
[15:49] <ogra> ?
[15:49] <ogra> the babbage can only boot from Sd or flash
[15:49] <asac_> not on fs ... just behind the master boot record
[15:49] <asac_> raw data
[15:50] <ogra> and flash is to small to hold more than a bootloader
[15:50] <asac_> so flash-kernel will do it
[15:50] <asac_> right
[15:50] <asac_> but how does redboot do it?
[15:50] <ogra> redboot doesnt cerate /boot
[15:50] <ogra> raw fis partition
[15:50] <asac_> but where does it put the stuff?
[15:50] <asac_> right
[15:50] <ogra> which we dont have
[15:50] <asac_> so thats the equivalent we could do as a fall back
[15:50] <ogra> with uboot
[15:51] <ogra> hrm
[15:51] <ogra> we already have a /boot partition
[15:51] <ogra> why use two
[15:51] <ogra> we need to re-use that /boot partition anyway
[15:51] <asac_> yes. what i mean is: make the non-fs data partition bigger and put it in there as raw data if we dont find it through the boot.scr looping
[15:51] <ogra> but we need to teach partman and ubiquity that this is the only option
[15:52] <asac_> does redboot support usb?
[15:52] <ogra> no
[15:52] <ogra> thats why we took the bootfloppy approach with it
[15:52] <asac_> anyway
[15:52] <ogra> uboot will just make everything a lot more complicated
[15:52] <asac_> ogra: right. i mean we can do both
[15:52] <asac_> would be waste sure
[15:52] <ogra> sure, but that doesnt go into flash-kernel
[15:52] <asac_> but if ubiquity fix is too hard
[15:53] <ogra> well, it has to go into ubiquity
[15:53] <asac_> flash-kernel updates the data in the fis partition, right?
[15:53] <ogra> right
[15:53] <ogra> and not right :)
[15:53] <asac_> thats waht flash-kernel would do for uboot ... just put it in the no-fs data
[15:53] <ogra> depends where you look at
[15:53] <asac_> ok
[15:53] <ogra> in the installer it uses the postinst from the package instead
[15:53] <ogra> that would be the complex part
[15:54] <ogra> additionally /boot as vfat in the installed system wont work
[15:54] <asac_> something else ... can we grep sed etc. something in hushshell?
[15:54] <ogra> i did some tests and update-initramfs gets very unhappy
[15:54] <asac_> e.g. basically parsing numberes out of command output?
[15:54] <ogra> no, no grep, no sed
[15:54] <ogra> hush only has loops and conditionals
[15:55] <ogra> and the test binary
[15:55] <asac_> i didnt expect them to be there ... just hoped it had some syntax for parsing stuff
[15:55] <asac_> ok
[15:55] <asac_> why do we go for uboot again?
[15:55] <asac_> ;)
[15:55] <ogra> because david wants it :P
[15:55] <asac_> whats his motivation?
[15:55] <ogra> he thinks we gain anything if we can put multiple kernels into /boot
[15:55] <asac_> i thoguth we told fsl to move there and now they moved there and we have to follow
[15:56] <ogra> which is very hard to do (not impossible though) with a fis partition
[15:56] <asac_> yeah i see that
[15:56] <ogra> you can do it indeed
[15:56] <ogra> but you wont be able to easily select
[15:56] <asac_> i mean the gain from multiple kernels
[15:56] <ogra> fallback
[15:56] <asac_> but we need framebuffer in uboot to make that really useful for normal users
[15:56] <ogra> also if you write to fis and power off the board, your bootloader setup is trashed
[15:57] <asac_> (as you properly mentioned at some point)
[15:57] <ogra> yeah
[15:57] <ogra> the power-off scenario is the one that bothers david most
[15:57] <asac_> thats true. imo you would just another set of fallback fis partitions
[15:57] <asac_> and then you have at least 2
[15:57] <ogra> but effectively, the more i work on our uboot i notice drawbacks
[15:57] <asac_> which should resolve that
[15:58] <ogra> uboot is definately slower in loading
[15:58] <asac_> well. uboot is buggy. that lets one think its all crap ;)
[15:58] <ogra> likely because of the FS inbetween
[15:58] <asac_> if it works and has usb support that would be great
[15:58] <ogra> yeah
[15:58] <ogra> i dont say its bad
[15:58] <asac_> ogra: uboot is probably slower because the mmc code is busted
[15:58] <asac_> loading the raw dat wasnt fast either
[15:58] <ogra> but loading kernel and initramfs takes abouot twice as long
[15:58] <asac_> i managed to load a 2M kernel with mmc read
[15:58] <asac_> and that took about 5 seconds (optimistically measured)
[15:59] <ogra> did you compare to redboot
[15:59] <asac_> but since we get hangs i wonder if thats really a generic mmc bug
[15:59] <asac_> yes, it should be really fast
[15:59] <asac_> < 1s
[15:59] <ogra> the time we load the kernel and initramfs the user sits in front of a black screen
[15:59] <asac_> there is something fishy with the mmc part i am 98% sure
[15:59] <ogra> i noticed i get impatient since  using uboot
[15:59] <ogra> i doubt that
[15:59] <ogra> you simply have an additional layer between you and the data
[15:59] <asac_> how can you doubt that? loading 2M with rad mmc read
[16:00] <asac_> taking 5 seconds means that the mmc driver is busted
[16:00] <asac_> ogra: i am not talking about fatload
[16:00] <ogra> hmm, k
[16:00] <ogra> with the 2009.01 uboot ?
[16:00] <asac_> do this: type mmc read 0x90008000 3000
[16:00] <asac_> or something
[16:00] <asac_> dont have help mmc at hand
[16:00] <ogra> i'm only takling about .01
[16:00] <asac_> ogra: i only tried it on .08
[16:00] <ogra> currently i cant, just running a reinstall
[16:01] <asac_> the blk number * 512 is the size
[16:01] <asac_> so 2048 is 1M
[16:01] <asac_> try to load that to some random address
[16:01] <asac_> if its fast then its fat
[16:01] <ogra> will do
[16:01] <ogra> we cant use fat in the installation anyway
[16:01] <asac_> we cant?
[16:01] <ogra> update-initramfs gets very unhappy
[16:02] <asac_> how?
[16:02] <asac_> we should fix that
[16:02] <ogra> it tries to do hardlinks in /boot for the backup files
[16:02] <asac_> isnt fat even included in default initram?
[16:02] <ogra> i'm talking about *update*-initramfs :)
[16:02] <ogra> not the initramfs itself
[16:03] <asac_> the hardlinks are temporary?
[16:03] <asac_> i dont se them in my /boot
[16:03] <ogra> yup
[16:03] <ogra> its during the .bak file creation
[16:03] <ogra> but surely has a speed reason that hardlinks are used
[16:04] <ogra> beyond that se should have vmlinuz and initrd.img symlinks that point to the current kernel
[16:04] <ogra> which isnt possible either on vfat
[16:04] <ogra> so during install we should reformat the SD /boot partition to ext2
[16:05] <ogra> which sadly means we wipe it, which in turn adds another risk like the power-off scenario david fears so much
[16:06] <ogra> (only during install indeed, not for every kernel update or re-rolled initramfs)
[16:06] <asac_> so dove uboot supports ext3/4 or what?
[16:06] <ogra> no, it uses ext2
[16:06] <ogra> but that can be anywhere (ide, usb, MMC)
[16:07] <asac_> but it uses fat on the live image?
[16:07] <ogra> and it doesnt re-use the installation media
[16:07] <asac_> or ext2 there too?
[16:07] <ogra> i think so
[16:07] <ogra> fat
[16:07] <ogra> but as i said, you dont re-use the same media
[16:07] <ogra> its differnt
[16:07] <asac_> we have at least 1 spare place for another partition on our live image in worst case
[16:08] <ogra> sure
[16:08] <ogra> but they will show up on your desktop :)
[16:08] <asac_> so we could simulate that, just that we have a special partition on the live disk because we cant do usb etc.
[16:08] <asac_> i will ask freescale whats up with usb support
[16:08] <asac_> maybe its really just filling in right numbers etc
[16:08] <ogra> far out ... last time i asked
[16:08] <ogra> no direver was written yet
[16:08] <asac_> hmm ok
[16:09] <ogra> but indeed we should ask
[16:09] <ogra> i asked at UDS time last time
[16:10] <asac_> maybe we should stop shipping images, but rather a image builder that allows to reproduce our exact "release" images and many more thing ;)
[16:11] <ogra> heh
[16:11] <ogra> that was the initial approach of rootstock
[16:11] <asac_> yes. something like that
[16:11] <asac_> just much more professional
[16:11] <ogra> that was the initial approach of rootstock :)
[16:11] <asac_> well ... professional in a way that i covers the whole stack
[16:11] <ogra> rotostock was only a quick first approach
[16:11] <asac_> from fs production to image for target device
[16:12] <asac_> i know
[16:12] <ogra> right
[16:12] <ogra> that were my plans
[16:12] <ogra> but they always fell over because of other more important specs
[16:12] <ogra> or because the images didnt work or... or ...
[16:12] <ogra> always something that stopped work on it
[16:12] <asac_> right. so we should kill the images and focus on that ;) j.k.
[16:13] <ogra> heh
[16:13] <asac_> but a good idea imo
[16:13] <ogra> we might be able next release, who knows
[16:13] <ogra> hrm, whats up with that installer
[16:13] <ogra> doesnt run
[16:13] <asac_> sigh
[16:14] <ogra> i thought partman was fixed
[16:14] <asac_> now that dove is fixed, imx51 is broken? ;)
[16:14] <ogra> its not arch specific
[16:14] <asac_> joking
[16:14] <ogra> the partman bug was there in A2 already
[16:15] <asac_> not sure if you were here still ... the images work again now ... the bootchartgui hangs  turned out to be triggered by outdated .pyc files of the previous python ;)
[16:16] <asac_> the import uno hang feels like its caused because of our libgcc3_uno.so.jaunty to me
[16:16] <asac_> which i found out is pulled in by that import
[16:17] <asac_> uno == ooo
[16:17] <asac_> dove really feels like a bloody minefield to me :-P
[16:17] <ogra> yeah, i read the backlog
[16:17] <ogra> it is
[16:18] <ogra> the prob is that the silicon often doesnt fulfill the actually promoted features
[16:18] <asac_> seems if everything is working right, then all is fine
[16:18] <asac_> but if stuff that isnt expected happens, it goes mad
[16:18] <ogra> imx51 has its own issues though
[16:18] <ogra> like being behind on kernel or software being not ready (see uboot)
[16:18] <asac_> too bad ... so the fact that there were still firefox packages in hardy/dapper didnt help
[16:19] <asac_> the source is in new :(
[16:19] <ogra> that hit us way harder in the last reelases
[16:19] <ogra> the luck with imx51 vs dove this time is that the silicon doesnt change anymore
[16:20] <ogra> so for you it feels like dove is a minefield :)
[16:20] <ogra> but it was both arches behaving like that in the last releases
[16:20] <asac_> yeah. i can bet that
[16:21] <asac_> i think we could have done better
[16:21] <asac_> doko for instance need both boards
[16:21] <asac_> if thta was the case he would have noticed that dove hangs before uploading the thumb2 switch
[16:21] <ogra> yeah
[16:21] <asac_> otherwise ncommander or someone else should have checked that
[16:21] <ogra> well, but thzumb2 was advertised by the vendor
[16:21] <asac_> ;)
[16:22] <ogra> so whom do you trust :)
[16:24] <ogra> grumble ...
[16:24] <ogra> install doesnt want to start
[16:31] <asac_> ogra: so how was lost?
[16:31] <asac_> ;)
[16:31] <ogra> great :)
[16:31] <asac_> is that on kabel 1?
[16:31] <ogra> yeah, the new episodes are on K!
[16:31] <ogra> K1
[16:31] <asac_> the new season starts while we are in portland :)
[16:31] <asac_> unfortunately final season
[16:32] <ogra> no, thats one season ahead of us
[16:32] <ogra> we have 5 here
[16:32] <asac_> yes, i am tracking US ;)
[16:32] <ogra> when we're in portland 6 starts in the US
[16:32] <ogra> ah
[16:32] <asac_> already have seen all ;)
[16:32] <ogra> heh
[16:32] <asac_> unforunately
[16:32] <asac_> but fortunately too
[16:32] <ogra> i'm pondering a HD+ reciever to watch them in HD
[16:32] <asac_> the voices are really better in original
[16:32] <ogra> as usual
[16:33] <ogra> but i watch them with susie
[16:33] <asac_> heh
[16:33] <ogra> he english doesnt suffice :)
[16:33] <asac_> i can give you the full collection ;)
[16:33] <ogra> but not dubbed :)
[16:33] <asac_> noo
[16:33] <asac_> subtitles are good for her ;)
[16:34] <ogra> heh
[16:34] <ogra> but i would have to type them
[16:34] <asac_> she has to catch up on reading chars compared to you ;)
[16:34] <ogra> heh
[16:34] <ogra> but i have to translate *and* to type
[16:34] <asac_> there are probably subtitles somewhere on the net
[16:35] <ogra> yeah, likely
[16:35] <ogra> too much effort though ...
[16:35] <asac_> just need to figure how to sync them with the tv broadcast ;)
[16:35] <asac_> so might be a bit off at first :)
[16:35] <ogra> my PVR is programmed and records it every week now
[16:35] <ogra> we'll just watch them if it fits
[16:36] <asac_> ah
[16:36] <asac_> does that cut out ads?
[16:36] <ogra> no, but it has a fast forward button :)
[16:37] <ogra> and timeshift
[16:37] <asac_> i wonder if chromium will have to go to non-free in debian
[16:37] <ogra> so for live TV i just have to start watching a little later
[16:37] <ogra> because of the licenses ?
[16:37] <asac_> they rejected my modemmanager upload because i didnt listed one copyright holder in the whole tree ;)
[16:37] <asac_> yes
[16:37] <ogra> heh
[16:37] <asac_> there are a bunch of files with just license, but without copyright holder
[16:38] <asac_> the licenses can be fixed with some effort
[16:38] <ogra> they will revoke your DD status one day
[16:38] <asac_> but the copyright owners will never be there
[16:38] <asac_> ogra: why?
[16:38] <ogra> "behaves to much like an ubuntu developer"
[16:38] <asac_> heh
[16:38] <asac_> well. i addressed the copyright issues and reuploaded modemmanager ;)
[16:39] <ogra> tony uploaded NM recently
[16:39] <asac_> i sponsored it
[16:39] <ogra> did he take it over now ?
[16:39] <asac_> no
[16:39] <asac_> i wanted him to drive that ... but it took ages :(
[16:39] <asac_> well we all are supposed together
[16:39] <asac_> the idea was to get it out 1 month after release ;)
[16:39] <ogra> well, he has other projects too
[16:40] <asac_> right
[16:40] <asac_> not complainig
[16:40] <asac_> just saying that he didnt take it over ;)
[16:40] <ogra> yeah
[16:40] <asac_> we have someone new though
[16:40] <ogra> ah, nice
[16:40] <asac_> but i guess he will be utilized enough with browser
[16:41] <asac_> and we need another for network
[16:41] <ogra> heh
[16:41] <ogra> yeah,m not everyone is insane like you
[16:41] <asac_> fortunately :)
[16:41] <ogra> hmm, my babbage SATA disk starts to rattle madly
[16:42] <ogra> i wonder if the installer now wipes my dev system too
[16:42] <ogra> (i picked side by side install this time, at least the installer does something with that setting)
[16:45] <asac_> do you see anything on the console?
[16:45] <ogra> nope
[16:45] <asac_> k
[16:45] <ogra> it checks the disk i think
[16:45] <ogra> just awfully slow
[16:45] <asac_> :(
[16:46] <ogra> i hope it doesnt try to resize the used space
[16:46] <asac_> what did you select?
[16:46] <ogra> that has my dev chroot
[16:46] <ogra> side by side
[16:46] <asac_> so fill up the rest of space?
[16:47] <ogra> didnt work
[16:47] <ogra> that was the one i tried before
[16:47] <ogra> oh, it moved
[16:48] <ogra> so lets see if the second stage starts this time
[16:50] <ogra> hmm, even though the disk rattles still and i see parted_server in the processlist, the second stage doesnt seem to want to start
[16:51] <ogra> well, i'll leave it running over night ... who knows i'll probably have a finished install tomorrow
[16:51] <asac_> sounds bad
[16:51] <ogra> else i'll take alternate ...
[16:51] <asac_> what size is the install partition?
[16:51] <ogra> 40gig or so
[16:51] <ogra> or even 50
[16:51] <asac_> do you know what its doing right now? fs creation?
[16:52] <ogra> rat .. rat ... rat ... rat ... rat ... rat ... rat
[16:52] <ogra> in a nice rhythm
[16:52] <ogra> nothing in the logs
[16:52] <asac_> that really sounds like my usb-storage issues ;)
[16:52] <asac_> cant you see dmest?
[16:52] <asac_> dmest
[16:52] <ogra> yeah, nothing in there
[16:52] <asac_> i hear rat .. rat ... rat ... rat ... rat ... rat ... rat too there ;)
[16:52] <ogra> well, i didnt have issues
[16:52] <ogra> until now
[16:53] <asac_> first it worked for me too
[16:53] <asac_> then it failed on lucid
[16:53] <ogra> it worked since A2
[16:53] <ogra> and before
[16:53] <asac_> right
[16:53] <asac_> i dont really think its the same
[16:53] <ogra> A2 was a complete reinstall though
[16:53] <asac_> what doest dmesg tell you ?
[16:53] <ogra> nothing
[16:53] <asac_> did it like the disk at all?
[16:54] <ogra> sure
[16:54] <asac_> can you hotplug and see what happens?
[16:54] <ogra> i have it in the partitioner too
[16:54] <ogra> hmm, not sure hotplugging is so good for a real SATA disk
[16:54] <asac_> yeah. dont do it
[16:54] <asac_> ;)
[16:55] <ogra> i think i'll start a download of alternate now
[16:55] <ogra> and try an install tomorrow
[16:57] <asac_> yeah
[16:57]  * asac_ goes and plays a game
[20:31] <GrueMaster> ogra: asac To hotplug a SATA drive, you need to treat it as a hot swap scsi drive.  To remove (as root), type ' echo "scsi remove-single-device 0 0 2 0" > /proc/scsi/scsi ' (where 0 0 2 0 is the Host Channel ID LUN of the desired drive).  To add (as root), type 'echo "scsi add-single-device 0 0 2 0" > /proc/scsi/scsi '
[20:32] <GrueMaster> Just don't do this with a mounted filesystem.  Bad juju happens if you do.
[20:34] <GrueMaster> I've done this several times on my system without issue.  Mainly when upgrading the drive I use for VirtualBox, or when testing or backing up a drive from a different system.  More convenient than trying to hook up a full system on my already crowded desk.