Bug#837123: [anna] segfault in wheezy installer
On Wed, Sep 14, 2016 at 08:59:52AM +0200, Aurelien Jarno wrote: > > > More details. > > The target system is pxe booted and next-server takes it to a (debian) > > system running tftpd-hpa. The defaults.cfg has lots of boot targets > > but the one I have been testing with is the netboot image, in manual > > install mode. The only boot options it is given are > > 'append vga=normal initrd=yadayada' > > It also falls over if I feed it a preseed file, where we use > > 'append auto=true priority=critical vga=normal initrd=yadayda > > url=blahdeblah' > > Thanks for the details. Here in a QEMU VM, both work fine. I learned today that this whole goose chase started when a colleague hit this using qemu and bridged networking. Before today I thought it was real hardware. I tried this with vmware fusion, setting next-server to the pxe server used above and the manual/interactive installer target. I was using NATted networking here; resolv.conf lists only the vmware nameserver (172.16.119.2). busybox segfaults at the same time and in the same way. If I test with wget or ping, I get a segfault unless I use IP addresses or add the hostname I want to resolve to /etc/hosts. I tried patching the initrd so that the hostname and lookup could be pre-configured. /etc/nsswitch.conf comes through unscathed but /etc/hosts is overwritten. When I hit the segfault I added the necessary /etc/hosts entry and retried. That worked; I was able to do a complete installation. I also figured out how to use netcat to get the log file. I've attached the syslog up to the first segfault, with DEBCONF_DEBUG=5. Vince syslog.debug=5.gz Description: application/gzip
Bug#837123: [anna] segfault in wheezy installer
On Wed, Sep 14, 2016 at 09:01:20AM +0200, Aurelien Jarno wrote: > > ... > > warning: Can't read pathname for load map: Input/output error. > > > > warning: Could not load shared library symbols for 4 libraries, e.g. > > /lib/libc.so.6. > > Use the "info sharedlibrary" command to see the complete listing. > > Do you need "set solib-search-path" or "set sysroot"? > > Core was generated by `ping ftp.au.debian.org'. > > Program terminated with signal 11, Segmentation fault. > > #0 0x7f826609d0ca in ?? () > > (gdb) bt full > > #0 0x7f826609d0ca in ?? () > > No symbol table info available. > > #1 0x in ?? () > > No symbol table info available. > > (gdb) q > > Have you installed libc6-dbg on this wheezy machine? Anyway I am afraid > that gdb is confused as the libc6 in debian-installer got some symbols > removed... I hadn't in the example above but it makes no difference if I have libc6-dbg installed, the bt is the same. Vince
Bug#837123: [anna] segfault in wheezy installer
On Wed, Sep 14, 2016 at 09:29:18AM +1000, Vincent McIntyre wrote: > > Also you might want to use the console (alt+f2) to run wget by hand and > > see if the issue happen with all hosts or only some of them. > > I tried to wget pages from a few web sites from the alt+f2 console. > It segfaulted every time when I used a DNS name in the URL, > but worked if I used an IP address in the URL. > ping does the same thing; segfaults only when using domain names. > > If I put an entry in /etc/hosts and try to access that hostname, > wget and ping also segfault, until I add this line to nsswitch.conf: > > hosts: files dns > > Then they both work for that hostname. > The only other nsswitch.conf lines are for passwd, group & shadow. > I was able to netcat busybox & the coredump to a wheezy machine and got this backtrace, which does not look like it is much help... % gdb ./ping ./ping.core GNU gdb (GDB) 7.4.1-debian ... warning: Can't read pathname for load map: Input/output error. warning: Could not load shared library symbols for 4 libraries, e.g. /lib/libc.so.6. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `ping ftp.au.debian.org'. Program terminated with signal 11, Segmentation fault. #0 0x7f826609d0ca in ?? () (gdb) bt full #0 0x7f826609d0ca in ?? () No symbol table info available. #1 0x in ?? () No symbol table info available. (gdb) q Vince --
Bug#837123: [anna] segfault in wheezy installer
On Tue, Sep 13, 2016 at 11:03:19PM +0200, Aurelien Jarno wrote: ... > > If all of that makes no difference, what would be the next step? > > What would be interesting would be to try to reproduce the issue in > qemu or virtualbox, with as many things as possible close to your > system. > Just to clarify - you mean try to run the installer using a qemu VM as the target for installation? I can certainly try that. More details. The target system is pxe booted and next-server takes it to a (debian) system running tftpd-hpa. The defaults.cfg has lots of boot targets but the one I have been testing with is the netboot image, in manual install mode. The only boot options it is given are 'append vga=normal initrd=yadayada' It also falls over if I feed it a preseed file, where we use 'append auto=true priority=critical vga=normal initrd=yadayda url=blahdeblah' > Also you might want to use the console (alt+f2) to run wget by hand and > see if the issue happen with all hosts or only some of them. I tried to wget pages from a few web sites from the alt+f2 console. It segfaulted every time when I used a DNS name in the URL, but worked if I used an IP address in the URL. ping does the same thing; segfaults only when using domain names. If I put an entry in /etc/hosts and try to access that hostname, wget and ping also segfault, until I add this line to nsswitch.conf: hosts: files dns Then they both work for that hostname. The only other nsswitch.conf lines are for passwd, group & shadow. > > My concern is there's a segfault still lurking in the stretch > > version. If we can squash it here that fix could be forward-ported. > > This is very unlikely, as both debian-installer and glibc are quite > different in stretch and do not use the shared library reduction > anymore. Ok that's good to know.
Bug#775541: tests of new packages
On Mon, Sep 12, 2016 at 02:38:32PM +1000, Vincent McIntyre wrote: A brief note on the client side of things. At step 3, after installing your packages but before tweaking nfs-server.service, the critical chain for the client mount is usr-local.mount +1.145s └─remote-fs-pre.target @7.493s └─nfs-client.target @2.362s After (step 4.x) it is somewhat different usr-local.mount +1.141s └─remote-fs-pre.target @10.207s └─nfs-server.service @10.193s +12ms └─rpc-statd.service @10.342s +18ms └─nss-lookup.target @10.340s The 'list-dependencies' output is the same for both Dependencies for usr-local.mount usr-local.mount ● ├─-.mount ● ├─system.slice ● ├─usr.mount ● └─network-online.target Not sure why nfs-client has dopped out of the picture. Nonetheless, the mount works fine. Cheers Vince
Bug#775541: tests of new packages
On Fri, Sep 09, 2016 at 10:22:25AM +0200, Andreas Henriksson wrote: > Hello Vincent McIntyre. > > Thanks for your thurough testing and useful feedback. > > Let me start with a disclaimer: I'm not maintaining nfs (and I'm > not even using it myself so my knowledge is very limited). My only > involvement here is trying to squash some RC bugs and unblocking > work elsewhere by importing native systemd units. That is fine with me and highly appreciated. > On Fri, Sep 09, 2016 at 11:57:34AM +1000, Vincent McIntyre wrote: > > > > Thanks Andreas for those new packages. > > I did some testing of the 1.2.8-9.2 packages on a clean jessie install. > > They are pretty close but I found an issue with NFS exports in one case. > > > > I used the attached check.sh script to show the state of various targets > > as I changed things. The attached results.tar shows the output from it. > > Between each major stage below, the system is rebooted. > > Then I log in and run check.sh before doing anything else. > > Throughout, /etc/network/interfaces contained: > > source /etc/network/interfaces.d/* > > auto lo > > iface lo inet loopback > > allow-hotplug eth0 > > I think this is problematic and unfortunately spoils my interest > in the rest of your testing. > > From what I've been told one of the main differences between "auto" > and "allow-hotplug" is that allow-hotplug will not block your bootup > so services will run wild and start up ASAP. This means they can and > likely will start up before your network connection is up. Specially > if using dhcp which takes time to configure the interface and extra > so if you're using a network device (eg. usb dongle) which takes a > long time to initialize. > > I assume eth0 was involved in your tests, and if so it would be > very useful to know what difference it makes if you use auto > instead. > Thanks for that. I've repeated with a slightly different numbering. The short version is that the client mounts and exports all work with your packages and 'auto eth0' BUT one change is needed to make exports work at boot time: /lib/systemd/system/nfs-mountd.service - After=network.target local-fs.target + After=rpcbind.target network.target local-fs.target There might be a more elegant way to this but this seems to work. I did a quick check of your packages with 'auto eth0' and a static address setup in /etc/network/interfaces. That worked also but to get the exports working at boot the change above was required. Detailed results: step 1 - jessie system with nfs packages 1.2.8-9 one fstab mount, no exports. no changes to /etc/default/nfs-* The fstab mount works ok; it politely waits for dhcp to finish before trying to mount. It works in all the other tests so I won't mention it further. step 2 - as above but export one filesystem. Tried a few different ways to do the exports - wildcard host (step2.1) - point the export at a single host (step2.2) - point the export at a netgroup (step2.3) All of these work with no problem. step 3 - jessie system with nfs packages 1.2.8-9.2 one fstab mount, one exported directory. rpc.mountd fails to start because it wants rpcbind to be there, but rpcbind has not been started yet. showmount -e fails: # showmount -e clnt_create: RPC: Program not registered step3.1 - modify /lib/systemd/system/nfs-mountd.service, - After=network.target local-fs.target + After=rpcbind.target network.target local-fs.target run systemd daemon-reload but don't reboot. The exports are still not there # showmount -e clnt_create: RPC: Program not registered re run exports, it fails # exportfs -rav exporting @all_hosts:/data/INSTALL_1 # showmount -e clnt_create: RPC: Program not registered # step 4 - reboot after step3.1: All of the exports work now. I don't need to insert any 30s waits anywhere, yay. Without the tweak to nfs-mountd.service, the critical chain is: nfs-mountd.service +33ms └─network.target @7.453s └─networking.service @2.349s +5.103s └─local-fs.target @2.345s └─data-INSTALL_1.mount @2.212s +132ms └─systemd-fsck@dev-mapper-libra\x2ddata.service @2.193s +16ms └─dev-mapper-libra\x2ddata.device @2.192s With the tweak in place nfs-mountd.service +19ms └─rpcbind.target @10.169s └─rpcbind.service @10.126s +42ms └─network-online.target @10.123s └─network.target @10.123s └─networking.service @1.289s +8.833s └─local-fs.target @1.285s └─data-INSTALL_1
Bug#837123: [anna] segfault in wheezy installer
On Mon, Sep 12, 2016 at 12:28:55PM +1000, Vincent McIntyre wrote: > > > - make sure all ipv6 related options are disabled > >and no ipv6 DNS entries exist for the target host > >Didn't try it. The failure happens really early, before the >preseed file is downloaded. Incorrect. The preseed is downloaded ok but it doesn't matter, as far as I can see, the fault happens before any network configuration directives in the preseed file can be used. Vince
Bug#837123: [anna] segfault in wheezy installer
On Sat, Sep 10, 2016 at 11:30:32AM +1000, Vincent McIntyre wrote: > > You've given me a few things to try out > - tell DHCP to supply different DNS servers (running bind) Makes no difference. These servers are not configured for v6, while the first ones I used were. There are no v6 entries for the host in any case. > - make sure all ipv6 related options are disabled >and no ipv6 DNS entries exist for the target host Didn't try it. The failure happens really early, before the preseed file is downloaded. > - make sure all ipv6 related options are enabled >and valid ipv6 DNS entries exist for the target host Didn't try > Also I can try installing oldstable with the jessie installer. This worked. Even with mirror/udeb/suite set to 'stable'. For anyone who comes along later, the udeb versions were anna 1.52 base-installer 1.154 libc6-udeb 2.19-18+deb8u4 netcfg 1.131+deb8u1 I think this bug can probably be downgraded until someone else can reproduce it, or at least marked as 'not found' in the later version of libc6-udeb. If I get time I will try with the daily installer and report on that. Vince
Bug#837123: [anna] segfault in wheezy installer
On Fri, Sep 09, 2016 at 03:59:17PM +0200, Aurelien Jarno wrote: > > I don't talk about the software running on your DNS servers, but > rather how they behave when they get queried. It might depends on > many other things, like if your network has IPv6 or not. > > Note that's only one explanation, not sure it's the right one, but > given I am unable to reproduce the issue, it's the only one that > come to my mind. Thank you for explaining. I am struggling with this idea since AFAIK the DNS servers have not been changed in the last six months or more so I can think of no reason for the behaviour to have changed. That history is what makes me think something must have changed in the installer around the time of the last point release (May). But from what you say that isn't the case. You've given me a few things to try out - tell DHCP to supply different DNS servers (running bind) - make sure all ipv6 related options are disabled and no ipv6 DNS entries exist for the target host - make sure all ipv6 related options are enabled and valid ipv6 DNS entries exist for the target host Also I can try installing oldstable with the jessie installer. If all of that makes no difference, what would be the next step? I assume I'd have to build a debug version of the installer and try to get a backtrace? My concern is there's a segfault still lurking in the stretch version. If we can squash it here that fix could be forward-ported. Kind regards Vince
Bug#837123: [anna] segfault in wheezy installer
On Fri, Sep 09, 2016 at 11:46:30AM +0200, Aurelien Jarno wrote: > Hi, > > On 2016-09-09 10:27, Vincent McIntyre wrote: > > > > Package: libc6-udeb > > Version: 2.13-38+deb7u10 > > Severity: grave > > Justification: breaks installation entirely > > > > The wheezy installer fails with anna reporting a segfault: > > > > ... > > anna[5033]: DEBUG: retrieving libc6-udeb 2.13-38+deb7u10 > > anna[5033]: DEBUG: retrieving finish-install 2.41wheezy1 > > anna[5033]: DEBUG: Segmentation fault > > anna[5033]: WARNING **: package retrieval failed > > kernel: [ 66.427372] wget[5382]: segfault a 0 ip 7176c922c0ca sp > > 7ffc8ca83890 error 6 in libresolv-2.13.so[7f76c9222000+13000] > > > > This occurs shortly after libc6-udev is downloaded, > > according to the installer interactive display. > > Unfortunately I am not able to reproduce the issue here. Given it > involves name resolving, I wouldn't be surprised it depends on the DNS > servers being used. Seriously??? I have to use the exactly right flavour of DNS server? I think this would have been using microsoft DNS servers. I preseume you're using BIND? Could this be a locale thing? > > The core of the issue is probably screwed up libc6 versions, > > see bugs 740068, 833432 > > It indeeds looks like that, that said the build logs actually show > that debian-installer 20130613+deb7u3+b2 has been built against > glibc > 2.13-38+deb7u10, so there is no version skew in this case. > > Unfortunately, without being able to reproduce the problem, it > will be very difficult to debug it. Lovely. Thanks for bothering to reply. Vince
Bug#775541: tests of new packages
I found one further issue which is related to #738063. I wanted to limit the exports to supporting version 2 and 3. I first set RPCMOUNTDOPTS="--manage-gids --no-nfs-version 4" as explained in /etc/default/nfs-kernel-server. But I found I also needed add the following to that file: RPCNFSDPRIORITY=0 + # other options for nfsd + # To disable NFSv4 on the server, specify '--no-nfs-version 4' here also + RPCNFSDOPTS="--no-nfs-version 4" I discovered this by reading the source of the new script /usr/lib/systemd/scripts/nfs-utils_env.sh which constructs the RPCNFSDARGS variable used in the /lib/systemd/system/nfs-server.service file. If you upload a new version of this package, could you add an empty definition of RPCNFSDOPTS to /etc/default/nfs-kernel-server, so people can find it? Users of the init script would also benefit from this change. Thanks Vince
Bug#775541: tests of new packages
Thanks Andreas for those new packages. I did some testing of the 1.2.8-9.2 packages on a clean jessie install. They are pretty close but I found an issue with NFS exports in one case. I used the attached check.sh script to show the state of various targets as I changed things. The attached results.tar shows the output from it. Between each major stage below, the system is rebooted. Then I log in and run check.sh before doing anything else. Throughout, /etc/network/interfaces contained: source /etc/network/interfaces.d/* auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet dhcp and /etc/network/interfaces.d/ was empty. step 1 - jessie system with nfs packages 1.2.8-9 one fstab mount, no exports. no changes to /etc/default/nfs-*. The fstab mount works ok; it tries to mount it way too early but we invoke it with the 'bg' option so eventually it works. step 2 - as above but with the _netdev option added to the fstab entry. System still tries to mount too early, before dhclient is done, but it works in the end. step 3 - as above but export one filesystem. The fstab mount works, as above. Tried a few different ways to do the exports - wildcard host (step3.1) This works ok. - point the export at a single host (step3.2) This tries to start mountd to early, before it can resolve the hostname given in the exports file. As a result we end up with an empty export list: # showmount -e Export list for install: # Restarting the service once the system is fully booted works # systemctl restart nfs-kernel-server.service # showmount -e Export list for install: /data/INSTALL_1 mayhem.atnf.CSIRO.AU # - point the export at a netgroup (step3.3) This works, even though the netgroup cannot be resolved (there's no definition for it). # showmount -e Export list for install: /data/INSTALL_1 @all_hosts # NB nfs-kernel-server starts before dhclient Sep 08 17:04:46 install nfs-kernel-server[657]: Exporting directories for NFS kernel daemon Sep 08 17:04:46 install kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Sep 08 17:04:46 install kernel: NFSD: starting 90-second grace period (net 818ba280) ... Sep 08 17:04:46 install rpc.mountd[738]: Version 1.2.8 starting Sep 08 17:04:46 install nfs-kernel-server[657]: Starting NFS kernel daemon: nfsd mountd. Sep 08 17:04:46 install acpid[734]: starting up with netlink and the input layer Sep 08 17:04:46 install acpid[734]: 1 rule loaded Sep 08 17:04:46 install acpid[734]: waiting for events: event logging is off ... Sep 08 17:04:49 install kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Sep 08 17:04:49 install kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sep 08 17:04:50 install dhclient[532]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 ... Sep 08 17:04:56 install ifup[522]: Starting rpcbind (via systemctl): rpcbind.service. Sep 08 17:04:56 install ifup[522]: Starting nfs-common (via systemctl): nfs-common.service. Sep 08 17:04:56 install kernel: Key type dns_resolver registered Sep 08 17:04:56 install kernel: NFS: Registering the id_resolver key type Sep 08 17:04:56 install kernel: Key type id_resolver registered Sep 08 17:04:56 install kernel: Key type id_legacy registered step3.4 - install new nfs packages but don't reboot yet. I didn't analyse this step carefully step 4 - jessie system with nfs packages 1.2.8-9.2 one fstab mount, one exported directory. rpc.mountd fails to start because it wants rpcbind to be there, but rpcbind has not been started yet. showmount -e fails: # showmount -e clnt_create: RPC: Program not registered step4.1 modify /lib/systemd/system/nfs-mountd.service, - After=network.target local-fs.target + After=rpcbind.target network.target local-fs.target run systemd daemon-reload but don't reboot. The exports are still not there # showmount -e clnt_create: RPC: Program not registered re run exports, it fails # exportfs -rav exporting @all_hosts:/data/INSTALL_1 # showmount -e clnt_create: RPC: Program not registered # step 5 - reboot after step4.1: usr-local.mount starts a little (1-2s) later. It starts just after ifup, but before dhclient has gotten an answer so it can't resolve the server hostname, but eventually the mount does work. Exports also work, in some cases: - wildcard case is OK (step5.1) # showmount -e Export list for install:
Bug#837123: ([anna] segfault in wheezy installer)
I just realised this went to the libc maintainers; I was expecting it would go to the debian-installer team. This might be an issue in the way libc6-udeb is being used within debian-installer, rather than libc6-udeb itself. I don't know how to figure out if that is the case; if it is the case, please do reassign. Kind regards Vince
Bug#837123: [anna] segfault in wheezy installer
Package: libc6-udeb Version: 2.13-38+deb7u10 Severity: grave Justification: breaks installation entirely The wheezy installer fails with anna reporting a segfault: ... anna[5033]: DEBUG: retrieving libc6-udeb 2.13-38+deb7u10 anna[5033]: DEBUG: retrieving finish-install 2.41wheezy1 anna[5033]: DEBUG: Segmentation fault anna[5033]: WARNING **: package retrieval failed kernel: [ 66.427372] wget[5382]: segfault a 0 ip 7176c922c0ca sp 7ffc8ca83890 error 6 in libresolv-2.13.so[7f76c9222000+13000] This occurs shortly after libc6-udev is downloaded, according to the installer interactive display. Background -- I was trying to reinstall an older system with wheezy. I was using the PXE install image available on 2016-09-08 UTC, at ftp.au.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot The mirror shows the last update timestamp as 2016-05-31. debian-installer/amd64/boot-screens/f1.txt has the fairly useless build date stamp 20130613+deb7u3+b2. This installation method was working fine with earlier installer versions. The breakage has been there some months I'd say. I only became fully aware of it yesterday. I don't think the mirror is out of date; I got the same result with the netboot installer image downloaded from ftp.us.debian.org. The log above was copied by eye from the console, I was unable to install the openssh-client=udeb to copy the logs, thanks to the segfault. The core of the issue is probably screwed up libc6 versions, see bugs 740068, 833432 Other package versions that may be of interest base-installer: 1.130 cdebconf-udeb: 0.182 di-utils: 1.92+deb7u1 libc6-udeb: 2.13-38+deb7u10 anna: 1.44+deb7u1 It's really unfortunate to have the oldstable installer break like this. I hope it can be fixed, age notwithstanding. Kind regards Vince --
Bug#775541: NFS mounts fail at boot after Debian 8.5 upgrade
Hello Paul I read your feedback on this issue with interest. Could you provide a bit more information about the package versions on your system? dpkg -l rpcbind nfs-common nfs-kernel-server systemd Also I think the output of these commands would be helpful systemd-analyze critical-path remote-fs-pre.target systemd-analyze critical-path nfs-kernel-server.service As to your question about After=rpcbind.service vs rpcbind.target, I think rpcbind.target is correct as you're trying to express that you want mounting remote filesystems to wait until everything to do with getting rpcbind going is complete. But I'm far from sure. Kind regards Vince
Bug#821811: samba: badlock patch breaks trust relationship
I can confirm that after downgrading these packages samba samba-common samba-common-bin libwbclient0 smbclient samba-tools to version 2:3.6.6-6+deb7u7 and then upgrading with apt-get -t santiago-wheezy install samba samba-common \ samba-common-bin libwbclient0 smbclient samba-tools the system continued to work without issue; it remained joined to the domain and users could connect as normal. Note that this system was not running winbind, it was not installed. Vince
Bug#784743: updated patch
Tags: patch The perl patching command given by Edmund results in this change: --- debian/patches/linker-specific-changes.orig 2011-11-19 16:45:51.0 +1100 +++ debian/patches/linker-specific-changes 2015-08-03 14:16:16.518331208 +1000 @@ -65,7 +65,7 @@ grtv00.o : $(DRVDIR)/imdef.h pgxwin.o : $(DRVDIR)/pgxwin.h -pndriv.o : ./png.h ./pngconf.h ./zlib.h ./zconf.h -+pndriv.o : /usr/include/png.h /usr/include/pngconf.h /usr/include/zlib.h /usr/include/zconf.h ++pndriv.o : x2driv.o figdisp_comm.o: $(DRVDIR)/commands.h zconf.h moved from /usr/include/ to /usr/include/arch-os-compiler/ e.g. /usr/include/x86_64-linux-gnu/zconf.h. I think what is needed here is a revised version of debian/patches/linker-specific-changes which I have attached to this message. -- Description: correct linker variables This patch set sets all the linker-specific variables correctly --- Last-Update: 2011-11-18 Index: pgplot5-5.2.2/makemake === --- pgplot5-5.2.2.orig/makemake +++ pgplot5-5.2.2/makemake @@ -658,6 +658,8 @@ CPGPLOT_LIB=$CPGPLOT_LIB # SHARED_LIB=$SHARED_LIB SHARED_LD=$SHARED_LD +SHARED_LD_PGPLOT_OPTS=$SHARED_LD_PGPLOT_OPTS +SHARED_LD_CPGPLOT_OPTS=$SHARED_LD_CPGPLOT_OPTS # # The libraries that the shared PGPLOT library depends upon. # This is for systems that allow one to specify what libraries @@ -667,6 +669,7 @@ SHARED_LD=$SHARED_LD # libraries when they link their executables. # SHARED_LIB_LIBS=$SHARED_LIB_LIBS +SHARED_LIB_CPGPLOT_LIBS=$SHARED_LIB_CPGPLOT_LIBS # # Ranlib command if required # @@ -806,7 +809,8 @@ grexec.o: grexec.f # libraries. #--- -lib : libpgplot.a $(SHARED_LIB) +#lib : libpgplot.a $(SHARED_LIB) +lib : libpgplot.a libpgplot.a : $(PG_ROUTINES) $(PG_NON_STANDARD) $(GR_ROUTINES) \ $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES) @@ -816,6 +820,16 @@ libpgplot.a : $(PG_ROUTINES) $(PG_NON_ST $(DRIVERS) $(SYSTEM_ROUTINES) | sort | uniq` $(RANLIB) libpgplot.a +#shared: $(PG_ROUTINES) $(PG_NON_STANDARD) $(GR_ROUTINES) \ +# $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES) +# $(SHARED_LD) + +shared: $(PG_ROUTINES) $(PG_NON_STANDARD) \ + $(GR_ROUTINES) $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES) + $(SHARED_LD) $(SHARED_LD_PGPLOT_OPTS) `ls $(PG_ROUTINES) \ + $(PG_NON_STANDARD) $(GR_ROUTINES) $(DISPATCH_ROUTINE) \ + $(DRIVERS) $(SYSTEM_ROUTINES) | sort | uniq` $(SHARED_LIB_LIBS) + EOD # Emit the shared library dependency if requested. @@ -824,7 +838,7 @@ if test -n $SHARED_LIB -a -n $SHARED_ cat makefile \EOD $(SHARED_LIB): $(PG_ROUTINES) $(PG_NON_STANDARD) \ $(GR_ROUTINES) $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES) - $(SHARED_LD) `ls $(PG_ROUTINES) \ + $(SHARED_LD) $(SHARED_LD_PGPLOT_OPTS) `ls $(PG_ROUTINES) \ $(PG_NON_STANDARD) $(GR_ROUTINES) $(DISPATCH_ROUTINE) \ $(DRIVERS) $(SYSTEM_ROUTINES) | sort | uniq` $(SHARED_LIB_LIBS) EOD @@ -1019,13 +1033,15 @@ EOD cat makefile \EOD +DEB_HOST_MULTIARCH=$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) + # Miscellaneous include files required by drivers griv00.o : $(DRVDIR)/gadef.h $(DRVDIR)/gmdef.h $(DRVDIR)/gphdef.h grivas.o : $(DRVDIR)/gadef.h grtv00.o : $(DRVDIR)/imdef.h pgxwin.o : $(DRVDIR)/pgxwin.h -pndriv.o : ./png.h ./pngconf.h ./zlib.h ./zconf.h +pndriv.o : /usr/include/png.h /usr/include/pngconf.h /usr/include/zlib.h /usr/include/$(DEB_HOST_MULTIARCH)/zconf.h x2driv.o figdisp_comm.o: $(DRVDIR)/commands.h @@ -1039,6 +1055,8 @@ cpg: libcpgplot.a cpgplot.h cpgdemo @echo 'will be needed.' @echo ' ' +cpg-shared: libcpgplot.so + pgbind: $(SRC)/cpg/pgbind.c $(CCOMPL) $(CFLAGC) $(SRC)/cpg/pgbind.c -o pgbind @@ -1050,6 +1068,13 @@ libcpgplot.a cpgplot.h: $(PG_SOURCE) pgb $(RANLIB) libcpgplot.a rm -f cpg*.o +libcpgplot.so: $(PG_SOURCE) pgbind + ./pgbind $(PGBIND_FLAGS) -w $(PG_SOURCE) + $(CCOMPL) -c $(CFLAGC) cpg*.c + rm -f cpg*.c + $(SHARED_LD) $(SHARED_LD_CPGPLOT_OPTS) cpg*.o $(SHARED_LIB_CPGPLOT_LIBS) + rm -f cpg*.o + cpgdemo: cpgplot.h $(SRC)/cpg/cpgdemo.c libcpgplot.a $(CCOMPL) $(CFLAGD) -c -I. $(SRC)/cpg/cpgdemo.c $(FCOMPL) -o cpgdemo cpgdemo.o $(CPGPLOT_LIB) $(LIBS)
Bug#706112: [PATCH v2] grub-installer: Support menu selection of grub boot disk
On Sun, Jun 09, 2013 at 01:47:36AM +0200, Cyril Brulebois wrote:
Vincent McIntyre vincent.mcint...@csiro.au (30/04/2013):
gah. The patch was not ok. My apologies for such a gross error.
I caught this by testing with 1.86 as downloaded from the archive.
Thanks, Vincent.
Applied locally. I'll try and play with it, and see when that can be
pushed to unstable, and maybe into {the next,an upcoming} wheezy point
release.
Okay, thanks for letting me know.
Since I posted that stuff I looked at thie code again and prepared
a patch series that includes the fix you've applied locally and
goes on to would bring the disk naming into line with the way grub-pc
does it. I'll send them off-list to avoid confusing the thread.
If you like them feel free to repost to the list.
It seems to me that there should be some kind of bug for this issue
to track progress on it, not sure how best to do that.
Cheers
Vince
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706112: [PATCH 0/4] grub-installer: Support menu selection of grub boot disk
On Sun, Jun 09, 2013 at 01:47:36AM +0200, Cyril Brulebois wrote:
Vincent McIntyre vincent.mcint...@csiro.au (30/04/2013):
gah. The patch was not ok. My apologies for such a gross error.
I caught this by testing with 1.86 as downloaded from the archive.
Thanks, Vincent.
Applied locally. I'll try and play with it, and see when that can be
pushed to unstable, and maybe into {the next,an upcoming} wheezy point
release.
Attached is a patch series I did a few weeks ago.
I haven't had time to test carefully but I should get them out there.
0001 of the series fixes the issue I raised earlier in the thread,
in a slightly different way. kibi suggests this should be considered
for inclusion in time for the wheezy point release.
0002 0003 are cleanups.
0004 introduces naming the disks in the same way as grub-pc.
All of the above will need testing, particular 0004.
From d8a3a9149f1a123caece540910608a772893f307 Mon Sep 17 00:00:00 2001
From: Vince McIntyre vincent.mcint...@csiro.au
Date: Fri, 3 May 2013 23:33:28 +1000
Subject: [PATCH 1/4] Add missing break in $bootdev question loop.
In version 1.86 of grub-installer, the while loop in which
grub-installer/bootdev is asked can result in the following
sequence of events:
$state is set to 1
grub-installer/only_debian is asked and gets a 'false' answer
$state is set to 2
$bootdev is set by select_bootdev (asks grub-installer/choose_bootdev).
The device pointed to by $bootdev exists,
so grub-installer/bootdev is never queued to be asked,
thus db_go returns true
and the code sets $bootdev to the value of grub-installer/bootdev,
which has not been set yet.
This results in grub-install being run with a blank value for $bootdev.
To avoid this, break out of the loop if select_bootdev returns
a suitable value for $bootdev. Otherwise, ask grub-installer/bootdev.
Signed-off-by: Vince McIntyre vincent.mcint...@csiro.au
---
grub-installer | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/grub-installer b/grub-installer
index 71e10c8..e0ce818 100755
--- a/grub-installer
+++ b/grub-installer
@@ -703,9 +703,11 @@ while : ; do
unset previous_state
fi
- if [ ! -e $bootdev ]; then
- db_input critical grub-installer/bootdev || true
+ if [ -e $bootdev ]; then
+ break
fi
+
+ db_input critical grub-installer/bootdev || true
if ! db_go; then
if [ $q ]; then
state=1
--
1.8.2.1
From 190e6576a205b9d166ee47e834b664b1037a10e7 Mon Sep 17 00:00:00 2001
From: Vince McIntyre vincent.mcint...@csiro.au
Date: Fri, 3 May 2013 23:43:33 +1000
Subject: [PATCH 2/4] Remove unnecessary else clause.
Signed-off-by: Vince McIntyre vincent.mcint...@csiro.au
---
grub-installer | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/grub-installer b/grub-installer
index e0ce818..bc1a482 100755
--- a/grub-installer
+++ b/grub-installer
@@ -684,9 +684,8 @@ while : ; do
fi
if [ -e $bootdev ] ; then
break
- else
- state=2
fi
+ state=2
else
# Exit to menu if /boot is on SATA RAID/multipath; we
# don't support device selection in that case
--
1.8.2.1
From 76b8a7059e410a83ab54e9378a2167dcb8d94bb3 Mon Sep 17 00:00:00 2001
From: Vince McIntyre vincent.mcint...@csiro.au
Date: Fri, 3 May 2013 23:44:46 +1000
Subject: [PATCH 3/4] Same line in both branches of if statement.
Signed-off-by: Vince McIntyre vincent.mcint...@csiro.au
---
grub-installer | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/grub-installer b/grub-installer
index bc1a482..fc5078a 100755
--- a/grub-installer
+++ b/grub-installer
@@ -685,7 +685,6 @@ while : ; do
if [ -e $bootdev ] ; then
break
fi
- state=2
else
# Exit to menu if /boot is on SATA RAID/multipath; we
# don't support device selection in that case
@@ -693,8 +692,8 @@ while : ; do
db_progress STOP
exit 10
fi
- state=2
fi
+ state=2
elif [ $state = 2 ]; then
if [ $previous_state != 1 ]; then
--
1.8.2.1
From 18d8175cfcb4807772e957cd904132e839b51720 Mon Sep 17 00:00:00 2001
From: Vince McIntyre vincent.mcint...@csiro.au
Date: Sat, 4 May 2013 00:32:50 +1000
Subject: [PATCH 4/4] Merge describe_disks() from grub-pc.
grub-pc's postinst displays disk descriptions in a clear concise way.
Use that for the disk descriptions in the choose_bootdev question.
This introduces another debconf variable, disk_description.
Signed-off-by: Vince McIntyre vincent.mcint...@csiro.au
---
debian/grub-installer.templates | 6 +++
grub-installer | 86 -
2 files changed, 90 insertions(+), 2 deletions(-)
mode change 100755 = 100644 grub-installer
diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates
index e439ad0..b52fc8e 100644
--- a/debian/grub-installer.templates
+++ b/debian/grub-installer.templates
@@ -112,6 +112,12 @@ _Description: GRUB password:
.
If you do not wish to set a GRUB
Bug#706112: [PATCH v2] grub-installer: Support menu selection of grub boot disk
On Mon, Apr 29, 2013 at 07:16:42PM +0200, Christian PERRIER wrote: Quoting Cyril Brulebois (k...@debian.org): Cyril Brulebois k...@debian.org (29/04/2013): While I haven't reviewed the patch yet, having the l10n bits in sync was a point I had in mind this very morning, so I'm glad you did that. And indeed, some feedback ASAP would be nice. I'll try to look into this patch in a few hours at most. Uploaded in time for the 1352 dinstall. Let's see if tests are successful. Of course, you're aware that translations are currently not in the git tree, as I committed the modified templates this morning, and the sync will happen in the upcoming night? So, in short, if the patch is OK, we need another upload to get the new template translated. gah. The patch was not ok. My apologies for such a gross error. I caught this by testing with 1.86 as downloaded from the archive. [PATCH] Actually set bootdev. After taking all the trouble to get the right value into the $bootdev shell variable, ensure that we db_set grub-installer/bootdev with that value. Signed-off-by: Vincent McIntyre vincent.mcint...@csiro.au --- grub-installer |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/grub-installer b/grub-installer index 71e10c8..f3d62fe 100755 --- a/grub-installer +++ b/grub-installer @@ -683,6 +683,7 @@ while : ; do previous_state=1 fi if [ -e $bootdev ] ; then + db_set grub-installer/bootdev $bootdev break else state=2 @@ -703,9 +704,12 @@ while : ; do unset previous_state fi - if [ ! -e $bootdev ]; then - db_input critical grub-installer/bootdev || true + if [ -e $bootdev ]; then + db_set grub-installer/bootdev $bootdev + break fi + + db_input critical grub-installer/bootdev || true if ! db_go; then if [ $q ]; then state=1 -- vincent.mcint...@csiro.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706112: [PATCH v2] grub-installer: Support menu selection of grub boot disk
Hi,
Thanks for the comments I've received on this patch.
I did some reading to see how other packages handle the issues raised.
I found grub-pc and iso-scan particularly helpful.
Hopefully this attempt is better. Less than a week from release,
I expect it is too late to include this but perhaps it could be
considered for r1.
Kind regards
Vince
---
Support user selection of grub boot disk from a list of
disks via a new question, grub-installer/choose_bootdev.
Check for a mismatch between a preseeded value of
grub-installer/bootdev and the guess at the default boot
disk made by grub-installer, and prompt the user to choose
the correct disk.
This should help the user avoid grub-installer writing to the MBR
of the wrong device (e.g. #696877,#706112) and fix the issue with
preseeded values of bootdev being ignored (e.g. #666974).
v2:
- try harder to avoid introducing new translatable strings
- recycle question first paragraph of grub-install/bootdev
- use iso-scan/ask_device text for manual entry text
- drop device_list() function; try to reuse existing functions
and follow the methods in grub-pc iso-scan
- don't abuse the 'seen' flag
Signed-off-by: Vincent McIntyre vincent.mcint...@csiro.au
---
debian/grub-installer.templates | 13 +
grub-installer | 99 +--
2 files changed, 109 insertions(+), 3 deletions(-)
diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates
index 888a656..e439ad0 100644
--- a/debian/grub-installer.templates
+++ b/debian/grub-installer.templates
@@ -86,6 +86,19 @@ _Description: Device for boot loader installation:
drive;
- /dev/fd0 will install GRUB to a floppy.
+Template: grub-installer/choose_bootdev
+Type: select
+Choices-C: manual, ${DEVICES_LIST}
+#flag:translate!:2
+__Choices: Enter device manually, ${DESCRIPTIONS}
+# :sl2:
+_Description: Device for boot loader installation:
+ You need to make the newly installed system bootable, by installing
+ the GRUB boot loader on a bootable device. The usual way to do this is to
+ install GRUB on the master boot record of your first hard drive. If you
+ prefer, you can install GRUB elsewhere on the drive, or to another drive,
+ or even to a floppy.
+
Template: grub-installer/password
Type: password
# :sl2:
diff --git a/grub-installer b/grub-installer
index f01eda1..71e10c8 100755
--- a/grub-installer
+++ b/grub-installer
@@ -1,5 +1,6 @@
#! /bin/sh
+# export DEBCONF_DEBUG=5
set -e
. /usr/share/debconf/confmodule
#set -x
@@ -590,7 +591,81 @@ esac
db_progress STEP 1
db_progress INFO grub-installer/progress/step_bootdev
+select_bootdev() {
+ [ X = X${DEBCONF_DEBUG} ] || log select_bootdev: arg='$1'
+
+ local dev_list dev_descr grubdev devices disk_id dev descr
+ local default_choice chosen result
+
+ result=
+ default_choice=$1
+
+ # /dev/disk/by-id has multiple links for the same physical disk.
+ # Let's trust grub-mkdevicemap to select the most suitable ones
+ # and correctly handle systems with no /dev/disk/by-id.
+ # Use disk id string as a shortcut way to describe it.
+ # FIXME switch to grub-pc's far more elegant disk_descriptions()
+ dev_list=
+ dev_descr=
+ devices=$($chroot $ROOT grub-mkdevicemap --no-floppy -m - | cut -f2)
+ for grubdev in $devices; do
+ disk_id=$(device_to_id $grubdev)
+ dev=$(readlink -f $disk_id)
+ dev_list=${dev_list:+$dev_list, }$dev
+ descr=$(echo $disk_id |sed -e 's+^.*/++' |sed -e 's+,+\\,+g')
+ if [ $dev = $disk_id ]; then
+ dev_descr=${dev_descr:+$dev_descr, }$dev
+ else
+ #/dev/sdX (id)
+ dev_descr=${dev_descr:+$dev_descr, }$dev ($descr)
+ fi
+ done
+
+ [ X = X${DEBCONF_DEBUG} ] || log Bootdev Choices: '$dev_list'
+ [ X = X${DEBCONF_DEBUG} ] || log Bootdev Descriptions:
'$dev_descr'
+
+ db_subst grub-installer/choose_bootdev DEVICES_LIST $dev_list
+ db_subst grub-installer/choose_bootdev DESCRIPTIONS $dev_descr
+ # set initial selection
+ if [ -n $default_choice ] ; then
+ chosen=$(readlink -f $default_choice)
+ if [ -n $chosen ] ;then
+ db_set grub-installer/choose_bootdev $chosen
+ fi
+ fi
+
+ db_input high grub-installer/choose_bootdev || true
+ if ! db_go; then
+ log Returning to menu
+ db_progress STOP
+ exit 10
+ fi
+
+ db_get grub-installer/choose_bootdev || true
+ # Choices-C (not shown to user) can be set to 'manual'
+ if [ $RET = manual ] ; then
+ result=
+ else
+ result=$(echo $RET | cut -d' ' -f1)
+ fi
+
+ [ X = X${DEBCONF_DEBUG
Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda
Hi Joey thank you for your helpful comments. I'm working on fixing the issues. I do have one question because I'm completely new to the translation side of things... On Thu, Apr 25, 2013 at 08:28:27AM -0400, Joey Hess wrote: There are also some hardcoded user-visible strings embedded in the code, which need to be a) moved to the template and b) somehow translated 3 months ago. I don't think that (An entry dialog will appear) adds anything to the $manual_entry string (Enter device manually). There is an enter information manually string in choose-mirror that could be copied, with full translations. I found the string, in po/sublevel1, here's the templates.po #. Type: select #. Choices #: ../choose-mirror-bin.templates.http-in:2001 #: ../choose-mirror-bin.templates.ftp.sel-in:2001 msgid enter information manually msgstr Is it the case that I need to a) give a unique number to the new question in grub-installer/po/templates.pot b) modify po/sublevel1/template.po to point to the new question like this: #. Type: select #. Choices #: ../choose-mirror-bin.templates.http-in:2001 #: ../choose-mirror-bin.templates.ftp.sel-in:2001 +#: ../grub-installer.templates:29001 msgid enter information manually msgstr Cheers Vince -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda
Sadly, this issue will probably be in wheezy as nobody digged enough to tackle this down and we get rid of it before the last version of D-I is released. Please see my working (for me), tested, waiting-for-review patch [1] sent to the -boot list yesterday. Cheers Vince [1] https://lists.debian.org/debian-boot/2013/04/msg00396.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda
On Thu, Apr 25, 2013 at 09:33:01AM +0200, Gaudenz Steinlin wrote:
Hi Vince
Please see my working (for me), tested, waiting-for-review patch [1]
sent to the -boot list yesterday.
Do you know how the problem can be triggerd. As far as I remember only
some installation from USB are affected and I don't know if the
difference between those affected and those unaffected has ever been
identified. If I know that I'm testing the right test case, I'm willing
to try your patch.
As I try to explain in the patch it seems to me that the issue is this:
- the program tries to make an intelligent guess about which device the
installer is mounted on and avoid that device. But in the case of USB
sticks it is quite difficult to tell. There is discussion of this in
#696877.
- in the 'while' loop starting at line 593 it typically asks the question
grub-installer/only-debian or grub-installer/with-other-os.
If it gets a 'true' ('yes') answer, it sets bootdev=$default_bootdev
and exits the loop with no further questions to the user.
If it gets a 'false' ('no') answer it should ask grub-installer/bootdev
ie give the user a chance to input the device name they want.
I'm assuming that this affects some installs and not others because there
are different enumeration orders on different systems.
It's entirely possible this patch is not the full resolution of the various
issues people have reported but I'm posting it to get feedback on the
approach and get some help with correctly integrating it into d-i.
It also needs tests on arches other than amd64/i386 and probably with
systems that require EFI.
Hope you can find time to apply the patch, build grub-installer and test.
I didn't rebuild the entire installer image when testing. I built the udeb
and after tasksel was done I scp'd it onto the test machine and installed
it with udpkg. I ran 'sh /usr/bin/grub-installer /target' on tty2, for some
reason I could not get it to work with the main menu on tty1.
Cheers
Vince
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517644: [RFC] Packages that looks ready for uploading
talking to myself again... Luk Claes wrote... Feel free to test with the version in proposed-updates to really make sure it's fixed. I'm not completely sure how to do this. From what I can gather from [1] I need to build my own installer image, which I'll have a go at. I initially thought would be able to just patch in the updated choose-mirror, but this appears to require building a CD [2]. Am I on the right track here? I was able to build a netboot image as per [1]. For anyone who might later care, the steps were: find/build a machine running lenny. svn co svn://svn.debian.org/svn/d-i/branches/d-i/lenny \ debian-installer-lenny cd debian-installer-lenny/installer apt-get build-dep debian-installer # installs a pile of packages dpkg-checkbuilddeps# should return nothing cd build grep DEBIAN_RELEASE config/common # set to 'lenny' grep USE_UDEBS_FROM config/common # ditto # this step is critical cp sources.list.udeb sources.list.udeb.local echo deb http://apt-proxy:/debian lenny-proposed-updates main/debian-installer \ sources.list.udeb.local echo deb http://apt-proxy:/debian lenny-proposed-updates main \ /etc/apt/sources.list echo deb-src http://apt-proxy:/debian lenny-proposed-updates main \ /etc/apt/sources.list apt-get update make reallyclean make build_netboot This produced a tree in dest/ that could copy into the TFTP server tree. grep choose-mirror dest/MANIFEST.udebs showed version 2.28lenny3. yay. Without the sources.list.udeb.local file I kept getting version 2.28lenny1. So it appears the fixed version Otavio uploaded did not make it into 5.0.1? Anyway I was able to install 'etch' with this build of the installer. Thanks for your work, folks. Looking forward to the point release. Cheers Vince [1] wiki.debian.org/DebianInstaller/Build -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517644: reopening
package: choose-mirror tags 517644 + reopen thanks Hi, I just tried to use the lenny installer to install an etch i386 system. The same issue as before occurs, see the /var/log/installer/syslog extract below. I redid the install with suite=oldstable in the PXE boot line and got the same result. Unlike Jeremy's test back in March, the installer selects 'lenny-support' in both tests. I am using the i386 netinst in the official mirrors, downloaded yesterday. boot-screens/f1.txt says the build date was '20090123lenny1'. However /var/log/installer/lsb-release is a little inconsistent: DISTRIB_RELEASE=5.0 (lenny) - installer build 20090123 Should it not be 20090123lenny1? Did choose-mirror-2.28lenny2 not make it in to lenny 5.0r1? How would I check that the installer I am using has the correct version of choose-mirror? Question: now that 'etch-support' is no longer in testing, is it now not possibly to try using the squeeze installer to install oldstable? syslog extracts: May 20 07:40:10 kernel: [0.00] Kernel command line: auto=true priority=critical vga=normal suite=etch initrd=debian/lenny/i386/debian-installer/i386/initrd.gz url=http://webserver/./preseed/debian/etch/i386/wkstn-lenny.cfg ... May 20 07:40:20 main-menu[1245]: INFO: Menu item 'network-preseed' selected May 20 07:40:20 preseed: successfully loaded preseed file from http://webserver/./preseed/debian/etch/i386/wkstn-lenny.cfg ... May 20 07:40:20 preseed: successfully loaded preseed file from http://webserver/./preseed/debian/etch/i386/mirror.cfg ... May 20 07:40:20 main-menu[1245]: INFO: Menu item 'choose-mirror' selected May 20 07:40:20 anna-install: Queueing udeb apt-mirror-setup for later installation May 20 07:40:20 choose-mirror[6497]: DEBUG: command: wget -q http://apt-proxy:/debian//dists/oldstable/Release -O - | grep ^Suite: | cut -d' ' -f 2 May 20 07:40:21 choose-mirror[6497]: DEBUG: command: wget -q http://apt-proxy:/debian//dists/stable/Release -O - | grep ^Codename: | cut -d' ' -f 2 May 20 07:40:22 choose-mirror[6497]: INFO: codename set to: lenny May 20 07:40:22 choose-mirror[6497]: DEBUG: command: wget -q http://apt-proxy:/debian//dists/stable/main/binary-i386/Release -O - | grep Architecture ... As before I manually checked the wget commands and got the right answer, ie oldstable/Release has Codename: etch. But as before the installer resets choose-mirror/suite to 'stable'. The mirror preseed contains these settings: d-i mirror/protocol string http d-i mirror/country string enter information manually d-i mirror/http/countries select enter information manually d-i mirror/http/hostnamestring apt-proxy: d-i mirror/http/directory string /debian/ d-i mirror/http/proxy string d-i mirror/suitestring oldstable d-i mirror/codename string etch d-i apt-setup/services-selectmultiselect security d-i apt-setup/security_host string apt-proxy:/security d-i apt-setup/contribboolean true d-i apt-setup/non-free boolean true -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517644: Info received (Bug#517644: [amd64][lenny] since lenny release, unable to install 'etch' via 'lenny' installer)
I've confirmed this behaviour also occurs when using ftp.au.debian.org as the mirror, instead of our local apt-proxy. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475958: document procedure to recover from /dev/hda became /dev/sda boot failure
Please let me know if something is wrong or badly written. It's a great idea to document this problem and ways to deal with it. It's an extremely unsettling experience to have it occur unexpectedly. Could I suggest taking your notes one step further, and explaining how to fix it permanently, or avoid it completely (by doing these steps before upgrading). I hope there aren't any errors here, I did proof-read it. I'm not sure if this applies in the same way to platforms other than x86. One can avoid this problem entirely, by using an identifier for the root filesystem that does not change from one boot to the next. There are two possible methods for doing this - labelling the filesystem, or using the filesystem's universal unique identifier (UUID). These methods are supported in Debian since the 'etch' release. The two approaches have advantages and disadvantages. The labelling approach is more readable, but there may be problems if another filesystem on your machine has the same label. The uuid approach is uglier, but having two clashing uuids is highly unlikely. For the examples below we assume the root filesystem is on /dev/hda6. We also assume your system has a working udev installation and ext2 or ext3 filesystems. To implement the labelling approach: 1. Label the filesystem (the name must be 16 characters) # e2label /dev/hda6 rootfilesys 2. Edit /boot/grub/menu.lst Change the line # kopt=root=/dev/hda6 ro to # kopt=root=LABEL=rootfilesys ro NB: Leave the '#' at the start of the line, it needs to be there. 3. Run update-grub, to update the 'kernel' lines in menu.lst # update-grub 4. Edit /etc/fstab Change the line that mounts the '/' partition, eg. /dev/hda6 / ext3 defaults,errors=remount-ro 0 1 to LABEL=rootfilesys / ext3 defaults,errors=remount-ro 0 1 The change that matters here is the first column, you don't need to modify the other columns of this line. To implement the uuid approach: 1. Find out the universal unique identifier of your filesystem: # ls -l /dev/disk/by-uuid | grep hda6 lrwxrwxrwx 1 root root 24 2008-09-25 08:16 d0dfcc8a-417a-41e3-ad2e-9736317f2d8a - ../../hda6 The uuid is the name of the symbolic link pointing to /dev/hda6. NB: your filesystem uuid will be a different string. 2. Edit /boot/grub/menu.lst Change the line # kopt=root=/dev/hda6 ro to # kopt=root=UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8 ro NB: Leave the '#' at the start of the line, it needs to be there. 3. Run update-grub, to update the 'kernel' lines in menu.lst # update-grub 4. Edit /etc/fstab Change the line that mounts the '/' partition, eg. /dev/hda6 / ext3 defaults,errors=remount-ro 0 1 to UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8/ ext3 defaults,errors=remount-ro 0 1 The change that matters here is the first column, you don't need to modify the other columns of this line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332782: Your contribution to the Debian release notes (re-post)
Hello, I allow that my contribution to the Debian GNU/Linux release notes can be distributed under any DFSG-free license. Good luck with the next release notes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403696: more info
I can confirm this bug. This might be related to some compatibility with libgtk2.0-0 ? % script log.gtk % strace gtkdialog % exit % grep ^open /tmp/log.gtk | grep -v ENOENT | \ sed -e 's/^.*\(.*\),.*/\1/' |xargs grep -li gtkdialog /usr/lib/libgtk-x11-2.0.so.0 Cheers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339290: additional info
Package: update-flashplugin
Hi
a little more info, hope this helps.
I have a sarge system in which I tried hacking
/etc/update-flashplugin.conf.rb
as noted above. This was the result.
# cat /etc/update-flashplugin.conf.rb
# -*- ruby -*-
#
module UpdateFlashPluginConf
SITES = {
#sluglug.ucsc.edu = /macromedia/tarball/debian/,
ruslug.rutgers.edu = /macromedia/tarball/debian/,
macromedia.mplug.org = /tarball/debian/,
macromedia.rediris.es = /tarball/debian/,
fpdownload.macromedia.com = /get/flashplayer/current/,
}
end
# update-flashplugin -f
Checking new upstream release...
I: checking http://macromedia.rediris.es/tarball/debian/...
No new version is detected. ( = not installed)
Updating flashplugin...
getting install_flash_player_7_linux.tar.gz [322/0 (inf%)]
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: install_flash_player_7_linux/libflashplayer.so: Not found in archive
tar: Error exit delayed from previous errors
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: install_flash_player_7_linux/flashplayer.xpt: Not found in archive
tar: Error exit delayed from previous errors
/usr/sbin/update-flashplugin:208:in `chdir': No such file or directory -
/tmp/flashupdater5639.0/install_flash_player_7_linux (Errno::ENOENT)
from /usr/sbin/update-flashplugin:208:in `install'
from /usr/sbin/update-flashplugin:220:in `update'
from /usr/sbin/update-flashplugin:428
# file /tmp/flashupdater5639.0/install_flash_player_7_linux.tar.gz
/tmp/flashupdater5639.0/install_flash_player_7_linux.tar.gz: HTML document
text
# cat /tmp/flashupdater5639.0/install_flash_player_7_linux.tar.gz
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
HTMLHEAD
TITLE404 Not Found/TITLE
/HEADBODY
H1Not Found/H1
The requested URL /tarball/debian/install_flash_player_7_linux.tar.gz was
not fo
und on this server.P
HR
ADDRESSApache/1.3.33 Server at macromedia.rediris.es Port 80/ADDRESS
/BODY/HTML
I was able to successfully install the player if I commented out all
other entries, ie.
# -*- ruby -*-
#
module UpdateFlashPluginConf
SITES = {
##sluglug.ucsc.edu = /macromedia/tarball/debian/,
#ruslug.rutgers.edu = /macromedia/tarball/debian/,
#macromedia.mplug.org = /tarball/debian/,
#macromedia.rediris.es = /tarball/debian/,
fpdownload.macromedia.com = /get/flashplayer/current/,
}
end
The files installed are not known to the package management system.
# dpkg -S /usr/lib/flashplugin-nonfree/flashplayer.xpt
dpkg: /usr/lib/flashplugin-nonfree/flashplayer.xpt not found.
Were they ever? It seems like the /usr/lib/flashplugin-nonfree directory
should be, but this was not created when I apt-get installed the package.
I did not specify a tarball location or proxy during installation.
Please let me know if you want this filed separately.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322239: mozilla-firefox: [patch] incorrectly set LD_LIBRARY_PATH in /usr/bin/firefox wrapper
And what about people that actually intend to use libraries from other locations instead of those in /lib, without breaking firefox ? Sorry, but I'm not following you. How would that come about? The library in question is libgcc_s.so.1. When would someone running a 'stable' system need to change the location of that library? p.d.o tells me that lib exists in libgcc1 and lib64gcc1 in /lib /lib64, respectively. Are you saying that the firefox wrapper should not contain /lib in LD_LIBRARY_PATH so that it works on 32-bit 64-bit arches? Ah, by the way, /usr/lib has been removed from LD_LIBRARY_PATH in 1.0.7-1... I see no reason to put it back, nor add /lib. See bug #321789. So why did the maintainer of mozilla accept this change? Were they wrong? Given /usr/lib was there before, it seemed ok to just enforce the ld_path for _all_ the libraries the browser was trying to load. I compared the differences between the two ldd runs in Julien's report and it seems that part of his problem was coming from some libs being picked up from /usr/lib/ instead of /usr/lib/mozilla-firefox/; for example /usr/lib/libmozjs.so (which comes from 'mozilla-browser'). The other part was the problem with libXinerama, where it does seem possible /usr/lib was put in LD_LIBRARY_PATH instead of /usr/X11R6/lib. If this was indeed the source of the /usr/lib entry in the first place then maybe it is better to exclude :/usr/lib:/lib from the ld_path. I thought the point of overriding an existing LD_LIBRARY_PATH in a wrapper script was to ensure the binary got exactly what it needed to run. Just as you showed me in your example code, and just as you have to do to make sure to get /usr/lib/mozilla-firefox/libmozjs.so, not the one installed by mozilla-browser. Is the difference here that you are only prefixing enough to LD_LIBRARY_PATH to force use of the libs you're providing? Julien's problem seems to have been that somewhere in /usr/lib is a library that provides some symbols that are also provided from /usr/X11R6/lib. It's unclear what that could be. I did a bit of poking around but could not see anything obvious. The only things from his ldd output which are in /usr/lib and refer to XineramaIsActive on my (sarge) system are /usr/lib/mozilla-firefox/firefox-bin /usr/lib/libgdk-x11-2.0.so.0 I also tried the same test as he did $ unset LD_LIBRARY_PATH $ LD_LIBRARY_PATH=/usr/lib/mozilla-firefox:/usr/X11R6/lib ldd -d -r \ /usr/lib/mozilla-firefox/firefox-bin $ LD_LIBRARY_PATH=/usr/lib/mozilla-firefox:/usr/lib ldd -d -r \ /usr/lib/mozilla-firefox/firefox-bin and saw no differences in the library resolutions. For the record, my /etc/ld.so.conf is this /usr/lib/libc5-compat /lib/libc5-compat /usr/i486-linuxlibc1/lib /usr/X11R6/lib /usr/lib/sse2/atlas /usr/lib/atlas/sse2 /usr/lib/sse2 /usr/lib/atlas The only reason I can offer for adding :/usr/lib:/lib to LD_LIBRARY_PATH is to override what I think is a common case, where people are building software that Debian doesn't provide (e.g. their own software) with a newer compiler and need LD_LIBRARY_PATH to pick up the libgcc for that compiler. Changing the firefox wrapper to make it more self-contained and robust doesn't seem to be a problem to me. But if by that reasoning the full solution is adding :/usr/X11R6/lib:/usr/lib:/lib or even :/usr/X11R6/lib:/usr/lib64:/lib64:/usr/lib:/lib to the EXTENT_LD_LIB_PATH then this is starting to get silly I guess. So I'm stuck with patching this silly thing? Teerificthanksabunch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322239: mozilla-firefox: [patch] incorrectly set LD_LIBRARY_PATH in /usr/bin/firefox wrapper
Package: mozilla-firefox
Version: 1.0.4-2sarge5
Followup-For: Bug #322239
Hi
I think I am seeing this too. It was reported in #316824 (for 'mozilla')
but I did not cross-report to 'mozilla-firefox'.
The patch below should fix the issue, see #316824 for why I think
it fixes it.
PLEASE can you apply this to the sarge version as well, it is most
annoying to have to continually repatch something like this as other
updates are rolled out.
Unfortunately the 'mozilla' maintainer did not notice or ignored my
request on that count.
Should I file another bug for 'mozilla', against the sarge version?
--- /usr/bin/firefox.orig 2005-05-17 12:07:46.0 +1000
+++ /usr/bin/firefox2005-07-04 14:36:33.726916000 +1000
@@ -93,7 +93,7 @@
##
## Set LD_LIBRARY_PATH
##
-EXTENT_LD_LIB_PATH=/usr/lib/mozilla-firefox:/usr/lib/mozilla-firefox/plugins:/usr/lib/mozilla/plugins:/usr/lib
+EXTENT_LD_LIB_PATH=/usr/lib/mozilla-firefox:/usr/lib/mozilla-firefox/plugins:/usr/lib/mozilla/plugins:/usr/lib:/lib
if [ ${LD_LIBRARY_PATH} ]; then
LD_LIBRARY_PATH=${EXTENT_LD_LIB_PATH}:${LD_LIBRARY_PATH}
else
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages mozilla-firefox depends on:
ii debianutils2.8.4 Miscellaneous utilities specific t
ii fontconfig 2.3.1-2 generic font configuration library
ii libatk1.0-01.8.0-4 The ATK accessibility toolkit
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib
ii libgcc11:3.4.3-13GCC support library
ii libglib2.0-0 2.6.4-1 The GLib library of C routines
ii libgtk2.0-02.6.4-3 The GTK+ graphical user interface
ii libidl00.8.5-1 library for parsing CORBA IDL file
ii libjpeg62 6b-10 The Independent JPEG Group's JPEG
ii libkrb53 1.3.6-2sarge2 MIT Kerberos runtime libraries
ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio
ii libpng12-0 1.2.8rel-1PNG library - runtime
ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3
ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li
ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte
ii libxft22.1.7-1 FreeType-based font drawing librar
ii libxp6 4.3.0.dfsg.1-14sarge1 X Window System printing extension
ii libxt6 4.3.0.dfsg.1-14sarge1 X Toolkit Intrinsics
ii psmisc 21.5-1Utilities that use the proc filesy
ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu
ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322239: mozilla-firefox: [patch] incorrectly set LD_LIBRARY_PATH in /usr/bin/firefox wrapper
I think I am seeing this too. It was reported in #316824 (for 'mozilla') but I did not cross-report to 'mozilla-firefox'. The patch below should fix the issue, see #316824 for why I think it fixes it. I don't see why the firefox script should circumvent YOUR broken LD_LIBRARY_PATH. If your LD_LIBRARY_PATH is b0rked in the first place, change it. Well, that's a helpful response! I need to have LD_LIBRARY_PATH set to run particular software that I need to run to do my work. In particular, we use Debian 'stable' because we need that stability when writing programs to swing 1,000 tonnes of metal around the sky (www.parkes.atnf.csiro.au). However for some other parts of our work we need to install a more recent GCC than stable provides into /usr/local/gnu. This is what is biting us here. The fix is only 4 bytes, and since the shell execs into the binary, who cares what mangling of LD_LIBRARY_PATH goes on inside the wrapper? I thought that was the whole point of the wrapper. And it means an important debian package runs nicely in a wider range of environments. Kind regards Vince -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
