Re: [gentoo-user] Re: new machine : case fan
150917 james wrote: > Make sure your case has a big and quiet fan to draw air across the HD. My case -- Deepcool Terraract BF -- has a fan in the wall : none of my previous cases had one, so I'm not sure how to connect it. It has a 3-pin plug & the Mobo -- Gigabyte GA-970A-UD3P -- has 2 3-pin sockets marked 'power fan' & 'system fan'. I've tried plugging the case fan into both, but it doesn't run. The various manuals + I/net sites don't offer any advice. Which is the correct socket or should both be ok ? Does the case fan run only when the inside starts getting too hot ? The machine has woken up -- it's like having a baby (grin) -- & BIOS shows everything is running as expected. Thanks for the useful help previously : fan advice wb welcome. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: update problems
Dale gmail.com> writes: > > I usually remember --oneshot but if I'm tired or distracted I > > forget it. > To avoid this, I added it to my make.conf. When I *really* want to have > something in the world file, I can either add it myself or use --select > on the command line to add it. Result, shouldn't be anything in the > world file that shouldn't be there. OK, I'll try this. I'll add --oneshot to the EMERGE_DEFAULT_OPTS= in make.conf. Works great. > I sometimes wonder why that isn't the default way. I guess because it > would confuse folks for a bit and because it has always been that way. One thing I see, is now you have a system that is full of pkg that do not update normally. I guess I'm say if you install pakages with --oneshot, they are not automatically updated, or are they? (discussion). 'emerge -uDNv world' is the most common form of update, probably, used by gentoo users. So how to best ferret out those oneshot packages for update; and that's if they should be updated semantics on that? James
Re: [gentoo-user] Re: update problems
On 22/09/2015 17:55, James wrote: > Dale gmail.com> writes: > > >>> I usually remember --oneshot but if I'm tired or distracted I >>> forget it. > > >> To avoid this, I added it to my make.conf. When I *really* want to have >> something in the world file, I can either add it myself or use --select >> on the command line to add it. Result, shouldn't be anything in the >> world file that shouldn't be there. > > OK, I'll try this. > I'll add --oneshot to the EMERGE_DEFAULT_OPTS= in make.conf. > > Works great. > >> I sometimes wonder why that isn't the default way. I guess because it >> would confuse folks for a bit and because it has always been that way. > > One thing I see, is now you have a system that is full of pkg that do > not update normally. I guess I'm say if you install pakages with --oneshot, > they are not automatically updated, or are they? (discussion). > > 'emerge -uDNv world' is the most common form of update, probably, used > by gentoo users. So how to best ferret out those oneshot packages for > update; and that's if they should be updated semantics on that? I think you two have it backwards. The intended workflow is that if you emerge something, you know what it is, you don't have to make further decisions about it and you want it in world. @world, by definition, is the list of packages you want. That plus @system plus all deps constitutes the set of what should be on the system, anything you have not in that set is subject to depcleaning If you are not sure about some package, by all means emerge it with -1. Check it out, verify it, make sure it does what you want then get it in world with emerge -n. Why would you want to have stuff around for extended periods that is not in world? If you have a package that you no longer want (as you know what is in your world right), unmerge it with -C Don't make life difficult for yourself. It's MUCH easier to know what's in world than to try and remember what should be and isn't. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] portage 2.2.21: rsync_excludes no longer taken into account
After today's update to ~portage-2.2.21 rsync gives more more than I asked for on repo update; it seems rsync_excludes is no longer read or observed. It's specified in PORTAGE_RSYNC_EXTRA_OPTS and of course the file with the exclusions exists etc. This has worked for aeons. Does anybody know what's up here? The release notes don't mention anything related (or I missed it). thanks, Holger
[gentoo-user] Re: update problems
Alan McKinnon gmail.com> writes: > > I'll add --oneshot to the EMERGE_DEFAULT_OPTS= in make.conf. > >> I sometimes wonder why that isn't the default way. I guess because it > >> would confuse folks for a bit and because it has always been that way. > > One thing I see, is now you have a system that is full of pkg that do > > not update normally. I guess I'm say if you install pakages with --oneshot, > > they are not automatically updated, or are they? (discussion). > > 'emerge -uDNv world' is the most common form of update, probably, used > > by gentoo users. So how to best ferret out those oneshot packages for > > update; and that's if they should be updated semantics on that? > I think you two have it backwards. mostly true for routine users. I myself find myself testing codes and inter operability between codes and stuff I write, more that just installing from the portage tree. I guess you could say I'm moving from user to hacker status (with extreme prejudice). I do not alway remember (-1); particularly when manually cleansing problems like the recent ncurses episode. I like Dale's approach. I just need a tool option or simple script that tells me what is installed and not in @system or @world. Surely this code/option exist and I have just missed it in the literature? > The intended workflow is that if you emerge something, you know what it > is, you don't have to make further decisions about it and you want it > in world. users yes, hackers no. For a long time, I just used gentoo. Now I'm coding (specifcations --> architecture --> then code) and hacking (modifying other codes) quite a lot. I have a robust world file that migrates from workstation to workstation and only update it, replace pkgs, or add a select few niftyones, like trace-cmd and heaptrack. So I'm not suggesting this for normal, new gentoo users. world, by definition, is the list of packages you want. That plus system plus all deps constitutes the set of what should be on the system, anything you have not in that set is subject to depcleaning true. If you are not sure about some package, by all means emerge it with -1. Check it out, verify it, make sure it does what you want then get it in world with emerge -n. Why would you want to have stuff around for extended periods that is not in world? Again, user focused, mostly true. If you have a package that you no longer want (as you know what is in your world right), unmerge it with -C It's not that simple. I'm spending a large amount of my gentoo-admin time installing--testing--marinating--modifying--testing--removal. Dale's simple suggesting is brilliant for my needs. (thx Dale). Don't make life difficult for yourself. It's MUCH easier to know what's in world than to try and remember what should be and isn't. Users (YES) hackers(??? no in my case). Sorry bro, I'm running with Dale in this one. Now, I still need a --oneshot parser solution for vdb (/var/db/pkg/)? 1] Glep-64 preliminary code? 2] a DAG? 3] Neil's mod to CheckInstall? 4] a 'man page option' would be keenest; that I have missed? 5] a script? 6] or a profile? [10] default/linux/amd64/13.0/developer I've been looking for some details on the developer profile; a list of additional packages only or some other keen settings and other goodies ? James
Re: [gentoo-user] Re: update problems
On Tue, 22 Sep 2015 18:03:19 +0200, Alan McKinnon wrote: > The intended workflow is that if you emerge something, you know what it > is, you don't have to make further decisions about it and you want it in > world. > > @world, by definition, is the list of packages you want. That plus > @system plus all deps constitutes the set of what should be on the > system, anything you have not in that set is subject to depcleaning > > If you are not sure about some package, by all means emerge it with -1. > Check it out, verify it, make sure it does what you want then get it in > world with emerge -n. Why would you want to have stuff around for > extended periods that is not in world? > > If you have a package that you no longer want (as you know what is in > your world right), unmerge it with -C > > Don't make life difficult for yourself. It's MUCH easier to know what's > in world than to try and remember what should be and isn't. I take a different approach, I have a set called temp in my world_sets. If I want to try something out, I "echo cat/pkg >>/etc/portage/sets/temp" then I can try it and keep it updated during the trial and not have to worry about its deps. All I need to do is look at the temp file from time to time and remove anything I no longer want, then it gets depcleaned along with its dependencies. Putting --oneshot is the defaults is fine as long as you remember to emerge -n anything you know you want. I've been using Gentoo for so long that I automatically add -1 without thinking about it even when using -p! -- Neil Bothwick If Wile E. Coyote had enough money to buy all that ACME crap, why didn't he just buy dinner? pgpglZ_wNqhrE.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: new machine : case fan
Philip Webb wrote: > 150917 james wrote: >> Make sure your case has a big and quiet fan to draw air across the HD. > My case -- Deepcool Terraract BF -- has a fan in the wall : > none of my previous cases had one, so I'm not sure how to connect it. > It has a 3-pin plug & the Mobo -- Gigabyte GA-970A-UD3P -- > has 2 3-pin sockets marked 'power fan' & 'system fan'. > I've tried plugging the case fan into both, but it doesn't run. > The various manuals + I/net sites don't offer any advice. > > Which is the correct socket or should both be ok ? > Does the case fan run only when the inside starts getting too hot ? > > The machine has woken up -- it's like having a baby (grin) -- > & BIOS shows everything is running as expected. > > Thanks for the useful help previously : fan advice wb welcome. > I have that mobo and I have 4 fan connectors. For mine, I have one for the CPU fan, front, rear and top. My side fan just plugs in and runs. It's those big 200mm thingys. Anyway, you should have 4 connectors on there. If needed, I can take the side off and give you a general location. It should be in the manual to tho. By the way, I also let the BIOS handle my fan speeds. It works pretty well. It's quiet but when compiling, it also keeps things cool. My CPU never goes above 110F. Good air flow and a large CPU cooler keeps things cool. Dale :-) :-)
Re: [gentoo-user] Re: update problems
On 22/09/2015 18:42, Neil Bothwick wrote: > On Tue, 22 Sep 2015 18:03:19 +0200, Alan McKinnon wrote: > >> The intended workflow is that if you emerge something, you know what it >> is, you don't have to make further decisions about it and you want it in >> world. >> >> @world, by definition, is the list of packages you want. That plus >> @system plus all deps constitutes the set of what should be on the >> system, anything you have not in that set is subject to depcleaning >> >> If you are not sure about some package, by all means emerge it with -1. >> Check it out, verify it, make sure it does what you want then get it in >> world with emerge -n. Why would you want to have stuff around for >> extended periods that is not in world? >> >> If you have a package that you no longer want (as you know what is in >> your world right), unmerge it with -C >> >> Don't make life difficult for yourself. It's MUCH easier to know what's >> in world than to try and remember what should be and isn't. > > I take a different approach, I have a set called temp in my world_sets. If > I want to try something out, I "echo cat/pkg >>/etc/portage/sets/temp" > then I can try it and keep it updated during the trial and not have to > worry about its deps. All I need to do is look at the temp file from time > to time and remove anything I no longer want, then it gets depcleaned > along with its dependencies. > > Putting --oneshot is the defaults is fine as long as you remember to > emerge -n anything you know you want. I've been using Gentoo for so long > that I automatically add -1 without thinking about it even when using -p! That can also work. I thought of maybe suggesting it later in the thread but you got in there first. Either way the owner of a Gentoo system still has to keep track on what he wants to be on it. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: update problems
On 22/09/2015 18:39, James wrote: > Alan McKinnon gmail.com> writes: > > > >>> I'll add --oneshot to the EMERGE_DEFAULT_OPTS= in make.conf. > I sometimes wonder why that isn't the default way. I guess because it would confuse folks for a bit and because it has always been that way. > >>> One thing I see, is now you have a system that is full of pkg that do >>> not update normally. I guess I'm say if you install pakages with --oneshot, >>> they are not automatically updated, or are they? (discussion). > >>> 'emerge -uDNv world' is the most common form of update, probably, used >>> by gentoo users. So how to best ferret out those oneshot packages for >>> update; and that's if they should be updated semantics on that? > >> I think you two have it backwards. > > mostly true for routine users. I myself find myself testing codes > and inter operability between codes and stuff I write, more that > just installing from the portage tree. I guess you could say I'm moving > from user to hacker status (with extreme prejudice). I do not alway > remember (-1); particularly when manually cleansing problems like the recent > ncurses episode. I like Dale's approach. I just need a tool option or simple > script that tells me what is installed and not in @system or @world. > Surely this code/option exist and I have just missed it in the literature? > > >> The intended workflow is that if you emerge something, you know what it >> is, you don't have to make further decisions about it and you want it >> in world. > > users yes, hackers no. For a long time, I just used gentoo. > Now I'm coding (specifcations --> architecture --> then code) > and hacking (modifying other codes) quite a lot. I have a robust > world file that migrates from workstation to workstation and only > update it, replace pkgs, or add a select few niftyones, like > trace-cmd and heaptrack. > > So I'm not suggesting this for normal, new gentoo users. > > > world, by definition, is the list of packages you want. That plus > system plus all deps constitutes the set of what should be on the > system, anything you have not in that set is subject to depcleaning > > true. > > If you are not sure about some package, by all means emerge it with -1. > Check it out, verify it, make sure it does what you want then get it in > world with emerge -n. Why would you want to have stuff around for > extended periods that is not in world? > > Again, user focused, mostly true. > > If you have a package that you no longer want (as you know what is in > your world right), unmerge it with -C > > It's not that simple. I'm spending a large amount of my gentoo-admin > time installing--testing--marinating--modifying--testing--removal. > Dale's simple suggesting is brilliant for my needs. (thx Dale). > > Don't make life difficult for yourself. It's MUCH easier to know what's > in world than to try and remember what should be and isn't. > > Users (YES) hackers(??? no in my case). > > Sorry bro, I'm running with Dale in this one. Portage can help with that then. The trick is to realise the exact question you are asking: what packages do I have installed for testing purposes and that are not in world? Seeing as @world is really just a regular set, use sets to your advantage. Create as many or as few or you need in /etc/portage/sets/ and emerge them (or just add the set name to /var/lib/portage/world_sets) They will update with a deep world update, but they are together in one place where you can add and remove them at will. Just don't do emerge @set_name, that won;t do an update, it will re-emerge everything in the set > Now, I still need a --oneshot parser solution for vdb (/var/db/pkg/)? --depclean If portage wants to take it out, it's not in world or a dep. To the best of my knowledge portage does not record that you used -1, it simply does not add the package to world. So you need to do it the long way, which is what --depclean does > 1] Glep-64 preliminary code? > 2] a DAG? > 3] Neil's mod to CheckInstall? > 4] a 'man page option' would be keenest; that I have missed? > 5] a script? > 6] or a profile? [10] default/linux/amd64/13.0/developer > > I've been looking for some details on the developer profile; > a list of additional packages only or some other keen settings > and other goodies ? > > > > James > > > > > > -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: update problems
Neil Bothwick digimed.co.uk> writes: > I take a different approach, I have a set called temp in my world_sets. If > I want to try something out, I "echo cat/pkg >>/etc/portage/sets/temp" > then I can try it and keep it updated during the trial and not have to > worry about its deps. All I need to do is look at the temp file from time > to time and remove anything I no longer want, then it gets depcleaned > along with its dependencies. That's a good approach. But, what I'm looking for could be a general purpose tool for *all* of the gentoo community to parse and identify packages that are not being updated or at lease fall into the orphan category. One common case is those packages installed (-1). I'd venture to guess from time to time that most gentoo users have packages installed that are not dependencies for any other packages. Often is it by accident or extreme manual cleansing events (like the recent ncurses episode) that folks stumble across these orphaned packages. I just think a tool or option in an existing tool does/should cover that scenario. It is a routine need, imho. That said are there any make.conf mods need to use sets like this, or just create the dir and and use your command line string? I might not use it permanently the way you do, but I can see putting a collection of (-1) packages into a set, for organizational structure. With clustering now infecting my gentoo world, I'll need a master by architecture, logically organized collection of "sets" to cover the myriad of node set-ups. Each system will most likely have a different installation of these sets. And the cluster is now moving to a multi-arch setup with aarch64. So you idea is worth pursuit for me at this time. I still need that tool to at least identify the (-1) installed packages. I know we have 'equery depends' but that does not traverse the entire list of installed packages, or did I miss that syntax? Any ideas on that sort of (-1) parsing are keenly appreciated ? James
Re: [gentoo-user] portage 2.2.21: rsync_excludes no longer taken into account
On Tue, Sep 22, 2015 at 12:28 PM, Holger Hoffstätte wrote: > > After today's update to ~portage-2.2.21 rsync gives more more than I > asked for on repo update; it seems rsync_excludes is no longer read > or observed. > > It's specified in PORTAGE_RSYNC_EXTRA_OPTS and of course the file > with the exclusions exists etc. This has worked for aeons. > > Does anybody know what's up here? The release notes don't mention > anything related (or I missed it). rsync has no option called rsync_excludes. Exactly what options are you specifying in PORTAGE_RSYNC_EXTRA_OPTS?
Re: [gentoo-user] Re: update problems
On Tue, 22 Sep 2015 17:35:10 + (UTC), James wrote: > > I take a different approach, I have a set called temp in my > > world_sets. If I want to try something out, I "echo cat/pkg > > >>/etc/portage/sets/temp" then I can try it and keep it updated > > >>during the trial and not have to > > worry about its deps. All I need to do is look at the temp file from > > time to time and remove anything I no longer want, then it gets > > depcleaned along with its dependencies. > > That's a good approach. But, what I'm looking for could be a general > purpose tool for *all* of the gentoo community to parse and identify > packages that are not being updated or at lease fall into the orphan > category. One common case is those packages installed (-1). I'd venture > to guess from time to time that most gentoo users have packages > installed that are not dependencies for any other packages. Often is it > by accident or extreme manual cleansing events (like the recent ncurses > episode) that folks stumble across these orphaned packages. I just > think a tool or option in an existing tool does/should cover that > scenario. It is a routine need, imho. That's exactly what depclean is for, to find any packages that are not dependencies of the installed sets. > That said are there any make.conf mods need to use sets like this, > or just create the dir and and use your command line string? That's all you do. Any file in /etc/portage/sets containing a list of atoms is taken to be a set definition. > I might not use it permanently the way you do, but I can see putting > a collection of (-1) packages into a set, for organizational structure. > With clustering now infecting my gentoo world, I'll need a master by > architecture, logically organized collection of "sets" to cover the > myriad of node set-ups. Each system will most likely have a different > installation of these sets. And the cluster is now moving to a > multi-arch setup with aarch64. I use sets like that too. I have one called base that I installed at the chroot stage of installation, containing various essential and useful packages - such as portage-utils, conf-update and eix. Then sets called desktop and laptop - sets can contain other sets so when installing my new laptop I only have to "emerge -u @laptop". -- Neil Bothwick Energizer Bunny arrested, charged with battery :) pgpgCipU1DSce.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: update problems
Alan McKinnon wrote: > On 22/09/2015 17:55, James wrote: >> Dale gmail.com> writes: >> >> I usually remember --oneshot but if I'm tired or distracted I forget it. >> >>> To avoid this, I added it to my make.conf. When I *really* want to have >>> something in the world file, I can either add it myself or use --select >>> on the command line to add it. Result, shouldn't be anything in the >>> world file that shouldn't be there. >> OK, I'll try this. >> I'll add --oneshot to the EMERGE_DEFAULT_OPTS= in make.conf. >> >> Works great. >> >>> I sometimes wonder why that isn't the default way. I guess because it >>> would confuse folks for a bit and because it has always been that way. >> One thing I see, is now you have a system that is full of pkg that do >> not update normally. I guess I'm say if you install pakages with --oneshot, >> they are not automatically updated, or are they? (discussion). >> >> 'emerge -uDNv world' is the most common form of update, probably, used >> by gentoo users. So how to best ferret out those oneshot packages for >> update; and that's if they should be updated semantics on that? > > I think you two have it backwards. > > The intended workflow is that if you emerge something, you know what it > is, you don't have to make further decisions about it and you want it in > world. > > @world, by definition, is the list of packages you want. That plus > @system plus all deps constitutes the set of what should be on the > system, anything you have not in that set is subject to depcleaning > > If you are not sure about some package, by all means emerge it with -1. > Check it out, verify it, make sure it does what you want then get it in > world with emerge -n. Why would you want to have stuff around for > extended periods that is not in world? > > If you have a package that you no longer want (as you know what is in > your world right), unmerge it with -C > > Don't make life difficult for yourself. It's MUCH easier to know what's > in world than to try and remember what should be and isn't. > > > For me at least, this way works best. Before I did it this way, if I had to workaround a portage block or some other issue, I would forget to add -1 and ended up with a world file full of stuff that shouldn't be there. By the way, this doesn't effect updating at all, at least it doesn't for me. If say I emerge googleeath and I want to keep it installed and added to world, I then emerge it with --select y on the command line and it gets added to the world file. Basically, if something gets added to the world file, I took a extra step to make sure it got there. It doesn't get there by mistake. Since I've been doing it this way, I have not had a single thing added to my world file that I didn't want to be there. For me at least, it works. It's just to easy to forget to add that -1. It's not hard at all to remember to add --select y when needed tho. If it was something you were testing, --select y -n works like a charm. For my way of thinking, I think having a extra step to add something to the world file leads to a cleaner system. I wouldn't set it on a new install until I was doing installing all the things I do want tho. After I had my usual stuff installed, that -1 would be added. To each his own tho. Dale :-) :-)
[gentoo-user] Re: portage 2.2.21: rsync_excludes no longer taken into account
On Tue, 22 Sep 2015 13:38:20 -0400, Mike Gilbert wrote: > On Tue, Sep 22, 2015 at 12:28 PM, Holger Hoffstätte > wrote: >> >> After today's update to ~portage-2.2.21 rsync gives more more than I >> asked for on repo update; it seems rsync_excludes is no longer read >> or observed. >> >> It's specified in PORTAGE_RSYNC_EXTRA_OPTS and of course the file >> with the exclusions exists etc. This has worked for aeons. >> >> Does anybody know what's up here? The release notes don't mention >> anything related (or I missed it). > > rsync has no option called rsync_excludes. Exactly what options are > you specifying in PORTAGE_RSYNC_EXTRA_OPTS? No, it hasn't - I understand that. I understand rsync better than I want to, trust me.. :) $grep RSYNC /etc/portage/make.conf PORTAGE_RSYNC_EXTRA_OPTS="--compress --exclude-from=/etc/portage/rsync_excludes" This is the way documented on the Gentoo wiki, and broke today (with .21). Hence I was thinking that maybe this now needs to go into the repos.conf config or got broken some other way. Just figured I ask before filing an unnecessary bug. thanks -h
[gentoo-user] Re: update problems
Rich Freeman gentoo.org> writes: > So, kicking the overworked portage team with stuff like "Gentoo has a > lousy package manager" is not helpful and certainly violates the CoC. > I don't see that here. +1 > On the other hand, that doesn't mean that we all need to line up and > drink the kool aide and say that the behavior pointed out in the > original message is desired behavior. Is the kool_aide spike with 151 rum? just curious > We can acknowledge that bugs exist without lining up with signs > demanding their immediate fix. The portage team does great work, but > the fact that package runtime dependencies can vary so much compared > to a binary distro greatly complicates the dependency-resolution > problem. So do some of our package-maintenance practices, and those > are being looked at right now. DAG nabbit, I thought I understood the problem and then lost focus? > Just doing that alone would probably triage a > large number of issues that confuse users which makes them somewhat > happier and cuts down on list traffic. and take our fun away? Now you're moving to my side of the installer issue? ;-) James
Re: [gentoo-user] Re: portage 2.2.21: rsync_excludes no longer taken into account
On Tue, Sep 22, 2015 at 3:31 PM, Holger Hoffstätte wrote: > On Tue, 22 Sep 2015 13:38:20 -0400, Mike Gilbert wrote: > >> On Tue, Sep 22, 2015 at 12:28 PM, Holger Hoffstätte >> wrote: >>> >>> After today's update to ~portage-2.2.21 rsync gives more more than I >>> asked for on repo update; it seems rsync_excludes is no longer read >>> or observed. >>> >>> It's specified in PORTAGE_RSYNC_EXTRA_OPTS and of course the file >>> with the exclusions exists etc. This has worked for aeons. >>> >>> Does anybody know what's up here? The release notes don't mention >>> anything related (or I missed it). >> >> rsync has no option called rsync_excludes. Exactly what options are >> you specifying in PORTAGE_RSYNC_EXTRA_OPTS? > > No, it hasn't - I understand that. I understand rsync better than I > want to, trust me.. :) > > $grep RSYNC /etc/portage/make.conf > PORTAGE_RSYNC_EXTRA_OPTS="--compress > --exclude-from=/etc/portage/rsync_excludes" > > This is the way documented on the Gentoo wiki, and broke today (with .21). > Hence I was thinking that maybe this now needs to go into the repos.conf > config or got broken some other way. Just figured I ask before filing an > unnecessary bug. I was going to try and reproduce it, but if you are certain it happened as a result of upgrading portage just go ahead and file the bug.
[gentoo-user] Docker - Assigning IP to container
Hi list, I have docker installed, and I have a running instance of MineOS also running, but each time I start the instance (system restarts) it makes its own IP address in the address space of my running system. I am using '-b' to connect it to the bridge I already have running, but instead of configuring its IP to be 192.168.3.130, its 3.4 or 3.5 or one of the unallocated IP's on the 192.168.3.0/24 address range. I can reboot my system, and docker restarts the container no problems, automatically. I followed a instruction that I should modify /etc/network/interaces, but that has done nothing to get the IP of the container to configure on startup :( /etc# cat network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d auto eth0 iface eth0 inet static address 192.168.3.130 netmask 255.255.255.0 gateway 192.168.3.1 Is there something I am missing, cause I would like the IP to lock on to the address I want, not some random one it decides to start on. -- --- Regards, Rod Smart
