Re: Debian 9 stretch screen flicker on w3m and command line applications

[Tino Calancha]

FWIW I have been suffering screenn flickering in Debian 9 since 1 or 2
weeks ago.
The flickering is _very_ serious: it makes my box almost unusable.

Booting with kernel option:
i915.enable_rc6=0

significantly reduces the problem but it doesn't completely fix it.

Instead the following fix works:

Create a file:
/usr/share/X11/xorg.conf.d/10-fix-screen-flickering.conf

with content:
--8<-cut here---start->8---
Section "Device"
   Identifier  "Intel Graphics"
   Driver  "intel"
   Option "AccelMethod"  "uxa"
EndSection
--8<-cut here---end--->8---

Best regards,
Tino

Re: Re: Problem with Canon FS4000US film scanner and VueScan on Wheezy

[Jean-Francois Bosc]

Hi Boudewijn,

this is getting a bit old, but I recently moved to Debian Stretch, and gave
a little more time to this problem. I noticed that udev raises an error saying
"... was not an MTP device", and after some search on the net I managed to make
VueScan work by adding a specific udev rule :

root@debian:~# cat /etc/udev/rules.d/69-FS4000US-MTP.rules 
ATTR{idVendor}=="04a9", ATTR{idProduct}=="3042", SYMLINK+="libmtp-%k", 
MODE="660", GROUP="scanner", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1", 
TAG+="uaccess"
root@debian:~#

Just in case it would help.
Best regards,
Jean-François


Le 22/9/2016 à 21:09, Jean-Francois Bosc a écrit :
> 
> Hi Boudewijn,
> 
> thanks for your answer. Unfortunately no, I didn't manage solve my problem. 
> The
> only solution I found from VueScan or other sources was to get (or write) a
> custom driver. And indeed my PC does not have an SCSI interface. But I've 
> found
> that there are PCI extension cards for plugging SCSI devices. This could be 
> the
> solution, maybe I will try to explore that.
> 
> Thanks again and best regards,
> Jean-François
> 
> 
> Le 18/9/2016 à 21:25, Boudewijn Kranendonk a écrit :
> > Hi Jean-Francois,
> > 
> > A year ago, on 06/14/2015 03:54 AM, Jean-Francois Bosc wrote[0]:
> > 
> > > I am trying to find some help for using a (rather old) Canon FS4000US film
> > > scanner with VueScan. Here is my problem : I am running Debian Wheezy (32
> > > bits), and I have been using the scanner for quite a while under previous
> > > Debian versions. 
> > > Now VueScan doesn't detect the scanner any more, it says "No scanner was 
> > > found attached to your computer". I suppose the problem appeared
> > > when I upgraded from Squeeze to Wheezy (I'm not 100% sure since I don't 
> > > use
> > > the scanner very often, but what else could it be ?)
> > 
> > I ran into the same problem on Jessie, and after that into your mail on the 
> > list. Have you ever found a solution? 
> > 
> > For Jessie I did find a solution: use SCSI instead of USB. With modern 
> > computers it may not be a solution, because they mostly come without 
> > parallel 
> > SCSI interface, but that is a problem that can be solved via a second hand 
> > computer. 
> > 
> > I have not yet mailed VueScan about USB support, that may be another option 
> > (the usblib reference from hamrick.com to the Sane-help did not help me). 
> > 
> > In short: the VueScan can run the FS4000us on Linux via SCSI. Do not forget 
> > to 
> > set the switch at the bottom of the scanner from USB to SCSI. 
> > 
> > Best regards,
> > 
> > Boudewijn
> > 
> > PS: if my mail does arrive at your place but not at the debian-user-list, 
> > would you mind forwarding it for future reference?
> > [0] https://lists.debian.org/debian-user/2015/06/msg00677.html

Mixing and Matching DHCP and static IPs

[Mark Fletcher]

Greetings and Merry Christmas / Happy Hannukah / insert appropriate 
greeting here

There's no way to describe this with all the relevant info in a short 
way, so I'll try instead to make this as entertaining a read as I can.

