Mon 25 Feb 2013 01:57:28 PM EST Feb 25 13:57:28 <wwoods>	halfline: yeah, plymouth stuff figured out - dracut-025 does plymouth --quit before trying the final unmount(s)
Mon 25 Feb 2013 01:57:33 PM EST Feb 25 13:57:33 <wwoods>	so there's the solution
Mon 25 Feb 2013 01:57:48 PM EST Feb 25 13:57:48 <halfline>	ugh
Mon 25 Feb 2013 01:57:56 PM EST Feb 25 13:57:56 <halfline>	that means things are going to flicker
Mon 25 Feb 2013 01:58:42 PM EST Feb 25 13:58:42 <halfline>	wwoods: probably better to update-root-fs to the new root
Mon 25 Feb 2013 02:18:45 PM EST Feb 25 14:18:45 <wwoods>	halfline: well. plymouth doesn't allow update-root-fs in shutdown mode
Mon 25 Feb 2013 02:19:41 PM EST Feb 25 14:19:41 <wwoods>	but also this is in initramfs during shutdown, so all other processes are already down and everything but root is unmounted
Mon 25 Feb 2013 02:20:16 PM EST Feb 25 14:20:16 <wwoods>	so this is likely happening milliseconds before reboot
Mon 25 Feb 2013 02:21:15 PM EST Feb 25 14:21:15 <wwoods>	but yeah, if plymouth should be running right up 'til reboot, it should probably be able to switch into the shutdown image
Mon 25 Feb 2013 02:21:53 PM EST Feb 25 14:21:53 <halfline>	the alternative is we fix quit --retain-splash to work for modesetting
Mon 25 Feb 2013 02:22:08 PM EST Feb 25 14:22:08 <halfline>	it would require hacking up systemd to accept the drm fd from plymouth
Mon 25 Feb 2013 02:22:26 PM EST Feb 25 14:22:26 <halfline>	since we have to keep the drm fd around until after plymouth exits
Mon 25 Feb 2013 02:23:56 PM EST Feb 25 14:23:56 <wwoods>	systemd is already dead at this point
Mon 25 Feb 2013 02:24:08 PM EST Feb 25 14:24:08 <wwoods>	the only thing running is dracut's /shutdown script
Mon 25 Feb 2013 02:25:03 PM EST Feb 25 14:25:03 <wwoods>	(and plymouthd, and any other daemon with argv[0][0] == '@')
Mon 25 Feb 2013 02:31:44 PM EST Feb 25 14:31:44 <halfline>	wwoods: hmm interesting 
Mon 25 Feb 2013 02:32:44 PM EST Feb 25 14:32:44 <halfline>	wwoods: so we need some way to leak the drm fd if we want plymouth to be quittable
Mon 25 Feb 2013 02:34:03 PM EST Feb 25 14:34:03 <halfline>	wwoods: maybe we could add a "plymouth get-splash-fd" command or something and dracut's /shutdown script could call it
Mon 25 Feb 2013 02:34:46 PM EST Feb 25 14:34:46 <halfline>	the problem with quitting plymouth is, as soon as the drm fd goes away the plymouth splash is going to go off screen
Mon 25 Feb 2013 02:35:02 PM EST Feb 25 14:35:02 <halfline>	so we need to keep that fd from getting closed to keep the splash up
Mon 25 Feb 2013 02:35:27 PM EST Feb 25 14:35:27 <halfline>	but maybe easier to fix update-root-fs to work in shutdown mode
Mon 25 Feb 2013 02:37:23 PM EST Feb 25 14:37:23 <wwoods>	I think that's probably the easier path
Mon 25 Feb 2013 02:37:33 PM EST Feb 25 14:37:33 <wwoods>	I don't really understand why plymouth refuses
Mon 25 Feb 2013 02:39:01 PM EST Feb 25 14:39:01 <wwoods>	I guess ply_progress_load_cache() won't work
Mon 25 Feb 2013 02:39:12 PM EST Feb 25 14:39:12 <wwoods>	but that could be a soft failure, couldn't it?
Mon 25 Feb 2013 02:43:12 PM EST Feb 25 14:43:12 <halfline>	yea
Mon 25 Feb 2013 02:43:19 PM EST Feb 25 14:43:19 <halfline>	just load the other file
Mon 25 Feb 2013 02:43:38 PM EST Feb 25 14:43:38 <halfline>	http://cgit.freedesktop.org/plymouth/commit/?id=59d78b4427bbbf95d846bb79307c8d11174bfae7
Mon 25 Feb 2013 02:43:45 PM EST Feb 25 14:43:45 <halfline>	http://cgit.freedesktop.org/plymouth/commit/?id=054d29019d03fe787eeb26267774743d2a849777
Mon 25 Feb 2013 02:44:16 PM EST Feb 25 14:44:16 <wwoods>	rad
Mon 25 Feb 2013 02:45:09 PM EST Feb 25 14:45:09 <wwoods>	dracut attempts to kill only processes that are running under /oldroot
Mon 25 Feb 2013 02:45:14 PM EST Feb 25 14:45:14 <wwoods>	so it should leave plymouth alone
Mon 25 Feb 2013 02:47:15 PM EST Feb 25 14:47:15 <wwoods>	(it checks /proc/$pid/{exe,root} for /oldroot)
Mon 25 Feb 2013 02:47:45 PM EST Feb 25 14:47:45 <wwoods>	(err, checks the targets of those symlinks for /oldroot)
Mon 25 Feb 2013 02:54:44 PM EST Feb 25 14:54:44 <halfline>	hmm, not sure /exe will be updated
Mon 25 Feb 2013 02:55:03 PM EST Feb 25 14:55:03 <halfline>	i think it might say (deleted) or some such, but we aren't reexecing ourself
Mon 25 Feb 2013 02:55:41 PM EST Feb 25 14:55:41 <wwoods>	maybe it should also respect argv[0][0]=='@'
Mon 25 Feb 2013 03:04:50 PM EST Feb 25 15:04:50 <wwoods>	oh, hm. actually it checks everything in /proc and /proc/fd 
Mon 25 Feb 2013 03:05:17 PM EST Feb 25 15:05:17 <wwoods>	and that happens before the final unmount
Mon 25 Feb 2013 03:05:32 PM EST Feb 25 15:05:32 <wwoods>	so yeah, that needs to respect the '@', I think
Mon 25 Feb 2013 03:11:26 PM EST Feb 25 15:11:26 <wwoods>	halfline: hrm. what happens to the open fds at newroot time?
Mon 25 Feb 2013 03:11:58 PM EST Feb 25 15:11:58 <halfline>	absolutely nothing
Mon 25 Feb 2013 03:12:09 PM EST Feb 25 15:12:09 <wwoods>	plymouthd has /oldroot/dev/{tty63,ptmx,fb0} open
Mon 25 Feb 2013 03:12:31 PM EST Feb 25 15:12:31 <halfline>	but /dev is a separate filesystem
Mon 25 Feb 2013 03:12:48 PM EST Feb 25 15:12:48 <wwoods>	right, but that keeps us from unmounting /oldroot/dev, which keeps us from unmounting /oldroot
Mon 25 Feb 2013 03:13:16 PM EST Feb 25 15:13:16 <halfline>	hmm
Mon 25 Feb 2013 03:13:30 PM EST Feb 25 15:13:30 <halfline>	i guess we could mount --move it but ugh
Mon 25 Feb 2013 03:13:33 PM EST Feb 25 15:13:33 <wwoods>	it could get mount --moved out of the way, but.. yeah
Mon 25 Feb 2013 03:13:41 PM EST Feb 25 15:13:41 <halfline>	jinx
Mon 25 Feb 2013 03:14:08 PM EST Feb 25 15:14:08 *	wwoods owes halfline a coke
Mon 25 Feb 2013 03:14:12 PM EST Feb 25 15:14:12 <halfline>	maybe better to look into passing the fd to dracut and quitting
Mon 25 Feb 2013 03:15:59 PM EST Feb 25 15:15:59 <wwoods>	possibly. I have no idea if bash knows how to receive an external FD
Mon 25 Feb 2013 03:16:25 PM EST Feb 25 15:16:25 <wwoods>	maybe a dumb helper in the initramfs that just gets and holds the FD until reboot?
Mon 25 Feb 2013 03:19:18 PM EST Feb 25 15:19:18 <airlied>	wwoods: half line a coke
Mon 25 Feb 2013 03:19:32 PM EST Feb 25 15:19:32 <airlied>	saved by punctuation
Mon 25 Feb 2013 03:23:06 PM EST Feb 25 15:23:06 <wwoods>	ha
Mon 25 Feb 2013 03:31:43 PM EST Feb 25 15:31:43 <halfline>	bash has built-in netcat, i'm sure it supports fd passing with some fancy syntax
Mon 25 Feb 2013 03:37:04 PM EST Feb 25 15:37:04 <halfline>	hmm, not good
Mon 25 Feb 2013 03:37:16 PM EST Feb 25 15:37:16 <halfline>	[rstrode@halflap] (/srv/sources/pkgs/bash/bash-4.2) <03:36 PM>
Mon 25 Feb 2013 03:37:16 PM EST Feb 25 15:37:16 <halfline>	$ grep SCM_ . -R
Mon 25 Feb 2013 03:37:22 PM EST Feb 25 15:37:22 <halfline>	$ 
Mon 25 Feb 2013 03:37:54 PM EST Feb 25 15:37:54 <halfline>	okay so we just make plymouth get-splash-fd block after it gets the fd
Mon 25 Feb 2013 03:38:17 PM EST Feb 25 15:38:17 <halfline>	we run from within the initrd
Mon 25 Feb 2013 03:38:42 PM EST Feb 25 15:38:42 <halfline>	maybe not block, but daemonize
Mon 25 Feb 2013 03:38:49 PM EST Feb 25 15:38:49 <halfline>	since we need to know when it's "safe" to call plymouth quit
Mon 25 Feb 2013 03:39:52 PM EST Feb 25 15:39:52 <halfline>	wwoods: what do you think?
Mon 25 Feb 2013 03:45:02 PM EST Feb 25 15:45:02 <wwoods>	that makes sense
Mon 25 Feb 2013 03:45:32 PM EST Feb 25 15:45:32 <wwoods>	so plymouth (run from initrd) grabs the fd and (maybe) daemonizes
Mon 25 Feb 2013 03:45:42 PM EST Feb 25 15:45:42 <wwoods>	and that process can just stay running 'til reboot
Mon 25 Feb 2013 03:46:24 PM EST Feb 25 15:46:24 <wwoods>	oh but hrm. is that fd connected to /oldroot/dev/fd0 specifically?
Mon 25 Feb 2013 03:46:31 PM EST Feb 25 15:46:31 <wwoods>	err fb0
Mon 25 Feb 2013 03:46:39 PM EST Feb 25 15:46:39 <wwoods>	or drm or whatever
Mon 25 Feb 2013 03:49:29 PM EST Feb 25 15:49:29 <wwoods>	AFAIK this doesn't matter for the startup transition, 'cuz the old /dev gets moved into the new system
Mon 25 Feb 2013 03:50:58 PM EST Feb 25 15:50:58 <wwoods>	but shutdown happens differently - it *binds* a *copy* of /dev into the shutdown initramfs
Mon 25 Feb 2013 03:51:15 PM EST Feb 25 15:51:15 <wwoods>	I wonder why that is..
Mon 25 Feb 2013 03:51:55 PM EST Feb 25 15:51:55 <ajax>	things still being shut down might need to access it on the way down?
Mon 25 Feb 2013 03:52:20 PM EST Feb 25 15:52:20 <wwoods>	ajax: but the same applies to plymouth and root-fs daemons during the transition from initrd to real root
Mon 25 Feb 2013 03:52:32 PM EST Feb 25 15:52:32 <wwoods>	if it works there, it outta work at shutdown?
Mon 25 Feb 2013 03:54:45 PM EST Feb 25 15:54:45 <halfline>	wwoods: hmm, good point
Mon 25 Feb 2013 03:55:06 PM EST Feb 25 15:55:06 <halfline>	we're trying to avoid having to close device fds and the proposed solution was to keep a device fd open and pass it around
Mon 25 Feb 2013 03:55:13 PM EST Feb 25 15:55:13 <halfline>	fail
Mon 25 Feb 2013 03:55:43 PM EST Feb 25 15:55:43 <halfline>	so it seems like the only answer is --move or MNT_DETACH
Mon 25 Feb 2013 03:56:22 PM EST Feb 25 15:56:22 <wwoods>	or maybe shutdown should be moving /{dev,proc,sys,run} like switch-root does
Mon 25 Feb 2013 03:56:50 PM EST Feb 25 15:56:50 <halfline>	that's what i meant by --move
Mon 25 Feb 2013 03:57:08 PM EST Feb 25 15:57:08 <wwoods>	ah, I thought you meant that dracut should be manually rejiggering the mounts
Mon 25 Feb 2013 03:57:11 PM EST Feb 25 15:57:11 <wwoods>	or something
Mon 25 Feb 2013 03:57:23 PM EST Feb 25 15:57:23 <wwoods>	which is actually what we have to do in anaconda, since we manage to set up a mount loop
Mon 25 Feb 2013 04:03:13 PM EST Feb 25 16:03:13 <halfline>	if those options aren't in the cards, we could reengineer plymouth to be re-execable
Mon 25 Feb 2013 04:03:46 PM EST Feb 25 16:03:46 <halfline>	then it would open /dev/dri again, copy the fb to a new buffer and the close the old fd
Mon 25 Feb 2013 04:04:11 PM EST Feb 25 16:04:11 <halfline>	sounds like a lot of work to be doing in the .25 seconds shutdown should take though
Mon 25 Feb 2013 04:05:41 PM EST Feb 25 16:05:41 <wwoods>	oh interesting. shutdown predates switch-root by almost a year
Mon 25 Feb 2013 04:06:12 PM EST Feb 25 16:06:12 <wwoods>	so switch-root is the later (and possibly therefore cleverer) implementation anyway