Bug#818065: console-setup is not read correctly at boottime and must be started manually
Hi all, I have this problem on 8 embedded systems running armbian stretch that all reports error like this on the systemd journal: Feb 16 14:17:10 rod-ba82a8 console-setup.sh[293]: /bin/setupcon: 866: /bin/setupcon: cannot open /tmp/tmpkbd.BccRnI: No such file Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE Feb 16 14:17:10 rod-ba82a8 systemd[1]: Failed to start Set console font and keymap. Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Unit entered failed state. Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Failed with result 'exit-code' So it look like the /tmp mount is required. I added it into the RequiresMountsFor line of the service file, run systemctl daemon-reload, but this make no change on the boot: console-setup failed with exactly the same error message. Then I tryed to run 'setupcon' and 'reboot', no change. Then I tryed to run 'systemctl start console-setup.service' and 'reboot': it worked !. So my conclusion so far are: 1) Yes setupcon and console-setup.service require /tmp mount but this is not the rot cause of the problem, even if the error message let you think so. 2) Simply running 'systemctl start console-setup.service' manually solved the problem on those 8 systems that also have /tmp added into RequiresMountsFor. Look like a timing and probably a dependency issue that make early console-setup to fail because it didn't find a expected file into /tmp. I don't know how this file is supposed to be there at bot time. Best regards. Jean-Christian
Bug#812611: Install on Orange Pi Plus eMMC work but no reboot
Le 06. 10. 16 à 21:29, Vagrant Cascadian a écrit : I don't believe there is any code in debian-installer to install u-boot; the installer did not install it. I don't believe there is any code within all of Debian to install u-boot automatically (unless you count SD image generation). It is at this point a manual process. And this is the only missing operation still required to fully support Debian a board like the Orange Pi Plus. Installing u-boot from within the debian-installer can be a rather dangerous operation on many systems which is why the installer doesn't try to do that yet. The problem is that u-boot isn't only a bootloader like GRUB but more like a PC BIOS and nobody would expect the debian-installer to flash BIOS-updates on a PC ;-). There are quite a number of systems where writing u-boot to internal storage going wrong completely bricks the system, i.e the system is electronics garbage afterwards. Most sunxi-based systems still have a way to trigger SD boot or FEL boot as a way to manually restore the firmware, but not all of them do, and on many non-sunxi-platforms a broken u-boot write is completely unrecoverable except by unsoldering the flash or - if one is lucky - by accessing it via JTAG, but both are methods that are inaccessible for a normal user. I understand, but the SD card image of the Debian installer is specifically targeted for the Orange Pi Plus board so it can take advantage of it. While the SD card images can be used for recovery in many cases, it is also possible that u-boot installed to eMMC fails in such a way that it doesn't fall back to SD card, requiring a lot of effort to reset the board. It depends entirely on the boot ROM of the board what order it searches for the bootloader... Not on that board. The H3 processor chip integrate a boot ROM that always first look at the SD card and then at the eMMC (unless forced into the special FEL mode). There is no way to break the ROM integrated into the processor chip. Take a look at http://linux-sunxi.org/BROM for the details. Given that experience, I tend to strongly prefer installing u-boot on SD card when possible, as you can easily remove the SD card and reinstall a known-good u-boot from another machine. This is exactly how the H3 boot ROM work already. You can write anything you want into the eMMC, there is absolutely no way to break the SD card boot from the CPU ROM. So there is no danger in writing the bootloader into the eMMC on that board. Writing the bootloader on the eMMC this is exactly what a user will expect while installing Debian into the eMMC. I'll put looking into support for installing u-boot from within the installer at least on certain systems onto my (unfortunately already way too long) todo list, but that will surely take quite some time. I'm also CCing Vagrant Cascadian, the Debian u-boot maintainer for some further input on this topic. Basically, it will require much of the same code as upgrading u-boot: https://bugs.debian.org/812611 Which has been on my todo list for quite some time with little activity. Due to the risk of bricking, both fresh installation and upgrading of u-boot should probably require some sort of opt-in process. Knowing how to install u-boot on a particular set of boards is another feature that's needed, although the SD-card image generation in debian-installer is a good start for several boards. To make matters more complicated, there are definitely some boards (Firefly, maybe BeagleBoard-X15) which can install the OS to eMMC, but u-boot still has to be loaded from SD card. I don't think we have much information on which boards those are. It may also vary from one u-boot version to the next... So, in short, there are quite a few complications to take into consideration. If someone can propose patches that take into account all these issues quite soon, it *might* be feasible for stretch. From a user point of view this would be a major achievement for the Debian armhf port that finally make some ARM boards as easy to install than a regular PC. Well, maybe even easier than the actual UEFI PC... Regards, Jean-Christian
Bug#585016: Logitech QuickCam 4000 Pro USB webcam does not work on Debian Squeeze. It works on Debian Lenny.
, 0x741af190) = 0 ioctl(3, VIDIOC_TRY_FMT, 0x741af190) = 0 ioctl(3, VIDIOC_ENUMINPUT, 0x741af8e0) = 0 ioctl(3, VIDIOC_ENUMSTD, 0x741af8e0) = 0 ioctl(3, FS_IOC32_GETVERSION or FS_IOC_GETVERSION or VIDIOCGCAP, 0x23d00f0) = 0 ioctl(3, VIDIOC_QUERYCTRL, 0x741af990) = -1 EINVAL (Invalid argument) ioctl(3, VIDIOC_QUERYCTRL, 0x741af990) = 0 ioctl(3, VIDIOC_G_CTRL, 0x741af980) = 0 ioctl(3, VIDIOC_QUERYCTRL, 0x741af990) = 0 ioctl(3, VIDIOC_G_CTRL, 0x741af980) = 0 ioctl(3, VIDIOC_QUERYCTRL, 0x741af990) = 0 ioctl(3, VIDIOC_G_CTRL, 0x741af980) = 0 ioctl(3, VIDIOC_QUERYCTRL, 0x741af990) = 0 ioctl(3, VIDIOC_G_CTRL, 0x741af980) = 0 mmap(NULL, 67108864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f932196 mmap(NULL, 462848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f93273ce000 mmap(NULL, 925696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f93272ec000 write(2, Reading image from /dev/video0\n, 31Reading image from /dev/video0 ) = 31 read(3, Any application I tried (xawtv, gstreamer, cheese, vgrabbj) wait indefinitely a image from the webcam, but it never cam. The bug was closed because the author suspected a version problem between the kernel and the modules after observing that the webcam was working after a reboot. But I carefully inspected the version of my modules and there absolutely cam from the right kernel. So I tried this: 1) unplug the webcam. 2) rmmod pwc (as root). 3) replug the webcam. And suddenly the vgrabbj command was working and write a clear picture. But the other video applications start showing a stream of green duplicated images were I can only recognize part of the scene. So suspect a initialization problem into the pwc.ko module. Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585016: Logitech QuickCam 4000 Pro USB webcam does not work on Debian Squeeze. It works on Debian Lenny.
Le 14. 01. 11 17:44, Ben Hutchings a écrit : On Fri, Jan 14, 2011 at 04:49:26PM +0100, Jean-Christian de Rivaz wrote: I have experienced this bug today on a AMD64 Squeeze machine and the same webcam. The Webcam work perfectly on the Lenny machines, but do not outputs any image on Squeeze, unless you remove the pwc.ko module and replug the camera. There is a trace of what happens while the pwc.ko in inserted fir the first time into the kernel: [...] Which version of vgrabbj did you use? Ben. vgrabbj 0.9.6 Doing more experiment show that when the pwc.ko module is linked to the kernel, it could bring either a working or a non-woring video interface as long as it stay linked. I was only able to change the state by a 'rmmod pwc' and a replug of the webcam. Jean-Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585016: Logitech QuickCam 4000 Pro USB webcam does not work on Debian Squeeze. It works on Debian Lenny.
Le 14. 01. 11 19:02, Ben Hutchings a écrit : On Fri, Jan 14, 2011 at 06:02:44PM +0100, Jean-Christian de Rivaz wrote: Le 14. 01. 11 17:44, Ben Hutchings a écrit : On Fri, Jan 14, 2011 at 04:49:26PM +0100, Jean-Christian de Rivaz wrote: I have experienced this bug today on a AMD64 Squeeze machine and the same webcam. The Webcam work perfectly on the Lenny machines, but do not outputs any image on Squeeze, unless you remove the pwc.ko module and replug the camera. There is a trace of what happens while the pwc.ko in inserted fir the first time into the kernel: [...] Which version of vgrabbj did you use? Ben. vgrabbj 0.9.6 [...] I mean the *package* version (dpkg -s vgrabbj). Oops! Sorry for the misunderstanding. Here is the details: dpkg -s vgrabbj Package: vgrabbj Status: install ok installed Priority: optional Section: graphics Installed-Size: 116 Maintainer: Michael Janssen jamu...@debian.org Architecture: amd64 Version: 0.9.6-3.2 Depends: ftplib3 (= 3.1), libc6 (= 2.7), libjpeg62 (= 6b1), libpng12-0 (= 1.2.13-4), libv4l-0 (= 0.5.0), zlib1g (= 1:1.1.4) Conffiles: /etc/vgrabbj.conf e49a78bfbf7a9884737538ea426fd76b Description: grabs a image from a camera and puts it in jpg/png format vgrabbj is a program that will grab an image from a v4l compatible device (usually a webcam of some sort) and save it in a jpg or png file. Homepage: http://vgrabbj.gecius.de/ More experiments show that the pwc.ko insertion do a working job half of the time. I am now able to get a proper video with VLC if I do this: 1) rmmod pwc. 2) plug the webcam. 3) gst-launch v4l2src ! ffmpegcolorspace ! xvimagesink 4) terminate the gstreamer process. 5) vlc v4l2:///dev/video0 This did not work right if I do not start gstreamer before vlc. Anyway gstreamer and cheese always show strange green images. I also notices that vlc can work one a single time with v4l instead of v4l2. After that the pwc.ko seem to be frozen as when is go wrong while linked to the kernel. Jean-Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
In http://article.gmane.org/gmane.comp.gnu.parted.bugs/10180 Jim Meyering provided a patch that solve the problem. After verification, he commited it into git://git.debian.org/git/parted/parted.git: commit 9f5b0608611eed40ef33be2096f5d482710602e5 Author: Jim Meyering meyer...@redhat.com Date: Tue Nov 9 10:25:36 2010 +0100 dos: fix a bug affecting very small devices (smaller than 1 cylinder) This bug was introduced in commit c79d91ec, dos: accommodate very small devices (useful for testing). * libparted/labels/dos.c (_primary_constraint): The bug was to skip setting start_geom for small devices. That led to a used- uninitialized bug in the subsequent ped_constraint_new call. The fix is to relax the constraint to use a starting sector of 1, if necessary. Report and diagnosis by Jean-Christian de Rivaz in http://thread.gmane.org/gmane.comp.gnu.parted.bugs/10178 * NEWS (Bug fixes): Mention it. Many thanks to Jim for this patch. Debian installer should use this last revision to fix this problem. It it worth noting that partman is still deficient in the way it handle a parted-server error. Improving it will certainly help to get better problem report from Debian users. I have see on the internet others installer report about hang at the same partman operation time. Also, the debian/rules for parted still should be updated with my proposed patch to remove obsoletes directives. So even if the primary cause is now fixed, from a quality view, this bug is still not in the state to be closed. Or should other bug be opened for those point ? Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
Colin Watson a écrit : On Tue, Nov 09, 2010 at 07:46:37PM +0100, Jean-Christian de Rivaz wrote: So even if the primary cause is now fixed, from a quality view, this bug is still not in the state to be closed. Or should other bug be opened for those point ? If you believe parted_server (which is in the partman-base package) needs improvements, please clone this bug and reassign the clone to partman-base. Keeping this bug open for that would make tracking too difficult. Ok. I can now reproduce the partman-base problem, using a specially created crash prone /lib/libparted.so.0.0.1 library. The parted-server, as expected, crash this way on the console it has been started from: r...@point:/home/jcdr/partman-base-test# bin/parted_server r...@point:/home/jcdr/partman-base-test# echo OPEN =dev=sdb /dev/sdb /var/lib/partman/infifo r...@point:/home/jcdr/partman-base-test# Backtrace has 19 calls on stack: 19: /lib/libparted.so.0(ped_assert+0x28) [0xb77bcea3] 18: /lib/libparted.so.0(ped_geometry_new+0x5a) [0xb77c6909] 17: /lib/libparted.so.0(ped_geometry_duplicate+0x73) [0xb77c69e2] 16: /lib/libparted.so.0(ped_constraint_init+0x15e) [0xb77c7aae] 15: /lib/libparted.so.0(ped_constraint_new+0x82) [0xb77c7b70] 14: /lib/libparted.so.0(+0x4eef7) [0xb77feef7] 13: /lib/libparted.so.0(+0x4f60c) [0xb77ff60c] 12: /lib/libparted.so.0(+0x4fc78) [0xb77ffc78] 11: /lib/libparted.so.0(+0x501e6) [0xb78001e6] 10: /lib/libparted.so.0(+0x130ab) [0xb77c30ab] 9: /lib/libparted.so.0(ped_disk_add_partition+0x15f) [0xb77c5896] 8: /lib/libparted.so.0(+0x4d1e4) [0xb77fd1e4] 7: /lib/libparted.so.0(+0x4d406) [0xb77fd406] 6: /lib/libparted.so.0(ped_disk_new+0xd2) [0xb77c1bda] 5: bin/parted_server() [0x805594d] 4: bin/parted_server() [0x8055b4b] 3: bin/parted_server() [0x805621b] 2: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb7680c76] 1: bin/parted_server() [0x804a101] The /var/lib/partman/outfifo simply report: OK OK And /var/log/partman say: parted_server: === Starting the server parted_server: main_loop: iteration 1 parted_server: Opening infifo parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sdb parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK So I think it's not really parted_server the cause of the problem (is case of libparted problem), but more the script that started it and failed to observe that it crashed. Still, this script probably in partman-base too. But what do you say by clone this bug ? * It there a procedure to do this ? * Or it's a administrative option I don't have access to as a user ? * Or I have to manually copy the report into a new one ? Regards, Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
It seem that the only maintained source archive for GNU parted is
git://git.debian.org/git/parted/parted.git . Right ?
I managed to find that the bug was introduced by this commit:
commit c79d91ec71882a1673daae0482aa90c514c63cc1
Author: Jim Meyering meyer...@redhat.com
Date: Tue Mar 30 16:50:59 2010 +0200
dos: accommodate very small devices (useful for testing)
* libparted/labels/dos.c (_primary_constraint): Don't pass a negative
device_length to ped_geometry_init when the underlying device
has fewer sectors than a cylinder.
diff --git a/libparted/labels/dos.c b/libparted/labels/dos.c
index 752f186..8679c49 100644
--- a/libparted/labels/dos.c
+++ b/libparted/labels/dos.c
@@ -1616,8 +1616,13 @@ _primary_constraint (const PedDisk* disk, const
PedCHSGeometry* bios_geom,
dev-length - min_geom-end))
return NULL;
} else {
- if (!ped_geometry_init (start_geom, dev, cylinder_size,
- dev-length - cylinder_size))
+ /* Do not assume that length is larger than 1 cylinder's
+ worth of sectors. This is useful when testing with
+ a memory-mapped disk (a la scsi_debug) that is say,
+ 2048 sectors long. */
+ if (cylinder_size dev-length
+!ped_geometry_init (start_geom, dev, cylinder_size,
+ dev-length - cylinder_size))
return NULL;
if (!ped_geometry_init (end_geom, dev, 0, dev-length))
return NULL;
I posted a message on the bug-par...@gnu.org, but it seem that there is
not a lot of developers on it, so I don't expect this will be handled
anytime soon.
The only basic idea I have right now, is to add a -t option to force
to not call ped_geometry_init (start_geom, ...) if cylinder_size
dev-length when using parted with a memory-mapped device for testing
purpose. There is maybe a better logic to handle all of that, but I
don't know this code good enough to see it. Where can I find a test case
with a memory-mapped device that needed this commit ?
Jean-Christian de Rivaz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
Christian PERRIER a écrit : Quoting Jean-Christian de Rivaz (j...@eclis.ch): Unfortunately there is no /var/log/installer/ directory: That dir exists on the installed system. As you couuldn't install, it is indeed not there ls -al /var/log drwxr-xr-x2 root root 0 Nov 5 22:33 . drwxr-xr-x8 root root 0 Nov 5 22:23 .. -rw-r--r--1 root root 17172 Nov 5 22:33 hardware-summary lrwxrwxrwx1 root root44 Nov 5 22:33 install-report.template - /usr/share/save-logs/install-report.template lrwxrwxrwx1 root root16 Nov 5 22:33 lsb-release - /etc/lsb-release -rw-r--r--1 root root 993 Nov 5 22:23 partman lrwxrwxrwx1 root root20 Nov 5 22:33 status - /var/lib/dpkg/status -rw-r--r--1 root root 71813 Nov 5 22:33 syslog /var/log/partman is what Miguel wanted to mention. Thanks for the clarification, here is the /var/log/partman: /bin/partman: *** /lib/partman/init.d/25md-devices: *** /lib/partman/init.d/30parted: *** parted_server: === Starting the server parted_server: main_loop: iteration 1 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sda /dev/sda parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sda parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK parted_server: Note =dev=sda as unchanged parted_server: Closing infifo and outfifo parted_server: main_loop: iteration 2 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sdb /dev/sdb parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sdb parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK I suspect that something like Closing infifo and outfifo for /dev/sdb is missing. On the screen I have at this moment a progress bar Starting up the partitioner fixed at 50% and a statement Scanning disks... on the lower left. If I understand correctly, those /var/log/partman traces are related to this code from /lib/partman/init.d/30parted that seem to talk to a parted_server process: cd $dev open_dialog OPEN $(cat $dev/device) read_line response close_dialog if [ $response = failed ]; then cd / rm -rf $dev fi Maybe parted_server is not responding to /lib/partman/init.d/30parted. A 'ps' give this processes list: PID USER VSZ STAT COMMAND 1 root 1360 S/bin/busybox init 2 root 0 SW [kthreadd] 3 root 0 SW [ksoftirqd/0] 4 root 0 SW [watchdog/0] 5 root 0 SW [events/0] 6 root 0 SW [cpuset] 7 root 0 SW [khelper] 8 root 0 SW [netns] 9 root 0 SW [async/mgr] 10 root 0 SW [pm] 11 root 0 SW [sync_supers] 12 root 0 SW [bdi-default] 13 root 0 SW [kintegrityd/0] 14 root 0 SW [kblockd/0] 15 root 0 SW [kacpid] 16 root 0 SW [kacpi_notify] 17 root 0 SW [kacpi_hotplug] 18 root 0 SW [kseriod] 19 root 0 SW [kondemand/0] 20 root 0 SW [khungtaskd] 21 root 0 SW [kswapd0] 22 root 0 SWN [ksmd] 23 root 0 SW [aio/0] 24 root 0 SW [crypto/0] 44 root 1356 S udevd --daemon --resolve-names=never 202 root 0 SW [ksuspend_usbd] 203 root 0 SW [khubd] 204 root 0 SW [ata/0] 205 root 0 SW [ata_aux] 207 root 0 SW [scsi_eh_0] 208 root 0 SW [scsi_eh_1] 209 root 0 SW [scsi_eh_2] 210 root 0 SW [scsi_eh_3] 222 root 0 SW [scsi_eh_4] 223 root 0 SW [usb-storage] 257 root 1360 S/sbin/syslogd -m 0 -O /var/log/syslog -S 259 root 1360 S/sbin/klogd -c 2 321 root 1364 S/bin/sh /sbin/debian-installer 322 root 1872 S-/bin/sh 323 root 1360 S/bin/busybox init 324 root 1360 S/usr/bin/tail -f /var/log/syslog 334 root 3364 S/usr/bin/bterm -f /lib/unifont.bgf -l C.UTF-8 /lib/d 335 root 14248 Sdebconf -o d-i /usr/bin/main-menu 341 root 1236 S/usr/bin/main-menu 1983 root 0 SW [loop0] 4463 root 1868 Sudhcpc -i eth0 -V d-i -O subnet -O broadcast -O rout 4744 root 1352 S udevd --daemon --resolve-names=never 5212 root 1712 Sudpkg --configure --force-configure partman-base 5213 root 1868 S/bin/sh /var/lib/dpkg/info/partman-base.postinst con 5214 root 1872 S/bin/sh /bin
Bug#602568: squeeze-di-beta1 installer: partman hang
I finally found the parted_servec.c into
http://packages.debian.org/squeeze/partman-base . I think the problem is
in the OPEN command path for /dev/sdb:
void
command_open()
{
log(command_open()); === found in the log
char *device;
scan_device_name();
if (1 != iscanf(%as, device))
critical_error(Expected device name.);
log(Request to open %s, device_name); === in the log
open_out();
if (device_opened(device_name)) {
static char *only_ok[] = { OK, NULL };
log(Warning: the device is already opened);
pseudo_exception(Warning,
The device is already opened., only_ok);
} else {
set_device_named(device_name, ped_device_get(device));
}
oprintf(OK\n); === In the log too
if (NULL != device_named(device_name)) {
oprintf(OK\n); === Last line from the log
deactivate_exception_handler();
set_disk_named(device_name,
ped_disk_new(device_named(device_name)));
unchange_named(device_name);
activate_exception_handler();
} else
oprintf(failed\n);
free(device);
}
So I now suspect that the function ped_disk_new() is where parted_server
failed. But it's actually just a beat, not a proven fact.
I have see that in the install expert mode that parted can be loaded as
a additional component, so I did and give it a try:
parted /dev/sda print
Model: ATA ST9250315AS (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End SizeType File system Flags
1 1049kB 54.5GB 54.5GB primary ntfs
3 54.5GB 55.1GB 537MB primary ext3 boot
4 55.1GB 250GB 195GB extended
5 55.1GB 109GB 53.7GB logical btrfs
2 250GB 250GB 21.2MB primary
Seem to be OK, despite the btrfs partition. Now with /dev/sdb:
parted /dev/sdb print
You found a bug in GNU Parted! Here's what you have to do:
Don't panic! The bug has most likely not affected any of your data.
Help us to fix this bug by doing the following:
Check whether the bug has already been fixed by checking
the last version of GNU Parted that you can find at:
http://ftp.gnu.org/gnu/parted/
Please check this version prior to bug reporting.
If this has not been fixed yet or if you don't know how to check,
please visit the GNU Parted website:
http://www.gnu.org/software/parted
for further information.
Your report should contain the version of this release (2.3)
along with the error message below, the output of
parted DEVICE unit co print unit s print
and the following history of commands you entered.
Also include any additional information about your setup you
consider important.
Assertion (dev != NULL) at ../../libparted/cs/geom.c:78 in function
ped_geometry_new() failed.
Ah! It's now clear that this is the 5MB FAT12 partition on /dev/sdb that
cause the problem. I think that the bug can now safely be assigned to
either parted or libparted0-udeb.
Here is the offending code:
/**
* Create a new PedGeometry object on \p disk, starting at \p start with a
* size of \p length sectors.
*
* \return NULL on failure.
*/
PedGeometry*
ped_geometry_new (const PedDevice* dev, PedSector start, PedSector length)
{
PedGeometry*geom;
PED_ASSERT (dev != NULL, return NULL); === Abort here.
geom = (PedGeometry*) ped_malloc (sizeof (PedGeometry));
if (!geom)
goto error;
if (!ped_geometry_init (geom, dev, start, length))
goto error_free_geom;
return geom;
error_free_geom:
free (geom);
error:
return NULL;
}
Obviously, this problem is not really into ped_geometry_new(), but into
a previously executed code that should have created the const PedDevice*
dev.
Now, is parted abort with a so clear assert message, this don't explain
why parted_server can terminate without generating a comparable message,
and why 30parted is unable to see that parted_server is not there
anymore. So maybe some more bugs should be open to fix all of this.
Regards,
Jean-Christian de Rivaz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
Can't easily find what's wrong into the parted-2.3/libparted code. But GNU Parted 1.8.8 from a Lenny machine work on this disk: parted /dev/sdb print Error: Can't have the end before the start! Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 32.8kB 5243kB 5210kB primary fat16 The problem maybe cam from the message Can't have the end before the start!. Also this version of parted say this is a FAT16 partition, but fdisk say this is a FAT12: fdisk -l /dev/sdb Disk /dev/sdb: 5 MB, 5242880 bytes 256 heads, 32 sectors/track, 1 cylinders Units = cylinders of 8192 * 512 = 4194304 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 1 250881 FAT12 Partition 1 has different physical/logical endings: phys=(40, 255, 32) logical=(1, 63, 32) It also say that something is wrong with the geometry of this partition. I then do a new partition on the /dev/sdb: Disk /dev/sdb: 5 MB, 5242880 bytes 256 heads, 32 sectors/track, 1 cylinders Units = cylinders of 8192 * 512 = 4194304 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 1 140801 FAT12 The parted from Lenny is still not happy: parted /dev/sdb print Error: Can't have the end before the start! Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 16.4kB 4194kB 4178kB primary And the parted on the Squeeze installer still hang the same way. After that I tryed to use a FAT16 partition: Disk /dev/sdb: 5 MB, 5242880 bytes 256 heads, 32 sectors/track, 1 cylinders Units = cylinders of 8192 * 512 = 4194304 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 1 140806 FAT16 But still, the parted from the installed abort with the same message. At this point, I am a bit confused: why the parted from the Squeeze installer get so ill with this 5MB disk despite the fact that others tools and previous parted version handle it correctly. Finally I removed the partition from that /dev/sdb disk and the installed worked. Ah! So the bug seem to be related to a unusual geometry of that disk. Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
Now Squeeze is installed into the notepad and I can test the parted 2.3-3 that is available from it. No problem without partition of course, bt the surprise is that it also have no issue with a FAT12 partition: fdisk -l /dev/sdb Disk /dev/sdb: 5 MB, 5242880 bytes 1 heads, 10 sectors/track, 1024 cylinders Units = cylinders of 10 * 512 = 5120 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 2102451151 FAT12 parted /dev/sdb print Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 5120B 5243kB 5238kB primary But from http://packages.debian.org/squeeze/libparted0-udeb it seem that this is this 2.3-3 version that is used into the installer. I feel lost in doubt. I rebooted and restarted the installer, only to find that his parted still abort the same way. Now the question is why the parted from the installer react so bad to something that do not hurt the parted from squeeze, since there should be compiled from the same code base ? Or is there something missing in the picture ? Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
Interesting finding: libparted.so.0.0.1 (from *.deb) != libparted.so.0.0.1 (from *.udeb) I have do this: apt-get source parted cd parted-2.3/ dpkg-buildpackage -rfakeroot -uc -us cd .. mkdir install-bin dpkg -x libparted0-udeb_2.3-3_i386.udeb install-bin/ dpkg -x parted-udeb_2.3-3_i386.udeb install-bin/ cd install-bin/ ls -l * lib: total 484 lrwxrwxrwx 1 jcdr jcdr 18 6 nov 21:46 libparted.so.0 - libparted.so.0.0.1 -rw-r--r-- 1 jcdr jcdr 489596 6 nov 21:37 libparted.so.0.0.1 sbin: total 72 -rwxr-xr-x 1 jcdr jcdr 68012 6 nov 21:37 parted Now test ./sbin/parted with the system library: ldd ./sbin/parted linux-gate.so.1 = (0xb77c) libparted.so.0 = /lib/libparted.so.0 (0xb773d000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb75f7000) libuuid.so.1 = /lib/libuuid.so.1 (0xb75f2000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb75ee000) libdevmapper.so.1.02.1 = /lib/libdevmapper.so.1.02.1 (0xb75cc000) libblkid.so.1 = /lib/libblkid.so.1 (0xb75b) /lib/ld-linux.so.2 (0xb77c1000) libselinux.so.1 = /lib/libselinux.so.1 (0xb7595000) libudev.so.0 = /lib/libudev.so.0 (0xb7586000) ./sbin/parted /dev/sdb print WARNING: You are not superuser. Watch out for permissions. Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 5120B 5243kB 5238kB primary It use the /lib/libparted.so.0 (with the root /) and work fine. Now test ./sbin/parted with the installer library: LD_LIBRARY_PATH=./lib/ ldd ./sbin/parted linux-gate.so.1 = (0xb78b1000) libparted.so.0 = ./lib/libparted.so.0 (0xb7831000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb76da000) libuuid.so.1 = /lib/libuuid.so.1 (0xb76d5000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb76d1000) libdevmapper.so.1.02.1 = /lib/libdevmapper.so.1.02.1 (0xb76af000) libblkid.so.1 = /lib/libblkid.so.1 (0xb7693000) /lib/ld-linux.so.2 (0xb78b2000) libselinux.so.1 = /lib/libselinux.so.1 (0xb7678000) libudev.so.0 = /lib/libudev.so.0 (0xb7669000) LD_LIBRARY_PATH=./lib/ ./sbin/parted /dev/sdb print WARNING: You are not superuser. Watch out for permissions. You found a bug in GNU Parted! Here's what you have to do: Don't panic! The bug has most likely not affected any of your data. Help us to fix this bug by doing the following: Check whether the bug has already been fixed by checking the last version of GNU Parted that you can find at: http://ftp.gnu.org/gnu/parted/ Please check this version prior to bug reporting. If this has not been fixed yet or if you don't know how to check, please visit the GNU Parted website: http://www.gnu.org/software/parted for further information. Your report should contain the version of this release (2.3) along with the error message below, the output of parted DEVICE unit co print unit s print and the following history of commands you entered. Also include any additional information about your setup you consider important. Assertion (dev != NULL) at ../../libparted/cs/geom.c:78 in function ped_geometry_new() failed. Abandon It use the ./lib/libparted.so.0 (the current directory lib instead of the root /) and failed. I verified that it work this way with the others partitions. There is obviously something different between this two library, despite the fact that there are compiled form the same source package: ls -l /lib/libparted.so.0.0.1 lib/libparted.so.0.0.1 -rw-r--r-- 1 root root 432668 17 oct 12:18 /lib/libparted.so.0.0.1 -rw-r--r-- 1 jcdr jcdr 489596 6 nov 21:37 lib/libparted.so.0.0.1 file /lib/libparted.so.0.0.1 lib/libparted.so.0.0.1 /lib/libparted.so.0.0.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped lib/libparted.so.0.0.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped The installed library is about 56k less in size that the system library. Is some code path not compiled for the installer version ? Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
I now have a backtrace: Backtrace has 20 calls on stack: 20: ./libparted/.libs/libparted.so.0(ped_assert+0x28) [0xb77d9073] 19: ./libparted/.libs/libparted.so.0(ped_geometry_new+0x5a) [0xb77e2aed] 18: ./libparted/.libs/libparted.so.0(ped_geometry_duplicate+0x73) [0xb77e2bc6] 17: ./libparted/.libs/libparted.so.0(ped_constraint_init+0x15e) [0xb77e3c92] 16: ./libparted/.libs/libparted.so.0(ped_constraint_new+0x82) [0xb77e3d54] 15: ./libparted/.libs/libparted.so.0(+0x504c8) [0xb781c4c8] 14: ./libparted/.libs/libparted.so.0(+0x50bdd) [0xb781cbdd] 13: ./libparted/.libs/libparted.so.0(+0x51249) [0xb781d249] 12: ./libparted/.libs/libparted.so.0(+0x517b7) [0xb781d7b7] 11: ./libparted/.libs/libparted.so.0(+0x1328f) [0xb77df28f] 10: ./libparted/.libs/libparted.so.0(ped_disk_add_partition+0x15f) [0xb77e1a7a] 9: ./libparted/.libs/libparted.so.0(+0x4e72c) [0xb781a72c] 8: ./libparted/.libs/libparted.so.0(+0x4e94e) [0xb781a94e] 7: ./libparted/.libs/libparted.so.0(ped_disk_new+0xd2) [0xb77dddbe] 6: /home/jcdr/install-O2/sbin/parted() [0x804dec5] 5: /home/jcdr/install-O2/sbin/parted() [0x804b26d] 4: /home/jcdr/install-O2/sbin/parted() [0x8054b7f] 3: /home/jcdr/install-O2/sbin/parted() [0x8051a52] 2: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb768bc76] 1: /home/jcdr/install-O2/sbin/parted() [0x804af21] I can reproduce this with this command from the package build: parted-2.3/build-udeb$ LD_LIBRARY_PATH=./libparted/.libs/ ~/install-O2/sbin/parted /dev/sdb print While analyzing the debian/rules I found this: # Workaround/fix bug #442308 CFLAGS += -fgnu89-inline UDEB_CFLAGS += -fgnu89-inline This bug is tracked here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442308 This workaround is now obsolete as is was introduced 3 years ago for parted 1.8-7 and we now use parted 2.3-3 that compile just fine without this option. But unfortunately this is not the cause of my problem. After a lot of test with different config.status file, I found this picture by testing only the build-udeb: library fail with CFLAGS=' -Werror' library fail with CFLAGS='-g -Werror' library good with CFLAGS='-g -O2 -Werror' library good with CFLAGS='-O2 -Werror' Something wrong without the -O2 optimization ? Seem incredible. But... I just want to check: library good in build-deb with CFLAGS='-g -O2 -fgnu89-inline -Werror' library good in build-udeb with CFLAGS='-O2 -fgnu89-inline -Werror' library fail in build-deb with CFLAGS='-g -fgnu89-inline -Werror' library fail in build-udeb with CFLAGS='-fgnu89-inline -Werror' Ouch! It better to use the -O2 optimizer ! Ok, now at this stage I can give some facts: 1) The lib/partman/init.d/30parted script is unable to detect and report abnormal parted-server end. 2) The CFLAGS -fgnu89-inline option from the bug #442308 can be removed for the current version of parted-2.3-3 3) Something bad happen with the parted-2.3-3 code when the -O2 optimization is not used. Enough for me. Please, someone from Debian, give me some instruction of what action must be taken now. Should I open others bugs report for 1) and 2) ? Regards, Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
Please find in attachment my current proposition of patch. It remove the
obsolete -fgnu89-inline and use the same flags for build-udeb than for
build-deb to get the -O2 optimization.
This work, but I still don't understand why the code fail without
optimization.
Regards,
Jean-Christian de Rivaz
--- a/debian/rules 2010-11-07 02:57:24.0 +0100
+++ b/debian/rules 2010-11-07 02:59:01.0 +0100
@@ -89,14 +89,11 @@
ifeq (, $(CFLAGS))
CFLAGS = -g
-UDEB_CFLAGS = -g
ifeq (, $(findstring noopt, $(DEB_BUILD_OPTIONS)))
CFLAGS += -O2
-UDEB_CFLAGS += -Os
else
CFLAGS += -O0
-UDEB_CFLAGS += -O0
endif
endif
@@ -118,10 +115,6 @@
CONFFLAGS += --disable-pc98
endif
-# Workaround/fix bug #442308
-CFLAGS += -fgnu89-inline
-UDEB_CFLAGS += -fgnu89-inline
-
# Enable device-mapper only on Linux
ifeq (linux, $(DEB_BUILD_ARCH_OS))
CONFDEVMAPPER = --enable-device-mapper
@@ -186,7 +179,7 @@
dh_testdir
[ -d build-udeb ] || mkdir build-udeb
- cd build-udeb CFLAGS=$(UDEB_CFLAGS) ac_cv_header_execinfo_h=no ../configure --prefix=/usr \
+ cd build-udeb CFLAGS=$(CFLAGS) ac_cv_header_execinfo_h=no ../configure --prefix=/usr \
--sbindir=/sbin --libdir=/lib --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info --enable-shared --disable-static \
--build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
Bug#602568: squeeze-di-beta1 installer: partman hang
code 143 Nov 5 22:25:40 main-menu[337]: WARNING **: Menu item 'partman-base' failed. Nov 5 22:26:06 main-menu[337]: INFO: Menu item 'save-logs' selected Nov 5 22:32:55 main-menu[337]: INFO: Menu item 'save-logs' selected Nov 5 22:33:38 main-menu[337]: INFO: Menu item 'save-logs' selected The debian installed log provide a partman log: /bin/partman: *** /lib/partman/init.d/25md-devices: *** /lib/partman/init.d/30parted: *** parted_server: === Starting the server parted_server: main_loop: iteration 1 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sda /dev/sda parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sda parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK parted_server: Note =dev=sda as unchanged parted_server: Closing infifo and outfifo parted_server: main_loop: iteration 2 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sdb /dev/sdb parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sdb parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK It seem to hang when processing /dev/sdb if I understand correctly. /dev/sdb is actually a small USB disk that is integrated into the same USB stick as the 2GB /dev/sdc USB disk. When I insert this USB stick into a regular Lenny machine I get this: [130550.986061] usb 2-2: new high speed USB device using ehci_hcd and address 11 [130551.189585] usb 2-2: configuration #1 chosen from 1 choice [130551.190036] scsi15 : SCSI emulation for USB Mass Storage devices [130551.190307] usb-storage: device found at 11 [130551.190317] usb-storage: waiting for device to settle before scanning [130551.190547] usb 2-2: New USB device found, idVendor=1dbe, idProduct=0102 [130551.190557] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [130551.190563] usb 2-2: SerialNumber: AA2719E4 [130556.190280] usb-storage: device scan complete [130556.191114] scsi 15:0:0:0: Direct-Access disk2go PURE II 8.20 PQ: 0 ANSI: 2 [130556.191726] scsi 15:0:0:1: Direct-Access disk2go PURE II 8.20 PQ: 0 ANSI: 2 [130556.194101] sd 15:0:0:0: [sdb] 10240 512-byte hardware sectors (5 MB) [130556.194599] sd 15:0:0:0: [sdb] Write Protect is off [130556.194603] sd 15:0:0:0: [sdb] Mode Sense: 03 00 00 00 [130556.194604] sd 15:0:0:0: [sdb] Assuming drive cache: write through [130556.196098] sd 15:0:0:0: [sdb] 10240 512-byte hardware sectors (5 MB) [130556.196602] sd 15:0:0:0: [sdb] Write Protect is off [130556.196605] sd 15:0:0:0: [sdb] Mode Sense: 03 00 00 00 [130556.196607] sd 15:0:0:0: [sdb] Assuming drive cache: write through [130556.196609] sdb: sdb1 [130556.490327] sd 15:0:0:0: [sdb] Attached SCSI removable disk [130556.495952] sd 15:0:0:1: [sdc] 4184064 512-byte hardware sectors (2142 MB) [130556.497988] sd 15:0:0:1: [sdc] Write Protect is off [130556.497992] sd 15:0:0:1: [sdc] Mode Sense: 03 00 00 00 [130556.497993] sd 15:0:0:1: [sdc] Assuming drive cache: write through [130556.500437] sd 15:0:0:1: [sdc] 4184064 512-byte hardware sectors (2142 MB) [130556.500973] sd 15:0:0:1: [sdc] Write Protect is off [130556.500976] sd 15:0:0:1: [sdc] Mode Sense: 03 00 00 00 [130556.500977] sd 15:0:0:1: [sdc] Assuming drive cache: write through [130556.500980] sdc: [130556.501789] sd 15:0:0:1: [sdc] Attached SCSI removable disk [130556.813803] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [130556.917917] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! So /dev/sdb is just an another innocent small 5MB usb storage disk. It's strange that partman can be getting trouble with this. How can I get more debug informations from partman to go deeper into the analysis ? Note: I first tried a AMD64 install that have the same exact problem before giving this report from a i386 install. The machine is only 2 days old and run without problem Windows 7 and Meego 1.1, so no hardware failure is expected. Regards, Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602568: squeeze-di-beta1 installer: partman hang
Miguel Figueiredo a écrit : A Sexta 05 Novembro 2010 23:06:26 Jean-Christian de Rivaz você escreveu: [...] How can I get more debug informations from partman to go deeper into the analysis ? [...] You can check /var/log/installer/partman and the syslog on that location can be useful too. Unfortunately there is no /var/log/installer/ directory: ls -al /var/log drwxr-xr-x2 root root 0 Nov 5 22:33 . drwxr-xr-x8 root root 0 Nov 5 22:23 .. -rw-r--r--1 root root 17172 Nov 5 22:33 hardware-summary lrwxrwxrwx1 root root44 Nov 5 22:33 install-report.template - /usr/share/save-logs/install-report.template lrwxrwxrwx1 root root16 Nov 5 22:33 lsb-release - /etc/lsb-release -rw-r--r--1 root root 993 Nov 5 22:23 partman lrwxrwxrwx1 root root20 Nov 5 22:33 status - /var/lib/dpkg/status -rw-r--r--1 root root 71813 Nov 5 22:33 syslog I already inspected the syslog as you can find the interesting part in my initial report: partman simply hang without verbose message. This is why I search a way to get more informations. Jean-Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585018: coinor-libcoinutils0: Cannot read gzip'ed or bzip2'ed file because zlib and bzlib was not compiled into COIN.
Package: coinor-libcoinutils0 Version: 2.6.3-1 Severity: normal Just try the most basic example from Clp: cp /usr/share/doc/coinor-libclp-doc/examples/hello.cpp . cp /usr/share/doc/coinor-libclp-doc/examples/hello.mps.gz . g++ -I /usr/include/coin -l Clp hello.cpp -o hello When executing: ../hello hello.mps.gz Cannot read gzip'ed file because zlib was not compiled into COIN! in CoinFileInput::create Clp3001W There were -1 errors when importing model from hello.mps.gz The same problem occure when using bzip compressed file: ../hello hello.mps.bz2 Cannot read bzip2'ed file because bzlib was not compiled into COIN! in CoinFileInput::create Clp3001W There were -1 errors when importing model from hello.mps.bz2 The ./hello work with a uncompressed hello.mps file. MPS files are usually compressed because this old format allow a very good compression ratio and many linear programming problem have a hug number of data. So it would greatly improve the usability of COIN-OR on Debian to have compression files support, at least for the input file. This should not be a big issue as the configure have the COIN_HAS_ZLIB and the COIN_HAS_BZLIB variable. Maybe juste a dependency problem. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/1 CPU core) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages coinor-libcoinutils0 depends on: ii libatlas3gf-base [liblapack.s 3.6.0-24 Automatically Tuned Linear Algebra ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.4-1 GCC support library ii liblapack3gf [liblapack.so.3g 3.2.1-8library of linear algebra routines ii libstdc++64.4.4-1The GNU Standard C++ Library v3 coinor-libcoinutils0 recommends no packages. coinor-libcoinutils0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585018: configure --enable-gnu-packages is part of the solution
This simple change improve the situation a little: diff --git a/debian/rules b/debian/rules index b5301a4..44e5bca 100755 --- a/debian/rules +++ b/debian/rules @@ -4,7 +4,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk LDFLAGS += -llapack -DEB_CONFIGURE_EXTRA_FLAGS += --enable-static +DEB_CONFIGURE_EXTRA_FLAGS += --enable-static --enable-gnu-packages build/coinor-libcoinutils-doc:: debian/stamp-build-coinor-libcoinutils-doc debian/stamp-build-coinor-libcoinutils-doc: But now the hello example say: ./hello hello.mps.gz ./hello: symbol lookup error: /usr/lib/libCoinUtils.so.0: undefined symbol: gzopen Or: ./hello hello.mps.bz2 ./hello: symbol lookup error: /usr/lib/libCoinUtils.so.0: undefined symbol: BZ2_bzReadOpen Effectively, ldd don't list the compression libraries: ldd hello linux-vdso.so.1 = (0x7fffb3a93000) libClp.so.0 = /usr/lib/libClp.so.0 (0x7f87542f7000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f8753fe3000) libm.so.6 = /lib/libm.so.6 (0x7f8753d6) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f8753b4a000) libc.so.6 = /lib/libc.so.6 (0x7f87537f6000) libCoinUtils.so.0 = /usr/lib/libCoinUtils.so.0 (0x7f87534bc000) /lib64/ld-linux-x86-64.so.2 (0x7f875468b000) liblapack.so.3gf = /usr/lib/atlas/liblapack.so.3gf (0x7f87528c7000) libblas.so.3gf = /usr/lib/atlas/libblas.so.3gf (0x7f8751f0a000) libgfortran.so.3 = /usr/lib/libgfortran.so.3 (0x7f8751c1e000) Something more is needed... Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585018: Working solution
I found that this change allow to build a fully working libCoinUtils.so.0 with correct dependencies to libz.so.1 and libbz2.so.1.0: diff --cc debian/rules index e08eea3,e08eea3,e08eea3..b5301a4 --- a/debian/rules +++ b/debian/rules -3,8 -3,8 -3,8 +3,8 include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk ---LDFLAGS += -llapack -lz -lbz2 ---DEB_CONFIGURE_EXTRA_FLAGS += --enable-static --enable-gnu-packages +++LDFLAGS += -llapack +++DEB_CONFIGURE_EXTRA_FLAGS += --enable-static build/coinor-libcoinutils-doc:: debian/stamp-build-coinor-libcoinutils-doc debian/stamp-build-coinor-libcoinutils-doc: Now the hello example work fine with both hello.mps.gz file and hello.mps.bz2 file. file hello.mps* hello.mps: ASCII text hello.mps.bz2: bzip2 compressed data, block size = 900k hello.mps.gz: gzip compressed data, from Unix, last modified: Tue Jun 8 13:01:53 2010 The following commands gives all the exact same output. ./hello hello.mps ./hello hello.mps.gz ./hello hello.mps.bz2 Please apply. Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585018: configure --enable-gnu-packages is not part of the solution
Soeren Sonnenburg a écrit : On Tue, 2010-06-08 at 15:56 +0200, Jean-Christian de Rivaz wrote: This simple change improve the situation a little: diff --git a/debian/rules b/debian/rules index b5301a4..44e5bca 100755 --- a/debian/rules +++ b/debian/rules @@ -4,7 +4,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk LDFLAGS += -llapack -DEB_CONFIGURE_EXTRA_FLAGS += --enable-static +DEB_CONFIGURE_EXTRA_FLAGS += --enable-static --enable-gnu-packages wait we cannot do that. coinor is licensed under the CPL. That means it is in conflict to the GPL and thus products linked to gnu gpl based backages is not allowed ... However bzip2/gzip are not gpl but bsd licenses so a different patch force enabling gzip/bzip2 would work. (Should I keep your private email for the reply or only the bug email ? I am not familiar with the Debian reporting convention. Sorry.) Thanks for pointing out this license issue, I have completely missed it. From the followings files: /usr/share/doc/zlib1g-dev/copyright /usr/share/doc/libbz2-dev/copyright It seem to me that both libraries have there own licenses, nor GPL, nor BSD. The /usr/share/doc/coinor-libcoinutils-dev/copyright license is more complicated, but I get the feeling (to be formally verified) that it is compatible with the license of both zlib1g and libbz2. So, from my understanding, the bug is to allow the zlib1g and libbz2 test in the CoinUtils/configure only if the --enable-gnu-packages is provided. It should alway test them because there are not GNU package at all and do not use the GPL license. I successfully tested this idea with the following patch (also in attachment because I worry that the mail split some lines): diff --git a/CoinUtils/configure b/CoinUtils/configure index 4e7660d..67fc675 100755 --- a/CoinUtils/configure +++ b/CoinUtils/configure @@ -32870,7 +32870,6 @@ fi; coin_has_zlib=no -if test $coin_enable_gnu = yes; then #if test x = x; then # hdr=#include zlib.h #else @@ -33117,7 +33116,6 @@ cat confdefs.h \_ACEOF _ACEOF fi -fi @@ -33137,7 +33135,6 @@ fi coin_has_bzlib=no -if test $coin_enable_gnu = yes; then #if test x = x; then # hdr=#include bzlib.h #else @@ -33384,7 +33381,6 @@ cat confdefs.h \_ACEOF _ACEOF fi -fi ## diff --git a/debian/rules b/debian/rules index b5301a4..d577b37 100755 --- a/debian/rules +++ b/debian/rules @@ -3,7 +3,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk -LDFLAGS += -llapack +LDFLAGS += -llapack -lz -lbz2 DEB_CONFIGURE_EXTRA_FLAGS += --enable-static build/coinor-libcoinutils-doc:: debian/stamp-build-coinor-libcoinutils-doc Could this satisfy the license problem ? Jean-Christian diff --git a/CoinUtils/configure b/CoinUtils/configure index 4e7660d..67fc675 100755 --- a/CoinUtils/configure +++ b/CoinUtils/configure @@ -32870,7 +32870,6 @@ fi; coin_has_zlib=no -if test $coin_enable_gnu = yes; then #if test x = x; then # hdr=#include zlib.h #else @@ -33117,7 +33116,6 @@ cat confdefs.h \_ACEOF _ACEOF fi -fi @@ -33137,7 +33135,6 @@ fi coin_has_bzlib=no -if test $coin_enable_gnu = yes; then #if test x = x; then # hdr=#include bzlib.h #else @@ -33384,7 +33381,6 @@ cat confdefs.h \_ACEOF _ACEOF fi -fi ## diff --git a/debian/rules b/debian/rules index b5301a4..d577b37 100755 --- a/debian/rules +++ b/debian/rules @@ -3,7 +3,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk -LDFLAGS += -llapack +LDFLAGS += -llapack -lz -lbz2 DEB_CONFIGURE_EXTRA_FLAGS += --enable-static build/coinor-libcoinutils-doc:: debian/stamp-build-coinor-libcoinutils-doc
Bug#372946: apt-listbugs
I discovered exactly this bug today while updating my Sarge machine. This is strange as I never see this before and I don't remenber having changed something significant. Here are my last updated package using 'ls -altr /var/lib/dpkg/info' : -rwxr-xr-x 1 root root4001 2006-09-20 14:19 mailman.config -rw-r--r-- 1 root root 16347 2006-09-20 14:19 mailman.templates -rwxr-xr-x 1 root root1378 2006-09-20 14:19 mailman.prerm -rwxr-xr-x 1 root root1203 2006-09-20 14:19 mailman.preinst -rwxr-xr-x 1 root root1073 2006-09-20 14:19 mailman.postrm -rwxr-xr-x 1 root root 15150 2006-09-20 14:19 mailman.postinst -rw-r--r-- 1 root root 45 2006-09-20 14:19 mailman.conffiles -rw-r--r-- 1 root root 216979 2006-09-20 14:19 mailman.md5sums -rwxr-xr-x 1 root root 160 2006-09-23 12:03 gdhcpd.postrm -rwxr-xr-x 1 root root 185 2006-09-23 12:03 gdhcpd.postinst -rw-r--r-- 1 root root 725 2006-09-23 12:03 gdhcpd.md5sums -rw-r--r-- 1 root root1346 2006-09-23 12:28 toolame.md5sums -rw-r--r-- 1 root root 74 2006-09-25 22:55 nfs-kernel-server.list -rw-r--r-- 1 root root 977 2006-09-25 22:55 gzip.list -rw-r--r-- 1 root root 525 2006-09-25 22:55 libgnutls11.list -rw-r--r-- 1 root root1148 2006-09-25 22:55 libgnutls11-dev.list -rw-r--r-- 1 root root 230 2006-09-25 22:55 libisc11.list -rw-r--r-- 1 root root 242 2006-09-25 22:55 libisccfg1.list -rw-r--r-- 1 root root 230 2006-09-25 22:55 libdns21.list -rw-r--r-- 1 root root 240 2006-09-25 22:55 libbind9-0.list -rw-r--r-- 1 root root 236 2006-09-25 22:55 liblwres9.list -rw-r--r-- 1 root root 60 2006-09-25 22:55 alsaplayer.list -rw-r--r-- 1 root root 266 2006-09-25 22:55 libalsaplayer0.list -rw-r--r-- 1 root root 672 2006-09-25 22:55 gdhcpd.list -rw-r--r-- 1 root root 299 2006-09-25 22:55 mindi-kernel.list -rw-r--r-- 1 root root 876 2006-09-25 22:55 toolame.list -rw-r--r-- 1 root root 742 2006-09-25 22:55 nfs-user-server.list -rw-r--r-- 1 root root4978 2006-09-26 19:50 mozilla-thunderbird.templates -rwxr-xr-x 1 root root1284 2006-09-26 19:50 mozilla-thunderbird.postinst -rwxr-xr-x 1 root root 878 2006-09-26 19:50 mozilla-thunderbird.prerm -rwxr-xr-x 1 root root1209 2006-09-26 19:50 mozilla-thunderbird.preinst -rwxr-xr-x 1 root root 558 2006-09-26 19:50 mozilla-thunderbird.postrm -rw-r--r-- 1 root root 41684 2006-09-26 19:50 mozilla-thunderbird.md5sums -rw-r--r-- 1 root root6545 2006-09-30 12:06 libssl0.9.7.templates -rwxr-xr-x 1 root root 15 2006-09-30 12:06 openssl.prerm -rwxr-xr-x 1 root root 665 2006-09-30 12:06 openssl.preinst -rwxr-xr-x 1 root root 120 2006-09-30 12:06 openssl.postinst -rw-r--r-- 1 root root 27288 2006-09-30 12:06 openssl.md5sums -rw-r--r-- 1 root root 21 2006-09-30 12:06 openssl.conffiles -rwxr-xr-x 1 root root 15 2006-09-30 12:06 libssl-dev.prerm -rwxr-xr-x 1 root root 15 2006-09-30 12:06 libssl-dev.postinst -rw-r--r-- 1 root root 30394 2006-09-30 12:06 libssl-dev.md5sums -rw-r--r-- 1 root root 53 2006-09-30 12:06 libssl0.9.7.shlibs -rwxr-xr-x 1 root root 15 2006-09-30 12:06 libssl0.9.7.prerm -rwxr-xr-x 1 root root 15 2006-09-30 12:06 libssl0.9.7.preinst -rwxr-xr-x 1 root root 321 2006-09-30 12:06 libssl0.9.7.postrm -rwxr-xr-x 1 root root3866 2006-09-30 12:06 libssl0.9.7.postinst -rw-r--r-- 1 root root 739 2006-09-30 12:06 libssl0.9.7.md5sums -rw-r--r-- 1 root root 128451 2006-10-05 13:18 mailman.list -rw-r--r-- 1 root root 50056 2006-10-05 13:18 libssl-dev.list -rw-r--r-- 1 root root 507 2006-10-05 13:18 libssl0.9.7.list -rw-r--r-- 1 root root 17073 2006-10-05 13:18 openssl.list -rw-r--r-- 1 root root 30210 2006-10-05 19:08 mozilla-thunderbird.list I remember seeing the bug only while doing the late two updates, the 2006-10-05 13:18 and the 2006-10-05 19:08. The only special thing on that machine is that it is NFS root, but I usualy don't have problem with that (expect that I have to use user space NFS instead of kernel space NFS for re-exporting). Any hit how to work around this problem ? -- Jean-Christian de Rivaz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