For the first time ever I have tried to introduce a machine with a 
static IP to my network and it has exposed what I have a horrible 
feeling is going to turn out to be an embarrassing gap in my knowledge. 
Some machines in my network can communicate with the new machine, and 
some can't. I have an "inner network" and an "outer network" and the 
inner can't see the new machine while the outer can. Details below.

I run a home network with what might be slightly unusual topology. At 
the centre of it is a Buffalo Airstation which services a bunch of 
iDevices, a couple of Androids, a Windoze laptop, and a mini ITX machine 
running Stretch, and its wired ethernet ports also service a NAS and my 
main Debian Stretch desktop. Until very recently I ran a cable from the 
AirStation's WAN port to another mini ITX PC, this one running LFS, 
which acts as my firewall (I don't trust the firewall in the 
AirStation). The firewall runs a DHCP server to supply the AirStation 
with an IP address. The AirStation runs its own DHCP server on its LAN 
side, giving out IP addresses in the range 192.168.11.0/24, which is how 
all my machines except the firewall get their IP addresses. The firewall 
gets its external-facing interface IP via DHCP from my ISP and is static 
IP on its internal-facing side.

Recently I threw together LFS on a Raspberry PI and decided to use it as 
a caching DNS server. My plan is to run dnscache on it. The list may 
remember a thread I started a few months ago about the best way to solve 
DNS worries I had back then; I got some good advice at that time and 
this is me implementing said advice -- at long last I have some time off 
work and time to work on this.

If the PI is going to be useful as a caching DNS server for my network, it 
needs to not be in danger of having its IP address changed -- especially 
since it is going to need to be sitting outside the AirStation's LAN 
(since the AirStation insists it is the DNS server for its LAN, but 
actually merely forwards on all DNS queries to whatever DNS server it 
has been given in its WAN setup).

So I bought myself an ethernet switch -- a Netgear ProSAFE Gigabit 
Switch to be precise -- and have configured the PI to have a static IP 
on the same subnet as the firewall and the IP address given to the 
AirStation by the firewall. To be concrete, the internal-facing firewall 
interface is 192.168.1.1 (static, works), the DHCP server I set up on 
the firewall gives out 192.168.1.2 to the AirStation (works), and I have 
configured the PI to use 192.168.1.3 (static, partly works). So inside 
AirStation LAN is 192.168.11.0/24, outside AirStation LAN is 
192.168.1.1, .2 and .3 -- note the third octet difference for internal 
and external. All 3 of AirStation WAN port, PI and firewall 
internal-facing interface are plugged into the switch. I ran the switch 
for a couple of days with just the firewall and the AirStation plugged 
in (ie the switch was strictly unnecessary at that stage) and the 
network suffered no apparent ill effects. So the switch appears to be in 
good working order.

