Lenny installer string freeze status 20080912
10 days left before the end of the string freeze NEW for today: Progress for Wolof (sublevel 1) Progress for Punjabi (sublevels 3 and 4) Languages meeting the release criteria: 45 -- Already activated and complete for level 1: 41 Arabic, Bulgarian, Czech, German, Dzongkha, Greek, Spanish, Basque, Finnish, French, Galician, Gujarati, Hebrew, Hindi, Croatian, Indonesian, Italian, Japanese, Georgian, Khmer, Korean, Lithuanian, Malayalam, Marathi, Norwegian Bokmål, Nepali, Dutch, Norwegian Nynorsk, Polish, Portuguese, Brazilian Portuguese, Romanian, Russian, Slovak, Swedish, Tamil, Thai, Turkish, Vietnamese, Simplified Chinese, Traditional Chinese Already activated and complete for sublevels 1 and 2: 4 Belarusian, Esperanto, Hungarian, Punjabi Not yet activated languages complete for sublevels 1 and 2: 0 Languages failing to meet the release criteria: 32 -- Activated languages: 18 Amharic, Bengali, Bosnian, Catalan, Danish, Estonian, Kurdish, Latvian, Macedonian, Northern Sami, Slovenian, Albanian, Tagalog, Ukrainian, Wolof Not yet activated languages: 14 Afrikaans, Welsh, Persian, Irish, Armenian, Icelandic, Kazakh, Kannada, Malagasy, Malay, Serbian, Telugu, Urdu, Xhosa (chances to get these in lenny are quite low) If your language is listed in "failing to meet the release criteria", please do not scream out. For many of these languages, only very few translated strings are missing and the needed update is very small. But, still, do your best for this to happen. The D-I i18n documentation is available at http://d-i.alioth.debian.org/doc/i18n/ signature.asc Description: Digital signature
Re: di-netboot-assistant - Debian-Installer netboot assistant
Hello Franklin, On Wednesday 23 July 2008, Franklin PIAT wrote: > On Tue, 2008-07-22 at 16:49 +0200, Frans Pop wrote: > > With this dhcpd configuration both problems were fixed and I could > > use di-n-a without the workarounds. I have one more issue for you. I installed di-n-a on an Etch box (my DNS/DHCP/TFTP server runs stable), which means that debian-installer/pxelinux.0 is also taken from stable. I also installed a number of images, both stable and testing. When netbooting I would get your menu correctly, but after selecting a testing install, instead of the D-I syslinux screen I would get a completely white display. I solved this by copying the pxelinux.0 from the testing image to the debian-installer directory. Apparently pxelinux.0 only gets loaded once (which makes sense) and thus the one in the debian-installer dir needs to be compatible with _all_ the images installed below it. One possible solution to this would be to extract the version from pxelinux.0 files of images getting installed, check if that version is higher than the one of the current file in the debian-installer dir and then replace that with the higher version. You could for example use this to get the version: $ strings pxelinux.0 | \ sed -rn "/^PXELINUX [.0-9]+/ s/^[^ ]* ([.0-9]+).*/\1/" 3.71 > > I also have a feature request: support for custom images. > > If I build a netboot image locally, I'd like to be able to add it to > > the menu somehow. > > Main thing is that these cannot be added to the di-n-a sources config > > file as there is no download location for them, so I need some way to > > just extract them into place and get them included in the menus. > > > > I see several options. > > > > 1) I create a custom "top-level" menu file that I specify in the > > dhcpd config and that has as one option to chainload to the di-n-a > > menu. This will work and gives complete freedom but disadvantage is > > an extra menu level and needing to maintain the menu by hand. > > By hand... :-( One problem with this. When I tried that I found that you modify some paths inside downloaded images to make them fit inside your structure. This of course does not happen for custom built images if they are installed by hand. I managed to work around this by using symlinks from within your structure to the custom images, while keeping the original paths inside the images. I wonder if that might not be a more solid solution also for images that are downloaded by di-n-a. In general it's IMO not very nice to change things in "external" sources. Let me know if you need more info on this. It was a while ago but I should be able to reproduce it without too much trouble. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Fwd: Announcement of D-I releases
Resending as we did not get a reply from the publicity team on the first message. Please also see the replies from other D-I team members to the original message available at: http://lists.debian.org/debian-boot/2008/06/msg00381.html Please reply to both lists, not to me privately. Cheers, FJP -- Forwarded Message -- Hi Alexander and team, Up till now we've basically only announced D-I releases on our project homepage [1], on d-d-a [2] and via times.d.n [3]. A copy of the announcement has sometimes been sent to d-user. As you can see, basically the same announcement in all cases, which is possibly a bit boring :-) But we've not announced anything on d-news (main reason: too much hassle getting it there). The changelog we send to d-d-a is probably not really suitable for d-n, but a shorter version with a bit more explanation and a link to [1] could work. Note that D-I releases, even though they contain full sets of CDs and DVDs, are not _Debian_ beta releases or release candidates and that has to be made very clear to a less technical audience. They are D-I releases with a testing snapshot; pre-release testing is done to ensure installs work and there are no major immediately visible issues after reboot, but nothing further. What do you think? Should we contact you in the run up to future releases to coordinate announcements? If we want to do that, we should probably prepare some template in advance, for both Beta and RC D-I releases. The next release is likely to be our RC1 release. The main goal would be (from my personal PoV at least) to get more people to test releases, maybe emphasizing the need for feedback (in English!) on foreign language installs and non-standard architectures. What do other D-I team members think? Cheers, FJP P.S. Thx for the quick follow up on the D-I release with a DPN. Good timing! [1] http://www.debian.org/devel/debian-installer/News/2008/20080609 [2] http://lists.debian.org/debian-devel-announce/2008/06/msg2.html [3] http://times.debian.net/1252-Debian-Installer-Lenny-Beta-2-released --- signature.asc Description: This is a digitally signed message part.
Re: Fwd: Announcement of D-I releases
* Frans Pop ([EMAIL PROTECTED]) [080912 10:09]: > Up till now we've basically only announced D-I releases on our project > homepage [1], on d-d-a [2] and via times.d.n [3]. A copy of the > announcement has sometimes been sent to d-user. > As you can see, basically the same announcement in all cases, which is > possibly a bit boring :-) > > But we've not announced anything on d-news (main reason: too much hassle > getting it there). The changelog we send to d-d-a is probably not really > suitable for d-n, but a shorter version with a bit more explanation and a > link to [1] could work. note that in my "master plan" i would like to see such snapshots somewhat stabilized (as in "not too badly broken, usable", not as in "debian full blown release") and announced them publicly. the reasoning behind this is that a certain group of people seem to like to update and reinstall as often as they can to get the feeling of maximum up-to-date-ness. And debian (as it has testing, anyway) can satisfy their demand easier, as in passing. I envision drop-in artwork packages that gives those snapshots a new look even, featuring a consistant suite of themes between stable releases. bottomline: make those snapshots vaguely predictable, ask the release team to prevent testing to be too badly broken, drop in a new look and feel and announce it much better, more visible. /andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di-netboot-assistant - Debian-Installer netboot assistant
Hello, Since I now have an account on Alioth, I was considering to host it there. Does "collab-maint/di-netboot-assistant.git" seems fine for you ? Franklin P.S. I am now subscribed to the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di-netboot-assistant - Debian-Installer netboot assistant
Hello Frans, On Fri, 2008-09-12 at 10:04 +0200, Frans Pop wrote: > On Wednesday 23 July 2008, Franklin PIAT wrote: > > On Tue, 2008-07-22 at 16:49 +0200, Frans Pop wrote: > > > With this dhcpd configuration both problems were fixed and I could > > > use di-n-a without the workarounds. > > I have one more issue for you. > > I installed di-n-a on an Etch box (my DNS/DHCP/TFTP server runs stable), > which means that debian-installer/pxelinux.0 is also taken from stable. Obviously, running stable on the server side is the right thing to do. > I also installed a number of images, both stable and testing. We can expect that some sysadmins will want to test installing stable+1 in advance, so I consider this the standard situation too. > When netbooting I would get your menu correctly, but after selecting a > testing install, instead of the D-I syslinux screen I would get a > completely white display. >From your point of view is this an RC bug ? (I do) > I solved this by copying the pxelinux.0 from the testing image to the > debian-installer directory. Apparently pxelinux.0 only gets loaded once > (which makes sense) and thus the one in the debian-installer dir needs to > be compatible with _all_ the images installed below it. > > One possible solution to this would be to extract the version from > pxelinux.0 files of images getting installed, check if that version is > higher than the one of the current file in the debian-installer dir and > then replace that with the higher version. > > You could for example use this to get the version: > $ strings pxelinux.0 | \ > sed -rn "/^PXELINUX [.0-9]+/ s/^[^ ]* ([.0-9]+).*/\1/" > 3.71 Do you think it would be a good idea to use : tr -c '[:print:] ' '\n' instead of "strings", in order to avoid depending on binutils for production servers ? (popcon says that binutils is installed on 87% of the systems... but the figure for dhcp/tftp enabled servers is probably much lower). > > > I also have a feature request: support for custom images. > > > If I build a netboot image locally, I'd like to be able to add it to > > > the menu somehow. > > > Main thing is that these cannot be added to the di-n-a sources config > > > file as there is no download location for them, so I need some way to > > > just extract them into place and get them included in the menus. > > > > > > I see several options. > > > > > > 1) I create a custom "top-level" menu file that I specify in the > > > dhcpd config and that has as one option to chainload to the di-n-a > > > menu. This will work and gives complete freedom but disadvantage is > > > an extra menu level and needing to maintain the menu by hand. > > > > By hand... :-( > > One problem with this. > > When I tried that I found that you modify some paths inside downloaded > images to make them fit inside your structure. This of course does not > happen for custom built images if they are installed by hand. > > I managed to work around this by using symlinks from within your structure > to the custom images, while keeping the original paths inside the images. I still have your request to use local images on my TODO list. If you install/extract a boot image manually, I suppose that it would work if it were extracted at the top, like : /var/lib/tftpboot/debian-installer/i386/pxelinux.0 > I wonder if that might not be a more solid solution also for images that > are downloaded by di-n-a. I will need to think about it, but the reason why I need to tweak the patch is that the image's version isn't included in the paths. So I have to replace: kernel debian-installer/i386/linux with : kernel debian-installer/etch/i386/linux or kernel debian-installer/lenny/i386/linux so I can have the two installed simultaneously. I must say that I'm much more comfortable with the way I handle elilo's menu. > In general it's IMO not very nice to change things in "external" sources. Generally speaking, the di-n-a shipped is Lenny is based on a script I used for myself. So it tweaks existing etch/lenny images. I want something robust for Lenny+1 : Not guessing anything; Don't tweak configuration files (except boot arguments), consistent architectures handling... Regards, Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di-netboot-assistant - Debian-Installer netboot assistant
On Friday 12 September 2008, Franklin PIAT wrote: > > You could for example use this to get the version: > > $ strings pxelinux.0 | \ > > sed -rn "/^PXELINUX [.0-9]+/ s/^[^ ]* ([.0-9]+).*/\1/" > > 3.71 > > Do you think it would be a good idea to use : > tr -c '[:print:] ' '\n' > instead of "strings", in order to avoid depending on binutils for > production servers ? (popcon says that binutils is installed on 87% of > the systems... but the figure for dhcp/tftp enabled servers is probably > much lower). Up to you. strings was just the first thing that came to mind for me. There may even be smarter ways to do it. I don't know. > I still have your request to use local images on my TODO list. I'll leave you to play around with it a bit. It would be nice if custom images could be assigned a class though (I mean a similar identification to e.g. stable) and if multiple such classes could be used. > I want something robust for Lenny+1 : Not guessing anything; Don't > tweak configuration files (except boot arguments), consistent > architectures handling... Yes, there's also always the risk that we'll restructure the location where images can be found, so having some kind of configuration file for that would be nice. signature.asc Description: This is a digitally signed message part.
Re: di-netboot-assistant - Debian-Installer netboot assistant
Franklin PIAT <[EMAIL PROTECTED]> writes: > I will need to think about it, but the reason why I need to tweak the > patch is that the image's version isn't included in the paths. So I have > to replace: > kernel debian-installer/i386/linux > with : > kernel debian-installer/etch/i386/linux > or > kernel debian-installer/lenny/i386/linux > so I can have the two installed simultaneously. > > I must say that I'm much more comfortable with the way I handle elilo's > menu. kernel lenny/debian-installer/i386/linux Would be a solution no? -- 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: Help testing syslinux
On 09/09/2008, Michal Suchanek <[EMAIL PROTECTED]> wrote: > On 09/09/2008, Chris Lamb <[EMAIL PROTECTED]> wrote: > > Michal Suchanek wrote: > > > > > However, the syslinux on the broken CD is also version 3.71. I wonder > > > what's going on here. > > > > > > You will have to be more precise; there are both broken and fixed.versions > > of syslinux with that version prefix. The syslinux on the 50M test ISOs is > > 2:3.71+dfsg-3, which is already in testing. > > > > > I will try to rebuild once more to be sure but it looks like the > syslinux I have installed is also dfsg-3. > I must have built the image just before a round of updates. It took quite a few modifications to rebuild, and the new image now works. Thanks Michal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di-netboot-assistant - Debian-Installer netboot assistant
On Friday 12 September 2008, Franklin PIAT wrote: > Since I now have an account on Alioth, I was considering to host it > there. > > Does "collab-maint/di-netboot-assistant.git" seems fine for you ? Seems fine. It could also be added to D-I SVN though and even be built as part of Debian Installer, as Joey suggested some time ago [1]. [1] http://lists.debian.org/debian-boot/2008/07/msg00235.html signature.asc Description: This is a digitally signed message part.
Re: di-netboot-assistant - Debian-Installer netboot assistant
On Fri, 2008-09-12 at 15:01 +0200, Frans Pop wrote: > On Friday 12 September 2008, Franklin PIAT wrote: > > Since I now have an account on Alioth, I was considering to host it > > there. > > > > Does "collab-maint/di-netboot-assistant.git" seems fine for you ? > > Seems fine. > > It could also be added to D-I SVN though and even be built as part of > Debian Installer, as Joey suggested some time ago [1]. That would be fine for me too. What should I do / Who should I ask ? Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di-netboot-assistant - Debian-Installer netboot assistant
On Fri, 2008-09-12 at 09:39 -0300, Otavio Salvador wrote: > Franklin PIAT <[EMAIL PROTECTED]> writes: > > > I will need to think about it, but the reason why I need to tweak the > > patch is that the image's version isn't included in the paths. So I have > > to replace: > > kernel debian-installer/i386/linux > > with : > > kernel debian-installer/etch/i386/linux > > or > > kernel debian-installer/lenny/i386/linux > > so I can have the two installed simultaneously. > > > > I must say that I'm much more comfortable with the way I handle elilo's > > menu. > > kernel lenny/debian-installer/i386/linux > > Would be a solution no? IIRC : That would only work if the DHCP directly points to : lenny/debian-installer/i386/pxelinux.0 Pxelinux.0 would then fetch it's files, relatively to it's it's own location (actually, I think it's the NIC' ROM that would do it). The problem with di-n-a's top menu, it's that pxelinux.0 must be at the top. Therefore configuration files must be rewritten to add "etch" somewhere in the path. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
sorry for the late dropin, haven't seen that before today #498712 came in. which clearly shows the uglyness of the current situation, why should the same variable be set on *two* places. On Mon, 25 Aug 2008, Frans Pop wrote: > On Monday 25 August 2008, Martin Michlmayr wrote: > > - the question was not asked (because debconf priority > medium) > > That would break the case where the architecture default if different from > the default of initramfs-tools. > > > - the policy is the same as the default of initramfs-tools (most) > > I thought about that, but that assumes the default of initramfs-tools > won't ever change. I'd prefer not to base code on that assumption. it won't change. initramfs-tools per default has the concept of generating an allmost generic initramfs. i'm happy with d-i setting it for specific embedded arch, but please drop that file when it is useless. as tbm said ($RET != "most") is easy to check. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498710: lenny install created etch sources.list
On Friday 12 September 2008, Jay Berkenbilt wrote: > Comments/Problems: > I have a local debian mirror. When I configured apt, I selected it > from the installation menu. The resulting /etc/apt/sources.list file > was configured for etch even though I used the lenny installer image. Are you sure that the symlinks of your mirror in debian/dists/ are correct? Sounds like you did not update them when etch became stable... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498710: lenny install created etch sources.list
Frans Pop <[EMAIL PROTECTED]> wrote: > On Friday 12 September 2008, Jay Berkenbilt wrote: >> Comments/Problems: >> I have a local debian mirror. When I configured apt, I selected it >> from the installation menu. The resulting /etc/apt/sources.list file >> was configured for etch even though I used the lenny installer image. > > Are you sure that the symlinks of your mirror in debian/dists/ are > correct? Sounds like you did not update them when etch became stable... Jackpot. That's it. Thanks. drwxr-sr-x 5 root root 101 Jan 6 2007 etch/ drwxr-sr-x 5 root root 101 Apr 21 2007 lenny/ drwxrwsr-x 5 root root 101 Jan 6 2007 sid/ lrwxrwxrwx 1 root root 5 Jul 17 2007 stable -> sarge lrwxrwxrwx 1 root root 4 Jul 17 2007 testing -> etch lrwxrwxrwx 1 root root 3 Jul 17 2007 unstable -> sid I will fix my links and also add this to my installation check list. Feel free to close the installation report. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498710: marked as done (lenny install created etch sources.list)
Your message dated Fri, 12 Sep 2008 17:40:13 +0200 with message-id <[EMAIL PROTECTED]> and subject line Re: Bug#498710: lenny install created etch sources.list has caused the Debian Bug report #498710, regarding lenny install created etch sources.list 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.) -- 498710: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498710 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- X-Debbugs-CC: [EMAIL PROTECTED] Package: installation-reports Boot method: grub, hard drive Image version: lenny daily image, vmlinuz, gtk/initrd.gz from "other images", 2008-09-06 14c952393386b41fd358b343267a3007 vmlinuz 5d476f9962126e3f8530fe374a49880c gtk-initrd.gz Date: September 6, 2008 Machine: Dell Latitude D810 Processor: Pentium M, 2 GHz Memory: 1 GB Partitions: FilesystemType 1K-blocks Used Available Use% Mounted on /dev/mapper/vg1-lenny--root xfs 6281216 4800960 1480256 77% / tmpfstmpfs 517972 0517972 0% /lib/init/rw udev tmpfs 1024096 10144 1% /dev tmpfstmpfs 517972 0517972 0% /dev/shm /dev/sda2 ext3 46665 21168 23088 48% /boot /dev/mapper/vg1-home xfs15718400 14671360 1047040 94% /home /dev/mapper/vg1-u1 xfs 1038336 4428 1033908 1% /u1 - Disk /dev/sda: 60.0 GB, 60011642880 bytes 255 heads, 63 sectors/track, 7296 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x41ab2316 Device Boot Start End Blocks Id System /dev/sda1 1 7 561966 FAT16 /dev/sda2 * 8 13 48195 83 Linux /dev/sda3 141473117274507 HPFS/NTFS /dev/sda41474729646773247+ 8e Linux LVM - LV VG Attr LSize Origin Snap% Move Log Copy% Convert etch-root vg1 -wi-a- 6.00G home vg1 -wi-ao 15.00G lenny-root vg1 -wi-ao 6.00G swap vg1 -wi-ao 2.00G u1 vg1 -wi-ao 1.00G - Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590] (rev 03) Kernel modules: intel-agp 00:01.0 PCI bridge [0604]: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port [8086:2591] (rev 03) Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:1c.0 PCI bridge [0604]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 [8086:2660] (rev 03) Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:1d.0 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658] (rev 03) Kernel driver in use: uhci_hcd Kernel modules: uhci-hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 [8086:2659] (rev 03) Kernel driver in use: uhci_hcd Kernel modules: uhci-hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 [8086:265a] (rev 03) Kernel driver in use: uhci_hcd Kernel modules: uhci-hcd 00:1d.3 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 [8086:265b] (rev 03) Kernel driver in use: uhci_hcd Kernel modules: uhci-hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c] (rev 03) Kernel driver in use: ehci_hcd Kernel modules: ehci-hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev d3) 00:1e.2 Multimedia audio controller [0401]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller [8086:266e] (rev 03) Kernel driver in use: Intel ICH Kernel modules: snd-intel8x0 00:1e.3 Modem [0703]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller [8086:266d] (rev 03) Kernel driver in use: Intel ICH Modem Kernel modules: snd-intel8x0m 00:1f.0 ISA bridge [0601]: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge [8086:2641] (rev 03) Kernel modules: intel-rng, iTCO_wdt 00:1f.2 IDE interface [0101]: Intel Corporation 82801FBM (ICH6M) SATA Controller [8086:2653] (rev 03) Kernel driver in use: ata_piix Kernel modules: ahci, ata_piix 01:00.0 VGA compatible controller [0300]: ATI Techno
Bug#498568: Debian cannot be installed on bootable SD cards
Hi Frans, On Thu, Sep 11, 2008 at 02:15:11PM +0200, Frans Pop wrote: > On Thursday 11 September 2008, Harald Welte wrote: > > The distribution installation initrd needs to > > 1. include and auto-load the sdhc.ko and sdhci_pci.ko kernel modules > > Including these modules is a trivial change. However, it does not make > sense to do so until the installer supports installing to an SD card. I agree. > Auto-loading is a non-issue for Debian-Installer. If the kernel/udev > supports the device that will just work. (And I know it does work as the > module gets loaded fine on my laptop.) good. > > 2. create the /dev/mmcblk* device nodes as per udev/hotplug events > > Not an issue. Should just work. good. I was not aware how much of the 'regular linux system' udev/hotplug magic you have in the installer initrd. > > The actual distribution installation program needs to > > 1. recognize /dev/mmcblk* as block devices that can be used as > >target device > > This is the main issue. As Debian Installer uses libparted for > partitioning the real question is whether or not libparted supports these > devices. If that is true then very minor adjustments in partman should > suffice to support partitioning them. I quickly browsed/grepped through the source code of libparted, and I didn't see anything regarding device names. It just opens whatever block device was specified and works with it. If I use the 'parted' program on my debian unstable system here with a SDHCI compliant card reader + 2GB SD card, I get: prithivi:~# parted /dev/mmcblk0 GNU Parted 1.8.8 Using /dev/mmcblk0 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: Unknown (unknown) Disk /dev/mmcblk0: 2013MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 131kB 2013MB 2013MB primary fat16 So it just works fine. > > 2. use a grub-install or similar program that can discover the bios > > drive number to /dev/mmcblk* device name mapping > > This is essentially outside the scope of the installer itself. Once grub > (or grub2) supports the devices the installer should need at most minor > changes in its grub-installer component. Grub support is thus a > pre-requirement for adding support in the installer. grub itself (the actual bootloader) has no problem. grub2 supports /dev/mmcblk* out of the box However, the old grub1 needs a one-line fix to the grub-install shellscript. I have sent a trivial patch to the grub developers, but they rejected it since grub1 is no longer maintained. So if Debian (or any other distribution) keeps shipping grub1, they would have to add the small patch from http://savannah.gnu.org/bugs/download.php?file_id=16416 > Main thing to get support in Debian Installer is to find someone who has > both the hardware and the motivation to work on this. As said before, the > actual changes in D-I itself should be trivial. I can help with actual testing on the hardware. Right now VIA has too few development boards internally to send them out to developers, sorry. However, I have read that the eeePC or at least some of its models support SD-boot, too. If that is the case, there should be plenty people out there with access to the hardware. Also, to add the support for installing on SD card, you don't actually need a bios that can boot it. As long as you can partition, format and install the dpkg's on the SD card, and you can put grub onto the card, everything should be fine. > If someone were to sponsor or loan me an SD card, I'd be happy to check if > libparted supports it and, if it does, do the needed partman changes. the actual SD card is certainly not a problem. 2GB cards are around 5 EUR these days (at least here in Taiwan), so less than the actual shipping cost. I'm happy to do a wire transfer to any account on the EU to enable you to buy a card :) -- - Harald Welte <[EMAIL PROTECTED]> http://linux.via.com.tw/ VIA Open Source Liaison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
