Bug#620805: installer hangs, while aptitude is waiting for input
Package: debian-installer Version: 20090123lenny8 Severity: high while installing a Debian from the netinst 5.0.8 i386 iso image, using expert install, the step Install the base system hangs at 1%... switching to the fourth console (alt+f4), i observe that aptitude is trying to upgrade the kernel (2.6.26-2-686), but complains that i am upgrading from an untrusted source (i am using mirror http://ftp.fr.debian.org/ through a proxy). the log shows that i MUST type Yes or No to continue, but the installer ui does not offer any way to answer the request, nor does it allows to cancel the current step. from another console, killing aptitude allows me to restart the same step, with the same outcome... preventing from installing the system, especially for novice users ! i would expect aptitude to never ask any question while performing an upgrade from the installer. a sensible default answer should be chosen so that the installer can continue its job. -- 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/4d9998c0.5000...@wowtechnology.com
Bug#620816: New Kazakh environment task and update for Kazakh desktop task
Package: tasksel
Version: 3.01
Severity: wishlist
Hi,
Please add Kazakh environment task and update Kazakh desktop task. Please find
attached patches.
Thanks,
Timur
From fb9dc6b8c99c1c59df8e543c31362a1d043ad5b5 Mon Sep 17 00:00:00 2001
From: Timur Birsh t...@linukz.org
Date: Mon, 4 Apr 2011 14:59:04 +0600
Subject: [PATCH 1/2] Add Kazakh environment task
---
debian/control | 10 ++
tasks/kazakh |5 +
2 files changed, 15 insertions(+), 0 deletions(-)
create mode 100644 tasks/kazakh
diff --git a/debian/control b/debian/control
index 9f46b58..27f4ac3 100644
--- a/debian/control
+++ b/debian/control
@@ -1554,6 +1554,16 @@ Description: Kannada KDE desktop
Depends: ${misc:Depends},
kde-l10n-kn
+Package: task-kazakh
+Architecture: all
+Description: Kazakh environment
+ This task installs programs and documentation in Kazakh
+ to help Kazakh speaking people use Debian.
+XBC-Maintainer: Timur Birsh t...@linukz.org
+Depends: ${misc:Depends},
+Recommends:
+ aspell-kk
+
Package: task-kazakh-desktop
Architecture: all
Description: Kazakh desktop
diff --git a/tasks/kazakh b/tasks/kazakh
new file mode 100644
index 000..19fdaea
--- /dev/null
+++ b/tasks/kazakh
@@ -0,0 +1,5 @@
+Task: kazakh
+Test-lang: kk
+Section: l10n
+Key:
+ task-kazakh
--
1.7.4.1
From 4381624ad6894919d75caaa6e9ff92139d27c7e3 Mon Sep 17 00:00:00 2001
From: Timur Birsh t...@linukz.org
Date: Mon, 4 Apr 2011 15:00:13 +0600
Subject: [PATCH 2/2] Enhance Kazakh environment task
---
tasks/kazakh-desktop |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tasks/kazakh-desktop b/tasks/kazakh-desktop
index b90c6c1..b7c5842 100644
--- a/tasks/kazakh-desktop
+++ b/tasks/kazakh-desktop
@@ -1,5 +1,5 @@
Task: kazakh-desktop
-Enhances: desktop
+Enhances: desktop, kazakh
Section: l10n
Key:
task-kazakh-desktop
--
1.7.4.1
Bug#612376: flash-kernel: please include efikamx support
Hello, I have added partial support for Efika devices into a branch for you to review, after nice work done by Loïc rewritting the base code. Please comments on: http://git.debian.org/?p=d-i/flash-kernel.git;a=commitdiff;h=fa8fdbc9607ebd892eba1e1c3b4ad12f710c901f Best regards, -- Hector Oron -- 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/20110404115627.GA26134@enorme.TCLDOMAIN.OFFICE
Re: Debian ARM architectures and subarchitectures
Hi,
(CC debian-boot to see if someone there knows better)
2011/4/4 Arnaud Patard arnaud.pat...@rtp-net.org:
Hector Oron hector.o...@gmail.com writes:
I am not sure how current Debian subarchitectures map to. Is it just
a giving name? Do they map to platform devices in linux kernel? Do
they map to machine devices?
I've not checked but I guess it's following the name of the mach-*
directories in the kernel.
I just see (probably Ubuntu contributed code) at libdebian-installer:
static const char *supported_generic_subarches[] = {
dove,
omap,
omap4,
mx51,
NULL
};
and machine mappings has:
{ Freescale MX51 Babbage Board, imx5 }, /* iMX51 reference hardware. */
If I were to add support for Freescales' i.MX51 cores, which would
be the agreed subarchitecture?
* mx51
* mx5
* mx5x
* imx51
* imx5
* imx5x
I would say mx5 as in mach-mx5 in the kernel but someone needs to check
if it's really possible to have mx50/mx51/mx53 in same kernel. I
remember some people on l-a-k ml saying it was not possible.
Would it break 'others' configurations if we set/change 'mx5' as
subarchitecture, which seems to be the most reasonable one at the
moment.
Best regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us.
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
--
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/AANLkTik1fzsr9ObB5YXq=9toxbqfzxw+r4amdpdex...@mail.gmail.com
Bug#612376: flash-kernel: please include efikamx support
Hi Martin, 2011/4/4 Martin Michlmayr t...@cyrius.com: * Hector Oron zu...@debian.org [2011-04-04 12:56]: Please comments on: http://git.debian.org/?p=d-i/flash-kernel.git;a=commitdiff;h=fa8fdbc9607ebd892eba1e1c3b4ad12f710c901f Clint added a boot.scr file in his original patch. Is that no longer needed. It is needed, but not sure if flash-kernel needs to take care of that file and regenerate every time a kernel is installed. I'll investigate if it is worth adding support for it. Also, my previous comments are not addressed: I was about to send out a better pointer: http://git.debian.org/?p=d-i/flash-kernel.git;a=shortlog;h=refs/heads/efika | Also, you need to add support in a number of other files: | - README | - debian/flash-kernel-installer.postinst | - initramfs-tools/hooks/flash_kernel_set_root | - debian/flash-kernel-installer.isinstallable (for the new subarch) Finally, is mx51 going to be the name of the kernel flavour? Can you have mx5 and mx6 in one kernel? What about different mx5x platforms in one kernel? I am not sure which kernel flavour we should use, hence I dropped an email to debian-arm@l.d.o, there is contributed code, probably by ubuntu, which adds imx51, mx51, etc... I think that needs to be clarified, so I am working on it. http://lists.debian.org/debian-arm/2011/04/msg9.html Cheers, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- 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/aanlktikohbcyy4q_2zpw+wvhflgnbrjtbtgtjd40p...@mail.gmail.com
Bug#612376: flash-kernel: please include efikamx support
* Hector Oron zu...@debian.org [2011-04-04 12:56]: Please comments on: http://git.debian.org/?p=d-i/flash-kernel.git;a=commitdiff;h=fa8fdbc9607ebd892eba1e1c3b4ad12f710c901f Clint added a boot.scr file in his original patch. Is that no longer needed. Also, my previous comments are not addressed: | Also, you need to add support in a number of other files: | - README | - debian/flash-kernel-installer.postinst | - initramfs-tools/hooks/flash_kernel_set_root | - debian/flash-kernel-installer.isinstallable (for the new subarch) Finally, is mx51 going to be the name of the kernel flavour? Can you have mx5 and mx6 in one kernel? What about different mx5x platforms in one kernel? -- Martin Michlmayr http://www.cyrius.com/ -- 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/20110404135647.gg21...@jirafa.cyrius.com
Bug#612376: flash-kernel: please include efikamx support
On Mon, Apr 04, 2011, Hector Oron wrote: Finally, is mx51 going to be the name of the kernel flavour? Can you have mx5 and mx6 in one kernel? What about different mx5x platforms in one kernel? I am not sure which kernel flavour we should use, hence I dropped an email to debian-arm@l.d.o, there is contributed code, probably by ubuntu, which adds imx51, mx51, etc... I think that needs to be clarified, so I am working on it. http://lists.debian.org/debian-arm/2011/04/msg9.html It would be nice if you could file a bug against linux to get the new flavor; I personally would recommend -mx5. Currently, the upstream kernel doesn't support building both i.MX51 and i.MX53 in the same kernel but the Linux Linaro branch and the Freescale BSP kernel do; also, I think the patches by Eric Miao allowing this (runtime phys offset patches -- i.MX51 has phys RAM at 0x9000 while i.MX53 has it at 0x7000, see arch/arm/mach-mx5/Makefile.boot) are pending in Sacha Hauer's tree, but I'm not entirely sure. Technically, mx5 would only support mx51 right now, but would soon allow supporting mx53 as well, notably for mx53loco / quickstart boards which I bet a bunch of Debian ARM users will get. I reviewed your commits, some notes: - fa8fdbc9607ebd892eba1e1c3b4ad12f710c901f Add support for Efika devices: please sort machine names alphabetically in the case statement - 7e6bd315830ad89c11aadebbe45f1636dd686055 README: Add Efika support: kernel uses nettop in cpuinfo, but vendors uses Smarttop; also, vendor uses Efika MX not just Efika. I would prefer just the vendor name in the README but you could have both with Efika MX Smarttop (nettop); the kernel name is set in stone now, but it's not too nice - 4f873843d590b6d5475dcef7d863919c89609b4f flash-kernel-installer.isinstallable: Add mx51 as subarchitecture: I realize this comes from other parts of d-i, but would it make sense to use arm*/mx5? My preference would be to avoid subarches as long as possible but use upstream names when required; arch/arm/mach-mx5 is the current name, so that's what I'd use. - 5deea668506d7a26a8b79fea218101c7900b9752 changelog: add Efika support (Closes: #612376): please amend the currently UNRELEASED changelog entry Othewise looked good; thanks! I'm also in favor of a boot.scr. Outside of Martin's remarks, we need to agree on whether this is meant for installation of Debian to PATA, to SD card, or both and whether this is meant to work with vendor's u-boot, upstream u-boot, or both. Thanks, -- Loïc Minier -- 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/20110404143412.ga6...@bee.dooz.org
Re: Debian ARM architectures and subarchitectures
On Mon, Apr 04, 2011, Hector Oron wrote:
static const char *supported_generic_subarches[] = {
dove,
matches mach-dove, no plat-dove
omap,
matches plat-omap, but no mach-omap (mach-omap1 supports OMAP1xxx and
mach-omap2 supports OMAP 2+ -- 2xxx, 3xxx, 4xxx).
omap4,
doesn't match any plat or mach dir
mx51,
neither does this
and machine mappings has:
{ Freescale MX51 Babbage Board, imx5 }, /* iMX51 reference hardware.
*/
plat-imx5 is a name which was used in the Freescale BSP which also used
mach-imx51 in the past.
Would it break 'others' configurations if we set/change 'mx5' as
subarchitecture, which seems to be the most reasonable one at the
moment.
I think you really want to go for mx5; as this was never supported in
Debian so far, that should be ok; if you need to change existing
imx5/mx51 bits, poke the Ubuntu folks (or I can forward) as it might
impact them.
I've commented in Debian #612376 on why we want mx5; quoting myself:
Currently, the upstream
kernel doesn't support building both i.MX51 and i.MX53 in the same
kernel but the Linux Linaro branch and the Freescale BSP kernel do;
also, I think the patches by Eric Miao allowing this (runtime phys
offset patches -- i.MX51 has phys RAM at 0x9000 while i.MX53 has it
at 0x7000, see arch/arm/mach-mx5/Makefile.boot) are pending in
Sacha Hauer's tree, but I'm not entirely sure.
Technically, mx5 would only support mx51 right now, but would soon
allow supporting mx53 as well, notably for mx53loco / quickstart boards
which I bet a bunch of Debian ARM users will get.
In the kernel, there's plat-mxc, mach-imx, mach-mx3 and mach-mx5. I
expect Debian will want to support popular mach-mx5 hardware for i.MX51
(Efika MX Smartbook and Smarttop) and i.MX53 (Freescale MX53LOCO /
Quickstart board).
Also note that the currently supported subarches in Debian ARM are:
- iop32x (matches mach-iop32x, not plat-iop -- there are some other
mach-iop*)
- kirkwood (matches mach-kirkwood, no plat-kirkwood I think it's
plat-orion)
- ixp4xx (matches mach-ixp4xx, no plat-ixp4xx -- not sure what it uses)
- orion5x (matches mach-orion5x, no plat-orion5x I think it's also
plat-orion)
- versatile (matches mach-versatile and plat-versatile)
So mach-* has been very consistent in Debian ARM kernel flavors.
Cheers,
--
Loïc Minier
--
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/20110404150906.gd6...@bee.dooz.org
Bug#612376: flash-kernel: please include efikamx support
Hello, 2011/4/4 Loïc Minier l...@dooz.org: It would be nice if you could file a bug against linux to get the new flavor; I personally would recommend -mx5. That's fine with me. I'll wait for the bug report until we had proper patches for kernel. Technically, mx5 would only support mx51 right now, but would soon allow supporting mx53 as well, notably for mx53loco / quickstart boards which I bet a bunch of Debian ARM users will get. I guess if we aim to unify, makes sense to use mx5 subarchitecture. I'll walk around debian-installer base code to fix subarches. I hope it does not break previous ubuntu contributions. I reviewed your commits, some notes: - fa8fdbc9607ebd892eba1e1c3b4ad12f710c901f Add support for Efika devices: please sort machine names alphabetically in the case statement - 7e6bd315830ad89c11aadebbe45f1636dd686055 README: Add Efika support: kernel uses nettop in cpuinfo, but vendors uses Smarttop; also, vendor uses Efika MX not just Efika. I would prefer just the vendor name in the README but you could have both with Efika MX Smarttop (nettop); the kernel name is set in stone now, but it's not too nice - 4f873843d590b6d5475dcef7d863919c89609b4f flash-kernel-installer.isinstallable: Add mx51 as subarchitecture: I realize this comes from other parts of d-i, but would it make sense to use arm*/mx5? My preference would be to avoid subarches as long as possible but use upstream names when required; arch/arm/mach-mx5 is the current name, so that's what I'd use. - 5deea668506d7a26a8b79fea218101c7900b9752 changelog: add Efika support (Closes: #612376): please amend the currently UNRELEASED changelog entry Othewise looked good; thanks! Please recheck changes: http://git.debian.org/?p=d-i/flash-kernel.git;a=commitdiff;h=108de0c2f52301151dd866fe5a0bb7c5f34e5f57 I'm also in favor of a boot.scr. Yes, I agree that flash-kernel needs to know about boot.scr, could we steal ubuntu code/approach (you explained on IRC) or should I write a patch for support it? 16:37 lool zumbi: well flash-kernel can do whatever is needed 16:38 lool zumbi: The main reason I'd use one would be to pass cmdline args such as root=UUID=xyz to the kernel but it's an useful facility for later changes as well 16:38 lool zumbi: Up to you 16:39 lool zumbi: It's also the only way to persist your cmdline flags when booting from SD, since you can't saveenv to SD 16:39 lool zumbi: There are two ways this could be supported: generated at Debian install time, generated every time flash-kernel is run 16:48 zumbi lool: ok, let's say, we enable boot.scr support on flash-kernel-installer, so it is just used at Debian install time, if later we find out we need it at kernel upgrade time, we can always add the code 16:50 lool zumbi: If we add it later, it might break expectations that the file is not overwritten on upgrade, and so it might overwrite user data 16:50 lool zumbi: In Linaro, we write a boot.txt near the boot.scr with the contents before calling mkimage; I think Ubuntu's flash-kernel will generate boot.scr from boot.txt if present 16:53 zumbi lool: I do not see why not follow Ubuntu approach 17:06 lool- zumbi: I'm not suggesting not to follow it either Outside of Martin's remarks, we need to agree on whether this is meant for installation of Debian to PATA, to SD card, or both and whether this is meant to work with vendor's u-boot, upstream u-boot, or both. I would say we want to install on which ever is mounted under /boot, so if /boot/boot.txt is present, then boot.scr is regenerated everytime kernel is installed. Best regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- 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/AANLkTimxi2KT+_g=LGf8j4F-wJHB=djr=r33qsft1...@mail.gmail.com
Re: Debian ARM architectures and subarchitectures
Loïc Minier l...@dooz.org writes:
On Mon, Apr 04, 2011, Hector Oron wrote:
static const char *supported_generic_subarches[] = {
dove,
matches mach-dove, no plat-dove
omap,
matches plat-omap, but no mach-omap (mach-omap1 supports OMAP1xxx and
mach-omap2 supports OMAP 2+ -- 2xxx, 3xxx, 4xxx).
omap4,
doesn't match any plat or mach dir
mx51,
neither does this
and machine mappings has:
{ Freescale MX51 Babbage Board, imx5 }, /* iMX51 reference hardware.
*/
plat-imx5 is a name which was used in the Freescale BSP which also used
mach-imx51 in the past.
Would it break 'others' configurations if we set/change 'mx5' as
subarchitecture, which seems to be the most reasonable one at the
moment.
I think you really want to go for mx5; as this was never supported in
Debian so far, that should be ok; if you need to change existing
imx5/mx51 bits, poke the Ubuntu folks (or I can forward) as it might
impact them.
I've commented in Debian #612376 on why we want mx5; quoting myself:
Currently, the upstream
kernel doesn't support building both i.MX51 and i.MX53 in the same
kernel but the Linux Linaro branch and the Freescale BSP kernel do;
also, I think the patches by Eric Miao allowing this (runtime phys
offset patches -- i.MX51 has phys RAM at 0x9000 while i.MX53 has it
at 0x7000, see arch/arm/mach-mx5/Makefile.boot) are pending in
Sacha Hauer's tree, but I'm not entirely sure.
that's why I was talking of checking imx51/imx53 support in same
kernel. iirc imx50 has same addresses as imx53.
Technically, mx5 would only support mx51 right now, but would soon
allow supporting mx53 as well, notably for mx53loco / quickstart boards
which I bet a bunch of Debian ARM users will get.
tbh, I was thinking of loco boards when talking of imx53. Given the
price of loco, it makes them interesting so would be bad to have 2
kernels instead of one.
In the kernel, there's plat-mxc, mach-imx, mach-mx3 and mach-mx5. I
expect Debian will want to support popular mach-mx5 hardware for i.MX51
(Efika MX Smartbook and Smarttop) and i.MX53 (Freescale MX53LOCO /
Quickstart board).
Also note that the currently supported subarches in Debian ARM are:
- iop32x (matches mach-iop32x, not plat-iop -- there are some other
mach-iop*)
- kirkwood (matches mach-kirkwood, no plat-kirkwood I think it's
plat-orion)
yeah, it's plat-orion for mach-kirkwood, mach-orion5x. I guess it's true
for mv78xx0 too.
Arnaud
--
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/87fwpym46l@lebrac.rtp-net.org
Processed: limit source to tasksel, tagging 620816
Processing commands for cont...@bugs.debian.org: #tasksel (3.02) UNRELEASED; urgency=low # # * Add Kazakh environment task. Closes: #620816 # limit source tasksel Limiting to bugs with field 'source' containing at least one of 'tasksel' Limit currently set to 'source':'tasksel' tags 620816 + pending Bug #620816 [tasksel] New Kazakh environment task and update for Kazakh desktop task Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 620816: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620816 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.130193837023052.transcr...@bugs.debian.org
Bug#612376: flash-kernel: please include efikamx support
On Mon, Apr 04, 2011 at 04:35:03PM +0100, Hector Oron wrote: I would say we want to install on which ever is mounted under /boot, so if /boot/boot.txt is present, then boot.scr is regenerated everytime kernel is installed. I think that could be a good thing to do for all platforms. -- 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/20110404181857.ga32...@scru.org
Bug#612376: flash-kernel: please include efikamx support
Hi,
2011/4/4 Clint Adams cl...@debian.org:
On Mon, Apr 04, 2011 at 04:35:03PM +0100, Hector Oron wrote:
I would say we want to install on which ever is mounted under /boot,
so if /boot/boot.txt is present, then boot.scr is regenerated
everytime kernel is installed.
I think that could be a good thing to do for all platforms.
Here a boot script I am currently using on Efika targets:
setenv kernel uImage;
setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait rw
video=imx-ipuv3-fb:1024x600M-16@60 rootfstype=ext4 quiet lpj=3997696
earlyprintk=serial;
${loadcmd} ${ramdiskaddr} ${ramdisk};
if imi ${ramdiskaddr}; then; else
setenv bootargs ${bootargs} noinitrd;
setenv ramdiskaddr ;
fi;
${loadcmd} ${kerneladdr} ${kernel}
if imi ${kerneladdr}; then
bootm ${kerneladdr} ${ramdiskaddr}
fi;
Do we want kernel versioning?
Do we want bootargs per machine? Or what alternatives do we have to
handle bootargs? I am really not sure how to handle that, while I do
not like hardcoded values, those might be needed.
In an official version I suspect we need to replace noinitrd bit.
Cheers,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us.
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
--
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/AANLkTinfudBido1rqCN=cszbgb1ndrfs8tombjj2x...@mail.gmail.com
Bug#579970: no crypttab and bogus mdadm.conf in initiaalramfs
Package: installation-reports Severity: normal I made three partitions on two identical drives: sd[ab]1, 1GB, raid1, /boot, ext4 sd[ab]2, 1GB, encrypted, swap sd[ab]3, 319GB, raid1, encrypted, /, ext4 The installer indicated no problem. On first boot the root filesystem could not be mounted. I set up the raids, the encryped root filesystem, edited mdadm and crypttab, ran dpkg-reconfigure linux-image... and now it works. /etc/crypttab was empty before and mdadm.conf contained some totaly bogus entries, which seem to come from another machine: DEVICE partitions # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST system # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=f6de5584:d9dbce39:090f16ff:f795e54c name=hetzner:0 ARRAY /dev/md/1 metadata=1.2 UUID=0e065fee:15dea43e:f4ed7183:70d519bd name=hetzner:1 ARRAY /dev/md/2 metadata=1.2 UUID=ce4dd5a8:d8c2fdf4:4612713e:06047473 name=hetzner:2 # This file was auto-generated on Sun, 06 Feb 2011 05:54:50 + # by mkconf 3.1.4-1+8efb9d1 My new mdadm.conf and crypttab: DEVICE /dev/sd[ab][13] # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST system # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/0 devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md/1 devices=/dev/sda3,/dev/sdb3 # target name source device key file options md1_crypt /dev/md1noneluks,tries=0 swap1 /dev/sda2 /dev/urandomswap swap2 /dev/sdb2 /dev/urandomswap -- 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/20110404185451.2757.5894.reportbug@scenicl
Bug#618929: Additional info
It is certainly possible that my CD drive is flaky. Do you know of a diagnostic test in the Debian release that I could use to simply read several known good CDs for errors? Thanks, Mike -Original Message- From: Miguel Figueiredo [mailto:el...@debianpt.org] Sent: Sunday, April 03, 2011 10:21 AM To: Tremblay, Mike A Cc: 618...@bugs.debian.org Subject: Re: Bug#618929: Additional info Hi, according to the log you sent grub was successfully installed: Mar 25 17:22:36 grub-installer: info: Installing grub on '/dev/sda' Mar 25 17:22:37 grub-installer: info: grub-install supports --no-floppy Mar 25 17:22:37 grub-installer: info: Running chroot /target grub-install --no-floppy --force /dev/sda Mar 25 17:22:57 grub-installer: Installation finished. No error reported. Mar 25 17:22:57 grub-installer: info: grub-install ran successfully Mar 25 16:55:48 kernel: [ 3697.543489] sr 1:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Mar 25 16:55:48 kernel: [ 3697.543539] sr 1:0:1:0: [sr0] Sense Key : Illegal Request [current] Mar 25 16:55:48 kernel: [ 3697.543587] Info fld=0x504c0, ILI Mar 25 16:55:48 kernel: [ 3697.543661] sr 1:0:1:0: [sr0] Add. Sense: Illegal mode for this track Mar 25 16:55:48 kernel: [ 3697.543740] sr 1:0:1:0: [sr0] CDB: Read(10): 28 00 00 05 04 c0 00 00 02 00 Mar 25 16:55:48 kernel: [ 3697.543823] end_request: I/O error, dev sr0, sector 1315584 On your log there are also several read errors from the CD used to install the system. This could be due to bad hardware, bad disk or even a driver issue. The read errors can lead to unexpected result. I would be great if you burn an image on a cd-recorder /disc known to work properly and verify if the burned cd is properly written/read before installing. You can also use a daily image with a newer kernel, those are available on: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/is o-cd/ Also Debian 6.0 got an update: http://cdimage.debian.org/debian-cd/6.0.1a/i386/iso-cd/ -- Melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address. -- 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/7575324f915a05448800386f6ceaf3670e049...@aeromsg2.aero.ball.com
Processed: your mail
Processing commands for cont...@bugs.debian.org: reassign 620805 apt-setup Bug #620805 [debian-installer] installer hangs, while aptitude is waiting for input Bug reassigned from package 'debian-installer' to 'apt-setup'. Bug No longer marked as found in versions debian-installer/20090123lenny8. severity 620805 important Bug #620805 [apt-setup] installer hangs, while aptitude is waiting for input Severity set to 'important' from 'normal' merge 619751 620805 Bug#619751: debian-installer: should upgrade debian-archive-keyring from the main mirror before attemping to fetch from security Bug#620805: installer hangs, while aptitude is waiting for input Merged 619751 620805. thanks Stopping processing here. Please contact me if you need assistance. -- 620805: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620805 619751: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619751 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.1301950989567.transcr...@bugs.debian.org
Bug#620881: installation-guide: MAKEDEV script absence
Package: installation-guide Severity: normal On section D.3.4.1. Create device files cd /dev MAKEDEV generic The makedev command does not exist or its need has been deprecated(?) and therefore should be removed. if MAKEDEV is in use, then this should instead be applied to debootstrap(?) for not providing it. best regards, JC -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110404210627.10073.44761.reportbug@dell
Bug#618929: Additional info
On Monday 04 April 2011 20:59:40 Tremblay, Mike A wrote: It is certainly possible that my CD drive is flaky. Do you know of a diagnostic test in the Debian release that I could use to simply read several known good CDs for errors? For Debian CD images you can use md5sum for checking the integrity/authenticity of the CDs. For example, on the files in http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/ making: $ md5sum debian-testing-i386-netinst.iso must report the same as in the content of the MD5SUMS.small file in the same directory. -- Melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org -- 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/201104042226.41710.el...@debianpt.org
Bug#620888: flash-kernel: please add armhf support
Package: flash-kernel
Version: 2.40
Severity: normal
Hello,
Could you consider the following patch which adds armhf support?
diff --git a/debian/changelog b/debian/changelog
index 211acc7..b1fc18c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -22,6 +22,7 @@ flash-kernel (2.40) UNRELEASED; urgency=low
[ Hector Oron ]
* Add Efika Smartbook and Nettop support (Closes: #612376)
+ * Add armhf support
-- Hector Oron zu...@debian.org Mon, 04 Apr 2011 16:13:12 +0100
diff --git a/debian/control b/debian/control
index 465a495..8264e2d 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Vcs-Browser: http://git.debian.org/?p=d-i/flash-kernel.git
Vcs-Git: git://git.debian.org/d-i/flash-kernel.git
Package: flash-kernel
-Architecture: arm armel armeb
+Architecture: arm armel armeb armhf
Depends: ${misc:Depends}, devio, initramfs-tools (= 0.92f)
Suggests: uboot-mkimage
Description: utility to make certain embedded devices bootable
@@ -25,8 +25,8 @@ Package: flash-kernel-installer
Section: debian-installer
Priority: standard
XC-Package-Type: udeb
-Architecture: arm armel armeb
-XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x s3c24xx
+Architecture: arm armel armeb armhf
+XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x s3c24xx mx5
Provides: bootable-system
Depends: cdebconf-udeb, installed-base
XB-Installer-Menu-Item: 7300
Best regards,
-- Héctor Orón
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
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/20110404214115.10316.20344.reportbug@enorme.TCLDOMAIN.OFFICE
Debian installer build: failed or old builds
Debian installer build overview --- Failed or old builds: * OLD BUILD:armel Mar 23 10:01 joey@box build_iop32x_netboot http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_netboot.log * OLD BUILD:armel Mar 23 10:04 joey@box build_iop32x_network-console_glantank http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_network-console_glantank.log * FAILED BUILD: armel bMar 23 10:04/b joey@box build_iop32x_network-console_glantank http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_network-console_glantank.log * OLD BUILD:armel Mar 23 10:09 joey@box build_iop32x_network-console_n2100 http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_network-console_n2100.log * FAILED BUILD: armel bMar 23 10:09/b joey@box build_iop32x_network-console_n2100 http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_network-console_n2100.log * OLD BUILD:armel Mar 23 10:14 joey@box build_iop32x_network-console_ss4000e http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_network-console_ss4000e.log * FAILED BUILD: armel bMar 23 10:14/b joey@box build_iop32x_network-console_ss4000e http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_network-console_ss4000e.log * OLD BUILD:armel Mar 23 10:18 joey@box build_ixp4xx_network-console http://people.debian.org/~joeyh/d-i/armel/images/daily/build_ixp4xx_network-console.log * FAILED BUILD: armel bMar 23 10:18/b joey@box build_ixp4xx_network-console http://people.debian.org/~joeyh/d-i/armel/images/daily/build_ixp4xx_network-console.log * OLD BUILD:armel Mar 23 10:24 joey@box build_kirkwood_netboot http://people.debian.org/~joeyh/d-i/armel/images/daily/build_kirkwood_netboot.log * OLD BUILD:armel Mar 23 10:43 joey@box build_kirkwood_netboot-gtk http://people.debian.org/~joeyh/d-i/armel/images/daily/build_kirkwood_netboot-gtk.log * OLD BUILD:armel Mar 23 10:46 joey@box build_kirkwood_network-console http://people.debian.org/~joeyh/d-i/armel/images/daily/build_kirkwood_network-console.log * FAILED BUILD: armel bMar 23 10:46/b joey@box build_kirkwood_network-console http://people.debian.org/~joeyh/d-i/armel/images/daily/build_kirkwood_network-console.log * OLD BUILD:armel Mar 23 10:50 joey@box build_orion5x_network-console http://people.debian.org/~joeyh/d-i/armel/images/daily/build_orion5x_network-console.log * FAILED BUILD: armel bMar 23 10:50/b joey@box build_orion5x_network-console http://people.debian.org/~joeyh/d-i/armel/images/daily/build_orion5x_network-console.log * OLD BUILD:armel Mar 23 10:56 joey@box build_versatile_netboot http://people.debian.org/~joeyh/d-i/armel/images/daily/build_versatile_netboot.log * OLD BUILD:armel Mar 23 11:02 joey@box build_ads_cf http://people.debian.org/~joeyh/d-i/armel/images/daily/build_ads_cf.log Totals: 110 builds (6 failed, 11 old) -- 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/e1q6ucl-00033t...@ravel.debian.org