Once I introduce the PI, (by plugging it into the switch, in case that 
isn't obvious) I find I cannot reach it (by ping or by SSH) from inside 
the LAN of my AirStation. For example, from my main Stretch desktop, I 
cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to 
the firewall at 192.168.1.1.

If I SSH into the firewall, and then try to SSH from _there_ to 
192.168.1.3, I can connect no problem. And I log in to the PI to find it 
bright eyed and bushy tailed, and able to connect to the internet (which 
it must do through the firewall just as all traffic from the AirStation 
does). But if I can't see it from the LAN, I can't use it for the 
purpose I spent the last week of my life building it for... :(

Now 192.168.1.1 is the default gateway the firewall supplies the 
AirStation (ie it supplies itself as the gateway) when the AirStation 
makes a DHCP request, and I'm guessing that is why I can reach 
192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I 
am wondering if the AirStation somehow doesn't know that it can reach 
192.168.1.3 directly, which I would expect it to since it is plugged 
into the same switch as it and 192.168.1.1 -- and if so, how I would 
persuade it to know that? I would also expect that if it did not know 
that, it would send packets for 192.168.1.3 to 192.168.1.1 for 
forwarding, just as it does every packet that is destined for the 
internet -- and I would expect the firewall to be able to forward them, 
since it can clearly see the PI.

Can anyone guess what might be wrong with the setup that is preventing 
me from being able to reach 192.168.1.3 from inside the AirStation LAN? 
A

Re: Mixing and Matching DHCP and static IPs

[Henning Follmann]

On Tue, Dec 26, 2017 at 12:23:41AM +0900, Mark Fletcher wrote:
> Greetings and Merry Christmas / Happy Hannukah / insert appropriate 
> greeting here
> 
> There's no way to describe this with all the relevant info in a short 
> way, so I'll try instead to make this as entertaining a read as I can.
> 
> For the first time ever I have tried to introduce a machine with a 
> static IP to my network and it has exposed what I have a horrible 
> feeling is going to turn out to be an embarrassing gap in my knowledge. 
> Some machines in my network can communicate with the new machine, and 
> some can't. I have an "inner network" and an "outer network" and the 
> inner can't see the new machine while the outer can. Details below.
> 
> I run a home network with what might be slightly unusual topology. At 
> the centre of it is a Buffalo Airstation which services a bunch of 
> iDevices, a couple of Androids, a Windoze laptop, and a mini ITX machine 
> running Stretch, and its wired ethernet ports also service a NAS and my 
> main Debian Stretch desktop. Until very recently I ran a cable from the 
> AirStation's WAN port to another mini ITX PC, this one running LFS, 
> which acts as my firewall (I don't trust the firewall in the 
> AirStation). The firewall runs a DHCP server to supply the AirStation 
> with an IP address. The AirStation runs its own DHCP server on its LAN 
> side, giving out IP addresses in the range 192.168.11.0/24, which is how 
> all my machines except the firewall get their IP addresses. The firewall 
> gets its external-facing interface IP via DHCP from my ISP and is static 
> IP on its internal-facing side.
> 
> Recently I threw together LFS on a Raspberry PI and decided to use it as 
> a caching DNS server. My plan is to run dnscache on it. The list may 
> remember a thread I started a few months ago about the best way to solve 
> DNS worries I had back then; I got some good advice at that time and 
> this is me implementing said advice -- at long last I have some time off 
> work and time to work on this.
> 
> If the PI is going to be useful as a caching DNS server for my network, it 
> needs to not be in danger of having its IP address changed -- especially 
> since it is going to need to be sitting outside the AirStation's LAN 
> (since the AirStation insists it is the DNS server for its LAN, but 
> actually merely forwards on all DNS queries to whatever DNS server it 
> has been given in its WAN setup).
> 
> So I bought myself an ethernet switch -- a Netgear ProSAFE Gigabit 
> Switch to be precise -- and have configured the PI to have a static IP 
> on the same subnet as the firewall and the IP address given to the 
> AirStation by the firewall. To be concrete, the internal-facing firewall 
> interface is 192.168.1.1 (static, works), the DHCP server I set up on 
> the firewall gives out 192.168.1.2 to the AirStation (works), and I have 
> configured the PI to use 192.168.1.3 (static, partly works). So inside 
> AirStation LAN is 192.168.11.0/24, outside AirStation LAN is 
> 192.168.1.1, .2 and .3 -- note the third octet difference for internal 
> and external. All 3 of AirStation WAN port, PI and firewall 
> internal-facing interface are plugged into the switch. I ran the switch 
> for a couple of days with just the firewall and the AirStation plugged 
> in (ie the switch was strictly unnecessary at that stage) and the 
> network suffered no apparent ill effects. So the switch appears to be in 
> good working order.
> 
> Once I introduce the PI, (by plugging it into the switch, in case that 
> isn't obvious) I find I cannot reach it (by ping or by SSH) from inside 
> the LAN of my AirStation. For example, from my main Stretch desktop, I 
> cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to 
> the firewall at 192.168.1.1.
> 
> If I SSH into the firewall, and then try to SSH from _there_ to 
> 192.168.1.3, I can connect no problem. And I log in to the PI to find it 
> bright eyed and bushy tailed, and able to connect to the internet (which 
> it must do through the firewall just as all traffic from the AirStation 
> does). But if I can't see it from the LAN, I can't use it for the 
> purpose I spent the last week of my life building it for... :(
> 
> Now 192.168.1.1 is the default gateway the firewall supplies the 
> AirStation (ie it supplies itself as the gateway) when the AirStation 
> makes a DHCP request, and I'm guessing that is why I can reach 
> 192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I 
> am wondering if the AirStation somehow doesn't know that it can reach 
> 192.168.1.3 directly, which I would expect it to since it is plugged 
> into the same switch as it and 192.168.1.1 -- and if so, how I would 
> persuade it to know that? I would also expect that if it did not know 
> that, it would send packets for 192.168.1.3 to 192.168.1.1 for 
> forwarding, just as it does every packet that is destined for the 
> internet -- and I would expe

Re: Mixing and Matching DHCP and static IPs

[Marc Auslander]

The safest way to fix an ip address in a dhcp served network is to tell
the dhcp server to associate that address with the mac of the unit.  The
address should be outside the dhcp range you set up.  I normall pin down
all my connected devices that way, leaving the dhcp assignment for
guests etc.  I've never seen a router which didn't support this.

Re: Mixing and Matching DHCP and static IPs

[Sven Hartge]

Marc Auslander  wrote:

> The safest way to fix an ip address in a dhcp served network is to tell
> the dhcp server to associate that address with the mac of the unit.  The
> address should be outside the dhcp range you set up.  I normall pin down
> all my connected devices that way, leaving the dhcp assignment for
> guests etc.  

The technical term of this is "DHCP reservation".

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Mixing and Matching DHCP and static IPs

[deloptes]

Henning Follmann wrote:

> 1) You talk too much.
> Solution: be precise but not chatty. Get to the point.
> 
> 2) Your network setup is overly complicated.
> Solution: simplify! Also very important: complexity is the enemy of
> security. Your set up should be straight forward that any issue becomes
> apparent without any effort.
> 
> Forget about your caching dns server ( at least for now) It is just
> another layer of complexity in your preexisting mess.

very good summary :)

Mark can start by drawing a diagram of the setup, configuring the DHCP an
DNS and firewall properly.
Ad DHCP Mark, you can setup a range with static and a range with dynamic IP
addresses. All that has static address must still be in the DNS to be
resolved.

I did not get it at which level you split the network in two
(internal/external or private/public) - I assume this is the firewall. It
also means the firewall has 2 interfaces - one for internal and one for
external network. You need a good IP-tables setup to make interconnect
possible.

What I describe is the most simple scenario and as Henning mentioned forget
the dns caching for now, until all this stands. I advise start with
DNS/DHCP in the internal (private) network.

regards

Re: Mixing and Matching DHCP and static IPs

[Nemeth Gyorgy]

2017-12-25 16:23 keltezéssel, Mark Fletcher írta:
> Can anyone guess what might be wrong with the setup that is preventing 
> me from being able to reach 192.168.1.3 from inside the AirStation LAN? 
> And how I could fix it? Google turned up the static-routes option of 
> dhcpd, which it appears could be used to tell the AirStation about the 
> route to 192.168.1.3, but A) I can't figure out how to use that to 
> advise a route that doesn't require a gateway and B) the man page 
> strongly discourages use of that feature (saying words to the effect of 
> "no clients respect this feature, it's useless")...
First check the routing on RPi. If it has only one (default) route to
the gateway (192.168.1.1) then it will not reach your 'internal' network.

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

