This is still an issue in Ubuntu 16.04, now initramfs-tools
unconditionally calls `wait-for-root /dev/nbd0 10` without even using
ROOTDELAY.
I also reported this bug to https://github.com/yoe/nbd/issues/36.
--
You received this bug notification because you are a member of Ubuntu
Server Team,
Hi Robie,
from https://wiki.ubuntu.com/Bugs/Importance => Critical:
> Renders the system temporarily or permanently unusable
Yup, especially if you are on a single core system and you've never heard of
what a terminal or a `kill -9 `is.
> Severely affects applications beyond the package
Lefteris, could you add the upstream patch here and follow all the SRU
steps? Thank you!
** Changed in: socat (Ubuntu)
Importance: Undecided => Critical
** Changed in: socat (Ubuntu)
Status: New => Confirmed
** Bug watch added: Debian Bug tracker #803378
*** This bug is a duplicate of bug 158 ***
https://bugs.launchpad.net/bugs/158
Hi, as the bug title says, it's a problem with socat, not with epoptes.
We cannot solve it in the epoptes code.
We've had reported it in https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=803378, you can
Hi Robie,
while this also happens in Debian, the use case is more common in Ubuntu,
because NetworkManager is patched to use a spawned dnsmasq instance as a local
resolver, and mixing the two DNS servers is problematic (neither bind-dynamic
nor bind-interfaces work very well).
In Debian they
Better regex to avoid a possibly commented #port=0:
grep -qr "^[[:space:]]*port=0" /etc/dnsmasq.d/ /etc/dnsmasq.conf && return
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Public bug reported:
The following function is defined in /etc/init.d/dnsmasq:
start_resolvconf()
{
# If interface "lo" is explicitly disabled in /etc/default/dnsmasq
# Then dnsmasq won't be providing local DNS, so don't add it to
# the resolvconf server set.
for interface in
Jaunty is EOL, closing this bug report.
** Changed in: nbd (Ubuntu)
Status: Confirmed = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nbd in Ubuntu.
https://bugs.launchpad.net/bugs/381766
Title:
nbd-server no
I think the problem is the missing ID_FS_TYPE in udev for nbd devices,
and that it's also reported more properly there:
https://bugs.freedesktop.org/show_bug.cgi?id=62565
Maybe wait-for-root could find some better workaround when ID_FS_TYPE is
unset though, e.g. checking the output of `blkid`...
Yes, it's still an issue in Trusty.
Also please use Incomplete, not Invalid when you need feedback from a bug
reporter.
root@ltsp241:~# blkid
/dev/nbd0: TYPE=squashfs
/dev/nbd1: UUID=d7bfcbc8-9718-46f9-b9e3-daf9e46f596a TYPE=swap
/dev/sr0: LABEL=Ubuntu 10.04.3 LTS i386 TYPE=iso9660
Hmmm, maybe this is an easier way to reproduce something similar without
using NBD at all:
wait-for-root /dev/sr0 1
succeeds in a booted system,
but fails from the initramfs if one adds break=bottom in the kernel command
line.
It succeeds in both cases for e.g. /dev/sda1.
--
You received
No, it's not an issue anymore in 14.04, so Wouter must have fixed it.
Marking as fix released.
** Changed in: nbd (Ubuntu)
Status: Incomplete = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nbd in Ubuntu.
Mathieu, I reopened this bug because it was never resolved... not just for the
TFTP issue.
Please see my #143 comment.
If you want more feedback tell me what to send, but DNS never worked properly
for me when dnsmasq and nm-dnsmasq are both running.
--
You received this bug notification
Thomas, yup, TFTP appears to be working fine with bind-dynamic.
I'll test if re-enabling dns=dnsmasq in
/etc/NetworkManager/NetworkManager.conf along with bind-dynamic allows
dnsmasq co-exist with nm-dnsmasq, and report back.
Thanks!
--
You received this bug notification because you are a
The fix for this issue caused another regression, dnsmasq now doesn't
function correctly as a tftp server either.
I just tried Trusty (dnsmasq 2.68-1), and network manager ships
/etc/dnsmasq.d/network-manager with:
bind-interfaces
So now dnsmasq only binds 127.0.0.1 for its tftp service:
udp
Or better yet, ltsp-server-standalone could Conflict: network-manager-
local-resolver so that all LTSP sysadmins that use dnsmasq don't bother
searching for a solution and manually editing configuration files...
--
You received this bug notification because you are a member of Ubuntu
Server
I'm still having problems with this on 14.04.
After the default installation, I installed dnsmasq and DNS stopped
working until system restart.
Now it's only working for a few seconds after each network-manager
restart!
If I comment out
#dns=dnsmasq
in NetworkManager.conf, then everything is
With the 12.04.2 CD shipping linux-generic-lts-quantal, Samba is now
completely unusable due to this bug.
Is someone working on SRU'ing it, or we're waiting for someone to do the
bureaucratic stuff like updating the bug description as per
** Description changed:
- Sorry for not being of any help here. I don't really know what happened.
- There was suddenly a report about a system problem. and apport started.
- just updated a few hours ago.
+ [Impact]
+ 12.04.2 users cannot share dirs with Samba due to smbd crashing with
To my own surprise I haven't seen any complaints related to the switch
from 127.0.0.1 to 127.0.1.1, even though I have been following AskUbuntu
and ubuntuforums.
It's possible that a large portion of Ubuntu users that are using dnsmasq as a
DNS server, only use LTS releases, so complains might
...and may I also suggest ipxe.usb, for those that need a quick solution
with dd and a usb stick. :)
http://ipxe.org/download#using_a_boot_cd-rom_or_usb_key
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipxe in Ubuntu.
Public bug reported:
For some older computers with no hard disks, it might be desired to boot
them from the network via a floppy disk, so shipping
/usr/lib/ipxe/ipxe.dsk would be useful.
Please generate and include ipxe.dsk to the ipxe binary package.
** Affects: ipxe (Ubuntu)
Importance:
This assumption is, er, questionable.
True, but if you don't mind, let's examine that question a bit.
This is the NM-spanwed command line:
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces
--pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid
(Another minor problem with your proposal as you phrased it is the
following. The existence of /etc/init.d/dnsmasq does not entail that the
dnsmasq is installed. The package could have been removed and not
purged.)
Correct, but then I wonder what prevents dnsmasq from running even if it's
NM kills and starts a new dnsmasq process every time this file
changes. Will that be a problem for your LTSP setup where dnsmasq is
also the DHCP server?
The most time consuming operation that dnsmasq does in our setups is
sending the kernel/initrd via TFTP. That takes a few seconds. If the
The real dnsmasq command line is:
/usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r
/var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
I think that NM would just need to update /var/run/dnsmasq/resolv.conf
instead of creating+updating
Would it be remotely possible in the future for the problem to be addressed
inside libc itself?
Other people not using NM or dnsmasq would still welcome the split VPN
resolving, right?
Should we file a wishlist bug request for it?
--
You received this bug notification because you are a member
I was reading about bind-interfaces at
http://www.thekelleys.org.uk/dnsmasq/docs/FAQ and I'm wondering, are
there any use cases that will have problems with bind-interfaces and the
standalone dnsmasq instance?
* Suppose a teacher boots her laptop (==LTSP server) without a network cable
plugged
Thanks, so until the #3 idea is implemented (if ever), I'll be disabling the
NM-spawned dnsmasq.
But of course the #2 idea is good enough for many cases, thank you all for your
work on this.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
What if NM always dropped whatever configuration file it needs in
/etc/dnsmasq.d/nm.conf,
and when NM was started, it would check if /etc/init.d/dnsmasq exists,
* if yes, dnsmasq is installed, so it read the configuration file and there's
no need to do anything,
* if not, dnsmasq-base is
In reply to #58, sorry, defining multiple except-interface= directives
works fine in my 2.59-4 after all, I think I might have used except-
interfaces, plural.
Solution #2 sounds good to me too. :)
If I understand well, a dnsmasq-base SRU is in order for 12.04 anyway to fix
the tftp issue, so
Note that while bind-interfaces can be specified multiple times,
defining except-interfaces more than once is a syntax error in my
dnsmasq 2.59-4.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
I tested bind-interfaces and except-interface=lo in the past (comment
#26), it worked as advertised. I haven't yet tested them in the chained
dnsmasq mode, but I guess it would work if I'm using a static IP (which
isn't always the case for LTSP servers, some teachers use their laptops
for LTSP
* Change NM such that it causes its slave dnsmasq to listen on ::1
instead of 127.0.0.1
Personally, when I install dnsmasq, I *don't want* to use the NM-spawned
dnsmasq, because it disables caching etc etc. So it wouldn't matter if
it listened on another address, on a socket or wherever else; I
It's better to eliminate the behavioral conflict, if we can, than to
formalize that conflict as a packaging dependency.
I was about to say this:
But then the main problem which caused me to report this bug would remain:
When I install the dnsmasq package, it wouldn't work.
I'd configure my
** Summary changed:
- Standalone dnsmasq is not compatible out of the box with NM+dnsmasq
+ Don't start local resolver if a DNS server is installed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
@jdthood: the Standalone dnsmasq is not compatible out of the box with
NM+dnsmasq title hints that the problem is caused by the dnsmasq
package, i.e. that it should be crippled and not listen on lo by
default in order to coexist with the local resolver implementation.
I don't think this is the
@Thomas: cool, I hope this one's better.
** Summary changed:
- Don't start local resolver if a DNS server is installed
+ Local resolver prohibits DNS servers from running
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in
Thomas, that was a very good summary at comment #33!
Why do you need the dnsmasq package at all? You want NM and dnsmasq.
Why not just use the NM-enslaved dnsmasq?
The NM-enslaved dnsmasq uses hardcoded options (in C) that provide extremely
limited functionality.
* It doesn't listen on ethX
The configuration itself shipped by default should be patched
If you mean something like:
except-interface=lo
bind-interfaces
...I just tested them and they do allow both dnsmasq instances to run.
But of course those settings won't be acceptable to most dnsmasq users,
as listening on lo is
** Also affects: dnsmasq (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
Don't start local resolver if a DNS
Since this won't be fixed for Precise from the network-manager side, the
dnsmasq package now is broken by default in desktop installations.
So I've added the dnsmasq package in the Affects: list, to make it easier for
people to locate the cause of the problem so that fewer duplicate bug reports
Maybe the problem is that software-center spawns debconf-communicate
with the user id instead of as root:
alkisg7368 1.7 0.5 65404 23364 pts/1Sl+ 07:48 0:00
/usr/bin/perl -w /usr/bin/debconf-communicate
I tried making a debconf-communicate wrapper, to force running it as root
I'm not sure if the erroneously hidden root password debconf question
comes from phpmyadmin or from dbconfig-common, so I put dbconfig-common
to the affects list as well.
** Also affects: dbconfig-common (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification
I ran software-center from the console, and I noticed this error:
debconf: DbDriver passwords warning: could not open
/var/cache/debconf/passwords.dat: access denied
Then I tried from scratch, by running ***sudo*** software-center
And everything worked fine, the password questions were
I tried: gdebi-gtk /var/cache/apt/archives/phpmyadmin_4%3a3.4.10.1-1_all.deb
without using sudo, and everything worked fine again, the debconf password
questions were displayed.
So the bug is probably in software-center.
--
You received this bug notification because you are a member of Ubuntu
Marking Fix Released - please re-open if this is not the case.
Confirming that it works fine now, thank you.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipxe in Ubuntu.
https://bugs.launchpad.net/bugs/916489
Title:
grub-ipxe
I'd love to see your iPXE boot script.
The easiest version is this:
#!ipxe
# We do assume that a DHCP server exists on the local network, e.g. a home
router
autoboot
# The rest only happens if no local *boot* server exists
kernel
Public bug reported:
First of all thanks a lot for the ipxe package, it's most helpful. :)
I just tried grub-ipxe 1.0.0+git-2.149b50-1ubuntu4 in kubuntu precise, and it
installed fine. But after selecting it in grub, and after the usual iPXE
headers, I got:
B: command not found
At that point
Public bug reported:
Please put ipxe.lkrn as a boot option in the isolinux menu of the live
CDs, so that they can be used to netboot computers, either for network-
based installation, or as LTSP clients, etc.
The embedded iPXE script would do this:
1) autoboot (that's an iPXE command)
2) on
I installed it into a vbox client so I was able to get a screenshot of
the B: command not found problem.
I talked with the devs in #ipxe about it, they say the problem was
related to the grub command line handling, and was fixed in
I did not see the issue myself, but the reporter and another person
(comments #1 and #2) say that for them, /etc/default/tftpd-hpa contained
/srv/tftp instead of the expected /var/lib/tftpboot, and that caused
the message forbidden directory to be displayed.
I don't know under which circumstances
As far as I know, this bug consists of three separate bugs, one in
tftpd-hpa (==when installing from the alternate CD tftpd-hpa uses /srv
while when installing from the desktop CD it uses /var/lib/tftpboot),
one in compiz, and a sound problem.
So I'm marking it invalid for LTSP and I'm putting
** Also affects: ltsp (Ubuntu)
Importance: Undecided
Status: New
--
tftpd-hpa doesn't start on boot
https://bugs.launchpad.net/bugs/522509
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tftp-hpa in ubuntu.
--
Public bug reported:
Binary package hint: tftp-hpa
tftpd-hpa version: 5.0-11ubuntu1
tftpd-hpa doesn't start on boot for me:
syslog.1:Feb 16 08:26:43 alkis in.tftpd[1399]: cannot resolve local IPv4 bind
address: 0.0.0.0, Name or service not known
But if I put a sleep 30 on top of
55 matches
Mail list logo
