'ping' uses localhost instead of public IP address












5














Let's say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.



When I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:



# ping server1.mydomain.com

PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms


But with tcpdump, I can see no ICMP traffic on eth0 and instead see the pings coming through lo:



# tcpdump -i lo

listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes

08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64

08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64

08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64

08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64

08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64

08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64


This behaviour is not limited to ping. I get the same with wget.



Why is this happening? Is this something caused by the configuration on my server?



I am using Debian 9 (Stretch).






networking routing wget ping tcpdump







share|improve this question




















  • 1




    This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
    – roaima
    15 hours ago










  • @roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.
    – Martin Vegter
    15 hours ago






  • 4




    You wanted to ping the machine at 11.22.33.44 (or server1.mydomain.com) and you did... The interface is irrelevant in your case because your packet does not need to be routed.
    – std_unordered_map
    13 hours ago








  • 1




    You may block all the exits in or out of your "room", but it won't stop you from reaching your "room" if you are already there...
    – std_unordered_map
    13 hours ago






  • 8




    Physically, if it actually went out on eth0 it wouldn't be received, an Ethernet interface doesn't "hear" what it's sending. So in any case, there needs to be a shortcut somewhere that says "oh this is a local packet, it must be handled locally". Probably easier to redirect the packet to lo0 than adding a "handle outbound traffic as inbound path", though one would have to check the relevant RFCs for correctness.
    – jcaron
    12 hours ago
















5














Let's say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.



When I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:



# ping server1.mydomain.com

PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms


But with tcpdump, I can see no ICMP traffic on eth0 and instead see the pings coming through lo:



# tcpdump -i lo

listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes

08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64

08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64

08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64

08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64

08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64

08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64


This behaviour is not limited to ping. I get the same with wget.



Why is this happening? Is this something caused by the configuration on my server?



I am using Debian 9 (Stretch).






networking routing wget ping tcpdump







share|improve this question




















  • 1




    This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
    – roaima
    15 hours ago










  • @roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.
    – Martin Vegter
    15 hours ago






  • 4




    You wanted to ping the machine at 11.22.33.44 (or server1.mydomain.com) and you did... The interface is irrelevant in your case because your packet does not need to be routed.
    – std_unordered_map
    13 hours ago








  • 1




    You may block all the exits in or out of your "room", but it won't stop you from reaching your "room" if you are already there...
    – std_unordered_map
    13 hours ago






  • 8




    Physically, if it actually went out on eth0 it wouldn't be received, an Ethernet interface doesn't "hear" what it's sending. So in any case, there needs to be a shortcut somewhere that says "oh this is a local packet, it must be handled locally". Probably easier to redirect the packet to lo0 than adding a "handle outbound traffic as inbound path", though one would have to check the relevant RFCs for correctness.
    – jcaron
    12 hours ago














5












5








5







Let's say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.



When I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:



# ping server1.mydomain.com

PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms


But with tcpdump, I can see no ICMP traffic on eth0 and instead see the pings coming through lo:



# tcpdump -i lo

listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes

08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64

08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64

08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64

08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64

08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64

08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64


This behaviour is not limited to ping. I get the same with wget.



Why is this happening? Is this something caused by the configuration on my server?



I am using Debian 9 (Stretch).






networking routing wget ping tcpdump







share|improve this question















Let's say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.



When I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:



# ping server1.mydomain.com

PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms

64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms


But with tcpdump, I can see no ICMP traffic on eth0 and instead see the pings coming through lo:



# tcpdump -i lo

listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes

08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64

08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64

08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64

08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64

08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64

08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64


This behaviour is not limited to ping. I get the same with wget.



Why is this happening? Is this something caused by the configuration on my server?



I am using Debian 9 (Stretch).






networking routing wget ping tcpdump




networking routing wget ping tcpdump






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 4 mins ago









Peter Mortensen

87958




87958










asked 17 hours ago









Martin Vegter

31334120234




