| === robbiew is now known as robbiew-afk | ||
| Keybuk | queue_fsck: /mnt: queuing check | 02:18 |
|---|---|---|
| Keybuk | mountall:mountall.c:564: Assertion failed in update_mount_dev_ids: mnt->udev_device != NULL | 02:18 |
| Keybuk | damnit, ion | 02:18 |
| Keybuk | ;) | 02:18 |
| ion | Huh | 02:19 |
| ion | Isn’t the only point where queue_fsck is called right after there’s an udev_device and it gets assigned to mnt->udev_device? :-P | 02:20 |
| Keybuk | no ;-) | 02:20 |
| Keybuk | what's the _needed thing about? | 02:21 |
| ion | update_mount_dev_ids only does its work if _needed is true, that is, an udev event that might have updated the mapping has been received. | 02:22 |
| Keybuk | right | 02:22 |
| Keybuk | just trying to understand the logic :p | 02:22 |
| Keybuk | it looks like the update_mount_dev_ids can be just called in fsck_lock() | 02:28 |
| Keybuk | and that should do the no-device => always lock thing | 02:28 |
| ion | But always lock what? | 02:28 |
| Keybuk | loopback mounted image :) | 02:28 |
| ion | The logic probably should be extended to follow that image to the partition it resides on, and that partition to the physical devices. | 02:29 |
| Keybuk | possibly | 02:31 |
| Keybuk | except that the partition it resides on must be already mounted :p | 02:31 |
| Keybuk | so there's little point <g> | 02:31 |
| Keybuk | already mounted => already checked | 02:32 |
| ion | Other images to be fscked may be on that partition. | 02:32 |
| Keybuk | a fair point | 02:32 |
| Keybuk | but then, arguably, you don't want to mount it either | 02:32 |
| Keybuk | so the same locks should be applied to mounts too | 02:33 |
| ion | Can mount be that IO-intensive? I can see a journal may need to be handled or something like that, but still. | 02:33 |
| Keybuk | if that's /usr | 02:34 |
| Keybuk | and the other thing is /whatever | 02:34 |
| Keybuk | then that means the boot will continue | 02:34 |
| Keybuk | that's IO intensive :p | 02:34 |
| ion | But it might just as well get to lock /whatever first and delay /usr. One could implement priorities, of course. | 02:35 |
| Keybuk | :) | 02:36 |
| Keybuk | it's one of those problems that gets deeper the longer you look at it, isn't it | 02:36 |
| ion | Heh | 02:36 |
| Keybuk | pushed to my branch | 02:41 |
| Keybuk | feel free to much aroun | 02:41 |
| Keybuk | muck around! | 02:41 |
| ion | With the fsck queue, the worst case scenario is that /usr gets fscked after /whatever, but because there’s no disk thrashing (if you have a HDD), it’s still faster than the worst case scenario with everything being parallel and fsck instances spending most of their time waiting for the disk to seek. I have no hard data, but i’d expect the worst mount to still be so fast it doesn’t need queuing. With queue prioritization, one could get the boot time even ... | 02:41 |
| ion | ... faster, of course. | 02:42 |
| ion | Thanks. I’ll try to look at the loop mount case. Shouldn’t be hard, just get the device from stat() and get an udev device object for that. | 02:42 |
| ion | Meh, bzr rebase is stupid compared to git rebase. | 02:51 |
| Keybuk | hmm? | 02:53 |
| Keybuk | why rebase? | 02:54 |
| ion | I just wanted to reset the branch to the ~ubuntu-core-dev state. merge probably would have done that, too. I just expected rebase to reset the branch to that state and then notice it doesn’t need to do anything else. You know that frustration you get with git, because you’re not used to its workflow? I haven’t studied bzr enough to be entirely familiar with its inner workings, so i get a similar thing with bzr. :-P | 02:58 |
| Keybuk | heh | 02:59 |
| ion | % bzr reset --help | 02:59 |
| ion | bzr: ERROR: unknown command "reset" | 02:59 |
| Keybuk | revert ;) | 02:59 |
| ion | bzr checkout does the wrong thing, too :-P | 02:59 |
| Keybuk | bzr's command set is more like svn's | 03:00 |
| Keybuk | whereas git's is more like an evening at the pleasure of the spanish inquisition's more perverted torturer | 03:01 |
| ion | With loop mounts, mnt->device is /foo/image, right? | 03:01 |
| Keybuk | yes | 03:01 |
| Keybuk | unless it's /dev/loop0 ;p | 03:01 |
| ion | Would it be ok to iterate through mnt->deps and set dep->udev_device = udev_device if it dep->device looks like an image file near the line that sets mnt->udev_device in try_udev_device? | 03:09 |
| Keybuk | isn't that wrong? | 03:11 |
| Keybuk | ie. exactly the wrong way around | 03:12 |
| Keybuk | mnt->udev_device = dep->udev_device is maybe right | 03:12 |
| Keybuk | but then how do you deal with multiple parents? | 03:12 |
| ion | Ah, i guessed the meaning of mnt->deps incorrectly, assuming it would be nicer to keep a list of ‘which mounts depend on this one’, so that they can be handled easily when ‘this one’ is ready. | 03:13 |
| Keybuk | I did the opposite | 03:14 |
| Keybuk | it turns out to be more reliable | 03:14 |
| ion | Now i need a struct udev *udev handle in update_physical_dev_ids, which may not have a mnt->udev_device. Would it be okay to make udev file-global? | 03:27 |
| ion | update_mount_dev_ids, that is, which i think should be renamed as update_physical_dev_ids. :-) | 03:28 |
| Keybuk | sure fiddle away ;) | 03:43 |
| ion | How to commit certain changes to a file, leaving the rest for the next commit? | 03:50 |
| ion | in bzr | 03:50 |
| ion | Similar to git add -p | 03:50 |
| === sadmac_ is now known as sadmac | ||
| ion | keybuk: Pushed to https://code.edge.launchpad.net/~ion/ubuntu/karmic/mountall/fsck-locking | 04:36 |
| sadmac | ion: bzr shelve is how you do add -p stuff. Its git stash essentially. You put away the bits you /don't/ want to commit | 04:57 |
| ion | Alright, thanks | 04:57 |
| === h\h_ is now known as haraldh | ||
| mugwump | Sometimes, when a system goes wrong, you need to go through the boot process piece by piece | 10:38 |
| mugwump | With SysV-style init, this is relatively easy. How do I debug very early stage bootup problems using upstart? | 10:39 |
| mugwump | I just replaced a hard-drive, see, and so I copied over using 'dd' | 10:41 |
| mugwump | chaos is ensuing.. | 10:41 |
| === h\h_ is now known as haraldh | ||
| mgoetze | in upstart 0.3, is there some way to specify that the post-stop script should only be run if the main script ran successfully? | 13:38 |
| sadmac2 | mgoetze: you can tell from one of the environment variables whether the service is stopping or failing... don't remember what its called... | 14:22 |
| sadmac2 | mgoetze: but basically you could do that and just have your post stop script quit immediately if the service failed. | 14:22 |
| Keybuk | actually you can't | 15:01 |
| sadmac2 | Keybuk: not exported there/ | 15:02 |
| sadmac2 | *? | 15:02 |
| Keybuk | right | 15:04 |
| === robbiew-afk is now known as robbiew | ||
| sadmac2 | oh, he said 0.3, right. | 15:09 |
| sadmac2 | Keybuk: we changed that in 0.6 didn't we? | 15:09 |
| ion | keybuk: It seems 0.2.0~ never remounts the root partition rw. I’ll investigate today. | 15:23 |
| Keybuk | ion: yeah I know why that is ;) | 15:32 |
| Keybuk | bit of a think-o | 15:32 |
| ion | keybuk: But other than that, the locking and everything seems to work with the PPA package. My branch also seems to handle the locking for loop mounts correctly. | 15:33 |
| Nattgew_ | how should i run a script at startup and shutdown using upstart? | 18:11 |
| sadmac2 | Nattgew_: depends on when precisely you want that to happen | 18:13 |
| Nattgew_ | well i have a script that i usually run at 99 on boot and at 01 at shutdown with the sysv scripts... | 18:13 |
| sadmac2 | Nattgew_: if you're on ubuntu or fedora, just install it as a sysv script like usual and it'll get run. If you're on another distro with a different/more exotic upstart config it'll depend on how they've set it up. | 18:15 |
| Nattgew_ | ok, i'm on ubuntu... i think i'm going to try using /etc/gdm/PreSession and PostSession | 18:16 |
| sadmac2 | Nattgew_: that does something slightly different. Possibly better. | 18:17 |
| Nattgew_ | yeah, i think it's more what i want. thanks for the info. | 18:18 |
| sadmac2 | np | 18:18 |
| === robbiew is now known as robbiew-afk | ||
| x-warrior | I'm using Ubuntu 9.10 Beta, installed bootchart and now i noticed that the boot time is longer. So I was thinking, the boot time increased? Or now with upstart bootchart can get a better (more real) time? | 19:30 |
| sadmac2 | x-warrior: might be more of a #ubuntu question, but I think I heard something about them starting boot chart earlier now (though its nothing to do with upstart) | 19:32 |
| x-warrior | sadmac2, ok, sorry I will ask at ubuntu ;) | 19:32 |
| === robbiew-afk is now known as robbiew | ||
| === robbiew is now known as robbiew-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!