** Changed in: netcfg (Ubuntu Lucid)
Milestone: None = ubuntu-10.04.3
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is a bug assignee.
https://bugs.launchpad.net/bugs/56679
Title:
provide a method to use a specified MAC-address as the
** Tags added: ipv6
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in Ubuntu.
https://bugs.launchpad.net/bugs/628145
Title:
Eucalyptus does not understand IPv6
--
Ubuntu-server-bugs mailing list
Public bug reported:
Binary package hint: bacula-console-qt
On lucid, in the Version Browser of bat, it is impossible to check the
latest version of a file. This is described in the following upstream
bug report: http://bugs.bacula.org/view.php?id=1550 (login using
anonymous/anonymous)
For
The error seems to be cosmetic, as the service would still start (I have
not checked in depth, though). Still, the fix is trivial and really
ought to be SRU'ed at some point, IMHO.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
Public bug reported:
Binary package hint: samba
The Samba postinst maintainer script systematically import all account
with uid = 1000. This is so that user account and such have
corresponding Samba account. In most case, this is a good thing and
make. However, where the machine has been
As Thierry and Anders pointed out above, this might be causing breakage.
See bug #605326, for example.
Considering we are installing recommended package by default, this ought
to be reviewed. I think winbind should be made a Suggests of wine
instead, since the NTLM authentication feature is not
As a note, you need to turn on verbosity by adding -v to TFTP_OPTIONS in
/etc/default/tftpd-hpa, otherwise the daemon do not log file get.
Useful to know when testing.
Beside, I can confirm the proposed update fix the bug too.
--
You received this bug notification because you are a member of
Dave: again, sorry I can't produce the correct text, as I am not sure
what the exact behavior is supposed to be. Feel free to mark as Won't
Fix, if you think it does not deserve to be clarified.
** Changed in: eucalyptus (Ubuntu)
Status: Expired = Confirmed
--
You received this bug
On 10-12-03 02:08 PM, Clint Byrum wrote:
I also see in the
DpkgTerminalLog.gz that nmbd fails to stop, meaning it is not running. I
may be wrong here, but I believe nmbd is necessary for winbind.
No, nmbd is not strictly required for winbindd. But the fact that nmbd
fail to start is indeed
Unless I am mistaken, this bug render likewise-open DOA. Now that the
last update to openldap in maverick-proposed has gone through, I guess
it would be a good time to push this one.
Not trying to push anybody around. I swear, I would do it myself if I
had the credentials! :)
--
Existing
Alexandre, I had the same problem. The root cause was that the server
directive in the client's puppet.conf did not match the hostname that
was used in the puppetmaster certificate. Check your puppetmaster
certificate with sudo puppetmaster -p puppetmaster (where
puppetmaster is the hostname of
Public bug reported:
Binary package hint: libnss-ldap
This has been researched on Lucid, but also affect earlier releases.
libnss-ldap depends on ldap-auth-config, which depends on ldap-auth-
client, which depends on libpam-ldap. This means that installing
libnss-ldap will systematically pull
Dave: I would love to, except I am not too sure what the expected
behavior is. It would be best if someone who actually knows what's
going on write the text in question.
--
Confusing comment in /etc/eucalyptus/eucalyptus.conf
https://bugs.launchpad.net/bugs/604400
You received this bug
Public bug reported:
In Lucid, in the file /etc/eucalyptus/eucalyptus.conf, the following
comment can be found near the bottom:
# Administrative overrides and customizations may go below, in accordance
# with the manpage for eucalyptus.conf(5).
Reading the above, one can be lead to think that
For the record, that bug made me lost a couple of hours, and left me
quite frustrated. I think it is serious enough to deserve a fix (ie,
clarifying the behavior in the in-line comment).
--
Confusing comment in /etc/eucalyptus/eucalyptus.conf
https://bugs.launchpad.net/bugs/604400
You received
H.M., fully agreed on all points. This topic have been brought up in
the past two UDS; not sure what the roadmap for resolution is.
--
How to decrease cloud-debug / cloud-error log verbosity (or disable them)
https://bugs.launchpad.net/bugs/463449
You received this bug notification because you
Public bug reported:
Binary package hint: eucalyptus-cc
After stopping the eucalyptus-cc service, it seems like the private
dhcpd3 process to serve IP to instances is left running. Moreover, the
iptables rules added by Eucalyptus in MANAGED mode are not being
flushed.
Here is a screen dump to
This bug is affecting me too.
A scenario where the iptables-preload feature would be needed is one
where the NC are in a separate private network (where the CC would have
its VNET_PRIVINTERFACE). If you wish to NAT traffic between the private
NC network and the public one (where the Walrus
Please disregard the previous command. Looking again, it seems like the
iptables rules eucalyptus-cc set up are sufficient to NAT connection
from NC to the outside world, so the private NC network topology is not
made impossible by this bug.
Still, iptables-preload sounds like a useful feature.
Daniel Nurmi wrote:
Scott, thank you for pursuing this issue. Indeed, the meta-data service
keys off of the public IP of the VM, since that is the only source
address that is translated when the NCs cannot directly contact the CLC
(MANAGED modes). In order for the meta-data service to work,
Public bug reported:
Binary package hint: eucalyptus-common
euca_conf --help usage summary for the --deregister-walrus argument is
wrong. We get:
--deregister-walrus host remove walrus from EUCALYPTUS
Assuming we currently have the Walrus service at 10.0.0.10, if we do:
$
Good news, but can we clarify the addressing part nonetheless? Ie, can
VNET_PUBLICIPS and the IP of VNET_PUBINTERFACE on the CC be on the same
subnet?
--
multi-machine topology, cannot reach an instance from the CLC
https://bugs.launchpad.net/bugs/559230
You received this bug notification
Just a question: why is VNET_PUBLICIPS commented in eucalyptus.conf?
--
multi-machine topology, cannot reach an instance from the CLC
https://bugs.launchpad.net/bugs/559230
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in
Looking at the comment history, I think it might be that the
VNET_PUBLICIPS range and the address of VNET_PUBINTERFACE are in the
same subnet, which cannot possibly work. Which is a known limitation
related to netfilter; ask Dan about it.
But without knowing what the value of VNET_PUBLICIPS on
Just to explain a bit further. The reason I am suspecting
VNET_PUBLICIPS to be wrong is that eth0 on the CC has two IP in the
10.55.55.0/24 range (see comment #11). I presume 10.55.55.8 is the CC
actual IP, and comment #7 indicate that 10.55.55.100 is the IP of the
instance. In this case,
Hi Carlos,
I think you are having the problem discussed at:
https://answers.launchpad.net/ubuntu/+source/eucalyptus/+question/87145
--
Cannot start more than 29 instances
https://bugs.launchpad.net/bugs/546293
You received this bug notification because you are a member of Ubuntu
Server Team,
It is probably the same root cause, though. Does euca-run-instances -n
30 ... works if you increase the value of VNET_ADDRSPERNET and do a
clean restart? If yes, then it's not really a bug, although I guess
euca2ools should say something meaningful about why no instance are
being started.
i am
Why not 256MB? 192MB just seems ... terribly odd.
CPU cores are usually the limiting factor anyway. Someone with limited
memory on node controllers and/or specific requirements can always
change the value in the web UI, if need be.
--
Increase m1.small memory to 192 MB
Public bug reported:
Binary package hint: smbfs
In Karmic, it is possible to mount a CIFS filesystem from a DFS
referral, but it would fail when using Kerberos authentication.
Witness:
warthogs\ca...@karmic-desktop:~$ mount.cifs
//warthogs.biz/namespace1/firstshare share --verbose -o sec=krb5
** Attachment added: dmesg.txt
http://launchpadlibrarian.net/41050898/dmesg.txt
--
mount.cifs cannot mount a DFS share when using Kerberos authentication
https://bugs.launchpad.net/bugs/539791
You received this bug notification because you are a member of Ubuntu
Server Team, which is
For comparison purpose, here is the output of smbclient -d3 -k -c
showconnect //warthogs.biz/namespace1/firstshare. We can see that it
work as expected.
--
mount.cifs cannot mount a DFS share when using Kerberos authentication
https://bugs.launchpad.net/bugs/539791
You received this bug
For comparison purpose, here is the output of smbclient -d3 -k -c
showconnect //warthogs.biz/namespace1/firstshare. We can see that it
work as expected.
** Attachment added: smbclient.txt
http://launchpadlibrarian.net/41051221/smbclient.txt
--
mount.cifs cannot mount a DFS share when using
The output of klist after running the mount.cifs command.
** Attachment added: klist.txt
http://launchpadlibrarian.net/41051333/klist.txt
--
mount.cifs cannot mount a DFS share when using Kerberos authentication
https://bugs.launchpad.net/bugs/539791
You received this bug notification
We still have the same problem in lucid, using kernel 2.6.32-16-generic.
Attached the relevant dmesg snippet. keyutils is 1.2-12, and likewise-
open is 5.4.0.39949-3.
** Attachment added: dmesg-lucid.txt
http://launchpadlibrarian.net/41056228/dmesg-lucid.txt
--
mount.cifs cannot mount a DFS
In lucid, there was the following in /var/log/debug that seems to relate
to the problem at hand.
** Attachment added: debug.txt
http://launchpadlibrarian.net/41057441/debug.txt
--
mount.cifs cannot mount a DFS share when using Kerberos authentication
https://bugs.launchpad.net/bugs/539791
Investigating the problem further, I thought the problem might have been
that resolving the DFS referral returned a NetBIOS machine name, not a
FQDN, for the server hosting the service (ie, WARTHOGS-ADC instead of
warthogs-adc.warthogs.biz). After looking around, I followed the advice
in
For the record, I had a all-in-one UEC system running on jaunty in
SYSTEM mode a while ago. I still have my notes somewhere, although I
doubt they would be very applicable to lucid.
--
After all-in-one setup node-cert.pem and node-pk.pem not found
https://bugs.launchpad.net/bugs/519648
You
Public bug reported:
Binary package hint: openbsd-inetd
/etc/default/openbsd-inetd is being sourced from /etc/init.d/openbsd-
inetd, but no such file is included in the openbsd-inetd package.
This is not such a terrible thing, as the init script will run just fine
anyway. I guess it would be
Rather, if euca-add-keypair could be pointed to an existing id file
(optionally, pointing to one stored in Launchpad), that would be
terrific. The fact that we have to generate a new key each time we
upload an identity to EC2/Eucalyptus is terribly annoying; using an
existing identity/key pair
not experienced with any of them, so I cannot make an
enlightened recommendation, but they all tries to address exactly the
problem being discussed here. I suggest you investigate them, and
reports bug you find along the way.
--
Etienne Goyer
Technical Account Manager - Canonical Ltd
Ubuntu Certified
Dan, would enabling the Eucalyptus DNS feature actually fix this
problem? If so, then is there a good reason to disable it in the first
place?
--
Hostname not set correctly on UEC cloud due to IP address in local-hostname
manifest data
https://bugs.launchpad.net/bugs/475354
You received this
Dustin Kirkland wrote:
Possibly a paper-cut?
Totally! Nominating.
** Also affects: server-papercuts
Importance: Undecided
Status: New
--
euca_conf is missing command-line completion
https://bugs.launchpad.net/bugs/458203
You received this bug notification because you are a member
Dustin Kirkland wrote:
How about cluster1? Which is actually a Pink Floyd reference? :-)
* http://en.wikipedia.org/wiki/Cluster_One
Ok, that is passable.
Could have been more geeky, though.
--
UEC Cluster name should have a default value
https://bugs.launchpad.net/bugs/513379
You received
The above could have used a smiley on my part, so there: :D
--
UEC Cluster name should have a default value
https://bugs.launchpad.net/bugs/513379
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Boring. Why not warthogs?
--
UEC Cluster name should have a default value
https://bugs.launchpad.net/bugs/513379
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs mailing list
Thierry: I cannot think of a downside to having keyutils installed.
mount.cifs can authenticate using NTLM. In fact, this is the default.
Kerberos authentication for CIFS mount is only really used in Active
Directory context. In that use-case, the administrator of the machine
mounting a CIFS
It is worth noting that smbfs already Suggests keyutils. I am not sure
it should be made a Depends, tough. Kerberos authentication is only one
possible mechanism, and already requires setting up Kerberos.
Maybe the requirement for keyutils could be documented in a
README.Debian?
--
Cifs mount
Dustin, thanks a lot for that fix! This will save tons of grieves to
lots of people down the road. I know *I* lost a couple of hours before
figuring out that VT extensions where disabled in the BIOS ... :D
--
kvm disabled in bios (was: Unable to start EUC instances - no supported
architecture
Sounds good now. I have no idea where the magic operate, as
/etc/network/if-up.d/ntpdate do not check the desktop environment
setting, but manually-set time persist across reboot now. Thanks, I
guess this can be closed.
--
Time is being adjusted by ntpdate even if you choose to manage time
Public bug reported:
In karmic, eucalyptus 1.6~bzr931-0ubuntu7, the text of the
eucalyptus/publicips debconf template is wrong. It says the following:
Please specify one or more ranges of IP addresses, e.g.:
192.168.1.100-192.168.1.199
or
192.168.2.50-192.168.2.99
Sorry guys, this was a user error. I was using a range in
VNET_PUBLICIPS that was not in use on the machine. Sorry for the noise!
** Changed in: eucalyptus (Ubuntu)
Status: New = Invalid
--
The text debconf template eucalyptus/publicips is wrong
https://bugs.launchpad.net/bugs/459204
, that would be great.
--
Etienne Goyer
Technical Account Manager - Canonical Ltd
Ubuntu Certified Instructor
~= Ubuntu: Linux for Human Beings =~
--
Cloud Web interface should allow overcommit on CPU
https://bugs.launchpad.net/bugs/457864
You received this bug notification because you
Public bug reported:
The euca_conf script, shipped in eucalyptus-common, is missing command-
line completion. This would be nice to have at some point.
** Affects: eucalyptus (Ubuntu)
Importance: Wishlist
Status: New
** Changed in: eucalyptus (Ubuntu)
Importance: Undecided =
Public bug reported:
The configuration file /etc/eucalyptus/eucalyptus.conf, used by all
Eucalyptus services (-cloud, -cc, -nc, etc) is very confusing and
practically undocumented. The inline comments are helpful, but they do
not provide enough context for the administrator to decide which
Public bug reported:
In karmic eucalyptus 1.6~bzr931-0ubuntu7, the output of euca_conf
--help is wrong about the argument to remove a node from the cluster.
It states the argument is --delete-nodes, while it should really be
--deregister-nodes.
** Affects: eucalyptus (Ubuntu)
Importance:
Public bug reported:
The copyright file of eucalyptus in karmic is incorrect. It states that
Eucalyptus is under a BSD-derived license, when it is really is under
GPLv3 at this point. Please see http://www.eucalyptus.com/licenses/,
and check the header of various source files for confirmation.
Joseph Salisbury wrote:
Hmm. I wonder if this could be related to the bios. I'll check it to
ensure the correct settings are enabled for KVM. Could an error like
this occur if the bios was not setup correctly?
Yes, indeed.
--
Unable to start EUC instances - no supported architecture for
On 2008-08-06, Steve had this tidbit of wisdom:
If you are only using libnss-ldap without nscd, there is nowhere in the
model for this reachability information to be stored. If you use nscd,
results will be cached in the event the server is down.
Well, yes and no. Enumeration of NSS database,
Dustin Kirkland wrote:
Note that I had to modprobe acpiphp. Perhaps we should consider loading
this module in init or in modules.conf.
I have reported this issue in bug #364916.
--
dynamic block device attach/detach not functional with karmic KVM
https://bugs.launchpad.net/bugs/432154
You
Not Dan, but here's my take anyway.
I would say it is fairly critical. The EBS functionality (on which the
block device attach/detach functionality depends) is a pretty important
feature. Without, data persistence is not obvious. For example, you
would run MySQL in the cloud by keeping table
Do not forget to create /var/run/eucalyptus/net/ too (per bug #365349),
otherwise only SYSTEM mode will work.
--
/var/run/eucalyptus is not being set with correct permissions on machine reboot
https://bugs.launchpad.net/bugs/431114
You received this bug notification because you are a member of
You will also want to make eth0 manual (iface eth0 inet manual),
otherwise both the bridge and eth0 will get an IP, making the routing
table funny.
--
eucalyptus node install results in broken /etc/network/interfaces
https://bugs.launchpad.net/bugs/430820
You received this bug notification
Colin, for me on jaunty, the following /etc/network/interfaces result in
a system with broken network (ie, cannot ping or connect to anything):
---
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
Unfortunately, I had to revert back to 1.5 for a specific project, and I
do not have the hardware to run two clusters in parallel (a stable one
on jaunty/1.5, and one for testing on karmic/1.6). I will not be able
to test any earlier than late next week. Sorry! :(
--
Instance fail to run
The problem is indeed with eucalyptus. There is now a check in the init
script that will make it fail if the EUCALYPTUS value of the
configuration file is not_configured. The config that shipped in the
last version indeed was. Somehow, the config file did not got upgraded
to the new version,
Got the same problem upgrading a Eucalyptus frontend (running -cloud,
-cc, -walrus and -sc). However, we cannot accept the package
maintainer's version, as it will overwrite the NODES value in the
configuration file, which would make the frontend consider there is no
node controller. People
Public bug reported:
On karmic, after upgrading Eucalyptus from 1.6~bzr672-0ubuntu4 to
1.6~bzr746-0ubuntu1, trying to run an instance fail with the following
error:
cloudmas...@uec-frontend:~$ euca-run-instances -t c1.medium -k warthogs-key
emi-073A1120
Warning: failed to parse error message
Trevor,
Can you have a look at bug #430093, and see if it is the same bug that
you get? If yes, could you add a comment with relevant details (such as
the above log snippet).
Thanks!
--
Eucalyptus cloud controller stops working suddenly
https://bugs.launchpad.net/bugs/428010
You received this
Public bug reported:
On karmic using Eucalyptus 1.6~bzr672-0ubuntu3, when trying to
deregister a Walrus server on the command-line, euca_conf reports that
the Walrus server is successfully deregistered, but some verbiage on the
command appears to indicate it was not. See below:
Public bug reported:
On karmic with Eucalyptus 1.6~bzr672-0ubuntu3, if you download the
certificate bundle before you register a Walrus server, the eucarc file
in the bundle declare the following variable:
export S3_URL=http://BukkitInternal:8773/services/Walrus/
BukkitInternal is not an
Ok, I did the registration already, and it appears to have succeeded. I
guess this bug should be closed as Invalid for now, i will try to figure
out what happened with the registration.
--
Cannot upload bundle to Walrus
https://bugs.launchpad.net/bugs/429590
You received this bug notification
Quick workaround on the frontend:
sudo cp ~eucalyptus/.ssh/id_rsa.pub ~eucalyptus/.ssh/authorized_keys
--
after UEC front-end (cluster) install, key sync stage of registration cannot
proceed without entering a password
https://bugs.launchpad.net/bugs/429087
You received this bug notification
Public bug reported:
On a brand new installation of Eucalyptus 1.6~bzr672-0ubuntu3 on karmic,
after manually copying ~eucalyptus/.ssh/id_rsa.pub to
~eucalyptus/.ssh/authorized_keys and successfully registering the
cluster, registration of the walrus component fail with the following
error:
The in question is already there, and writable only by root, hence why
scp fail:
cloudmas...@uec-frontend:~$ sudo ls -l /var/lib/eucalyptus/keys//euca.p12
-rw-r--r-- 1 root root 21546 2009-09-14 18:06 /var/lib/eucalyptus/keys//euca.p12
--
Registering Walrus fail
The following workaround allows you to proceed with walrus registration:
sudo chown eucalyptus:eucalyptus /var/lib/eucalyptus/keys/euca.p12
--
Registering Walrus fail
https://bugs.launchpad.net/bugs/429719
You received this bug notification because you are a member of Ubuntu
Server Team,
Public bug reported:
On karmic using Eucalyptus 1.6~bzr672-0ubuntu3, when you use euca_conf
--get-credentials cred.zip to retrieve the certificate bundle on the
frontend, the eucarc file contains the following declaration:
export S3_URL=http://127.0.0.1:8773/services/Walrus
export
Public bug reported:
On karmic running Eucalyptus 1.6~bzr672-0ubuntu3, after installing a
node controller and registeringit successfully, it is impossible to run
an instance. On the frontend:
euca-describe-availability-zones verbose
AVAILABILITYZONEwarthogs10.153.108.210
Public bug reported:
On karmic running Eucalyptus 1.6~bzr672-0ubuntu3, instances fail to
start. I have not been able to track down the cause. I systematically
get the following:
cloudmas...@uec-frontend:~$ euca-run-instances -t c1.medium -k warthogs-key
emi-073A1120
RESERVATION r-5254095A
** Attachment added: nc.log
http://launchpadlibrarian.net/31806315/nc.log
--
Instance fail to run
https://bugs.launchpad.net/bugs/429754
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs
*** This bug is a duplicate of bug 423465 ***
https://bugs.launchpad.net/bugs/423465
** This bug has been marked a duplicate of bug 423465
euca.p12 owned by root
--
Registering Walrus fail
https://bugs.launchpad.net/bugs/429719
You received this bug notification because you are a member
I had the same problem when testing earlier today. I *believe*
(although I am not sure) that happen when you have not registered the
clc on the walrus machine. Are you running walrus on a different
machine than the cloud controller?
--
Eucalyptus hangs euca-upload-bundle doesn't return
I confirm I had exactly the same problem happen to me last week.
When looking at /var/log/eucalyptus/cloud-error.log, there was some
verbiage about a corrupted index or somesuch. Do you see something
similar?
Also, is it possible that you started the eucalyptus-cloud service from
within an SSH
I see the same symptoms here. eucalyptus-cc has been running for a bit
over a month now. That is also on jaunty amd64, eucalyptus-cc
1.5~bzr266-0ubuntu2.
cloudmas...@eucalyptus-frontend:~$ ps up 2642
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
110 2642 2.7
Public bug reported:
Binary package hint: eucalyptus-nc
This is a wishlist item.
As it can be hard to track problems running instances on a node
controller caused by the node controller not supporting HVM, it would be
good if the package installer would warn of the situation. For example,
we
I already reported that issue as bug #424541.
--
UEC installer does not set up a bridge device by default for Eucalyptus nodes
(NCs)
https://bugs.launchpad.net/bugs/425915
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in
Public bug reported:
Sample output of euca_conf ran on a cluster controller:
--
ubu...@t61p:~$ sudo euca_conf --register-nodes 192.168.144.65
INFO: We expect all nodes to have eucalyptus
This bug have been fixed in karmic. It should be SRUed for jaunty, or
marked WONTFIX, as appropriate.
--
eucalyptus-nc service fail to start at boot, cannot connect to libvirtd
https://bugs.launchpad.net/bugs/364723
You received this bug notification because you are a member of Ubuntu
Server
This could be fixed relatively easily by calling euca_conf in the
postinst script of either eucalyptus-common or -cc, such as:
euca_conf --dhcpd /usr/sbin/dhcpd3
euca_conf --dhcp_user dhcpd
--
In /etc/eucalyptus/eucalyptus.conf, VNET_DHCPDAEMON and VNET_DHCPUSER should be
set to value
I have not yet verified that this is still a bug in karmic, but it
should be fixed if it is.
--
Any network mode beside SYSTEM fail because /var/run/eucalyptus/net do not exist
https://bugs.launchpad.net/bugs/365349
You received this bug notification because you are a member of Ubuntu
Server
That is what I would guessed too, and I think it would be a good
default behavior. I know some people have very strong opinion on this
issue. Should it be discussed at a Server team meeting, or even as a
session in the next UDS? That way, we could get opinion from all
stakeholders and
The latest daily hardy server CD ISO (20090709) works just fine indeed.
When provided with the iscsi=true boot option, it will prompt for the
iSCSI target to use, the iSCSI target will show up as a block device in
the partitionner dialog, and you can use it for non-root file systems
just fine. I
I do not have the problem Kevin reports above; iscsi=true works just
fine for me. I tested using the karmic server CD image dated
08-Jul-2009 10:32 from the same location he does.
I am pleased to report the iSCSI installer support works just fine now for me.
The iSCSI dialog come up fine, the
Colin, as the bug is in the installer part of the package, I would need
an ISO to test. Or can I test using the netboot installer?
--
iSCSI install fails under hardy
https://bugs.launchpad.net/bugs/236640
You received this bug notification because you are a member of Ubuntu
Server Team, which
Thierry Carrez wrote:
Not exactly, what I'm saying is that on *every* network that has a
correct DNS setup, this change will result in a small performance hit
and/or useless network noise. This is not a question of large company
networking. Everyone can setup dnsmasq for local name resolution
Steve, I built open-iscsi with the above debdiff, and iscsi_discovery
does work just like the unpatched version. I found two other bugs with
it (the block device is not being made available right away, and it
cause a kernel oops in certain circumstance), but I will be reporting
these separately.
Is still still an issue an issue on hardy, which ship with open-iscsi
2.0.865? If not, then I guess we should close this bug as invalid or
wontfix.
--
Open solaris iscsi target causes panic in open-iscsi
https://bugs.launchpad.net/bugs/159682
You received this bug notification because you are a
The kernel oops have been reported as bug #395323.
The target block device not being made available right away is not a
bug, it is the expected behavior. Sorry for the noise.
--
iSCSI install fails under hardy
https://bugs.launchpad.net/bugs/236640
You received this bug notification because
Attached is /var/log/syslog from the daily karmic server ISO (June
29th).
However, it does not include the fix Steve uploaded in comment 25 (open-
iscsi 2.0.865-1ubuntu4). As it is an installer bug, I guess it will ned
to find it's way into the daily build before I can test.
** Attachment
As I explained a couple months earlier (see comment 2), even if the path
to iscsi-iname is fixed, it still fail in the end. The installer goes
on just fine, but if you choose to configure a file system residing on
an iSCSI target to be mounted at boot time (not as the root file system,
just about
Quick test lead me to believe that open-iscsi 2.0.865-1ubuntu3.1 from
hardy-proposed work as explained by Steve. That is, the block device
appear after the bonded Ethernet is brought up. It is too late for the
file system on the iSCSI target to be mounted from /etc/fstab, but at
least we do not
1 - 100 of 120 matches
Mail list logo