> Henning Follmann wrote:
> 
> > 1) You talk too much.

And you are rude. Solution: learn some manners. If you don't have the 
attention span to read more than a few lines of prose, I'm not 
interested in your attempts to make that my problem. As others have 
demonstrated, plenty people do.

> > 
> > 2) Your network setup is overly complicated.
> > Solution: simplify! Also very important: complexity is the enemy of
> > security. Your set up should be straight forward that any issue becomes
> > apparent without any effort.
> > 

Nah -- it works fine, and has done for ages, except for this one problem 
which introducing the machine that will be the DNS cache has revealed.

> > Forget about your caching dns server ( at least for now) It is just
> > another layer of complexity in your preexisting mess.

There's no point in forgetting the DNS caching, it's the only reason I'm 
doing any of this, otherwise I already have a perfectly functioning 
network protected by a simple layer of security and there would be 
nothing to do. And where would the fun in that be? :)

Mark

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Mon, Dec 25, 2017 at 06:00:00PM +0100, deloptes wrote:
> Henning Follmann wrote:
> 
> Mark can start by drawing a diagram of the setup, configuring the DHCP an
> DNS and firewall properly.
> Ad DHCP Mark, you can setup a range with static and a range with dynamic IP
> addresses. All that has static address must still be in the DNS to be
> resolved.

