Re: Custom driver image for etch
Op 09-04-2008 om 13:54 schreef Paul Civati: > I need to use a kernel module at install time and thereafter, > for a RAID card that isn't supported in the standard kernels. Please spent effort in a dialog with the manufacturer of the RAID card. Explain them that you what to use their product with Linux. > I could build a custom installer/kernel, but I'd really like > to only install the driver module so that the system can still > make use of the standard updated kernels. Presuming that any > apt upgraded kernels would not wipe out my custom driver. > > I see the debian-installer will load a driver image if I want, > but I can't find anywhere that says how to go about creating > one. > > So how do I go about creating a custom driver image? > > Or any other insight on how to load additional modules? I think that http://wiki.debian.org/DebianInstaller/Modify may help. > Preferably I would like this to be loadable during a PXE > initiated install. > > -Paul- Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475398: tasksel: add kerneloops to standard task
Joey Hess wrote: > Per Olofsson wrote: >> The default is to ask the user for permission before submitting anything. >> This >> is done by kerneloops-applet apparently. See /etc/kerneloops.conf. > > Does that only work in gnome? What about kde/xfce? I think it should work in all desktop environments, at least in theory. The applet is started from /etc/xdg/autostart/kerneloops-applet.desktop, which is desktop-independent. It doesn't use any Gnome libraries, and uses libnotify for notifying the user. I have not tested, though. -- Pelle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: syslinux vesamenu
On Thu, Aug 2, 2007 17:05:51 -0400, Joey Hess wrote: > Here's a version of d-i that uses the syslinux vesamenu, which > provides a nice menu of boot options. > > svn://svn.debian.org/d-i/people/joeyh/vesamenu/ > http://kitenet.net/~joey/tmp/mini.iso > > I think all the image types are fully working except for some > integration with debian-cd. > > The main problem with using the vesamenu is that qemu doesn't display > it right on boot, unless it's booted with -std-vga. Looks like the > video mode isn't set right without that. Unfortunatly, -std-vga breaks > the d-i framebuffer. (g-i is ok.) After fetching your SVN branch, updating the kernel version, and using qemu 9.1 from unstable, the menu looks good, and no framebuffer problems where to be found. Both with or without -std-vga. I think it would be a good addition for Etch. Maybe post-beta2, though. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Re: Custom driver image for etch
On Wednesday 09 April 2008, Paul Civati wrote: > I could build a custom installer/kernel, but I'd really like > to only install the driver module so that the system can still > make use of the standard updated kernels. Presuming that any > apt upgraded kernels would not wipe out my custom driver. > > I see the debian-installer will load a driver image if I want, > but I can't find anywhere that says how to go about creating > one. Basically you need to build your driver module against the kernel headers for the same kernel the installer uses (which is the -486 flavor of the i386 kernel) and make sure the ABI matches. So, if 'uname -a' in the installer gives you 2.6.18-6-486, you need to build your module against linux-headers-2.6.18-6-486. You can then just copy that module into the correct place under /lib/modules in the installer, run 'depmod -a' and 'modprobe '. Note that you will also need to build the module for the kernel flavor you intend to install for the target system and then before you reboot the system copy that into /target/lib/modules and chroot into /target to run depmod -a and update the initrd. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Custom driver image for etch
I looked at the cd-drivers.img, net-drivers-1.img, net-drivers-2.img images and I see that there are udeb packages, plus some additional files to indicate what the modules are, PCI device IDs and the like. I suppose what I'm asking really is, how do I build a udeb with my module, what additional files are needed in the image, and then, can I preseed that additional image? That seems an appropriate solution? -Paul- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Custom driver image for etch
Geert Stappers <[EMAIL PROTECTED]> wrote: > > I need to use a kernel module at install time and thereafter, > > for a RAID card that isn't supported in the standard kernels. > > Please spent effort in a dialog with the manufacturer of the RAID card. > Explain them that you what to use their product with Linux. Areca, and they are. Only the driver in 2.6.18 is older, and doesn't cater for a few newer models of their cards. > > So how do I go about creating a custom driver image? > > Or any other insight on how to load additional modules? > > I think that http://wiki.debian.org/DebianInstaller/Modify may help. I did look at this before, but it mostly seemed to detail how to rebuild the install boot images, which seemed quite long winded, where as I just wanted to generate an additional image. -Paul- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Custom driver image for etch
Frans Pop <[EMAIL PROTECTED]> wrote: > Basically you need to build your driver module against the kernel headers > for the same kernel the installer uses (which is the -486 flavor of the > i386 kernel) and make sure the ABI matches. So, if 'uname -a' in the > installer gives you 2.6.18-6-486, you need to build your module against > linux-headers-2.6.18-6-486. > > You can then just copy that module into the correct place under /lib/ > modules in the installer, run 'depmod -a' and 'modprobe '. > > Note that you will also need to build the module for the kernel flavor you > intend to install for the target system and then before you reboot the > system copy that into /target/lib/modules and chroot into /target to run > depmod -a and update the initrd. Thanks for the details. But is there really no way to automate this? I asked about an additional driver image because that way I can presumably set up a preseed to pull that in and do this all automatically. -Paul- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Custom driver image for etch
On Friday 11 April 2008, Paul Civati wrote: > I suppose what I'm asking really is, how do I build a udeb with > my module, what additional files are needed in the image, and > then, can I preseed that additional image? > > That seems an appropriate solution? It seems overly complex to me. Why not just put the modules on a webserver somewhere and then just use a preseed-early script to do wget and depmod? If that is done before Detect disks, then it should possibly even be loaded automatically. And then use a preseed-late script to do similar things for the target system. On the webserver you could even put the modules in a subdir based on the ABI so you know you'll get the correct version. If you really want to create a udeb for it, kernel-wedge is what we normally use to repackage a whole kernel into udebs, but that's not really suitable for creating an additional udeb for a single module. You can simply create a udeb manually using basic Debian packaging tools. There are plenty of simple examples in the D-I subversion source repository. The etch-support udeb is a relatively simple example. For general documentation about installer internals, see: http://d-i.alioth.debian.org/doc/talks/debconf6/paper/ Basically, there are many ways to do this. But if you want to do something complex, you'll need to invest the time to learn how yourself. If you do find something that works for you and is not documented yet, adding it to the wiki would be appreciated. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#475398: tasksel: add kerneloops to standard task
On Friday 11 April 2008, Per Olofsson wrote: > Joey Hess wrote: > > Per Olofsson wrote: > >> The default is to ask the user for permission before submitting > >> anything. This is done by kerneloops-applet apparently. See > >> /etc/kerneloops.conf. > > > > Does that only work in gnome? What about kde/xfce? > > I think it should work in all desktop environments, at least in theory. > The applet is started from /etc/xdg/autostart/kerneloops-applet.desktop, > which is desktop-independent. It doesn't use any Gnome libraries, and > uses libnotify for notifying the user. > > I have not tested, though. I installed it without problems on my KDE desktop. It's dependencies look sane (did not pull in any new packages in my case) and the default configuration is to ask to be allowed to submit. Only remaining question is how it works on systems that do not have a graphical environment installed, especially with the default of "ask". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475525: Failure to start after installation using grub
Package: installation-reports Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/20080410-2/i386/iso-cd/debian-testing-i386-netinst.iso Date: Apr 11 2008 01:00 UTC Machine: Pc clon Processor: PIV 2.4 ghz Memory: 1 gb Partitions: /dev/sda1jfsmounted as / /dev/sda3 xfsmouned as /home /dev/sda5 swap /dev/sda6 xfsmounted as /data Output of lspci -nn and lspci -vnn: ( I'll send it to you later ) I've two disk drives : - 80 gb serial ata ( initially detected as /dev/sda and after installation /dev/sdb ) - 40 gb ata-133 ( initially detected as /dev/hdc and after installation /dev/sda ) Base System Installation Checklist: [O] Initial boot: [O] Detect network card: [O] Configure network:[O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system: [O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader: [O] Overall install: [O] Comments/Problems: The problem is that after rebootig, grub boots ok, but then when it tries to start the system, it can't find the partition /dev/sda1 ( as it was detected at installation time ). What I found out was that the disk was now detected as /dev/sdb instead of /dev/sda. So I changed the parameter in grub ( "E" command ) and changed /dev/sda1 by /dev/sdb1. After that, it loads the kernel but the system can't find the other partitions ( /dev/sda3 /dev/sda5 - swap - /dev/sda6 ). At that moment, it is proposed to give root password for entering in maintenance mode, so I did it. Then I changed the contents of the /dev/fstab to match the new way the disk is detected ( /dev/sdb instead of /dev/sda ). I alsa have to change the configuration file of the resume to point to the "new" swap partition. After that the system works great. Regards. Facundo. Buenos Aires - Argentina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: syslinux vesamenu
Jérémy Bobbio <[EMAIL PROTECTED]> writes: > On Thu, Aug 2, 2007 17:05:51 -0400, Joey Hess wrote: >> Here's a version of d-i that uses the syslinux vesamenu, which >> provides a nice menu of boot options. >> >> svn://svn.debian.org/d-i/people/joeyh/vesamenu/ >> http://kitenet.net/~joey/tmp/mini.iso >> >> I think all the image types are fully working except for some >> integration with debian-cd. >> >> The main problem with using the vesamenu is that qemu doesn't display >> it right on boot, unless it's booted with -std-vga. Looks like the >> video mode isn't set right without that. Unfortunatly, -std-vga breaks >> the d-i framebuffer. (g-i is ok.) > > After fetching your SVN branch, updating the kernel version, and using > qemu 9.1 from unstable, the menu looks good, and no framebuffer problems > where to be found. Both with or without -std-vga. > > I think it would be a good addition for Etch. Maybe post-beta2, though. Lenny ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house."
Bug#475398: tasksel: add kerneloops to standard task
On Fri, Apr 11, 2008 at 01:38:30PM +0200, Frans Pop wrote: > I installed it without problems on my KDE desktop. It's dependencies look > sane (did not pull in any new packages in my case) and the default > configuration is to ask to be allowed to submit. > > Only remaining question is how it works on systems that do not have a > graphical environment installed, especially with the default of "ask". If you're not running a graphical interface, with the default of 'ask', nothing's going to listen for kerneloops dbus messages, so the daemon will never be signalled to send oopses. You can, of course, change the default in /etc/kerneloops.conf from 'ask' to 'always'. Do you think we need a debconf question to set this up? Or a note to let people know they can activate it? My opinion is that this will still be useful even if people with headless servers don't activate it. I think many more people encounter kernel bugs on desktop Debian machines than they do on servers. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473659: Can't open /dev/tty2: No such file or directory in d-i
* Martin Michlmayr <[EMAIL PROTECTED]> [2008-03-31 23:29]: > Can't open /dev/tty2: No such file or directory > Can't open /dev/tty3: No such file or directory > Can't open /dev/tty4: No such file or directory waldi, can you please upload the fix for this. Thanks. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475581: wrong paths in win32-loader.ini on mini.iso
Package: debian-installer Severity: normal The mini.iso puts all files in the root of the CD. But the win32-loader.ini contains: i386/linux=linux i386/initrd=initrd.gz That won't work.. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- see shy jo signature.asc Description: Digital signature
Re: syslinux vesamenu
Jérémy Bobbio wrote:
> After fetching your SVN branch, updating the kernel version, and using
> qemu 9.1 from unstable, the menu looks good, and no framebuffer problems
> where to be found. Both with or without -std-vga.
>
> I think it would be a good addition for Etch. Maybe post-beta2, though.
The svn branch is an old branch, the current one is in git,
ssh://git.debian.org/git/users/joeyh/d-i.git branch vesamenu
I've just brought it up-to-date with current trunk. Attached is a patch.
Also attached is a debian-cd patch to support the modified syslinux files.
I have not tested it, but have had luck with modifying this file w/o
testing before. ;-) Would someone like to try building CDs? There are
three cases that should be tested:
- i386 CD
- make sure it doesn't have amd64 menu entries..
- amd64 CD
- also shouldn't have amd64 menu entries (cause the normal
entries are amd64)
- i396+amd64 combined cd
- should have supplimental amd64 menu entries
This patch should also be safely backwards compatable for building CDs
from a d-i that lacks vesamenu.
--
see shy jo
diff --git a/installer/build/boot/x86/amd.cfg b/installer/build/boot/x86/amd.cfg
new file mode 100644
index 000..1def0a7
--- /dev/null
+++ b/installer/build/boot/x86/amd.cfg
@@ -0,0 +1,23 @@
+menu hshift 9
+menu width 57
+default64 amd64-install
+
+label amd64-install
+ menu label ^AMD64 install
+ kernel ${KERNEL}
+ append ${VIDEO_MODE} initrd=${INITRD} -- quiet ${CONSOLE}
+label amd64-expert
+ menu label AMD64 expert install
+ kernel ${KERNEL}
+ append priority=low ${VIDEO_MODE} initrd=${INITRD} -- ${CONSOLE}
+label amd64-rescue
+ menu label AMD64 rescue mode
+ kernel ${KERNEL}
+ append ${VIDEO_MODE} initrd=${INITRD} rescue/enable=true -- quiet ${CONSOLE}
+label amd64-auto
+ menu label AMD64 automated install
+ kernel ${KERNEL}
+ append auto=true priority=critical ${VIDEO_MODE} initrd=${INITRD} -- quiet ${CONSOLE}
+
+# Only present if gtk frontend is available.
+include ${SYSDIR}amdgtk.cfg
diff --git a/installer/build/boot/x86/amdgtk.cfg b/installer/build/boot/x86/amdgtk.cfg
new file mode 100644
index 000..8322487
--- /dev/null
+++ b/installer/build/boot/x86/amdgtk.cfg
@@ -0,0 +1,16 @@
+label amd64-installgui
+ menu label AMD64 graphical install
+ kernel ${KERNEL}
+ append ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} -- quiet ${CONSOLE}
+label amd64-expertgui
+ menu label AMD64 graphical expert install
+ kernel ${KERNEL}
+ append priority=low ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} -- ${CONSOLE}
+label amd64-rescuegui
+ menu label AMD64 graphical rescue mode
+ kernel ${KERNEL}
+ append ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} rescue/enable=true -- quiet ${CONSOLE}
+label amd64-autogui
+ menu label AMD64 graphical automated install
+ kernel ${KERNEL}
+ append auto=true priority=critical ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} -- quiet ${CONSOLE}
diff --git a/installer/build/boot/x86/boot.txt b/installer/build/boot/x86/boot.txt
deleted file mode 100644
index bcd16fc..000
--- a/installer/build/boot/x86/boot.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-${SYSDIR}splash.rle
-
-Press F1control and F then 1 for help, or ENTER to ${BOOTPROMPT}
diff --git a/installer/build/boot/x86/gtk.cfg b/installer/build/boot/x86/gtk.cfg
new file mode 100644
index 000..ff4b0ea
--- /dev/null
+++ b/installer/build/boot/x86/gtk.cfg
@@ -0,0 +1,16 @@
+label installgui
+ menu label ^Graphical install
+ kernel ${KERNEL}
+ append ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} -- quiet ${CONSOLE}
+label expertgui
+ menu label Graphical expert install
+ kernel ${KERNEL}
+ append priority=low ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} -- ${CONSOLE}
+label rescuegui
+ menu label Graphical rescue mode
+ kernel ${KERNEL}
+ append ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} rescue/enable=true -- quiet ${CONSOLE}
+label autogui
+ menu label Graphical automated install
+ kernel ${KERNEL}
+ append auto=true priority=critical ${VIDEO_MODE_GTK} initrd=${INITRD_GTK} -- quiet ${CONSOLE}
diff --git a/installer/build/boot/x86/menu.cfg b/installer/build/boot/x86/menu.cfg
new file mode 100644
index 000..354cba6
--- /dev/null
+++ b/installer/build/boot/x86/menu.cfg
@@ -0,0 +1,4 @@
+include ${SYSDIR}text.cfg
+include ${SYSDIR}gtk.cfg
+include ${SYSDIR}amd.cfg
+
diff --git a/installer/build/boot/x86/prompt.cfg b/installer/build/boot/x86/prompt.cfg
new file mode 100644
index 000..cd2957d
--- /dev/null
+++ b/installer/build/boot/x86/prompt.cfg
@@ -0,0 +1,15 @@
+prompt 1
+display ${SYSDIR}f1.txt
+timeout 0
+include ${SYSDIR}menu.cfg
+
+f1 ${SYSDIR}f1.txt
+f2 ${SYSDIR}f2.txt
+f3 ${SYSDIR}f3.txt
+f4 ${SYSDIR}f4.txt
+f5 ${SYSDIR}f5.txt
+f6 ${SYSDIR}f6.txt
+f7 ${SYSDIR}f7.txt
+f8 ${SYSDIR}f8.txt
+f9 ${SYSDIR}f9.txt
+f0 ${SYSDIR}f10.txt
diff --git a/installer/build/boot/x86/syslinux.cfg b/installer/build/boot/x86/syslinux.cfg
index 9b98daa..d11c447 100644
--- a/installer/build/boot/x86/syslinux.cfg
+++ b/installer/build/boot/x86/syslinux.cfg
@@ -1,34 +1,21 @@
-${SYSLINUX_SE
Bug#475581: marked as done (wrong paths in win32-loader.ini on mini.iso)
Your message dated Fri, 11 Apr 2008 15:39:09 -0400 with message-id <[EMAIL PROTECTED]> and subject line Re: Bug#475581: wrong paths in win32-loader.ini on mini.iso has caused the Debian Bug report #475581, regarding wrong paths in win32-loader.ini on mini.iso 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 [EMAIL PROTECTED] immediately.) -- 475581: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475581 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: debian-installer Severity: normal The mini.iso puts all files in the root of the CD. But the win32-loader.ini contains: i386/linux=linux i386/initrd=initrd.gz That won't work.. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- see shy jo signature.asc Description: Digital signature --- End Message --- --- Begin Message --- Joey Hess wrote: > Package: debian-installer > Severity: normal > > The mini.iso puts all files in the root of the CD. But the > win32-loader.ini contains: > > i386/linux=linux > i386/initrd=initrd.gz > > That won't work.. Er, am I wrong? I'm not very familiar with this config file. Looking at the one for the full CD, it has: i386/linux=install/vmlinuz i386/initrd=install/initrd.gz So hmm, guess I'm wrong, NM. -- see shy jo signature.asc Description: Digital signature --- End Message ---
Bug#475581: wrong paths in win32-loader.ini on mini.iso
On Fri, Apr 11, 2008 at 03:15:37PM -0400, Joey Hess wrote: > Package: debian-installer > Severity: normal > > The mini.iso puts all files in the root of the CD. But the > win32-loader.ini contains: > > i386/linux=linux > i386/initrd=initrd.gz > > That won't work.. This is correct AFAICS. "i386/linux" is not interpreted as a path, it's a constructed index name: ReadINIStr $linux $d\win32-loader.ini "installer" "$arch/$gtklinux" ReadINIStr $initrd$d\win32-loader.ini "installer" "$arch/$gtkinitrd" Did you find any odd/broken behaviour? -- Robert Millan I know my rights; I want my phone call! What use is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
base-installer_1.76etch1_amd64.changes ACCEPTED
Accepted: base-installer_1.76etch1.dsc to pool/main/b/base-installer/base-installer_1.76etch1.dsc base-installer_1.76etch1.tar.gz to pool/main/b/base-installer/base-installer_1.76etch1.tar.gz base-installer_1.76etch1_amd64.udeb to pool/main/b/base-installer/base-installer_1.76etch1_amd64.udeb Override entries for your package: base-installer_1.76etch1.dsc - required debian-installer base-installer_1.76etch1_amd64.udeb - required debian-installer Announcing to [EMAIL PROTECTED] Closing bugs: 469030 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-lvm_53etch1_amd64.changes ACCEPTED
Accepted: partman-lvm_53etch1.dsc to pool/main/p/partman-lvm/partman-lvm_53etch1.dsc partman-lvm_53etch1.tar.gz to pool/main/p/partman-lvm/partman-lvm_53etch1.tar.gz partman-lvm_53etch1_all.udeb to pool/main/p/partman-lvm/partman-lvm_53etch1_all.udeb Override entries for your package: partman-lvm_53etch1.dsc - standard debian-installer partman-lvm_53etch1_all.udeb - standard debian-installer Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469030: marked as done (debian ppc64 not booting after install)
Your message dated Fri, 11 Apr 2008 19:52:34 + with message-id <[EMAIL PROTECTED]> and subject line Bug#469030: fixed in base-installer 1.76etch1 has caused the Debian Bug report #469030, regarding debian ppc64 not booting after install 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 [EMAIL PROTECTED] immediately.) -- 469030: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469030 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: debian-40r3-powerpc-businesscard.iso Version: 40r3 powerpc64 Description: I installed debian 40r3 on a IBM Power 620 (7025-f0). The install was successful, but the system did not boot from the scsi disc, with the output shown below. Boot messages: Welcome to yaboot version 1.3.13 Enter "help" to get some basic usage information boot: Linux old boot: Linux Please wait, loading kernel... Elf32 kernel loaded... Loading ramdisk... ramdisk loaded at 0220, size: 5264 Kbytes OF stdout device is: /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] command line: root=/dev/sda4 ro console=ttyS0 memory layout at init: alloc_bottom : 02724000 alloc_top: alloc_top_hi : rmo_top : ram_top : Looking for displays alloc_down() called with mem not initialized EXIT called ok 0 > --- End Message --- --- Begin Message --- Source: base-installer Source-Version: 1.76etch1 We believe that the bug you reported is fixed in the latest version of base-installer, which is due to be installed in the Debian FTP archive: base-installer_1.76etch1.dsc to pool/main/b/base-installer/base-installer_1.76etch1.dsc base-installer_1.76etch1.tar.gz to pool/main/b/base-installer/base-installer_1.76etch1.tar.gz base-installer_1.76etch1_amd64.udeb to pool/main/b/base-installer/base-installer_1.76etch1_amd64.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Frans Pop <[EMAIL PROTECTED]> (supplier of updated base-installer package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 07 Mar 2008 12:37:42 +0100 Source: base-installer Binary: base-installer Architecture: source amd64 Version: 1.76etch1 Distribution: stable Urgency: low Maintainer: Debian Install System Team Changed-By: Frans Pop <[EMAIL PROTECTED]> Description: base-installer - Install the base system (udeb) Closes: 469030 Changes: base-installer (1.76etch1) stable; urgency=low . * powerpc: correctly recognize systems with 'RS64-IV (sstar)' cpu as powerpc64 (closes: #469030). Files: b584134882877745961f294a2519bc73 928 debian-installer required base-installer_1.76etch1.dsc b69b50a350d4c1baa1f6d80d8dd513b8 212086 debian-installer required base-installer_1.76etch1.tar.gz e483ad50b371ec4e59cdb7d8e82b00f3 167256 debian-installer required base-installer_1.76etch1_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH0Yrfgm/Kwh6ICoQRApa2AJkBUuWisBZL5tiwHSzKMCFC1un4XACeJlvm guGkVRuk6xeVVLy/Mjq+w6U= =j5U3 -END PGP SIGNATURE- --- End Message ---
Bug#475525: Failure to start after installation using grub
On Friday 11 April 2008, Facundo Ariel Perez wrote: > I've two disk drives : > - 80 gb serial ata ( initially detected as /dev/sda and after > installation /dev/sdb ) > - 40 gb ata-133 ( initially detected as /dev/hdc and after > installation /dev/sda ) > > Comments/Problems: > > The problem is that after rebootig, grub boots ok, but then when it > tries to start the system, it can't find the partition /dev/sda1 ( as > it was detected at installation time ). > What I found out was that the disk was now detected as /dev/sdb > instead of /dev/sda. This is a known issue described in the errata for both the stable release and the Lenny 1 release [1]. You found the correct way to deal with it, although you can potentially find yourself in the same situation again if the "wrong" driver should be loaded first. However, it seems that two different modules are claiming to support your IDE drive, which AFAIK should not happen, so the output of 'lspci -nn' would be very welcome. Cheers, FJP [1] http://www.debian.org/devel/debian-installer/errata -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475525: Failure to start after installation using grub
Here they go ... Regards. Facundo. El Friday 11 April 2008 16:56:57 Frans Pop escribió: > On Friday 11 April 2008, Facundo Ariel Perez wrote: > > I've two disk drives : > > - 80 gb serial ata ( initially detected as /dev/sda and after > > installation /dev/sdb ) > > - 40 gb ata-133 ( initially detected as /dev/hdc and after > > installation /dev/sda ) > > > > Comments/Problems: > > > > The problem is that after rebootig, grub boots ok, but then when it > > tries to start the system, it can't find the partition /dev/sda1 ( as > > it was detected at installation time ). > > What I found out was that the disk was now detected as /dev/sdb > > instead of /dev/sda. > > This is a known issue described in the errata for both the stable release > and the Lenny 1 release [1]. You found the correct way to deal with it, > although you can potentially find yourself in the same situation again if > the "wrong" driver should be loaded first. > > However, it seems that two different modules are claiming to support your > IDE drive, which AFAIK should not happen, so the output of 'lspci -nn' > would be very welcome. > > Cheers, > FJP > > [1] http://www.debian.org/devel/debian-installer/errata 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host [1039:0661] (rev 11) 00:01.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge) [1039:0003] 00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] [1039:0964] (rev 36) 00:02.5 IDE interface [0101]: Silicon Integrated Systems [SiS] 5513 [IDE] [1039:5513] (rev 01) 00:02.7 Multimedia audio controller [0401]: Silicon Integrated Systems [SiS] AC'97 Sound Controller [1039:7012] (rev a0) 00:03.0 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) 00:03.1 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) 00:03.2 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) 00:03.3 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 2.0 Controller [1039:7002] 00:04.0 Ethernet controller [0200]: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet [1039:0900] (rev 90) 00:05.0 IDE interface [0101]: Silicon Integrated Systems [SiS] SATA [1039:0181] (rev 01) 00:08.0 Multimedia video controller [0400]: Zoran Corporation ZR36057PQC Video cutting chipset [11de:6057] (rev 02) 01:00.0 VGA compatible controller [0300]: nVidia Corporation NV11 [GeForce2 MX/MX 400] [10de:0110] (rev b2) 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host [1039:0661] (rev 11) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:8113] Flags: bus master, medium devsel, latency 32 Memory at e000 (32-bit, non-prefetchable) [size=64M] Capabilities: Kernel driver in use: agpgart-sis Kernel modules: sis-agp 00:01.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge) [1039:0003] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: e000-efff Memory behind bridge: d6f0-d7ff Prefetchable memory behind bridge: d800-dfff Kernel modules: shpchp 00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] [1039:0964] (rev 36) Flags: bus master, medium devsel, latency 0 00:02.5 IDE interface [0101]: Silicon Integrated Systems [SiS] 5513 [IDE] [1039:5513] (rev 01) (prog-if 80 [Master]) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:810e] Flags: bus master, medium devsel, latency 128, IRQ 20 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at ffa0 [size=16] Capabilities: Kernel driver in use: pata_sis Kernel modules: pata_sis, sis5513 00:02.7 Multimedia audio controller [0401]: Silicon Integrated Systems [SiS] AC'97 Sound Controller [1039:7012] (rev a0) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:810f] Flags: bus master, medium devsel, latency 64, IRQ 23 I/O ports at d800 [size=256] I/O ports at dc00 [size=128] Capabilities: Kernel driver in use: Intel ICH Kernel modules: snd-intel8x0 00:03.0 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:810e] Flags: bus master, medium devsel, latency 64, IRQ 17 Memory at d6efc000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd Kernel modules: ohci-hcd 00:03.1 USB Controller [0c03]: Silicon Integr
Re: r52621 - in trunk/installer/build: config util
Joey Hess <[EMAIL PROTECTED]> writes: > Author: joeyh > Date: Fri Apr 11 18:29:30 2008 > New Revision: 52621 > > Log: > create localudebdir if it does not exist > > This aids building d-i from a git repo, as localudebs is not tracked by git > due to being an empty directory. > > > Modified: >trunk/installer/build/config/i386.cfg >trunk/installer/build/util/get-packages > > Modified: trunk/installer/build/config/i386.cfg > == > --- trunk/installer/build/config/i386.cfg (original) > +++ trunk/installer/build/config/i386.cfg Fri Apr 11 18:29:30 2008 > @@ -1,7 +1,7 @@ > MEDIUM_SUPPORTED = cdrom netboot netboot-gtk hd-media floppy #monolithic > > # The version of the kernel to use. > -KERNELVERSION = 2.6.24-1-486 > +KERNELVERSION = 2.6.25-rc7-486 > KERNELMAJOR = 2.6 > KERNEL_FLAVOUR = di > KERNELNAME = vmlinuz ... I guess it was commited by mistake. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r52621 - in trunk/installer/build: config util
Otavio Salvador <[EMAIL PROTECTED]> writes: > ... > > I guess it was commited by mistake. Sorry, didn't see you have reverted it already. Thanks anyway. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475639: Daily builds Lenny installer show "no installable kernel was found..."
Package: installation-reports Booting from CD using daily builds (11Apr-200) installer, when the installer are copying base packages, apper next meesage: "no installable kernel was found in the defined APT Sources" I check MD5 of my download iso and is OK, burn on CD appers OK My system is a HP Laptop dv2425 with SATA HDD, manual fdisk works fine in previous stages of setup, previously I was using lenny without problems
