Re: apt: Saves some downloaded packages under truncated filenames
Cyril Brulebois (2013-09-19):
> My log said:
> | Get:140 http://ftp.fr.debian.org/debian/ unstable/main/debian-installer
> cdebconf-newt-terminal amd64 0.22 [4,538 B]
>
> […]
> | Needed cdebconf-newt-terminal not found (looked in
> apt.udeb/cache/archives/, debugudebs/)
>
> and no such file there indeed, but some strangely-named files:
> | c
I used a breakpoint in flNotDir to detect when said udeb was being
handled. Caller was pkgAcqArchive::Done(), which extracts the filename
from the Message it receives:
| // Grab the output filename
| string FileName = LookupTag(Message,"Filename");
Showing all of Message (using gdb's “set print elements 0”):
| (gdb) p Message
| $24 = {
| static npos = ,
| _M_dataplus = {
| > = {
| <__gnu_cxx::new_allocator> = {}, },
| members of std::basic_string,
std::allocator >::_Alloc_hider:
| _M_p = 0x186b348 "201 URI Done\nURI:
http://ftp.fr.debian.org/debian/pool/main/c/cdebconf-terminal/cdebconf-newt-terminal_0.22_amd64.udeb\nFilename:
/home/kibi/debian-installer/installer/build/apt.udeb/cache/archives/partial/c\nSize:
4538\nLast-Modified: Fri, 06 Sep 2013 05:42:23 GMT\nMD5-Hash:
20db6152fce5081fcbf49c7c08f21246\nMD5Sum-Hash:
20db6152fce5081fcbf49c7c08f21246\nSHA1-Hash:
fa2a40f777a2f48b9634866bc780fb059e60b2fe\nSHA256-Hash:
c4d99ef27285f0c9090005313165627e56e0972e687af7e68c2b1d1538e2ae09\nSHA512-Hash:
046dc9b0dbe08fd1ec54301714a452c70abb847b262a94fc9f468fff7259a542849b759e71f974ae3a878f4b04db42bf6e600bfd2090bc40eba0806a9b4e9a8c"
| }
| }
So it appears the message is corrupted?
Now looking into the http method (ISTR ftp led to the same results),
adding a trivial clog call in there, I'm getting:
| Filename in http method:
/home/kibi/debian-installer/installer/build/apt.udeb/cache/archives/partial/c
so it was actually set way before that, as expected DestFile.
Trying to apt-get install --print-uris, that's indeed sufficient
to exhibit the issue, no need to download/clean/playagain.
Since Owner->DestFile is used both for creating a Message and for
printing URIs, I suspect that's the one going bad. Looking at
apt-private/private-install.cc's InstallPackages(), it appears
the Fetcher is created by the PackageManager, and one then gets the
files out of there. I suspect this is what wants getting looked at.
As for reproducing the issue:
| debcheckout debian-installer foo
| cd foo/build
| export DEB_HOST_ARCH=$(dpkg-architecture -qDEB_HOST_ARCH)
| ./util/get-packages udeb acpi-modules-3.10-3-amd64-di alsa-base-udeb
alsa-utils-udeb anna archdetect bogl-bterm-udeb brltty-udeb busybox-udeb
cdebconf-gtk-terminal cdebconf-gtk-udeb cdebconf-newt-terminal
cdebconf-newt-udeb cdebconf-priority cdebconf-text-udeb cdebconf-udeb
choose-mirror choose-mirror-bin console-setup-linux-fonts-udeb
console-setup-pc-ekmap console-setup-udeb core-modules-3.10-3-amd64-di
crc-modules-3.10-3-amd64-di crypto-modules-3.10-3-amd64-di
debian-archive-keyring-udeb di-utils di-utils-reboot di-utils-shell
di-utils-terminfo download-installer env-preseed espeak-data-udeb espeakup-udeb
ethdetect event-modules-3.10-3-amd64-di fat-modules-3.10-3-amd64-di
fb-modules-3.10-3-amd64-di file-preseed firewire-core-modules-3.10-3-amd64-di
fontconfig-udeb fonts-farsiweb-udeb fonts-khmeros-udeb fonts-lao-udeb
fonts-lklug-sinhala-udeb fonts-mlym-udeb fonts-sil-abyssinica-udeb
fonts-sil-padauk-udeb fonts-taml-udeb fonts-telu-udeb fonts-thai-tlwg-udeb
fonts-tibetan-machine-udeb fonts-ukij-uyghur-udeb
(I suspect one can truncate the package list some more, but that's
for another day; if you're on another arch, try this command
instead, without the export: make rebuild_netboot)
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#723297: marked as done (elilo-installer link with -L/usr/lib)
Your message dated Thu, 19 Sep 2013 12:30:59 +0800 with message-id and subject line Re: Bug#723297: elilo-installer link with -L/usr/lib has caused the Debian Bug report #723297, regarding elilo-installer link with -L/usr/lib to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 723297: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723297 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: elilo-installer Version: 1.23 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. elilo-installer_1.23_mips64el.build.xz Description: Binary data --- End Message --- --- Begin Message --- sorry for this mistake bug report On Tue, Sep 17, 2013 at 6:33 PM, YunQiang Su wrote: > Package: elilo-installer > Version: 1.23 > X-Debbugs-CC: wzss...@gmail.com > > This package has one or more -L/usr/lib in its build system, > which will make it ftbfs if there is libraries under /usr/lib, > while is not the default architecture, mips* for example. > > On mips* systems, /usr/lib is defined as place to hold O32 > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. > > Beside the way, on the multiarch system like Debian, user may install > libraries under /usr/lib by hand. > > Please use the default search path if you can, and please consider fix > this. > > I will try to fix this bug, while if you can help to fix it, > It will be very appreciative. > > The attachement is the buildlog of this package on mips64el platform. -- YunQiang Su--- End Message ---
Bug#723263: marked as done (colo-installer link with -L/usr/lib)
Your message dated Thu, 19 Sep 2013 10:36:05 +0800 with message-id and subject line Re: Bug#723263: colo-installer link with -L/usr/lib has caused the Debian Bug report #723263, regarding colo-installer link with -L/usr/lib to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 723263: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723263 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: colo-installer Version: 1.25 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. colo-installer_1.25_mips64el.build.xz Description: Binary data --- End Message --- --- Begin Message --- sorry for this mistake bug report. On Tue, Sep 17, 2013 at 6:30 PM, YunQiang Su wrote: > Package: colo-installer > Version: 1.25 > X-Debbugs-CC: wzss...@gmail.com > > This package has one or more -L/usr/lib in its build system, > which will make it ftbfs if there is libraries under /usr/lib, > while is not the default architecture, mips* for example. > > On mips* systems, /usr/lib is defined as place to hold O32 > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. > > Beside the way, on the multiarch system like Debian, user may install > libraries under /usr/lib by hand. > > Please use the default search path if you can, and please consider fix > this. > > I will try to fix this bug, while if you can help to fix it, > It will be very appreciative. > > The attachement is the buildlog of this package on mips64el platform. -- YunQiang Su--- End Message ---
apt: Saves some downloaded packages under truncated filenames
Package: apt Version: 0.9.11.3 Severity: serious Justification: breaks d-i builds; probable memory corruption Cyril Brulebois (2013-09-17): > Looking at recent linux logs, it seems systemd's udev-udeb depending on > libudev1 (instead of libudev1-udeb) is the thing breaking the build from > now, so the issue apparently disappeared, at least for the time being. > Once that's fixed, it should be trivial to see whether some udebs are > still (considered) missing. Unfortunately, the logs that were partially > pasted are now gone. systemd/udev are now fixed. And the problem is back on the buildds. Luckily I reproduced the problem locally! It sure looks like apt is indeed doing its job, downloading packages, as Ben mentioned at the very beginning. *But* it fails to save them under a proper name. My log said: | Get:140 http://ftp.fr.debian.org/debian/ unstable/main/debian-installer cdebconf-newt-terminal amd64 0.22 [4,538 B] […] | Needed cdebconf-newt-terminal not found (looked in apt.udeb/cache/archives/, debugudebs/) and no such file there indeed, but some strangely-named files: | c | cde | lowmemcheck_1.40_amd64. | mai and surprise surprise: | $ for i in c cde mai lowmemcheck_1.40_amd64.; do dpkg -f $i Package; done | cdebconf-newt-terminal | cdebconf-newt-udeb | speakup-modules-3.10-3-amd64-di | lowmemcheck I'll try to come up with a test case that doesn't involve trying to build d-i. I'm attaching a transcript in the meanwhile. Mraw, KiBi. kibi@bowmore:~/debian-installer/installer/build$ make rebuild_netboot-gtk USE_UDEBS_FROM=sid rm -f ./stamps/tree-unpack-netboot-gtk-stamp ./stamps/tree-netboot-gtk-stamp ./stamps/extra-netboot-gtk-stamp ./stamps/get_udebs-netboot-gtk-stamp rm -f ./tmp/netboot-gtk/diskusage.txt rm -f ./tmp/netboot-gtk/all.utf rm -f ./tmp/netboot-gtk/unifont.bdf ./tmp/netboot-gtk/tree/lib/unifont.bgf rm -f pkg-lists/standard-udebs pkg-lists/kernel-module-udebs rm -rf ./dest/netboot/gtk/debian-installer ./dest/netboot/gtk/netboot.tar.gz ./dest/netboot/gtk/mini.iso rm -rf ./tmp/netboot-gtk update-manifest make[3]: `sources.list.udeb' is up to date. Ign copy: localudebs/ InRelease Ign copy: localudebs/ Release.gpg Ign copy: localudebs/ Release Get:1 copy: localudebs/ Packages [20 B] Ign copy: localudebs/ Translation-en Get:2 http://ftp.fr.debian.org unstable InRelease [204 kB] Get:3 http://ftp.fr.debian.org unstable/main/debian-installer amd64 Packages [54.1 kB] Get:4 http://ftp.fr.debian.org unstable/main/debian-installer i386 Packages [60.4 kB] Fetched 319 kB in 0s (400 kB/s) Reading package lists... Done Reading package lists... Done Building dependency tree... Done dh_testroot # Ensure that sources.list.udeb has trusted=yes. # Only needed for a while to ensure all build systems get the new # version of the file, then can be removed. if ! grep -q -L 'trusted=yes' sources.list.udeb; then \ rm -f sources.list.udeb; \ make sources.list.udeb; \ fi get-packages udeb acpi-modules-3.10-3-amd64-di alsa-base-udeb alsa-utils-udeb anna archdetect bogl-bterm-udeb brltty-udeb busybox-udeb cdebconf-gtk-terminal cdebconf-gtk-udeb cdebconf-newt-terminal cdebconf-newt-udeb cdebconf-priority cdebconf-text-udeb cdebconf-udeb choose-mirror choose-mirror-bin console-setup-linux-fonts-udeb console-setup-pc-ekmap console-setup-udeb core-modules-3.10-3-amd64-di crc-modules-3.10-3-amd64-di crypto-modules-3.10-3-amd64-di debian-archive-keyring-udeb di-utils di-utils-reboot di-utils-shell di-utils-terminfo download-installer env-preseed espeak-data-udeb espeakup-udeb ethdetect event-modules-3.10-3-amd64-di fat-modules-3.10-3-amd64-di fb-modules-3.10-3-amd64-di file-preseed firewire-core-modules-3.10-3-amd64-di fontconfig-udeb fonts-farsiweb-udeb fonts-khmeros-udeb fonts-lao-udeb fonts-lklug-sinhala-udeb fonts-mlym-udeb fonts-sil-abyssinica-udeb fonts-sil-padauk-udeb fonts-taml-udeb fonts-telu-udeb fonts-thai-tlwg-udeb fonts-tibetan-machine-udeb fonts-ukij-uyghur-udeb gpgv-udeb gtk2-engines-udeb hw-detect hyperv-modules-3.10-3-amd64-di i2c-modules-3.10-3-amd64-di initrd-preseed input-modules-3.10-3-amd64-di installation-locale kbd-udeb kernel-image-3.10-3-amd64-di libasound2-udeb libatk1.0-udeb libblkid1-udeb libcairo2-udeb libcrypto1.0.0-udeb libdebconfclient0-udeb libdebian-installer4-udeb libexpat1-udeb libffi6-udeb libfontenc1-udeb libfreetype6-udeb libfribidi0-udeb libgdk-pixbuf2.0-0-udeb libglib2.0-udeb libgtk2.0-0-udeb libharfbuzz0-udeb libiw30-udeb libkmod2-udeb libmtdev1-udeb libnl-3-200-udeb libnl-genl-3-200-udeb libnss-dns-udeb libnss-files-udeb libpango1.0-udeb libpciaccess0-udeb libpcre3-udeb libpixman-1-0-udeb libpng12-0-udeb libtextwrap1-udeb libudev1-udeb libuuid1-udeb libvte9-udeb libx11-6-udeb libxau6-udeb libxcb1-udeb libxcursor1-udeb libxdmcp6-udeb libxext6-udeb libxfixes3-udeb libxfont1-udeb libxft2-udeb libxi6-udeb libxinerama1-udeb libxkbfi
Bug#723307: marked as done (flash-kernel link with -L/usr/lib)
Your message dated Thu, 19 Sep 2013 10:02:02 +0800 with message-id and subject line Re: Bug#723307: flash-kernel link with -L/usr/lib has caused the Debian Bug report #723307, regarding flash-kernel link with -L/usr/lib to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 723307: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723307 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: flash-kernel Version: 3.11 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. flash-kernel_3.11_mips64el.build.xz Description: Binary data --- End Message --- --- Begin Message --- sorry for this mistake bug report. I am closing it. On Wed, Sep 18, 2013 at 10:17 AM, Dmitrijs Ledkovs wrote: > please ignore this thread. > I've now noticed these bug reports were raised to debian-devel in the > " link with -L/usr/lib" thread. > > Regards, > > Dmitrijs. > > On 18 September 2013 02:54, Dmitrijs Ledkovs wrote: >> Dear YunQiang Su, >> >> It looks like this class of problems is reported against a lot of >> packages now. Did you consult on debian-devel before doing this mass >> bug filing? >> >> Regards, >> >> Dmitrijs. >> >> >> On 17 September 2013 11:34, YunQiang Su wrote: >>> Package: flash-kernel >>> Version: 3.11 >>> X-Debbugs-CC: wzss...@gmail.com >>> >>> This package has one or more -L/usr/lib in its build system, >>> which will make it ftbfs if there is libraries under /usr/lib, >>> while is not the default architecture, mips* for example. >>> >>> On mips* systems, /usr/lib is defined as place to hold O32 >>> libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. >>> >>> Beside the way, on the multiarch system like Debian, user may install >>> libraries under /usr/lib by hand. >>> >>> Please use the default search path if you can, and please consider fix >>> this. >>> >>> I will try to fix this bug, while if you can help to fix it, >>> It will be very appreciative. >>> >>> The attachement is the buildlog of this package on mips64el platform. -- YunQiang Su--- End Message ---
Debian installer build: failed or old builds
Debian installer build overview --- Failed or old builds: * FAILED BUILD: amd64 Sep 19 00:03 buildd@barber build_cdrom_isolinux http://d-i.debian.org/daily-images/amd64/daily/build_cdrom_isolinux.log * FAILED BUILD: amd64 Sep 19 00:03 buildd@barber build_cdrom_gtk http://d-i.debian.org/daily-images/amd64/daily/build_cdrom_gtk.log * FAILED BUILD: amd64 Sep 19 00:03 buildd@barber build_cdrom-xen http://d-i.debian.org/daily-images/amd64/daily/build_cdrom-xen.log * FAILED BUILD: amd64 Sep 19 00:05 buildd@barber build_netboot-gtk http://d-i.debian.org/daily-images/amd64/daily/build_netboot-gtk.log * FAILED BUILD: amd64 Sep 19 00:05 buildd@barber build_netboot-xen http://d-i.debian.org/daily-images/amd64/daily/build_netboot-xen.log * FAILED BUILD: amd64 Sep 19 00:05 buildd@barber build_hd-media http://d-i.debian.org/daily-images/amd64/daily/build_hd-media.log * FAILED BUILD: amd64 Sep 19 00:06 buildd@barber build_hd-media_gtk http://d-i.debian.org/daily-images/amd64/daily/build_hd-media_gtk.log * FAILED BUILD: armel Sep 18 08:10 buildd@ancina build_iop32x_netboot http://d-i.debian.org/daily-images/armel/daily/build_iop32x_netboot.log * FAILED BUILD: armel Sep 18 08:11 buildd@ancina build_iop32x_network-console_glantank http://d-i.debian.org/daily-images/armel/daily/build_iop32x_network-console_glantank.log * FAILED BUILD: armel Sep 18 08:11 buildd@ancina build_iop32x_network-console_n2100 http://d-i.debian.org/daily-images/armel/daily/build_iop32x_network-console_n2100.log * FAILED BUILD: armel Sep 18 08:12 buildd@ancina build_iop32x_network-console_ss4000e http://d-i.debian.org/daily-images/armel/daily/build_iop32x_network-console_ss4000e.log * FAILED BUILD: armel Sep 18 08:12 buildd@ancina build_kirkwood_netboot http://d-i.debian.org/daily-images/armel/daily/build_kirkwood_netboot.log * FAILED BUILD: armel Sep 18 08:13 buildd@ancina build_kirkwood_netboot-gtk http://d-i.debian.org/daily-images/armel/daily/build_kirkwood_netboot-gtk.log * FAILED BUILD: armel Sep 18 08:14 buildd@ancina build_kirkwood_network-console http://d-i.debian.org/daily-images/armel/daily/build_kirkwood_network-console.log * FAILED BUILD: armel Sep 18 08:15 buildd@ancina build_orion5x_network-console http://d-i.debian.org/daily-images/armel/daily/build_orion5x_network-console.log * FAILED BUILD: armel Sep 18 08:15 buildd@ancina build_versatile_netboot http://d-i.debian.org/daily-images/armel/daily/build_versatile_netboot.log * FAILED BUILD: armhf Sep 18 09:39 buildd@hasse build_mx5_netboot http://d-i.debian.org/daily-images/armhf/daily/build_mx5_netboot.log * FAILED BUILD: armhf Sep 18 09:40 buildd@hasse build_mx5_network-console http://d-i.debian.org/daily-images/armhf/daily/build_mx5_network-console.log * FAILED BUILD: armhf Sep 18 09:41 buildd@hasse build_mx5_netboot-gtk http://d-i.debian.org/daily-images/armhf/daily/build_mx5_netboot-gtk.log * FAILED BUILD: armhf Sep 18 09:41 buildd@hasse build_vexpress_netboot http://d-i.debian.org/daily-images/armhf/daily/build_vexpress_netboot.log * FAILED BUILD: i386 Sep 19 00:02 buildd@biber build_cdrom_isolinux http://d-i.debian.org/daily-images/i386/daily/build_cdrom_isolinux.log * FAILED BUILD: i386 Sep 19 00:03 buildd@biber build_cdrom_gtk http://d-i.debian.org/daily-images/i386/daily/build_cdrom_gtk.log * FAILED BUILD: i386 Sep 19 00:03 buildd@biber build_cdrom-xen http://d-i.debian.org/daily-images/i386/daily/build_cdrom-xen.log * FAILED BUILD: i386 Sep 19 00:04 buildd@biber build_netboot-gtk http://d-i.debian.org/daily-images/i386/daily/build_netboot-gtk.log * FAILED BUILD: i386 Sep 19 00:07 buildd@biber build_hd-media http://d-i.debian.org/daily-images/i386/daily/build_hd-media.log * FAILED BUILD: i386 Sep 19 00:07 buildd@biber build_hd-media_gtk http://d-i.debian.org/daily-images/i386/daily/build_hd-media_gtk.log * OLD BUILD:ia64 May 26 00:12 buildd@alkman build_cdrom http://d-i.debian.org/daily-images/ia64/daily/build_cdrom.log * OLD BUILD:ia64 May 26 00:16 buildd@alkman build_netboot http://d-i.debian.org/daily-images/ia64/daily/build_netboot.log * FAILED BUILD: kfreebsd-amd64 Sep 19 00:26 buildd@fano build_cdrom_grub http://d-i.debian.org/daily-images/kfreebsd-amd64/daily/build_cdrom_grub.log * FAILED BUILD: kfreebsd-amd64 Sep 19 00:26 buildd@fano build_cdrom_gtk http://d-i.debian.org/daily-images/kfreebsd-amd64/daily/build_cdrom_gtk.log * FAILED BUILD: kfreebsd-amd64 Sep 19 00:29 buildd@
Re: Weekly build status
Christian PERRIER (2013-09-18): > Quoting Steve McIntyre (st...@einval.com): > > > CCing the debian-boot list where people are likely to know more. I > > *think* this is a know bug in the build scripts that has been causing > > a lot of failing builds lately. KiBi? > > > Yes, there is a thread in debian-boot about the daily builds > failures. Cyril is trying to investigate the issue or at least to work it > around. Steve, see: http://d-i.debian.org/daily-images/build-logs.html udev-udeb had broken dependencies, this was fixed in the last systemd upload (a few hours ago). Before that, there was a -2 to -3 linux kernel ABI bump, and src:linux was lately successfully built on all platforms. So udebs should be in a better shape very soon, for more or less all architectures. I'll handle remaining issues as they pop up. Mraw, KiBi. signature.asc Description: Digital signature
Processed: found 722064 in 1.99
Processing commands for cont...@bugs.debian.org: > found 722064 1.99 Bug #722064 [keyboard-configuration] start and stop actions are no longer supported Marked as found in versions console-setup/1.99. > thanks Stopping processing here. Please contact me if you need assistance. -- 722064: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722064 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13795351735894.transcr...@bugs.debian.org
Bug#723635: installation-report: MDADM filesystem-root set up by reinstalling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: installation-reports Version: 2.49 Severity: wishlist Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** - -- Package-specific info: Boot method: CD Image version: img-url & builddate Date: Machine: GIGABYTE GA-MA78GM-S2H mainboard Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs15426432 4435156 10991276 29% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 380156 848379308 1% /run /dev/disk/by-uuid/10634b61-3094-458a-8ee9-624731354791 xfs 15426432 4435156 10991276 29% / tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 2438020 224 2437796 1% /run/shm /dev/sda7 xfs 991196 53352937844 6% /boot /dev/sdg1 xfs 14637056 5784608 8852448 40% /media/fs-ro Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o] Detect network card:[o] Configure network: [o] Detect CD: [o] Load installer modules: [o] Clock/timezone setup: [o] User/password setup:[o] Detect hard drives: [o] Partition hard drives: [o] Install base system:[o] Install tasks: [o] Install boot loader:[o] Overall install:[o] Comments/Problems: For a few days I tried converting my existing installation on my main PC, which has a USB-stick filesystem-root, into a RAID1 over USB-flashmemory and harddisk. First I tried to follow the recipy there: http://anonscm.debian.org/gitweb/?p=pkg-mdadm/mdadm.git;a=blob;f=debian/README.recipes;hb=HEAD [10. converting existing filesystem to RAID1] But it turned out that this is quite outdated and would not work anymore, because its seems to be from a time when md-devices were not partitioned. I had to use a live-CD in order to operate on the root-filesystem, but the last step, trying to add the existing data to the RAID, that was created with one missing disk, failed. Next I tried to develop my own method, basing on this recipe. Some obstacles appeared, for example an SD-card with a 2048-byte physical blocksize differing from the filesystem's, causing trouble repeatedly, being not workable and 723...@bugs.debian.org. I managed to create the the array then with a different new SD-card, transferrred all data from the USB-stick, in use, onto the raid using tar, but was not able to boot from the array, not even with a non-raid boot-partition on my harddisk. I was told so already, when creating the RAID. Finally I found this in wiki.debian.org: https://wiki.debian.org/Multi%20HDD/SSD%20Partition%20Scheme?highlight=%28mdadm%29 https://wiki.debian.org/DebianInstaller/SoftwareRaidRoot about installation on RAID-root, which also did not work initially, because an extra non-raid /boot/-partition is necessary too, when there are USB-devices involved, this maybe related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624343. Now I tried to transfer the software selections from the old filesystem-root to the new one and failed again using dpkg --get-selections and dpkg --set-selections followed by 'apt-get dselect-upgrade'. Before doing this I copied /etc/apt/sources.list and /etc/apt/preferences over and did an 'aptitude update', but it failed anyway, so I am going to report this separately against 'dpkg', because this is not happening to me for the first time either. - -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7 (wheezy) - installer build 20130613" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux md-ho 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS780 Host Bridge [1022:9600] lspci -knn: Subsystem: Advanced Micro Devices [AMD] RS780 Host Bridge [1022:9600] lspci -knn: 00:01.0 PCI bridge [0604]: Advanced Micro D