Hmmm it seems like you think I'm saying my network is fundamentally 
broken. It isn't -- works fine except for the one problem of not being 
able to reach the PI from the AirStation LAN. If I could just convince 
the AirStation's WAN side that 192.168.1.3 is on the same subnet as it, 
I'd be away.

> 
> I did not get it at which level you split the network in two
> (internal/external or private/public) - I assume this is the firewall. It
> also means the firewall has 2 interfaces - one for internal and one for
> external network. You need a good IP-tables setup to make interconnect
> possible.
> 

split -- there are essentially two splits because there are two 
firewalls -- one of which I want and one I can't turn off. The firewall 
I set up sits at the outermost edge of the network (obviously) and has 2 
interfaces. The other is at the AirStation, which regards its WAN port 
as the outside but that is actually connected to the inside of the real 
firewall.

Firewall, iptables etc -- Yep set that up ages ago. That's been working 
for a year or so. And the two interfaces of the firewall were covered in 
my original post.

> What I describe is the most simple scenario and as Henning mentioned forget
> the dns caching for now, until all this stands. I advise start with
> DNS/DHCP in the internal (private) network.

Again if I drop the dns caching, I would be back to the network I've 
been running up to now which certainly works but continues to have the 
problem I'm trying to solve which is what happens when the ISP changes 
their DNS addresses. My firewall will smoothly switch gears but the 
AirStation won't. The caching DNS server is designed to fix that. Having 
the DHCP server on the firewall pass root DNS servers like 8.8.8.8 to 
the AirStation would dodge the issue, but the advice I got on this forum 
in the past was set up a local DNS cache, and I thought that sounded 
like a fun toy, so here I am.

Mark

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Mon, Dec 25, 2017 at 11:49:17AM -0500, Marc Auslander wrote:
> The safest way to fix an ip address in a dhcp served network is to tell
> the dhcp server to associate that address with the mac of the unit.  The
> address should be outside the dhcp range you set up.  I normall pin down
> all my connected devices that way, leaving the dhcp assignment for
> guests etc.  I've never seen a router which didn't support this.
> 

Thanks, this sounds like a plan. Would doing so be likely to change the 
routing information clients get about how to reach other clients on the 
same subnet? It would SEEM that the problem boils down to 192.168.1.2 
(AirStation) not knowing how to route to 192.168.1.3 (PI), when there is 
no router required here, they can talk directly...

I'll try it anyway. Thanks.

Mark

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Mon, Dec 25, 2017 at 05:53:42PM +0100, Sven Hartge wrote:
> Marc Auslander  wrote:
> 
> > The safest way to fix an ip address in a dhcp served network is to tell
> > the dhcp server to associate that address with the mac of the unit.  The
> > address should be outside the dhcp range you set up.  I normall pin down
> > all my connected devices that way, leaving the dhcp assignment for
> > guests etc.  
> 
> The technical term of this is "DHCP reservation".
> 

Thanks Sven, that will help me find documentation on doing this with dhcpd.

Mark

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 25/12/2017 à 16:23, Mark Fletcher a écrit :


There's no way to describe this with all the relevant info in a short
way


Yes there is a way. You really talk too much.


so I'll try instead to make this as entertaining a read as I can.


You failed. Ther result is just long and boring.


the internal-facing firewall
interface is 192.168.1.1 (static, works), the DHCP server I set up on
the firewall gives out 192.168.1.2 to the AirStation (works), and I have
configured the PI to use 192.168.1.3 (static, partly works). So inside
AirStation LAN is 192.168.11.0/24, outside AirStation LAN is
192.168.1.1, .2 and .3 -- note the third octet difference for internal
and external.

