I haven't, and for the time being, it's worked well enough for me to
remove the usb key when the installer gets to the "loading additional
modules" stage... that way the only disk that shows up is the hard
disk and not the USB key. Sounds like there is general progress that
has been made on this...
No problems with it being in Jaunty. As I mentioned, take it as you
will, just contributing back the package update. And I guess if more
people reproduce the issue I encountered in 1.2.9 which is now in
Intrepid then it could always be in intrepid-updates.
That bug (the one with "-d" values >1 not
Public bug reported:
Binary package hint: makedumpfile
New upstream version just released. Fixed an issue that was previously
encountered with using any "-d" argument greater than 1 on some systems.
(Seems to have had to do with compile flags for large file support).
Works fine now even up to the
** Attachment added: "Diff against upstream 1.3.0"
http://launchpadlibrarian.net/18547110/makedumpfile_1.3.0-ubuntu1.diff.gz
--
Update makedumpfile package to new upstream 1.3.0
https://bugs.launchpad.net/bugs/283490
You received this bug notification because you are a member of Ubuntu
Bugs,
Just realized I hadn't pulled the current makedumpfile source package to
merge this against (I created against 1.2.9-ubuntu1). Will probably need
to re-base against new version. I'd expect this is trivial, but if you
want me to re-post a diff.gz I can.
-Kevin
versions skipped:
makedumpfile (1.2.
Public bug reported:
Binary package hint: crash
Crash seems to depend on the program "strings" (in binutils package) to
match vmcore dumps to vmlinux kernels. If you try to run crash without
binutils installed, it will fail saying the vmlinux image and dump do
not match (along with an error furth
Public bug reported:
Binary package hint: oprofile
running "opcontrol --vmlinux=vmlinux-file-here" fails and reports that
the image is invalid. However, if you install binutils, it works fine.
I'm guessing there is a silent runtime dependency on a program like "nm"
to get information out of the k
Thanks all. I'll likely be submitting a similar "update" bug for
makedumpfile 1.3.0 when it is released. Turns out the bug I was
encountering still existed in 1.2.9 but I worked with the upstream dev
to resolve it and 1.3.0 is now in "rc2" status
Additionally, in Ben's original commit he appears t
** Attachment added: "makedumpfile_1.2.9-0ubuntu1.diff.gz"
http://launchpadlibrarian.net/17738415/makedumpfile_1.2.9-0ubuntu1.diff.gz
--
Upgrade to new upstream version 1.2.9
https://bugs.launchpad.net/bugs/271956
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Public bug reported:
Binary package hint: makedumpfile
Pulled 1.2.9 from upstream on sourceforge and integrated previous Ubuntu
modifications to makefile.
See attached diff.gz
** Affects: makedumpfile (Ubuntu)
Importance: Undecided
Status: New
** Tags: upgrade
--
Upgrade to ne
>From upstream sourceforge site at
http://sourceforge.net/project/shownotes.php?group_id=178938&release_id=624021
I knew it was possible/likely this wouldn't be in the next release, I
had needed to do the packaging ASAP, so I figured I'd contribute back
and save the ubuntu devs some work.
File Re
Public bug reported:
Binary package hint: debian-installer
Please note I have reproduced this on 7.04. If needed I can attempt to
reproduce the bug on a newer version, but I haven't had the time and it
should still be fixed on 7.04 anyway.
I extracted the kernel and initrd from mini.iso to a usb
Note this has been reported on the mailing list and received no
response.
https://lists.ubuntu.com/archives/ubuntu-
installer/2007-December/000131.html
--
debian-installer fails to configure grub correctly when booted from a usb
pendrive
https://bugs.launchpad.net/bugs/181908
You received this
Updated from 9.04 to 9.10 and then to 10.04 today. Found that in both
newer releases my remote stopped working. Once I made it to 10.04, I
looked around and found this thread. Things look like they go back
pretty far, so perhaps things are in a better shape today, as I was able
to get mine working
Public bug reported:
When putting a VLAN tag onto a frame, the 8021q (VLAN) driver in 2.6.27
and 2.6.28 don't update the skb->mac_header pointer, thus anything in
the transmit stack attempting to use this pointer AFTER the 8021q driver
adds a tag is going to be off by VLAN_HLEN. In the typical cas
** Attachment added: "Patch (same as on kernel.org commitdiff)"
http://launchpadlibrarian.net/34622555/if_vlan.h.patch
--
[hardy, jaunty] 8021q driver doesn't update skb->mac_header in __vlan_put_tag
https://bugs.launchpad.net/bugs/463689
You received this bug notification because you are a m
Oops, that last sentence should read "I have confirmed that this is not
an issue in 2.6.24, so Hardy ought to be safe, but 2.6.27 (intrepid) and
2.6.28 (jaunty) are affected."
--
[hardy, jaunty] 8021q driver doesn't update skb->mac_header in __vlan_put_tag
https://bugs.launchpad.net/bugs/463689
Y
:o Worse, yet, this typo made it into the title as well... should have
been "[intepid, jaunty] 8021q driver doesn't update skb->mac_header in
__vlan_put_tag" Sorry!
--
[hardy, jaunty] 8021q driver doesn't update skb->mac_header in __vlan_put_tag
https://bugs.launchpad.net/bugs/463689
You received
18 matches
Mail list logo