31334120234








  • 1




    This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
    – roaima
    15 hours ago










  • @roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.
    – Martin Vegter
    15 hours ago






  • 4




    You wanted to ping the machine at 11.22.33.44 (or server1.mydomain.com) and you did... The interface is irrelevant in your case because your packet does not need to be routed.
    – std_unordered_map
    13 hours ago








  • 1




    You may block all the exits in or out of your "room", but it won't stop you from reaching your "room" if you are already there...
    – std_unordered_map
    13 hours ago






  • 8




    Physically, if it actually went out on eth0 it wouldn't be received, an Ethernet interface doesn't "hear" what it's sending. So in any case, there needs to be a shortcut somewhere that says "oh this is a local packet, it must be handled locally". Probably easier to redirect the packet to lo0 than adding a "handle outbound traffic as inbound path", though one would have to check the relevant RFCs for correctness.
    – jcaron
    12 hours ago














  • 1




    This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
    – roaima
    15 hours ago










  • @roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.
    – Martin Vegter
    15 hours ago






  • 4




    You wanted to ping the machine at 11.22.33.44 (or server1.mydomain.com) and you did... The interface is irrelevant in your case because your packet does not need to be routed.
    – std_unordered_map
    13 hours ago








  • 1




    You may block all the exits in or out of your "room", but it won't stop you from reaching your "room" if you are already there...
    – std_unordered_map
    13 hours ago






  • 8




    Physically, if it actually went out on eth0 it wouldn't be received, an Ethernet interface doesn't "hear" what it's sending. So in any case, there needs to be a shortcut somewhere that says "oh this is a local packet, it must be handled locally". Probably easier to redirect the packet to lo0 than adding a "handle outbound traffic as inbound path", though one would have to check the relevant RFCs for correctness.
    – jcaron
    12 hours ago








1




1




This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
15 hours ago




This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
15 hours ago












@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.
– Martin Vegter
15 hours ago




@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.
– Martin Vegter
15 hours ago




4




4




You wanted to ping the machine at 11.22.33.44 (or server1.mydomain.com) and you did... The interface is irrelevant in your case because your packet does not need to be routed.
– std_unordered_map
13 hours ago






You wanted to ping the machine at 11.22.33.44 (or server1.mydomain.com) and you did... The interface is irrelevant in your case because your packet does not need to be routed.
– std_unordered_map
13 hours ago






1




1




You may block all the exits in or out of your "room", but it won't stop you from reaching your "room" if you are already there...
– std_unordered_map
13 hours ago




You may block all the exits in or out of your "room", but it won't stop you from reaching your "room" if you are already there...
– std_unordered_map
13 hours ago




8




8




Physically, if it actually went out on eth0 it wouldn't be received, an Ethernet interface doesn't "hear" what it's sending. So in any case, there needs to be a shortcut somewhere that says "oh this is a local packet, it must be handled locally". Probably easier to redirect the packet to lo0 than adding a "handle outbound traffic as inbound path", though one would have to check the relevant RFCs for correctness.
– jcaron
12 hours ago




Physically, if it actually went out on eth0 it wouldn't be received, an Ethernet interface doesn't "hear" what it's sending. So in any case, there needs to be a shortcut somewhere that says "oh this is a local packet, it must be handled locally". Probably easier to redirect the packet to lo0 than adding a "handle outbound traffic as inbound path", though one would have to check the relevant RFCs for correctness.
– jcaron
12 hours ago










1 Answer
1






active

oldest

votes


















9














The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.



Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.






share|improve this answer








New contributor




std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • actually that new network namespace does have (only) a loopback interface, but it's down by default
    – A.B
    8 hours ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491859%2fping-uses-localhost-instead-of-public-ip-address%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









9














The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.



Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.






share|improve this answer








New contributor




std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • actually that new network namespace does have (only) a loopback interface, but it's down by default
    – A.B
    8 hours ago
















9














The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.



Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.






share|improve this answer








New contributor




std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • actually that new network namespace does have (only) a loopback interface, but it's down by default
    – A.B
    8 hours ago














