FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Laptop

 
 
LinkBack Thread Tools
 
Old 04-07-2011, 07:55 PM
Chris Lumens
 
Default move from our own init to systemd

> > Okay, I can just change the very end of anaconda to look like this:
> >
> > elif not flags.livecdInstall:
> > os.system("systemctl --force --no-wall reboot")
> >
> > Then in the livecd case, we just fall off the bottom, anaconda exits,
> > and whatever started anaconda (the livecd script) takes back over.
>
> Also if flags.imageInstall.

Done.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-07-2011, 08:33 PM
Chris Lumens
 
Default move from our own init to systemd

> I do not think we should hold up this patch set for s390 changes, but
> there will be a fair amount of work to hack up and dismantle linuxrc.s390.
> I would like systemd to start up as init on s390 just like it does on the
> non-s390 platforms, and then use the unit file dependency capability to
> have it run either one or multiple interactive device configuration
> programs. The whole point of linuxrc.s390 is to bring up system devices
> and set up networking so we can lauch loader when the user logs in via
> ssh. Because that needs to happen before loader runs and we have
> historically had our init.c launch loader, linuxrc.s390 became init on
> that platform.

Yeah, so the first step is to take everything we require from
linuxrc.s390 and rewrite in Python (hooray!). Perhaps we can even get
some code reuse from pyanaconda that way. Then, add some
anaconda-s390.service file that only gets installed on s390. That'll
start up the Python program to interrogate for device config. In lorax,
we conditionally add that file to
/lib/systemd/system/loader.service.wants and make sure we set the
Before= appropriately too.

Bam, working in systemd just fine. For me, the greatest advantage to
this approach is that s390 acts just like every other platform except we
run one extra program. That's much different from now where we take an
entirely different path to loader. One significant advantage to s390
with this is that fewer differences means fewer places we will
accidentally break it when making changes.

> The parts of linuxrc.s390 we'll need to salvage are the prompts and
> validation code for different device types. The parts that make the
> script work enough like init so it can be init can be trashed. I would
> very much like to have these parts rewritten in Python since we have that
> now in initrd.img, or at the very least multiple smaller shell scripts
> divided in to logical tasks.

My preferred approach would be one Python program with all the various
prompts and validation code as modules. Like I said earlier, it'd be
nice to share with pyanaconda where appropriate.

Multiple programs could be done, but with more .service file copying and
linking. It seems a little unnecessarily messy.

> At any rate, we can keep linuxrc.s390 around for now.

It's still being kept around, but keep in mind anaconda will call
systemctl to do the reboot/shutdown/etc. and I don't think that'll work
if systemd's not running.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-07-2011, 08:40 PM
David Cantrell
 
Default move from our own init to systemd

Chris Lumens <clumens@redhat.com> wrote:

> > I do not think we should hold up this patch set for s390 changes, but
> > there will be a fair amount of work to hack up and dismantle linuxrc.s390.
> > I would like systemd to start up as init on s390 just like it does on the
> > non-s390 platforms, and then use the unit file dependency capability to
> > have it run either one or multiple interactive device configuration
> > programs. The whole point of linuxrc.s390 is to bring up system devices
> > and set up networking so we can lauch loader when the user logs in via
> > ssh. Because that needs to happen before loader runs and we have
> > historically had our init.c launch loader, linuxrc.s390 became init on
> > that platform.
>
> Yeah, so the first step is to take everything we require from
> linuxrc.s390 and rewrite in Python (hooray!). Perhaps we can even get
> some code reuse from pyanaconda that way. Then, add some
> anaconda-s390.service file that only gets installed on s390. That'll
> start up the Python program to interrogate for device config. In lorax,
> we conditionally add that file to
> /lib/systemd/system/loader.service.wants and make sure we set the
> Before= appropriately too.
>
> Bam, working in systemd just fine. For me, the greatest advantage to
> this approach is that s390 acts just like every other platform except we
> run one extra program. That's much different from now where we take an
> entirely different path to loader. One significant advantage to s390
> with this is that fewer differences means fewer places we will
> accidentally break it when making changes.