(...)

Once I introduce the PI, (by plugging it into the switch, in case that
isn't obvious) I find I cannot reach it (by ping or by SSH) from inside
the LAN of my AirStation. For example, from my main Stretch desktop, I
cannot ping or SSH to the PI at 192.168.1.3.


What happens when you try ?


If I SSH into the firewall, and then try to SSH from _there_ to
192.168.1.3, I can connect no problem. And I log in to the PI to find it
bright eyed and bushy tailed, and able to connect to the internet (which
it must do through the firewall just as all traffic from the AirStation
does). But if I can't see it from the LAN, I can't use it for the
purpose I spent the last week of my life building it for... :(


What is the netmask configured on the Pi ? Can you show the full routing 
table on the Pi ?
What are the subnet and netmask advertised by the DHCP server running on 
the firewall ?
Can you display the full routing table of the Airstation, including 
routes on the WAN interface ?


Did you run a packet sniffer on the firewall and the Pi to look what's 
going on ?

Re: Mixing and Matching DHCP and static IPs

[Gene Heskett]

On Monday 25 December 2017 19:54:10 Mark Fletcher wrote:

> On Mon, Dec 25, 2017 at 06:00:00PM +0100, deloptes wrote:
> > Henning Follmann wrote:
> >
> > Mark can start by drawing a diagram of the setup, configuring the
> > DHCP an DNS and firewall properly.
> > Ad DHCP Mark, you can setup a range with static and a range with
> > dynamic IP addresses. All that has static address must still be in
> > the DNS to be resolved.
>
> Hmmm it seems like you think I'm saying my network is fundamentally
> broken. It isn't -- works fine except for the one problem of not being
> able to reach the PI from the AirStation LAN. If I could just convince
> the AirStation's WAN side that 192.168.1.3 is on the same subnet as
> it, I'd be away.
>
Have you looked at the AirStations web page? There may be a bridge option 
that is not turned on. But that will mean you'll need the devils own 
firewall because that will allow drive by hackers free access to your 
home network.  And Grandpa Gene here may do odd things, but thats NOT 
one of them.

> > I did not get it at which level you split the network in two
> > (internal/external or private/public) - I assume this is the
> > firewall. It also means the firewall has 2 interfaces - one for
> > internal and one for external network. You need a good IP-tables
> > setup to make interconnect possible.
>
> split -- there are essentially two splits because there are two
> firewalls -- one of which I want and one I can't turn off. The
> firewall I set up sits at the outermost edge of the network
> (obviously) and has 2 interfaces. The other is at the AirStation,
> which regards its WAN port as the outside but that is actually
> connected to the inside of the real firewall.
>
> Firewall, iptables etc -- Yep set that up ages ago. That's been
> working for a year or so. And the two interfaces of the firewall were
> covered in my original post.
>
> > What I describe is the most simple scenario and as Henning mentioned
> > forget the dns caching for now, until all this stands. I advise
> > start with DNS/DHCP in the internal (private) network.
>
> Again if I drop the dns caching, I would be back to the network I've
> been running up to now which certainly works but continues to have the
> problem I'm trying to solve which is what happens when the ISP changes
> their DNS addresses. My firewall will smoothly switch gears but the
> AirStation won't. The caching DNS server is designed to fix that.
> Having the DHCP server on the firewall pass root DNS servers like
> 8.8.8.8 to the AirStation would dodge the issue, but the advice I got
> on this forum in the past was set up a local DNS cache, and I thought
> that sounded like a fun toy, so here I am.
>
> Mark


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Out of root partition space

[Sarah Johnson]

Hi,
I ran out of root partition disk space and can't install or remove any more 
packages or even login gui window manager anymore

i spent few good hours researching for solutions and found that i can resize 
root and home partitions using resize2fs and lvresize tools but they are not 
even installed on my system

so is it safe to resize debian root and other partitions using windows machine 
partitioning tool ?
knowing that my debian installation is on a USB stick

Thanks
-- 
Sarah Johnson

Re: Mixing and Matching DHCP and static IPs

[Paul Johnson]

On Mon, Dec 25, 2017 at 10:49 AM, Marc Auslander 
wrote:

> The safest way to fix an ip address in a dhcp served network is to tell
> the dhcp server to associate that address with the mac of the unit.  The
> address should be outside the dhcp range you set up.  I normall pin down
> all my connected devices that way, leaving the dhcp assignment for
> guests etc.  I've never seen a router which didn't support this.
>
>
Or, just tell the DHCP server that you want a specific MAC address to
always be assigned to a specific IP address.  It doesn't matter if it's in
or out of the assignment range, then, or whether or not the unit in
question understands DHCP or is configured manually on it's end; the DHCP
server will not assign another client to that IP.  Though for ease of
dealing with static assignments, I personally find it much simpler to do it
all at the DHCP server end only if the client end speaks DHCP, just in the
off chance I need to change the network configuration later.

GRUB and boot partition

[microsoft gaofei]

https://wiki.archlinux.org/index.php/GRUB#Boot_partition  . ArchWiki has 
carried an introduction of GRUB , it offers a feature to decrypt your 
partitions and you don't need to separate /boot . Debian also uses GRUB as its 
boot loader ,but Debian still separates /boot partition and leave it unencrypted

Re: Out of root partition space

[Doug]

On 12/25/2017 08:44 PM, Sarah Johnson wrote:

Hi,
I ran out of root partition disk space and can't install or remove any 
more packages or even login gui window manager anymore


i spent few good hours researching for solutions and found that i can 
resize root and home partitions using resize2fs and lvresize tools but 
they are not even installed on my system


so is it safe to resize debian root and other partitions using windows 
machine partitioning tool ?

knowing that my debian installation is on a USB stick

Thanks
--
Sarah Johnson 
Why not download GParted--the version that runs off a CD, and burn 
it--and use that? At least it's Linux, and has a lot of capability, like 
changing partition sizes, making new ones, moving existing ones, etc.


--doug

Re: Out of root partition space

[john doe]

On 12/26/2017 5:04 AM, Doug wrote:


On 12/25/2017 08:44 PM, Sarah Johnson wrote:

Hi,
I ran out of root partition disk space and can't install or remove any 
more packages or even login gui window manager anymore


i spent few good hours researching for solutions and found that i can 
resize root and home partitions using resize2fs and lvresize tools but 
they are not even installed on my system


so is it safe to resize debian root and other partitions using windows 
machine partitioning tool ?

knowing that my debian installation is on a USB stick

Thanks
--
Sarah Johnson 
Why not download GParted--the version that runs off a CD, and burn 
it--and use that? At least it's Linux, and has a lot of capability, like 
changing partition sizes, making new ones, moving existing ones, etc.




Rescue mode seems a good choise to start with.
I wouldn't use windows for that unless you have some spare time! :)
Maybe backing up your home partition might be a good idea.

--
John Doe

Re: Out of root partition space

[David Baron]

Isn't the Debian I installed wonderful!
I ended up putting in an additional drive and repartitioning to solve this.

On Tue, Dec 26, 2017, 8:34 AM john doe  wrote:

> On 12/26/2017 5:04 AM, Doug wrote:
> >
> > On 12/25/2017 08:44 PM, Sarah Johnson wrote:
> >> Hi,
> >> I ran out of root partition disk space and can't install or remove any
> >> more packages or even login gui window manager anymore
> >>
> >> i spent few good hours researching for solutions and found that i can
> >> resize root and home partitions using resize2fs and lvresize tools but
> >> they are not even installed on my system
> >>
> >> so is it safe to resize debian root and other partitions using windows
> >> machine partitioning tool ?
> >> knowing that my debian installation is on a USB stick
> >>
> >> Thanks
> >> --
> >> Sarah Johnson
> > Why not download GParted--the version that runs off a CD, and burn
> > it--and use that? At least it's Linux, and has a lot of capability, like
> > changing partition sizes, making new ones, moving existing ones, etc.
> >
>
> Rescue mode seems a good choise to start with.
> I wouldn't use windows for that unless you have some spare time! :)
> Maybe backing up your home partition might be a good idea.
>
> --
> John Doe
>
>