9












9








9






The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.



Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.






share|improve this answer








New contributor




std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.



Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.







share|improve this answer








New contributor




std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 16 hours ago









std_unordered_map

1115




1115




New contributor




std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • actually that new network namespace does have (only) a loopback interface, but it's down by default
    – A.B
    8 hours ago


















  • actually that new network namespace does have (only) a loopback interface, but it's down by default
    – A.B
    8 hours ago
















actually that new network namespace does have (only) a loopback interface, but it's down by default
– A.B
8 hours ago




actually that new network namespace does have (only) a loopback interface, but it's down by default
– A.B
8 hours ago


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491859%2fping-uses-localhost-instead-of-public-ip-address%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Entries order in /etc/network/interfaces

Image
4 I have a device with two interfaces, eth0 and eth1. One should get its IP from a DHCP server and the other should get its IP statically. If my /etc/network/interfaces file is configured as follows: auto lo iface lo inet loopback auto eth1 iface eth1 inet dhcp iface eth1 inet6 auto auto eth0 iface eth0 inet static address 10.10.10.10 netmask 255.255.255.0 Everything works great, eth1 gets its IP from the DHCP server, eth0 sets its IP statically from the information given, but if I try to change the order in the file, such as auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.10.10.10 netmask 255.255.255.0 auto eth1 iface eth1 inet dhcp iface eth1 inet6 auto In this case, eth1 fails to get an IP. Does the /etc/network/interface care about th...
Read more

新発田市

Image
しばたし 新発田市 市のシンボル・新発田城（二の丸隅櫓） 新発田市旗 1934年7月9日制定 新発田市章 1934年7月9日制定 国 日本 地方 中部地方、北陸地方 甲信越地方、信越地方 都道府県 新潟県 団体コード 15206-4 法人番号 5000020152064 面積 533.10 km 2 総人口 96,267 人 [編集] （推計人口、2018年10月1日） 人口密度 181 人/km 2 隣接自治体 新潟市、阿賀野市、胎内市、北蒲原郡聖籠町、東蒲原郡阿賀町 福島県喜多方市 山形県西置賜郡小国町 市の木 サクラ 市の花 アヤメ 市のシンボル 新発田城 新発田市役所 市長 [編集] 二階堂馨 所在地 〒 957-8686 新潟県新発田市中央町3丁目3番3号 北緯37度56分52.5秒東経139度19分38.2秒 外部リンク 公式ウェブサイト ■ ― 政令指定都市 / ■ ― 市 / ■ ― 町 / ■ ― 村 地理院地図 Google Bing GeoHack MapFan Mapion Yahoo! NAVITIME ゼンリン   表示   ウィキプロジェクト 新発田市中心部周辺の空中写真。 1975年撮影の8枚を合成作成。国土交通省 国土画像情報（カラー空中写真）を基に作成。 新発田市 （しばたし）は、新潟県下越地方にある市である。新潟市への通勤率は16.6%（平成22年国勢調査）。 目次 1 概要 2 地理 2.1 隣接している自治体・行政区 3 地域・市街地構成 4 歴史 4.1 市名の由来 4.2 沿革 5 人口 6 行政 6.1 市長 7 経済 7.1 産業 7.1.1 市内の主な企業 7.1.2 漁業 8 姉妹都市・提携都市 8.1 国内 8.2 海外 9 施設・...
Read more

Grub takes very long (several minutes) to open Menu (in Multi-Boot-System)

Image
0 I have a Multi-Boot-System with 4 different installations of Linux. (1 Manjaro, 3 Mint) spread over 2 hard drives (2 on each). After doing grub-install /dev/sdX and update-grub several times within each installation ... the Grub-menu needs more and more time to open. It started with a few more seconds, now it takes several minutes. I tried to purge and reinstall Grub but this made the problem even worse: apt-get purge grub grub-pc grub-common apt-get install grub-common grub-pc os-prober update-grub What could be causing this problem? linux grub2 multiboot share | improve this question edited 4 mins ago ...
Read more