Yeah, this is exactly along the lines I was thinking.

> > The parts of linuxrc.s390 we'll need to salvage are the prompts and
> > validation code for different device types. The parts that make the
> > script work enough like init so it can be init can be trashed. I would
> > very much like to have these parts rewritten in Python since we have that
> > now in initrd.img, or at the very least multiple smaller shell scripts
> > divided in to logical tasks.
>
> My preferred approach would be one Python program with all the various
> prompts and validation code as modules. Like I said earlier, it'd be
> nice to share with pyanaconda where appropriate.
>
> Multiple programs could be done, but with more .service file copying and
> linking. It seems a little unnecessarily messy.

A single Python program is fine with most of the code in pyanaconda. I
was thinking multiple programs if it were staying in shell and the fact
that I just wanted to break up the 3000+ line shell script. But that'll
go, so whatever.

> > At any rate, we can keep linuxrc.s390 around for now.
>
> It's still being kept around, but keep in mind anaconda will call
> systemctl to do the reboot/shutdown/etc. and I don't think that'll work
> if systemd's not running.

It's rawhide. Patches welcome and all until we get around to it.

--
David Cantrell <dcantrell@redhat.com>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Honolulu, HI | UTC-10

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-08-2011, 05:37 AM
Ales Kozumplik
 
Default move from our own init to systemd

On 04/07/2011 08:54 PM, Chris Lumens wrote:

I don't know much about systemd yet and since I rebase my
threaded-ui patches regularly and depend on this feature I'd prefer
if you figured this out before pushing the set.


Okay, changing the systemctl commands up a little bit has helped, though
there are some problems:


Thanks, that should help. I'll take a look into the remaining issues if
I hit them. The cleanup problem for instance was the same before and the
strategy is to cleanup everything (in this case checking if something is
mounted on /mnt/source and unmount it).



* Booting off the DVD, loader does not detect that we're on a DVD
because /mnt/source is never unmounted. This shows off a larger
problem - because you have no idea where anaconda is going to get
interrupted, you can't possibly hope to clean up everything with some
code somewhere. So, you'll likely just have to live with this
problem.

>

* NM doesn't want to bring up the network the second time through.

* Sometimes, stdin appears to be getting scrambled. Don't know what
that's about yet.


Ales

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-12-2011, 02:22 PM
Will Woods
 
Default move from our own init to systemd

On Thu, 2011-04-07 at 14:54 -0400, Chris Lumens wrote:

> * Booting off the DVD, loader does not detect that we're on a DVD
> because /mnt/source is never unmounted. This shows off a larger
> problem - because you have no idea where anaconda is going to get
> interrupted, you can't possibly hope to clean up everything with some
> code somewhere. So, you'll likely just have to live with this
> problem.

I'm not deeply familiar with the DVD-specific problem you're alluding to
here, but - could we do anaconda teardown stuff as a systemd service
that gets run at shutdown? If we're moving init to systemd we probably
need to move de-init stuff there too..

-w

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-12-2011, 06:46 PM
Chris Lumens
 
Default move from our own init to systemd

> > * Booting off the DVD, loader does not detect that we're on a DVD
> > because /mnt/source is never unmounted. This shows off a larger
> > problem - because you have no idea where anaconda is going to get
> > interrupted, you can't possibly hope to clean up everything with some
> > code somewhere. So, you'll likely just have to live with this
> > problem.
>
> I'm not deeply familiar with the DVD-specific problem you're alluding to
> here, but - could we do anaconda teardown stuff as a systemd service
> that gets run at shutdown? If we're moving init to systemd we probably
> need to move de-init stuff there too..

Oh, it's a pretty simple problem. If anaconda restarts in the middle of
a DVD install, /mnt/source is never unmounted. Then when loader runs
the second time, mounting /mnt/source fails because it's busy so we
don't bother to look for what's in that directory. You can imagine
other similar problems happening with other installation methods.

But yes, we can probably work in some code to get called when systemd
shuts down the service. As dlehman suggested, anaconda-cleanup could be
helpful. I'll take a look.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 04:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org