Bug#774987: xfce cd lacks gnome-keyring, so network-manager cannot connect to many networks
Package: debian-cd Severity: normal gnome-keyring is a recommend of network-manager-gnome. While network-manager-gnome is included on the xfce CD, gnome-keyring is not. It should be. I noticed this when installing stable, but testing appears to also have the problem. An install from the xfce CD w/o network will result in an installed system that lacks gnome-keyring. When attempting to connect to a wifi network that needs a password, network-manager will immediately fail, and display a very non-useful "the network connection has been disconnected" alert. Many users at this point will be stuck and not able to figure out why their system is broken. Adding gnome-keyring as a depend to tasks that include network-manager-gnome would be one way to solve this, if fixing the debian-cd recommends resolution code is intractable. It would probably be a good idea to compare installs from CD with and w/o network, and see what recommended packages get left off. There are likely other land-mines like this one lurking. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: Digital signature
Re: desktop media size
Actually, I agree that making CD-1 not default to the regular default desktop is confusing, so instead: debian-8.0.0-amd64-CD-1.iso debian-8.0.0-amd64-CD-2.iso [etc] debian-8.0.0-amd64-xfce+lxde+mate-CD.iso debian-8.0.0-amd65-light-desktop-CD.iso -> debian-8.0.0-amd64-xfce+lxde+mate-CD.iso debian-8.0.0-amd64-DVD-1.iso debian-8.0.0-amd64-DVD-2.iso [etc] debian-8.0.0-amd64-gnome+cinnamon-DVD.iso -> debian-8.0.0-amd64-DVD-1.iso debian-8.0.0-amd64-desktop-DVD.iso -> debian-8.0.0-amd64-gnome+cinnamon-DVD.iso debian-8.0.0-amd64-kde-DVD.iso -- see shy jo signature.asc Description: Digital signature
Re: desktop media size
Adding cinnamon to gnome looks to add around 20 mb of debs. Maybe something like: debian-8.0.0-amd64-CD-1.iso debian-8.0.0-amd64-CD-2.iso [etc] debian-8.0.0-amd64-xfce+lxde+mate-CD.iso -> debian-8.0.0-amd64-CD-1.iso debian-8.0.0-amd65-light-desktop-CD.iso -> debian-8.0.0-amd64-xfce+lxde+mate-CD.iso debian-8.0.0-amd64-DVD-1.iso debian-8.0.0-amd64-DVD-2.iso [etc] debian-8.0.0-amd64-gnome+cinnamon-DVD.iso -> debian-8.0.0-amd64-DVD-1.iso debian-8.0.0-amd64-desktop-DVD.iso -> debian-8.0.0-amd64-gnome+cinnamon-DVD.iso debian-8.0.0-amd64-kde-DVD.iso -- see shy jo signature.asc Description: Digital signature
Re: desktop media size
Steven Chamberlain wrote: > I tried to get some figures on kfreebsd-amd64 (where XFCE is still the > default for now) using the tools from debian-cd.git, hacked to generate > a jessie CD-1 packagelist without a full mirror available. If these > results are correct, it looks rather promising: > * required stuff for CD1, no full desktop: 819 packages / 357 MiB > * LXDE: 926 packages / 413 MiB > * MATE: 954 packages / 468 MiB > * XFCE: 946 packages / 433 MiB > > Since LXDE is so small, and MATE and XFCE share many components, I think > it is even viable (at least on kfreebsd) to fit all three onto one CD! > (1049 packages / 507 MiB) > > Since MATE images don't exist yet, perhaps an LXDE+MATE+XFCE CD-ROM > would be sufficient, and saves having to produce yet another image type? > On kfreebsd we may not care to have CD-1, 2, 3 etc. any more if we had > such a disc (but still having a DVD-1 for the default desktop, of course). Yeah, it looks like adding MATE to XFCE may only add 70 mb or so of debs. That's a good idea! For such a CD, it makes sense for debian-cd to pass desktop=xfce (or perhaps mate). Tasksel will then default to mate, and let the user choose from the other available desktop environments[1], either the limited set included on the CD, or the full set available from the mirror. It might be pretty reasonable to make such a CD be CD #1. Unless it would be too confusing to make that CD default to a different desktop than the DVDs do. -- see shy jo [1] Although tasksel does not currently make lxde or cinnamon choices visible in its task list. TBD signature.asc Description: Digital signature
Bug#762613: use /usr/lib/tasksel/default_desktop to find per-arch default
Package: debian-cd Severity: normal tools/boot/jessie/common.sh looks for the first desktop task in the Recommends of task-desktop to get the default. That will still work, but it would be better if it sourced /usr/lib/tasksel/default_desktop and passed an architecture name to default_desktop_for_arch to get back the name of the desktop. This is intended to be a stable API, that allows different defaults for different arches. Currently, kfreebsd and hurd default to xfce, not gnome. -- see shy jo signature.asc Description: Digital signature
Bug#762487: desktop selection changes
Package: debian-cd
Severity: important
Changes to desktop selection in tasksel and recently to d-i are going to
need updates to debian-cd. The attached patch might work, or at least
point in the right direction.
--
see shy jo
From 723ae4c5fb37461863d2312cfb25a201e7594cfd Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 22 Sep 2014 15:14:47 -0400
Subject: [PATCH] adapt desktop handling for tasksel/d-i changes
tasksel now allows selecting the desktop, and d-i has dropped the boot menu
desktop selection. This patch attempts to update debian-cd for these
changes, removing the desktop boot menus from the CDs.
CD images for specific desktops (xfce/kde/mate/etc) should still override
the default tasksel desktop.
untested
---
tools/boot/jessie/boot-x86 | 14 +
tools/boot/jessie/common.sh | 4 +-
tools/boot/jessie/x86-desktop.sh | 109 +--
3 files changed, 5 insertions(+), 122 deletions(-)
diff --git a/tools/boot/jessie/boot-x86 b/tools/boot/jessie/boot-x86
index df42c96..e42dee0 100644
--- a/tools/boot/jessie/boot-x86
+++ b/tools/boot/jessie/boot-x86
@@ -150,19 +150,16 @@ extra_image () {
done
}
-# If multiple desktops are to be supported, set the default one
-ORIG_DESKTOP=
case "$DESKTOP" in
$UNSPEC_DESKTOP_DEFAULT)
# default from tasksel
DESKTOP=
;;
all)
- ORIG_DESKTOP=$DESKTOP
+ # default from tasksel
DESKTOP=
;;
light)
- ORIG_DESKTOP=$DESKTOP
DESKTOP=xfce
;;
esac
@@ -377,14 +374,7 @@ if [ -n "$KERNEL_PARAMS" ]; then
done
fi
-case "$ORIG_DESKTOP" in
- all)
- modify_for_all_desktop ;;
- light)
- modify_for_light_desktop ;;
- *)
- modify_for_single_desktop ;;
-esac
+set_default_desktop
# Add autorun
if [ -f boot$N/setup.exe ]; then
diff --git a/tools/boot/jessie/common.sh b/tools/boot/jessie/common.sh
index a09c8af..8a38b09 100644
--- a/tools/boot/jessie/common.sh
+++ b/tools/boot/jessie/common.sh
@@ -27,8 +27,8 @@ UNSPEC_DESKTOP_DEFAULT="$($BASEDIR/tools/apt-selection cache depends task-deskto
exit
}')"
-# Only i386 and amd64 support desktop selection with the 'light' and 'all'
-# desktops; make sure other arches get a working config
+# Only i386 and amd64 use DESKTOP to set the default desktop;
+# make sure other arches get a working config
if [ "$ARCH" != i386 ] && [ "$ARCH" != amd64 ]; then
if [ "$DESKTOP" = all ] || [ "$DESKTOP" = "$UNSPEC_DESKTOP_DEFAULT" ] ; then
DESKTOP=
diff --git a/tools/boot/jessie/x86-desktop.sh b/tools/boot/jessie/x86-desktop.sh
index 8560d67..707c0f8 100644
--- a/tools/boot/jessie/x86-desktop.sh
+++ b/tools/boot/jessie/x86-desktop.sh
@@ -26,10 +26,6 @@ multiarch_workaround() {
boot$N/isolinux/amdtxt.cfg || true
sed -i "/^include menu.cfg/ a\include instsel.cfg" \
boot$N/isolinux/prompt.cfg
- if [ -e boot$N/isolinux/desktop/prompt.cfg ]; then
- sed -i "/^default install/ a\include instsel.cfg" \
- boot$N/isolinux/desktop/prompt.cfg
- fi
cat >boot$N/isolinux/instsel.cfg <boot$N/isolinux/menu.cfg <
signature.asc
Description: Digital signature
Re: new tasksel
Andrew M.A. Cater wrote: > Is there any scope/space for this: essentially only a tiny step up from what > you'd get by installing using a netinst > without a mirror? Un-select everything in tasksel. (Also, this thread is not about random suggestions or user support.) -- see shy jo signature.asc Description: Digital signature
Re: new tasksel
Steven Chamberlain wrote: > Init system? > ... sysvinit > ... upstart > ... OpenRC Note that my email was meant to alert people who need to do work to do it, not to solicit way-down-the-slippery-slope suggestions that can be rejected out of hand by looking at the description of TASKsel. -- see shy jo signature.asc Description: Digital signature
new tasksel
I have made some significant changes to tasksel, that will need changes elsewhere. I plan to upload this to unstable pretty soon, feedback permitting. Some of the more popular desktop environments are individually selectable in tasksel, in a little sub-menu. (Of course that's displayed suboptimally due to debconf, wah.) (There is still, obviously, a default desktop.) Parts of the syslinux boot menus are obsoleted (though not actually broken) by the above change and should be removed. Which will also probably mean changing the installation manual too. debian-cd also has some isolinux menus for desktop selection that can be removed now. Note that I kept the tasksel/desktop preseed working, so debian-cd can continue to use it for non-default-desktop CDs. Most of the server tasks were not well enough defined or useful and so were removed. I kept ssh-server, print-server, and web-server. This may need documentation updates somewhere. No translatable strings were changed so far, but I would like to change "Debian desktop environment" to "Desktop environment", because that would make the display look better: │[*] Desktop environment │ │[*] ... Xfce│ │[ ] ... GNOME │ │[ ] ... KDE │ There's room to add a limited number of blends type tasks, but this will be up to the blends people to put together patches for. The menu only has 8 out of 10 slots used now, and my feeling is that a modest amount of hierarchy here can allow adding slightly more choices to the menu without it descending into unusable chaos. So, perhaps something like this, although I am unsure of the names. │[ ] Debian pure blends │ │[ ] ... Debian Edu │ │[ ] ... Debian Med │ │[ ] ... DebiChem│ │[ ] Openstack │ │[ ] ... Compute Node│ │[ ] ... Proxy Node │ -- see shy jo, for fjp signature.asc Description: Digital signature
desktop media size
I'd like to get a statement from the CD team for this page -- https://wiki.debian.org/DebianDesktop/Requalification/Jessie Which asks, for each desktop: Does the desktop fit on the media (CD(?), DVD, usb) we want to be able to contain a complete desktop environment? --- My feeling as a somewhat member of the CD team is that, if the default desktop is gnome, we can make a gnome DVD which is also suitable size for a small USB key (4 gb), and there is not any point in having a single CD that doesn't fit all of gnome. While if the default desktop is xfce, we might be able to cram it all into one CD (does it still fit?). -- see shy jo signature.asc Description: Digital signature
Re: Bug#485586: debian-installer: Default to graphical install
Didier 'OdyX' Raboud wrote: > Now, the ideal would be to use syslinux' ifcpu/ifcpu64 c32 modules to > determine the menu order depending on the machine (see [0]): no "64 bit" > option on 32 bit machines, "hidden or down the menu" "32 bit" option on > 64 bit-capable machines. This used to be the case via the default64 option patched into syslinux, but then #505243 complicated it and #505496 saw the default64 option removed from syslinux. It would certainly be worth fixing this reversion in the multiarch CD. -- see shy jo signature.asc Description: Digital signature
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
Yves-Alexis Perez wrote: > I actually think having no default desktop would be just fine, instead > having the current 3-4 desktop installation media. Then anyone can pick > the DE she likes. I recently spent some time installing community computer labs in rural Brazil. Internet bandwidth was nearly nonexistant[1], so if you were lucky, someone could come up with a thumb drive with a Debian image containing a desktop environment that fit the target machines, which were variously recycled donations from more wealthy areas, or several revs back in government computer subsidies -- so all too underpowered for gnome. If the xfce iso didn't exist, people in these situtations would not be able to install a usable Debian system. At the same time, there is room for better communication, because what I observed is that users mostly tried to install with the default gnome CD first, only to find out it wasn't suited to their hardware. We could better communicate that eg, xfce and lxde images are more suited to older hardware. -- see shy jo [1] Eg, shared celluar modems, mostly over bandwidth caps and so reduced to a trickle. signature.asc Description: Digital signature
Re: Bug#712696: debian-installer: Add Cinnamon and Mate as alternative DEs.
Steve McIntyre wrote: > >I'm not sure we want to support every desktop environment out there… but > >I guess tasks might not hurt, so punting that to tasksel. And adding > >debian-cd@ to the loop, to get some feelings about whether new images > >would sound like a vaguely sane idea (I'm really not sure). > > Adding new image options shouldn't be too difficult, but beware that > we might even start to struggle for space on DVD#1 if we end up with > lots of different desktops...! I'm glad to see these are packaged now, and will be happy to add tasks to tasksel. I don't have time to put the tasks together myself, but it should be easy to put something together using task-gnome-desktop as a starting place. -- see shy jo signature.asc Description: Digital signature
Re: Plan of action for Secure Boot support
Cyril Brulebois wrote: > (Sorry, I'm new to all this) do you mean (1) the regular linux image > packages are getting a signature added, and we're using those like we do > today, or (2) that we'll have additional linux image packages with the > signatures to be used instead of the usual linux image packages when a > Secure Boot environment is detected? (or (3) something else…) The secure boot shim is a small bootloader. It's the only part that absolutely needs to be signed by MS, AIUI. It was designed to facilitate distributions in our position. Signed versions are also already available, produced by DD Matthew Garret, though not as Debian packages (perhaps he could be convinced to maintain it?) http://mjg59.dreamwidth.org/20303.html http://www.codon.org.uk/~mjg59/shim-signed/ (Assuming the plan is to use Matthew's shim and not the other one created by IIRC, the Linux Foundation.) -- see shy jo signature.asc Description: Digital signature
Re: Tasks and CD sizes again
Steve McIntyre wrote: > I'm thinking we should possibly drop one of these deps in the loop > between task-$DESKTOP-desktop and task-desktop. Joey, what do you > think? I think that the dependencies need to remain circular, and as tasksel has no maintainer scripts, it avoids the well-known problems with circular dependencies. apt-get install task-desktop should install a usable desktop environment, not just an X server (with no display manager even) and a web browser apt-get install task-foo-desktop should install an X server. -- see shy jo signature.asc Description: Digital signature
Re: Dropping businesscard ISO images?!?
Francesco Poli wrote: > I used the network boot method once to install Debian onto a headless > box (running d-i over the serial console was fun!), but can the network > boot ISO image be used also when booting from removable media (such as > CDROM, USB stick, ...)? Yes. -- see shy jo -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120715121054.ga8...@kitenet.net
Re: Tweaking tasks
Steve McIntyre wrote: > No, not yet at least. To be honest, I've had a lot of pressure to just > add all the Recommends anyway recently to match what people would > install by default. That's what I've done so far. It's complicated. Sometimes we drop a package from a direct Recommends in a task-* package because a metapackage like gnome has the same Recommends. I do feel that deeper recommends could be omitted (or sorted to the end of the package list) and get a working CD, but it would require testing. -- see shy jo signature.asc Description: Digital signature
Re: Tweaking tasks
Steve McIntyre wrote: > Following up from the thread about lack of space... > > A couple of weeks back I rewrote the task support in debian-cd to deal > with the change from tasks-in-Packages to task meta-packages. After a > lot of local testing, today is the first time the weeklies have been > built using the new code. There's probably some more tweaking due for > Recommends handling yet, but this seems to work at the moment. Wow, that's a relief! Thank you immensely. > The last package on amd64 CD#1 is libgjs0b. task-desktop fits on CD#1, > but task-gnome-desktop is ~90 packages into CD#2. gnome-shell-common > doesn't even make CD#1, which means the desktop will be a > little... sparse. The full sorted package list is at Is this with or without Recommends of tasks? Does it omit the (probably uncessary) Recommends of packages recommended by tasks? -- see shy jo signature.asc Description: Digital signature
Bug#672941: cdrom: There is neither XFCE (nor LXDE) in Wheezy xfce+lxde-CD-1.iso
Fab wrote: > I'm referring to the iso file created in 2012-05-07 > http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing- > amd64-xfce+lxde-CD-1.iso > I expected to find XFCE and LXDE packages in this iso. debian-cd is currently failing to put the new task-* task packages on all CDs and DVDs for some reason, even when they fit. -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
While this has been an interesting thread, it may be predicated on a false premise. I examined the latest weekly CD build, and the reason no desktop tasks at all (even lxde or xfce) appear on their respective CDs is because debian-cd is simply not including tasksel's new task-* packages, at all. The packages on the CD seem fairly random, including things not in any task like wmaker, alien, and, on the lxde+xfce CD, lots of KDE, but no ldxe or xfce. Even DVD #1 seems broken, containing task-desktop, but not task-gnome-desktop. I'm sure gnome still fits on a DVD. Seems likely that things are badly broken in debian-cd's task handling. Likely related to tasksel's new task-* packages. The way debian-cd needs to handle the new task packages is this: * Put task-gnome-desktop on CD#1, task-kde-dekstop on KDE CD #1, etc. (No need to use /usr/share/tasksel/descs/debian-tasks.desc anymore.) * Try to include at all Recommends of task-* packages, not only their dependencies, as this is used to pull in the majority of packages for tasks. Do this even when normal Recommends inclusion is disabled. * If space is tight, drop some of the task-* Recommends. And, since this needs to be special cased anyway, it would be nice to have an option to abort the build, and/or warn if they don't fully fit. -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Lisandro Damián Nicanor Pérez Meyer wrote: > Indeed, I have seen that pattern before, although I think it was because > people are used to get CDs, not DVDs (ie, just a matter of habit). Another reason is that it's more likely for a throwaway USB key to be in the 1-2 gb range than the 5 gb range. -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Neil Williams wrote: > "supporting only the smaller/lighter desktop environments" is exactly > what comes out of accepting that the first two options just won't be > acceptable. Changing compression is only putting off the inevitable. > There's *no* reason to think that GNOME or KDE are going to get back > below the 1 CD limit at the next Debian stable release. > > I'd support XFCE4 as the default Graphical Desktop Environment and > possibly putting GNOME (and KDE) as alternative options. > > That way, GNOME and KDE (as explicit options) should only show up in > the list if using a medium which can provide that amount of packages. While I have started putting XFCE on systems I install for family etc, I am not sure if it's really suitable yes to be the default desktop environment. There are probably quite a lot of fit and finish issues. Here are two major problems: * Currently the XFCE taks uses wicd, which has a much less polished UI than network-manager. For example, when wicd needs a password, it opens a rather complex configuration panel, rather than just prompting for the password. Probably some users also use network-manager for things like cell connections, that wicd doesn't support. * There does not seem to be much accessability support in XFCE. With gnome, we have a fully accessible system from the login manager on. Accessability improvements are on the XFCE roadmap; this should improve with time. http://wiki.xfce.org/releng/4.10/roadmap/accessibility I hope that we can avoid the CD size forcing the desktop for at least one more release. Note that we had the same trouble the last two releases, and managed to make it fit in the end both times. -- see shy jo signature.asc Description: Digital signature
pointers to http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
There seem to be few pointers to the non-free firmware CDs. While I don't want to oversell them (they should not be used by default), I have added a link in the installation manual's firmware section. Would it also make sense to add a link to http://www.debian.org/CD/faq/ -- see shy jo signature.asc Description: Digital signature
Re: Renaming xm-debian.cfg to just debian.cfg
Ian Campbell wrote: > Or do I need to worry about non-daily/weekly builds too? I suppose that > if an alpha/beta release is made there will necessarily be a d-i upload > first (with this change)? Yes, debian-installer will be uploaded before any such release. > Patches to both are attached, I can checkin the d-i one myself if > debian-cd are happy with the approach. Looks fine to me. -- see shy jo signature.asc Description: Digital signature
tasksel changes
tools/update_tasks has been broken by tasksel being changed to use task packages. from README.tasksel: > The general sequence in which packages are added for "complete" images is: > 1) Packages required by Debian Installer > 2) Packages required to install the base system (debootstrap) > 3) Any packages with priority "standard" or higher > 4) Packages from tasksel tasks >a) Packages defined as "key" packages for primary tasksel tasks >b) Packages defined as "key" packages for language tasks Down to here should still work ok; the only Key packages now are task-* packages, but they Depend on the packages that used to be listed as Key. >c) Regular packages from primary tasksel tasks >d) Regular packages from language tasks Here's the problem; before this was determined by tools/update_tasks using Task fields. The Task fields are going away, the equivilant now is the list of Recommends of a task package such as task-gnome-desktop: Recommends: gnome-accessibility, gnome-desktop-environment, gnome, iceweasel-gnome-support, epiphany-browser, libreoffice-gnome, libreoffice-evolution, inkscape Since the code is mostly awk, I have not tried to write a patch, but it does not look *too* bad, the same code was already parsing the Packages file to find the Task fields and should only need to parse it differently. -- see shy jo signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
Steve McIntyre wrote: > There are uses I've heard about, including (apparently quite common) > using CDs and DVDs to seed a mirror on a Windows server. If I had to chose between that working, and not needing to worry about filename lengths, I'd choose the latter. > >Is it possible to provide Joliet filenames for only a subset of files? > > It is, yes. But not something I'd like to do if we can avoid it. One approach then would be to omit joliet filenames for the few long packages. This would not even impact your use case above much, since any mirror seeded from files from CDs needs a further sync step. -- see shy jo signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
Steve McIntyre wrote: > I've noticed a problem recently in the archive when building CDs, > aggravated to a certain extent by the newer source formats. Some of > the filenames in the archive are getting *very* long, and this is > causing issues. As a matter of course, we build CDs with RockRidge and > Joliet support so that we have long filenames for Linux and Windows > users. What is the use case for accessing long filenames from the CD in Windows? The files needed by win32-loader need to be accessible, and documentation too, but it should not matter if deb files cannot be looked up from within Windows. If these files could be dealt with, using Rock Ridge alone would be an alternative to consider: /README.html /README.mirrors.html /README.mirrors.txt /README.source /win32-loader.ini /css/debinstall-print.css /css/debinstall.css /doc/bug-log-access.txt /doc/bug-log-mailserver.txt /doc/bug-mailserver-refcard.txt /doc/bug-maint-info.txt /doc/bug-maint-mailcontrol.txt /doc/bug-reporting.txt /doc/constitution.txt /doc/debian-manifesto /doc/dedication /doc/mailing-lists.txt /doc/social-contract.txt /doc/source-unpack.txt /pics/blue-lowerleft.png /pics/blue-lowerright.png /pics/blue-upperleft.png /pics/blue-upperright.png /pics/debian-61.png /pics/logo-50.jpg /pics/openlogo-nd-50.png /pics/red-lowerleft.png /pics/red-lowerright.png /pics/red-upperleft.png /pics/red-upperright.png /doc/FAQ/debian-faq.en.html.tar.gz /doc/FAQ/debian-faq.en.pdf.gz /doc/FAQ/debian-faq.en.ps.gz /doc/FAQ/debian-faq.en.txt.gz Is it possible to provide Joliet filenames for only a subset of files? -- see shy jo signature.asc Description: Digital signature
Re: task packages support in debian-cd
Steve McIntyre wrote: > Right, so you mean #1 above. My initial way would be something like > #1, basically because it's easiest to code, BUT: the normal dependency > following code will only place the task package *itself* on the CD iff > all of the Depends and Recommends have already been placed there. We'd > have to add special case code for the task packages if we want to > change that. Right, it should be depth-first, but with the exception that a task can be put on the CD even if its Recommends don't fit. Without that, gnome will surely not fit on the first CD. > >BTW, I hope this will make it a lot easier to check what tasks fit on > >the CD, since we can just look to see where task-* ends up. > > And this suggests that we probably *shouldn't* do that special casing, > in fact. No, I think it's fine if some of the dregs of gnome doesn't make it onto the CD, as long as it has the task and depends and whatever recommends _do_ fit. > If I understand you correctly, the main thing we have to do to achieve > what we need is to switch *on* inclusion of Recommends: for our > builds. I don't know that we want that in general. Tasks have always been a special case. One way approach it would be to have tools/update_tasks just dump out lists of all tasks's Depends/Recommends like it dumps out lists based on Key/Task now. -- see shy jo signature.asc Description: Digital signature
task packages support in debian-cd
I mailed about this before, but I can be a bit more concrete now since a tasksel using task packages is in BYHAND waiting to get into experimental. These task packages each Depend on what used to be called the "Key" packages of a task. And they tend to Recommend a lot of other packages. So, it will be important that debian-cd attempts to install the Recommends of task-* packages that it puts on the CD. Ideally, it should put the task on the CD, put all its Depends on the CD, and then attempt to put all its Recommends on the CD. (Whether to put transative Recommends on is up to you. Probably they should be considered lesser priority than direct Recommends.) If the Recommends don't all fit, it would still make sense to include the task package on the CD. I don't know what method is used now. Maybe it currently puts all listed packages and Depends on the CD, and only tries to fill in Recommends at the end, if there is extra space. That's not the right approach for task packages; including a Recommends of task-gnome-desktop is more important than including some less important task. BTW, I hope this will make it a lot easier to check what tasks fit on the CD, since we can just look to see where task-* ends up. -- see shy jo signature.asc Description: Digital signature
Re: Debian testing installer BUG
Joey Hess wrote: > Steve McIntyre wrote: > > On Tue, Mar 01, 2011 at 11:14:38AM -0300, Joao Gustavo Cabral wrote: > > >Dear Comrades, > > > > > >I would like to notify the following BUG at the base system install > > >step: DEBOOTSRAP ERROR: RELEASE FILE NOT VALID. > > > > Hi Joao, > > > > Known bug, should be fixed soon. > > So, there was a followup to #614315 today saying that debootstrap 1.0.28 > failed like this. Since you seem to know, what's the situation? Actually, I assume it's just that the CD builds are pointing to wheezy_d-i images, and need to be repointed at sid_d-i? -- see shy jo signature.asc Description: Digital signature
Re: Debian testing installer BUG
Steve McIntyre wrote: > On Tue, Mar 01, 2011 at 11:14:38AM -0300, Joao Gustavo Cabral wrote: > >Dear Comrades, > > > >I would like to notify the following BUG at the base system install > >step: DEBOOTSRAP ERROR: RELEASE FILE NOT VALID. > > Hi Joao, > > Known bug, should be fixed soon. So, there was a followup to #614315 today saying that debootstrap 1.0.28 failed like this. Since you seem to know, what's the situation? -- see shy jo signature.asc Description: Digital signature
Re: Bug#612074: debian-cd: provide iso image aligned on usb thumb drive size
Steve McIntyre wrote: > We'll find out. :-) I've grepped out (roughly!) the list of packages > that will have now moved from DVD#1 to DVD#2 for both i386 and amd64 > (wheezy). See each file at > > http://cdimage.debian.org/cdimage/tmp/ > > if you're interested. These tasks were removed (both arches): kannada-desktop, telugu, telugu-desktop, gujarati-desktop The remainder is reasonably high popularity stuff that is in no tasks. -- see shy jo signature.asc Description: Digital signature
Re: Bug#612074: debian-cd: provide iso image aligned on usb thumb drive size
Steve McIntyre wrote: > Then I'm going to make DVD#1 limit to 4GB for amd64, i386 and the > amd64/i386 m-a DVD. Then it'll fit on a 4GB stick too, and I think > that's useful. The rest of the set will still fill up to the normal > 4.7GB DVD size, as there's no point to keeping to that limit on later > discs. Other arches and source DVDs will also not be affected - > there's also no point messing with them AFAICS. Please correct me if > you think I'm wrong here! > > For a 1GB or 2GB (or even 8GB/16GB) image, we *can* add more builds > targetted to fit those sizes, but I would rather make those be totally > separate builds; they're not close enough to any of the current > standard sizes that we generate IMHO. > > Thoughts? A good general principle would be to not add custom sizes that are smaller than the size of the typically well-tested CD media. A 500mb iso is likely to be nearly useless because it will never fit Gnome, for example, and so will end up having to download nearly as much from the network as would a netinst iso. I'm curious what tasks, if any, are made unavailable by reducing the DVD to 4gb. Probably the key packages of all tasks fit in 4gb anyway, but do *all* packages of all tasks? -- see shy jo signature.asc Description: Digital signature
Re: Debian installer build: failed or old builds
Christian PERRIER wrote: > > * FAILED BUILD: armel Feb 09 22:18 joey@box > > build_iop32x_network-console_ss4000e > > > > http://people.debian.org/~joeyh/d-i/armel/images/daily/build_iop32x_network-console_ss4000e.log > > These do fail because of: > > Ign http://cdn.debian.net unstable/main/debian-installer armel Packages > Err http://cdn.debian.net unstable/main/debian-installer armel Packages > 403 Forbidden [IP: 149.20.20.135 80] > Fetched 20 B in 1s (19 B/s) > W: Failed to fetch > http://cdn.debian.net/debian/dists/unstable/main/debian-installer/binary-armel/Packages.gz > 403 Forbidden [IP: 149.20.20.135 80] > > E: Some index files failed to download, they have been ignored, or old ones > used instead. mirrors1.kernel.org always returns 403 when accessed as cdn.debian.net. --2011-02-10 16:28:03-- http://cdn.debian.net/debian/dists/stable/main/binary-armel/Packages.gz Resolving cdn.debian.net... 149.20.20.135, 128.226.116.176 Connecting to cdn.debian.net|149.20.20.135|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2011-02-10 16:28:05 ERROR 403: Forbidden. Note that mirrors2.kernel.org is does not have this problem. The CDN status page shows it knows of this problem and dig shows it has removed the host from the CDN. But there seems to be a DNS caching problem. joey@finch:~>host cdn.debian.net 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: cdn.debian.net is an alias for deb.cdn.araki.net. deb.cdn.araki.net has address 128.226.116.176 deb.cdn.araki.net has address 149.20.20.135 Are google's DNS servers ignoring the cdn.debian.net TTL? -- see shy jo signature.asc Description: Digital signature
Bug#609334: 50mirror treats bluray as if CD size
Package: apt-setup Version: 1:0.52 Severity: normal Tag: patch This is one of the problems sledge alluded to in http://lists.debian.org/debian-boot/2010/12/msg00562.html When installing from bluray, the cd_type is "full_cd", and so the user will be prompted at high priority using incorrect text from apt-setup/use/cd: "You are installing from a CD, which contains a limited selection of packages." The bluray should be given its own cd_type, and there would be little or no need to use a mirror in this case, or prompt for more discs. Note that once the cd_type is changed, 41cdset will begin doing the right thing for bluray, with no code changes, by not prompting for additional discs. The attached patch is, obviously, untested (but fairly clearly correct), and uses cd_type of "bluray". -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable') 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 -- see shy jo Index: generators/50mirror === --- generators/50mirror (revision 66209) +++ generators/50mirror (working copy) @@ -80,6 +80,10 @@ use_prio=low fi ;; + bluray*) + use_mirror=false + use_prio=low + ;; *) use_mirror=true use_prio=high Index: generators/41cdset === --- generators/41cdset (revision 66209) +++ generators/41cdset (working copy) @@ -38,6 +38,7 @@ fi # multi-arch CDs have cd_type 'non_complete' # KDE/Xfce CDs and multi-arch DVDs have '/single' postfix in cd_type +# bluray CDs have cd_type 'bluray' cd_type=$(cat /cdrom/.disk/cd_type) if [ "$cd_type" != full_cd ] && [ "$cd_type" != dvd ]; then exit 0 signature.asc Description: Digital signature
Re: lack of gnome on squeeze CD #1
Josselin Mouette wrote: > This would need to be tested, but 1+2 without recommends sounds like the > good thing to add. We could remove the mail client (evolution) if it > turns out too big, nowadays the media player looks more important. I'm testing 1+2 in tasksel 2.87 and we can move the list back into a metapackage if it works. (Uploaded; hopefully the next build of the CD will have the change.) > How should I name the new metapackage? My first thought is just to move > these packages from gnome-desktop-environment to gnome-core, and to make > gnome-core the key package. Sounds ok to me. -- see shy jo signature.asc Description: Digital signature
Re: lack of gnome on squeeze CD #1
Josselin Mouette wrote: > Where can that list be found? It looks correct, but different from the > one in tasksel. That is the Key packages from the gnome-desktop and desktop tasks in tasksel. > So one of the solutions would be to ditch Recommends. I was wrong about recommends being included currently. > Full GNOME is already not included, since that would be the “gnome” > package, not “gnome-desktop-environment”. Well, that is included in the task as a non-key package, so is downloaded if possible. (And should be included on the DVD, assuming all of gnome fits on a DVD :) > If you really want to make it fit on a CD, we could use the following > list instead of the one above: > gnome-core > dmz-cursor-theme > epiphany-browser (or iceweasel, but epiphany should be smaller) > gdm3 > desktop-base > evince > file-roller > gnome-about > gnome-keyring > gnome-screensaver > gnome-themes > gnome-user-guide > gtk2-engines > gvfs-backends > libgnome2-perl (unless someone finally fixes #542175) > policykit-1-gnome > gnome-disk-utility > And if possible: > gstreamer0.10-alsa > gstreamer0.10-plugins-base > gstreamer0.10-plugins-good > totem > evolution > > I can make a metapackage out of this list if it can help. We should probably do that. That's enough of gnome not to be laughable? (network-manager-gnome seems to not be included in that, but then it's recommended by the gnome-metapackage so would not be included from the current gnome-desktop-enviromnent using task either, if installing w/o a network, I think..) Rough size numbers (probably 20 mb or more off in some direction): i386amd64 available space on CD #1 for gnome 372 mb 392 mb - gnome-desktop-environment with recommends 543 mb 584 mb gnome-desktop-environment no recommends366 mb 394 mb list 1+2 with recommends 411 mb 436 mb list 1+2 no recommends 257 mb 279 mb list 1 with recommends 307 mb 332 mb list 1 no recommends 214 mb 236 mb -- see shy jo signature.asc Description: Digital signature
Re: lack of gnome on squeeze CD #1
Sven Hoexter wrote: > Please don't shoot me but do we really want to produce CD images beside the > netinst iso? I'm not sure if that's still needed in times of usb thumb drives > all around with a multitude of capacity you've on a CD. CD images are useful specifically on USB thumb drives. Well, you can use a DVD image if the drive is > 4gb; the one I keep on my keychain is not, yet. -- see shy jo signature.asc Description: Digital signature
lack of gnome on squeeze CD #1
The squeeze CD #1 [a], which is probably still one of the most commonly mass-produced Debian CDs, no longer contains the Gnome desktop environment, or any self-contained working desktop environment. I believe the multiarch CD [b] also lacks a DE. I wanted to bring this to the attention of the desktop and gnome team, who presumably might care, since I have seen mentions of it, but nobody taking action to fix this. Apparently the desktop task is just too large for the CD now. The minimum packages that *must* be on the CD for the desktop task to be offered at all are as follows: gnome-desktop-environment xorg xserver-xorg-video-all xserver-xorg-input-all desktop-base menu iceweasel Some of this could be trimmed, but not much. All told, it comes to 551 MB of packages. Leaving out the last 2 packages from the list, it's 550 MB of packages. Leaving out Recommends, 405 MB. IIRC, debian-cd currently treats Recommends like Depends, and always includes them. So, some options: 1. Ship squeeze with a CD that requires a fast network to be useful. Sorta like the netinst CD, but bigger. The default choice. 2. Switch the first CD to be the KDE CD [c], or the XFCE+LXDE CD [d]. 3. Find a way to make gnome fit. One way would be to make it include only a subset of the gnome-desktop-environment task. (Full GNOME would still be downloaded from a mirror if a mirror was available.) Or try to trim back the recommends either in debian-cd or otherwise. 4. Find some other creative solution. For example, we could pack CD #1 full of useful text-mode tools, recovery tools, net admin tools etc, and round it out with the top packages from popcon and make it a sysadmin dream CD. (I think #1 is a pretty dreadful choice. Even on a moderatly fast network, downloading all that stuff was going to use another hour of my time this evening. If this happens we should IMHO deprecate use the CD #1 in all documentation and recommend another CD or DVD.) [a] http://cdimage.debian.org/cdimage/squeeze_di_beta1/i386/iso-cd/debian-squeeze-di-beta1-i386-CD-1.iso [b] http://cdimage.debian.org/cdimage/squeeze_di_beta1/multi-arch/iso-cd/debian-squeeze-di-beta1-amd64-i386-powerpc-netinst.iso [c] http://cdimage.debian.org/cdimage/squeeze_di_beta1/i386/iso-cd/debian-squeeze-di-beta1-i386-kde-CD-1.iso [d] http://cdimage.debian.org/cdimage/squeeze_di_beta1/i386/iso-cd/debian-squeeze-di-beta1-i386-xfce+lxde-CD-1.iso -- see shy jo signature.asc Description: Digital signature
Re: using isohybrid for usb bootable isos
George Danchev wrote: > Therefore I exchanged several mails with Thomas (xorriso upstream, also > CC'ed) > about adding such functionality to xorriso and here is how it currently looks > like: All looks very sane. > * the image file (this could be the requested second firmware partition) as > given via option, would be written right after the space of the iso image. Particularly nice as it saves an average of .5 mb. > b) Do you think that this plan for features of an image generator, would be > helpful to debian-cd and d-i, when completed. Assuming debian-cd does switch to xorriso, so after it supports jidgo; yes, I think this would be helpful. And we could use it in d-i's own iso generation earlier. I would caution that my idea of adding a partition for firmware is potentially half-baked. Especially since it's only easily accessible when using a USB stick, not when using a CD. The same problem could be solved more generally by eg, using multisession to append the firmware to the iso. But that would require the user run a script; the firmware parition does allow even a user limited to Windows and no extra programs to add firmware to their USB stick. -- see shy jo signature.asc Description: Digital signature
Bug#475243: Do we still need to think about adding acpi?
Steve McIntyre wrote: > Looks like nobody ever made this change; is it still relevant? I think so yes, hw-detect will still try install acpi. -- see shy jo signature.asc Description: Digital signature
Re: using isohybrid for usb bootable isos
Steve McIntyre wrote: > That itself is a minor pain, but not enough to make me complain about > a useful feature. The *more* difficult thing is trying to make > iso-hybrid work with jigdo: we make the .iso and .jigdo files directly > in the same invocation of genisoimage, so anything we do to > post-process the .iso files won't show up in the .jigdo > equivalents. :-( > > I've been trying to find time for ages to either: (a) add iso-hybrid > support directly into genisoimage, or (b) port the jigdo code from > genisoimage to xorriso, which is the long-term plan. xorriso already > includes the needed iso-hybrid support, but it'll take quite a lot of > work to add jigdo code there. I take it it's not an easy option to have jidgo just run isohybrid? One problem with your long-term plan is that it would not allow adding on the firmware partition prior to generating the jidgo, as xorriso won't be doing that. (I do wonder if it's worth spending scarce time on jidgo.) -- see shy jo signature.asc Description: Digital signature
Re: using isohybrid for usb bootable isos
Joey Hess wrote: > So ideally, debian-cd would add a small second partition to the iso file's > partition table, and tack on a FAT filesystem. This could probably be done > by running fdisk on the iso file after isohybrid. I've attached a patch with a script, which I am checking into d-i for now, that does that. This would add 6 to 7 mb to iso images it's used on, I don't know how Steve feels about that. :) -- see shy jo #!/bin/sh # Given an iso image, runs isohybrid on it to allow it to be booted from # USB stick as well as CD. Then it adds a small second FAT partition, which # the user can use to provide firmware files to the installer on the same # USB stick. # This needs to be big enough to hold the uncompressed firmware.tar.gz # file. Currently that is 4.4M; add a few more to grow. firmware_volume_size_M=6 # max size 11 chars: --- firmware_volume_name="Firmware" iso="$1" if [ -z "$iso" ]; then echo "usage: $0 iso" >&2 exit 1 fi set -e isohybrid "$iso" # Make the firmware volume. tmpdir="$(mktemp -d)" firmware_volume_file="$tmpdir/fat" mkfs.msdos -n "$firmware_volume_name" -C "$firmware_volume_file" \ $(expr $firmware_volume_size_M \* 1024) # Combine images. # XXX This wastes some space because isohybrid pads the iso to one # megabyte. Could reuse that padding for the start of the firmware volume. cat "$firmware_volume_file" >> "$iso" rm -r "$tmpdir" # Now adjust the partition table of the hybrid iso. # It has a first partition which is the iso; add a second partition for the # firmware volume. ( # Go into extended menu and set cylinders to 32. # This is the same number of cylinders (currently) used by isohybrid. echo x echo c echo 32 echo r # Make new partition #2 echo n echo p echo 2 echo echo +"$firmware_volume_size_M"M # Pedantically, set partition type to 1: FAT 16 echo t echo 2 echo 1 # Done! echo w ) | fdisk "$iso" From 9e4ab44eb5d43353769350872803cae71553eae5 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 13 Sep 2010 22:07:36 -0400 Subject: [PATCH 1/2] create geniso_hybrid_plus_firware_partition script This script makes a hybrid iso image with a second partition for firmware. --- installer/build/config/x86.cfg |2 +- .../util/geniso_hybrid_plus_firware_partition | 62 2 files changed, 63 insertions(+), 1 deletions(-) create mode 100755 installer/build/util/geniso_hybrid_plus_firware_partition diff --git a/installer/build/config/x86.cfg b/installer/build/config/x86.cfg index 4a0a005..e9ef577 100644 --- a/installer/build/config/x86.cfg +++ b/installer/build/config/x86.cfg @@ -279,7 +279,7 @@ arch_miniiso: x86_syslinux -no-emul-boot -boot-load-size 4 -boot-info-table \ -o $(TEMP_MINIISO) $(TEMP_CD_TREE) - isohybrid $(TEMP_MINIISO) + geniso_hybrid_plus_firware_partition $(TEMP_MINIISO) # Netboot files .PHONY: arch_netboot_dir diff --git a/installer/build/util/geniso_hybrid_plus_firware_partition b/installer/build/util/geniso_hybrid_plus_firware_partition new file mode 100755 index 000..52cccf1 --- /dev/null +++ b/installer/build/util/geniso_hybrid_plus_firware_partition @@ -0,0 +1,62 @@ +#!/bin/sh +# Given an iso image, runs isohybrid on it to allow it to be booted from +# USB stick as well as CD. Then it adds a small second FAT partition, which +# the user can use to provide firmware files to the installer on the same +# USB stick. + +# This needs to be big enough to hold the uncompressed firmware.tar.gz +# file. Currently that is 4.4M; add a few more to grow. +firmware_volume_size_M=6 +# max size 11 chars: --- +firmware_volume_name="Firmware" + +iso="$1" + +if [ -z "$iso" ]; then + echo "usage: $0 iso" >&2 + exit 1 +fi + +set -e + +isohybrid "$iso" + +# Make the firmware volume. +tmpdir="$(mktemp -d)" +firmware_volume_file="$tmpdir/fat" +mkfs.msdos -n "$firmware_volume_name" -C "$firmware_volume_file" \ + $(expr $firmware_volume_size_M \* 1024) + +# Combine images. +# XXX This wastes some space because isohybrid pads the iso to one +# megabyte. Could reuse that padding for the start of the firmware volume. +cat "$firmware_volume_file" >> "$iso" +rm -r "$tmpdir" + +# Now adjust the partition table of the hybrid iso. +# It has a first partition which is the iso; add a second partition for the +# firmware volume. +( + +# Go into extended menu and set cylinders to 32. +# This is the same number of cylinders (currently) used by isohybrid. +echo x +echo c +echo 32 +echo r + +# Make new partition #2 +echo n +echo p +echo 2 +echo +echo +"$firmware_volume_size_M"M + +# Pedantically, set partition type to 1: FAT 16 +echo t +echo 2 +echo 1 +
using isohybrid for usb bootable isos
I've done some investigation of using isohybrid on an iso image (d-i alpha1 i386 netinst) to allow it to be booted from USB stick. Basically, postprocess the image with isohybrid, and write it direct to the usb stick. On the single machine I tried it on, that booted ok without any tweaking of isohybrid options. So I think this would be a useful thing for debian-cd to do. I assume it would probably conflict with eg, the boot sector magic used for multiarch isos. If it were only done for i386/amd64 isos, that would be enough to allow bypassing the complicated process to use the d-i hd-media images on usb sticks. Does that make sense from a debian-cd point of view? From the d-i side, cdrom-detect needs to be able to mount the iso when booted from usb stick. There is a cdrom-detect/try-usb that already enables that, but it's not on by default. So far, only live-installer has needed it. It should be very safe to move into the default codepath. The second problem is that apt will try, and fail, to mount the CD itself. apt-setup removed the apt.conf.d/00NoMountCDROM file. Basically, it would need to somehow detect that the CD is on a USB stick, and avoid doing that. It currently looks for /hd-media/ existing, which I made as a workaround. Just checking that the cdrom is mounted from /dev/sd?1 might do, or cdrom-detect could set a flag when it found it on a usb device partition. After working around those 2 problems, d-i successfully installed! But, another issue is that the user needs to be able to drop firmware onto the stick so that d-i can find it. Since isohybrid creates a partition table, after writing the iso to the stick, the user can replug it and see a first partition that is the iso image (so read-only). To add firmware, they would have to add a second partition, which is harder than the current process for usb sticks. So ideally, debian-cd would add a small second partition to the iso file's partition table, and tack on a FAT filesystem. This could probably be done by running fdisk on the iso file after isohybrid. d-i could also run isohybrid when generating the mini.iso and eliminate the need for very complex manual setup of a "netboot" usb stick. Firmware loading problems also apply there. BTW, I don't think the hd-media images should be removed, they do allow for use cases beyond simply installing from a USB stick. - Forwarded message from Tanguy Ortolo - Date: Thu, 9 Sep 2010 12:43:53 +0200 From: Tanguy Ortolo To: debian-b...@lists.debian.org Subject: Complicated installation from USB Reply-To: debian-b...@lists.debian.org, Tanguy Ortolo User-Agent: Mutt/1.5.18 (2008-05-17) Hello, Debian has been installable from USB (or from any non-optical non-floppy mass storage device, to be exact, but I shall use the term “USB stick” for convenience) since some time. Preparing installation optical disks or floppies is, or used to be easy, and involves two operations, depending on the case: wget cd.iso wodim dev=/dev/cdrom cd.iso wget floppy.img dd if=floppy.img of=/dev/floppy However, preparing an USB stick is not really easy: wget hd-media.img wget cd.iso dd if=hd-media.img of=/dev/stick mount /dev/stick /mnt cp cd.iso /mnt umount /mnt The installation manual explains that in a non-straightforward way, describing two methods, and giving only hints to find where to download the two needed images. In addition, this procedure depends on *nix tools, and is thus inapplicable for many user that start installing Debian from a foreign system, which is a common case. Because of this complication, I see many beginners failing at preparing USB images, if not failing to install Debian at all because they do not have an optical drive. Could we consider providing ready-to-use hd-media images? Something that would only need to be downloaded an written to a USB stick, as we do for optical media? I see two ways to implement that: * doing the copy of the CD image on the hd-media filesystem before making it available as an image; * using the recent hybrid boot feature of SYSLINUX, that allow to build single images that are bootable either as El Torito optical media or as MBR on-optical media, if applicable to the Debian installer. If there are specific reasons not to provide ready-to-use, but only pieces of hd-media images, as we currently do, these reasons might be worth being documented in the installation manual with a note such as: “Note: this procedure is not as easy as the CD one, because [blah].” That would avoid further messages such as this very one. :-) Cheers, and thanks for the great piece of software that the Debian installed is, by the way, to support so many architectures and media types. :-) -- ,--. : /` ) Tanguy Ortolo | `-'Debian maintainer \_ - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Constantly Usable Testing BoF @ DebConf10
I'd like to invite d-i and debian-cd members who are attending DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30. http://penta.debconf.org/dc10_schedule/events/681.en.html The purpose of the BoF is to finally explore whether it would make sense to implement the Constantly Usable Testing idea[1], ways to do it, and get feedback and advice from teams that could be affected by it. Some topics that might come up: * How would d-i install a snapshot of testing? (eg, some special temporary suite name) * Could having CUT releases of testing offload work that d-i is currently doing on beta releases? Or otherwise improve things by, eg, providing a snapshot for installation media to use? * Space/bandwidth/building of CUT CD images. -- see shy jo [1] http://kitenet.net/~joey/code/debian/cut signature.asc Description: Digital signature
Re: Getting d-i to find firmware on the CD generated by debian-cd
Frans Pop wrote: > On Tuesday 16 March 2010, Holger Levsen wrote: > > On Dienstag, 16. März 2010, Frans Pop wrote: > > > An additional issue with non-free firmware is that including it in the > > > way you propose would (I think) mean it will get loaded without any > > > prompting of the user, which may in some cases violate licence terms. > > > > i thought the same at first, but actually that's not the case. The user > > is still asked (by the package) if she wants to accept the licence. (As > > no preseeding takes place.) > > But that's only at the point where the package gets installed in the target > system. And at that point the firmware is already in use. I checked, and the assumption that the firmware deb's debconf prompt is displayed seems to be untrue: hw-detect.post-base-installer.d/50install-firmware: for deb in /var/cache/firmware/*.deb; do if [ -f "$deb" ]; then cp -a "$deb" /target/tmp # TODO debconf passthrough if ! in-target dpkg -i "/tmp/$(basename "$deb")"; then # dpkg failed, force removal of package in-target dpkg --force-depends --remove "$(deb_package "$deb")" || true fi in-target does not provide debconf passthrough, and apt-install cannot be used here. To use debconf passthrough here would require ripping the passthrough setup code out of debconf-apt-progress, It might be more expedient to make a pkgsel hook that uses apt-install to re-download and install the firmware debs. -- see shy jo signature.asc Description: Digital signature
Re: Getting d-i to find firmware on the CD generated by debian-cd
Petter Reinholdtsen wrote: > Should this be the default behaviour of debian-cd, or should hw-detect > be changed to look for firmware packages where debian-cd put them when > firmware debs is in the package list? The problem with making hw-detect look in pool/ is that it does not know what debs contain firmware. It assumes there will not be too many debs in the places it looks, and so it examines them all, unpacking them to find ones that contain the firmware files. If it also looked in pool/, it would unpack every deb on the CD, which would be horribly slow. It could look for debs with "firmware" or "microcode" in their names but that is vulnerable to false positives and negatives. > ln -s ../pool/non-free/f/firmware-nonfree/*.deb . That source package does not contain all available firmware, FWIW. You're missing at least zd1211-firmware and atmel-firmware. debian-cd has a list in tasks/firmware. -- see shy jo signature.asc Description: Digital signature
Re: testing firmware image out of date
Frans Pop wrote: > No, the build is correct. Just the symlink for testing needed updating from > lenny to squeeze. any chance of automating that symlink? I'd expect this has prevented wifi from working during install for many users. -- see shy jo -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309210947.ga15...@kitenet.net
testing firmware image out of date
The firmware bundle at http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/testing/current/ contains firmware files from lenny. inflating: atmel-firmware_1.3-4_all.deb inflating: firmware-bnx2_0.14+lenny2_all.deb inflating: firmware-bnx2x_0.14+lenny2_all.deb inflating: firmware-ipw2x00_0.14+lenny2_all.deb inflating: firmware-iwlwifi_0.14+lenny2_all.deb inflating: firmware-qlogic_0.14+lenny2_all.deb inflating: firmware-ralink_0.14+lenny2_all.deb inflating: ixp4xx-microcode_2.4-2_armel.deb inflating: libertas-firmware_5.110.22.p14-1_all.deb inflating: zd1211-firmware_2.21.0.0-0.1_all.deb I'm fairly sure that testing did not have such old versions of when the file was built in February, so is it building against stable? -- see shy jo signature.asc Description: Digital signature
Bug#543256: tasksel maintainer's perspective
I don't appreciate the confrontational tone Frans is using in this thread, and so will not be continuing to follow it. -- see shy jo signature.asc Description: Digital signature
Re: Bug#543256: tasksel maintainer's perspective
So, that change was made in tasksel three months ago, near to the start what was, AFAIK at the time, a 1.5 year release cycle. This was done in full knowledge that enabling recommends would take some time to sort out, including getting debian-cd to disable NORECOMMENDS and maybe handle recommends more intelligently; dealing with demotion of unnecessary recommends; and dealing with any size increase issues. If the current release timeframe[1] is not long enough to sort these issues out, perhaps the release team should be told about that. Or perhaps someone will want to revert this -- but you get to own all the issues of the installer not installing recommends while maintainers assume it will. Frans Pop wrote: > Losing network-manager-gnome from CD1 seems like a fairly major issue > to me. Oddly it didn't seem to be treated as a big deal by a lot of people when it happened to stable CD1. :-/ [users disabling recommends] > IMO maintainers of desktop tasks do *not* have to worry about this. But they clearly do: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;att=0;bug=542095 | In the end this is possible, and you’re not the first one to ask, but | then we’ll get bug reports from stupid users asking why this or that | functionality doesn’t work, while Recommends have not been installed. -- see shy jo [1] Is anyone even knows that that is anymore. signature.asc Description: Digital signature
Bug#536312: task overrides for stable appear to be updated when unstable changes -> no network-manager etc in default debian 5.0r2 install
Package: ftp.debian.org Severity: grave Tags: d-i The Task field overrides for stable are supposed to be based on the task data contained in the tasksel in stable. However, they seem to be being based on those in unstable, which results in newly installed 5.0r2 systems missing important packages including network-manager-gnome, pidgin, and gstreamer0.10-ffmpeg. None of these packages have a Task: gnome-desktop field in stable, and all of them should. All of these packages were removed from that task in tasksel 2.79, which is in unstable. Additionally, pm-utils is in the desktop and laptop tasks, a change that was only made in unstable. hibernate is missing from the laptop task, which was also only done in unstable. Additionally, the kde-desktop task is likely 100% hosed, since unstable's version has been updated for kde 4. I have not checked 5.0r2 CD images to see if their tasks are also broken, but based on tasksel's upload date and when 5.0r2 was released, it seems likely they are. Ftpmasters: Task override updating is handled by an autobyhand script fjp wrote, /srv/ftp.debian.org/dak/scripts/debian/byhand-task. I don't have access to look at what's on ftpmaster, but looking at the patches fjp posted about this, it seems to update /srv/ftp.debian.org/scripts/external-overrides/task with the file from tasksel, and then run mk-extra-overrides.sh in the same directory. Perhaps the issue of keeping differing overrides for stable and unstable separate was entirely overlooked? Although IIRC ftpmaster had a different set of task override files for stable. Recommendation: Fix tasks, on ftpmaster immediatly, throw out all 5.0r2 CD images, and maybe try to deal with upgrading brokenly installed systems? Then figure out how the autobyhand script failed and fix it.. -- see shy jo signature.asc Description: Digital signature
Re: Bug#532515: handling of Recommends (was: on making decisions vs letting things happen)
Frans Pop wrote: > I don't think policy for Recommends is wrong, but I do feel it results to > a hell of a lot of packages getting installed that are not actually > needed/wanted in practice. We have a whole release cycle to sort this out now. > IMO the special handling of Recommends in D-I > so far was justified, especially as we did consciously compensate for not > installing Recommends by default by adding them to the task definitions > in cases where they were really needed/wanted. I seemed to be approximatly the only one doing that, and am inactive though.. > I feel that the change could have been discussed more before being > implemented in tasksel, possibly with some coordinated effort to check > the impact on _all_ tasks instead of just the Gnome desktop task and > maybe filing bugs to fix the most problematic Recommends. Yes, a non-inactive person to handle this in tasksel would have done much better than me. -- see shy jo signature.asc Description: Digital signature
reassign 493173 to debian-cd
# Automatically generated email from bts, devscripts version 2.10.34 reassign 493173 debian-cd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: syslinux vesamenu
Otavio Salvador wrote: > I'd like to know when Joey plans to commit it. Joey? I've been holding off for review. Now that we're happy with it except for some minor string changes and reorganisation (which should be doable without a lot of pain, I think, although there are certian types of reorganisations that would be problimatic IIRC), I'm basically ready to merge it now. I'd want to update the version of isolinux in debian-cd to current testing, add vesamenu.c32 to debian-cd alongside it, and apply my debian-cd patch first. The d-i patch can be merged in once debian-cd is ready for it. -- see shy jo signature.asc Description: Digital signature
Re: syslinux vesamenu
Frans Pop wrote: > What I'd like to see is just the basic choices selectable from the menu, and > a prompt for advanced usage. One option to do this could be: Last month syslinux got submenu support for vesamenu, so its now doable.. Here's an example image with menu items for text and gtk: http://kitenet.net/~joey/tmp/mini.iso Here's an example image with the full set of possible options: http://kitenet.net/~joey/tmp/minifakemulti.iso (only the i386 text d-i options will really boot in these hacked together images) > It would also be nice to have a function key that returns the user to the > vesa menu (if possible). The best thing I've been able to come up with is ctrl-alt-del to get back to the menu. You can define a boot target that restarts the vesa menu, but I ran into some bugs when doing it, and requring people type "menu" to get back to the menu is not very intuitive. -- see shy jo signature.asc Description: Digital signature
Re: syslinux vesamenu
I've finished and tested the debian-cd patch for using vesamenu. Did
notice one problem. When the vesamenu is used, "default64" does not
behave the same as it normally does in syslinux. Rather than setting the
default that's used then enter is pressed, it makes syslinux
*immediately* start booting the amd64 installer with no chance for
interaction.
So unless it gets fixed[1], default64 can't be used on vesamenu images,
and I've disabled it. Instead, you need to manually pick amd64 off the
menu when booting a multiarch image.
Is this a big problem? At least there is a menu, with "AMD64 install"
visible on it. (Maybe that would be better named "64 bit install" to
avoid the amd/ia64/x86_64 confusion..)
I've created 3 test CD images that use vesamenu:
http://kitenet.net/~joey/tmp/vesamenu/
My feeling is that this is basically ready to go and is quite unlikely
to break anything in the beta2 timeframe if applied soon.
PS, the win32-loader.ini file on the multi-arch CDs lists kernel/initrd
images for amd64, but not for i386. Seems wrong.
--
see shy jo
[1] IIRC I reported this upstream last fall..
Index: tools/boot/lenny/boot-x86
===
--- tools/boot/lenny/boot-x86 (revision 1585)
+++ tools/boot/lenny/boot-x86 (working copy)
@@ -180,17 +180,33 @@
extra_image gtk/initrd.gz
mv boot$N/$ISOLINUXDIR/f3.txt.withgtk boot$N/$ISOLINUXDIR/f3.txt
mv boot$N/$ISOLINUXDIR/f4.txt.withgtk boot$N/$ISOLINUXDIR/f4.txt
- mv boot$N/$ISOLINUXDIR/isolinux.cfg.withgtk boot$N/$ISOLINUXDIR/isolinux.cfg
+ if [ -e boot$N/$ISOLINUXDIR/isolinux.cfg.withgtk ]; then
+ mv boot$N/$ISOLINUXDIR/isolinux.cfg.withgtk boot$N/$ISOLINUXDIR/isolinux.cfg
+ fi
+ else
+ # Remove gtk isolinux config files.
+ rm -f boot$N/$ISOLINUXDIR/gtk.cfg
+ rm -f boot$N/$ISOLINUXDIR/amdgtk.cfg
fi
rm -f boot$N/$ISOLINUXDIR/isolinux.cfg.with* 2>/dev/null || true
- sed -i "s|/install/|/$INSTALLDIR/|" boot$N/$ISOLINUXDIR/isolinux.cfg
+ for f in isolinux.cfg text.cfg gtk.cfg; do
+ if [ -e boot$N/$ISOLINUXDIR/$f ]; then
+ sed -i "s|/install/|/$INSTALLDIR/|" boot$N/$ISOLINUXDIR/$f
+ fi
+ done
+ for f in amd.cfg amdgtk.cfg; do
+ if [ -e boot$N/$ISOLINUXDIR/$f ]; then
+ sed -i "s|/install/|/$INSTALLDIR_amd64/|" boot$N/$ISOLINUXDIR/$f
+ fi
+ done
if [ -e boot$N/win32-loader.ini ] ; then
sed -i "s|install/|$INSTALLDIR/|" boot$N/win32-loader.ini
fi
cp -f $BASEDIR/data/$DI_CODENAME/isolinux.bin boot$N/$ISOLINUXDIR/
+ cp -f $BASEDIR/data/$DI_CODENAME/vesamenu.c32 boot$N/$ISOLINUXDIR/
if [ -n "$KERNEL_PARAMS" ]; then
# Substitute custom kernel params into the isolinux config
@@ -213,11 +229,20 @@
mv $file.tmp $file
done
- cat boot$N/isolinux-amd64/isolinux.cfg | awk '
- /^[Ll][Aa][Bb][Ee][Ll]/ { printf("label amd64-%s\n", $2) }
- /^[Dd][Ee][Ff][Aa][Uu][Ll][Tt]/ { printf("default64 amd64-%s\n", $2) }
- /[Kk][Ee][Rr][Nn][Ee][Ll]/ { print $0 }
- /[Aa][Pp][Pp][Ee][Nn][Dd]/ { print $0 }' >> boot$N/isolinux/isolinux.cfg
+ if [ -e boot$N/isolinux/amd.cfg ]; then
+ # Split isolinux configs exist, so the amd.cfg will
+ # be loaded and set things up for amd64. No munging
+ # needed.
+ :
+ else
+ # This is compatability code for old versions of d-i that
+ # do not use split isolinux configs.
+ cat boot$N/isolinux-amd64/isolinux.cfg | awk '
+/^[Ll][Aa][Bb][Ee][Ll]/ { printf("label amd64-%s\n", $2) }
+/^[Dd][Ee][Ff][Aa][Uu][Ll][Tt]/ { printf("default64 amd64-%s\n", $2) }
+/[Kk][Ee][Rr][Nn][Ee][Ll]/ { print $0 }
+/[Aa][Pp][Pp][Ee][Nn][Dd]/ { print $0 }' >> boot$N/isolinux/isolinux.cfg
+ fi
sed -i -e "/^arch=/d ; /^i386\//p; s/^i386\//amd64\//; s/=$INSTALLDIR_i386\//=$INSTALLDIR_amd64\//g" \
boot$N/win32-loader.ini
@@ -227,8 +252,16 @@
mkdir -p boot$N/isolinux
mv -f boot$N/isolinux-amd64/* boot$N/isolinux
fi
- rm -rf boot$N/isolinux-amd64
+
+ if [ -e boot$N/isolinux/amd.cfg ]; then
+ # Split isolinux configs exist. Remove the amd.cfg
+ # to avoid it being loaded on a disc that does not
+ # have both amd64 and i386 dirs.
+ rm -f boot$N/isolinux/amd.cfg
+ rm -f boot$N/isolinux/amdgtk.cfg
+ fi
fi
+ rm -rf boot$N/isolinux-amd64
if [ "$SPLASHPNG" ] ; then
# Insert our own splash screen. Color index 0 is
Index: data/lenny/isolinux.bin
===
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: data/lenny/vesamenu.c32
===
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on: data/lenny/vesamenu.c32
___
Name: svn:mime-type
+ application/octet-stream
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#475243: 100% successful install on Fujitsu 2110 lifebook
Also, when apt-install is fixed to complain about queued items that fail to install, won't it start complaining about acpi if it's not on the netinst? -- see shy jo signature.asc Description: Digital signature
Bug#475243: 100% successful install on Fujitsu 2110 lifebook
Frans Pop wrote: > IIRC you once said that maybe we should not install acpi at all as it's not > really needed (only acpid is). On that basis I've always thought that is > was OK to install it if available and not if, eh, not. It's true that it's not really needed. However, I think we should make a decision and be consistent. If it's installed or not depending on the boot media, this violates least suprise, since a user (ie, me) who does use it will never know if the installer has installed it, or if it needs to be manually installed. -- see shy jo signature.asc Description: Digital signature
Re: What CDs and DVDs should we produce for lenny?
> 2. Is it worth producing all the CDs/DVDs/whatever for all the > architectures? AFAIK no supported armel machines boot from CD or DVD. For arm, you can apparently boot a netwinder from a parallel port CD drive, but armel doesn't support netwinders. So there's very little point in having any images. The only other use I can see is loop mounting an image on a web/ftp server and using it as a partial mirror, which doesn't work very well since apt wants it to be gpg signed, and is especially problimatic during installation since it probably doesn't include all udebs that would be needed for a network installation. -- see shy jo signature.asc Description: Digital signature
Bug#443991: installation-reports
Marek Grabowski wrote: > This is my output: > > apt-install: Reading package lists... > apt-install: Building dependecy tree... > apt-install: E: Couldn't find package dmraid > main-menu[1136]: WARNING **: Configuring 'bootstrap-base' failed with > error code 1 The netinst iso was missing the dmraid package. I've committed a fix and it should be fixed in the next build of the iso. -- see shy jo signature.asc Description: Digital signature
Re: tasksel and creating tasks
[EMAIL PROTECTED] wrote: > It would be appreciated if someone could tell me where to find some > information or documentation regarding working with tasksel and creating > tasks for selection after installation. Have you read its README? -- see shy jo signature.asc Description: Digital signature
Re: Reasonable maximum package size ?
Anthony Towns wrote: > Debug packages: (369MB) (not arch:all) > 53959746 boson-dbg > 55430908 icedove-dbg > 56274922 koffice-dbg > 59787420 iceape-dbg > 86404478 libgl1-mesa-dri-dbg These seem to be built with separated debugging symbols. They could probably still be reduced in size with compilation flags as discussed in the recent thread on dbg packages. > 57383550 libqt4-debug This doesn't use separated debug symbols, so it's a good candidate for a bug report to switch to them. > > The advantages would be: [...] > > - make it possible to not include such data on the regular binary CDs, > > but for example on separate arch-independent "data" CDs > > Particularly for game data, it seems like it'd make more sense (at least > from a user's pov) to include the game code and the game data on the same > CD, given they'd always be installed at the same time. I've no idea if > that could realistically be done, or if there's any point thinking about > it 'til later though. debian-cd already supports multiarch CDs. It seems fairly doable to exclude a set of packages from the main CD sets and put them on a set of multiarch game CDs. It seems worthwhile as it would reduce the total number of CDs containing said game data from approx 36 to 4. It might even make the resulting CDs more likely to be used; currently few people bother to use a full 23 CD set, but if they're into games and know which 4 CDs contain the large ones, it's worth getting just those 4. Better yet, put it on a single DVD. -- see shy jo signature.asc Description: Digital signature
Re: netinst, businesscard, and media sizes
Frans Pop wrote: > True, that would be an option. Do you only mean the k7 kernel, or also the > 64-bits kernel, or even the xen/vserver kernels? The k7 kernel is the main thing that is missing imho. The bigmem and xen kernels would be useful if base-installer somehow installed them in the future. I don't know if the amd64 kenrel has a broad enough use case to justify it. > This has to be weighed against the increased download size. Yes. -- see shy jo signature.asc Description: Digital signature
Re: netinst, businesscard, and media sizes
Matt Taggart: > I have been told (by Steve Langasek) that the netinst image sizes are > "whatever it takes to do net install, to be used on a regular CD but kept as > small as possible for download purposes". The netinst images are all pretty > close to the 185mb mini-CD size, > > archsize free space on a 185mb disk > = > arm:136mb49mb > sparc: 138mb47mb > amd64: 145mb40mb > i386: 159mb26mb > alpha: 162mb23mb > hppa: 162mb23mb > mips: 168mb17mb > mipsel: 170mb15mb > ia64: 212mb -27mb > ppc:234mb -49mb The mini CD size is the primary target of the netinst. A secondary target is putting the netinst on a hd-media usb stick. We were not able to keep it fitting on a 128 mb stick for etch, so the current target there is 256 mb, of which ~245 mb is available for the netinst. > Only ia64 and powerpc are over that size which is good, that means that most > of the current netinst images are usable on miniCDs, if not optimal. But > there's also some opportunity to squeeze a little more on there for most of > the archs. Getting the ia64 and powerpc below 185mb would be good, making use > of the extra space on the other archs would be a bonus. IMHO the best use of the space for i386 would be including a full set of the kernels d-i can install on there, instead of only the 486 and 686 kernels. That would fix one of the current hidden problems of using the netinst, that you may not get the ideal optimised kernel. -- see shy jo signature.asc Description: Digital signature
Re: too many CD ISOs
I've been looking around the CD vendors. Ideally, I'd like to buy: * netinst (in an actual mini-iso form factor) * businesscard (in an actual businesscard form factor) * multiarch DVD * multiarch CD I have not been able to find any of these for etch. Haven't checked _all_ the US vendors yet, but I am not optimistic. * gnome CD (CD #1), kde CD, and xfce CD The only way to get this from many vendors is by buying a set of all 23 CDs for ~$30. (Other vendors offer a 21 CD set that omit the kde and xfce CDs.) I don't mind the price, but buying 20 CDs that I will _never_ use is not something I can justify. (Things are somewhat better for the DVDs; even if I'd never use DVDs 2/3 it's useful archivally.) IMHO we need to do something to get vendors to default to selling the CDs that are useful, and de-emphasise the great big vanity packs that are just a waste of plastic for most users. -- see shy jo signature.asc Description: Digital signature
Re: Artwork for "Etch" completed
Ulrich Hansen wrote: > My series of CD-/DVD-covers for Debian "Etch" is now completed. You > can find them at: > > http://ulihansen.kicks-ass.net/etch > > License is the GNU GPL, the source is available as editable Gimp XFC > and I included a description how to adapt the artwork to individual > preferences. > > I'd really appreciate it, if you would link to my site from > http://www.debian.org/CD/artwork/ > > If you need additional information please send a message. Thanks, I've added it to the website for the next build. Good artwork and I like how the three DVDs each have different text. -- see shy jo signature.asc Description: Digital signature
Re: [PATCH] make multi-arch CD/DVD images more visible
Robert Millan wrote: > What kind of people do you have in mind ? Users of other architectures should > have a clear idea of what they're looking for. People for whom a ~500mb netinst is not the best choice of installation medium, for one. -- see shy jo signature.asc Description: Digital signature
Re: [PATCH] make multi-arch CD/DVD images more visible
Frans Pop wrote: > + Multi-arch CD/DVD image for PC or Mac (i386 / amd64 / powerpc) > + > + Download via HTTP: [ href="http://cdimage.debian.org/cdimage/weekly-builds/multi-arch/iso-cd/";>CD] > [ href="http://cdimage.debian.org/cdimage/weekly-builds/multi-arch/iso-dvd/";>DVD] > + Download via href="$(HOME)/CD/jigdo-cd">jigdo: [ href="http://cdimage.debian.org/cdimage/weekly-builds/multi-arch/jigdo-cd/";>CD] > [ href="http://cdimage.debian.org/cdimage/weekly-builds/multi-arch/jigdo-dvd/";>DVD] > + This seems reasonable, although it's wishful thinking that this will prevent people from downloading the right image. Indeed, the multiarch netinst linked to above is not the right image for a lot of people.. -- see shy jo signature.asc Description: Digital signature
Re: Bug#411552: please set a timeout in syslinux screen
Robert Millan wrote: > Please do set a timeout in syslinux screen. Even if it's a very high one. > Since sparc already has 600/10 s as timeout, I propose the same for x86. IIRC you have to enter something at boot to make a sparc boot from CD. CD booting is not the default, like it is on many x86 machines. Therefore, you're comparing apples and oranges, the existance of a timeout on sparc is not relevant. > Rationale: > > Some computers have BIOSes that don't support USB keyboards. These are > not necessarily old computers; I've found relatively new ones (with amd64 > cpu, etc) that also exhibit this fuckage. The problem is terrible for any > OS whose installer relies on BIOS calls to receive keyboard input at some > point. A friend of mine stopped using Windows because he was unable to > install it :-). Then again, we had an Ubuntu CD and we were unable to > type anything in the boot screen (which AFAIK is syslinux-based and relies > on BIOS). Fortunately thanks to the timeout the system booted and he > could install something Debian-ish at least. However, Debian install > wouldn't work unless a special CD were built with timeout enabled. That is obviously a problem, but so is d-i booting unexpectedly. My ambivilance factor is high on this one.. -- see shy jo signature.asc Description: Digital signature
Re: Bug#410418: installation-reports: Successful installation on HP Omnibook 6000
Geoff Simmons wrote: > Sure, please find it attached. Ok well, you have a cdrom: line with contrib in it, so the installer did the right thing in adding the security.debian.org contrib lines. OTOH, it's sorta weird that the cdrom had a contrib component on it. Apparently for some reason our netinst includes msttcorefonts which is in contrib. Ok, a lot of unncessary stuff including this is getting pulled onto the netinst due to debian-cd's annoying behavior of satisfying every alternative in orded dependencies. cdebconf depends on the whole gtk/fontconfig toolchain, which has an ored dependency that includes msttcorefonts. cdebconf is supposed to be in the exclusion list, but debian-cd seems to be broken now. Due to recent changes it first adds everything, including all package deps. Then it excludes packages (but not their deps). This is why we're getting msttcorefonts, and the whole fontconfig/gtk chain on the netinst, which is currently 160 mb (30 mb larger than it should be). -- see shy jo signature.asc Description: Digital signature
Re: Netinst or Regular inst with USB HID support?
Michael Loftis wrote: > Right now I'm having a pretty big issue attempting to install etch onto > some intel blades because Debian doesn't' include USB HID support on the > installation CD images. Has anyone created either netinst discs or the > like which will work with a legacy free system? Eh? All etch installation images include USB keyboard support, including the udbhid module. -- see shy jo signature.asc Description: Digital signature
Re: A first test report on multiarch DVD
Giuseppe Sacco wrote: > The DVD version shown when pressing F1 at the boot prompt is "Debian > testing M-A 1 20070102-08:25; d-i 2006110". > > I have a couple of questions regarding this DVD, even if I will retry > this install tomorrow after updating my image with jigdo to the new > version dated 20070125. > > 1. is there anything I should do in order to start the amd64 kernel > instead of the i386? You need to boot with install64 or something like that. It's documented in the help screens, f5 or so. -- see shy jo signature.asc Description: Digital signature
Re: confused by recent debian-cd changes
Steve McIntyre wrote:
> >How it seems to really work:
> >
> > - tasks/base-sarge is never updated for new versions of debootstrap in
> > recent memory, but things like "filesutils", fileutils, and arcboot are
> > manually added to it, ignoring the comments at the top of the file.
>
> Ouch. In that case we need to fix this. Dependencies are going to
> become fun here, of course. I hadn't noticed the problem here yet, but
> I've never felt the need to modify tasks.
I think I've comprehensively fixed + updated this one.
> > - tasks/debian-installer is generated by tools/generate_di_list, which
> > now must be run on a machine containing a mirror of the unofficial amd64
> > port, or you won't get the same file as is in cvs.
>
> Apologies, that's my fault from when I added the amd64 support into
> debian-cd.
>
> > - tasks/debian-installer+kernel likewise but more so
>
> Ditto.
>
> >Is this accurate? Am I wasting my time trying to do things like the
> >documentation and common sense would indicate they should be done?
>
> I can well believe what you're seeing. The way I suggest to fix this:
>
> * remove the auto-generated files from cvs altogether:
>* tasks/base-sarge
>* tasks/debian-installer
>* tasks/debian-installer+kernel
>
> * Add a dependency on debootstrap to generate the base-$suite file as
>needed
>
> * A full debian-cd run should generate the
>tasks/debian-installer{,+kernel} as needed too. If people don't
>have a full mirror attached for the arches they're targetting then
>they're going to struggle to do anything anyway. It's not clear why
>these were ever committed into cvs, and I agree it was a mistake.
That would indeed be better than the hack I put in for
tasks/debian-installer+kernel. Doing a similar hack for
tasks/debian-installer was unmaintainable anyway.
> Does this sound reasonable? The next question - do we want to do this
> _now_, or will it wait until after the sarge release so we don't risk
> destabilising too much? I guess I'm asking how much change we're
> likely to see in d-i between now and the release. Your call, really.
I don't really anticipate needing to update tasks/debian-installer
before release. The debian-installer+kernel lists kernel packages to
install and it will be changing over the next couple of weeks.
--
see shy jo
signature.asc
Description: Digital signature
confused by recent debian-cd changes
Before I throw anymore pennies down the well that is debian-cd, let me make sure I understand how it's supposed to work vs. how people seem to want it to work based on recent modifications. How it's supposed to work: - tasks/base-sarge is regenerated periodically by the code fragement given at the top of the file, to track changes in debootstap - tasks/debian-installer is generated by tools/generate_di_list, which needs to run on a full debian mirror - tasks/debian-installer+kernel likewise - these tasks/ files, though machine generated, are kept in cvs for ill-defined reasons, possibly because not everyone has a full mirror. Whatever the reasons, keeping them in cvs seemed to lead to -- How it seems to really work: - tasks/base-sarge is never updated for new versions of debootstrap in recent memory, but things like "filesutils", fileutils, and arcboot are manually added to it, ignoring the comments at the top of the file. - tasks/debian-installer is generated by tools/generate_di_list, which now must be run on a machine containing a mirror of the unofficial amd64 port, or you won't get the same file as is in cvs. - tasks/debian-installer+kernel likewise but more so Is this accurate? Am I wasting my time trying to do things like the documentation and common sense would indicate they should be done? -- see shy jo signature.asc Description: Digital signature
Re: Bug#283137: Problem when booting from second CD
Santiago Garcia Mantinan wrote: > > Proably because there are no udebs at all, let alone kernel udebs, on > > the second CD. So I'm reassigning this to debian-cd; if the second full > > CD is intended to be bootable, it needs to have the d-i udebs on it. > > :-??? Does this seem reasonable? I mean, isn't it more reasonable to inform > the user of this problem and ask him to change the cd and introduce the one > with the udebs on it rather than having the udebs on each bootable cd? We could do that.. they will need to use the first CD for base installation anyway. What's the point of booting from the second CD? Will it use syslinux instead of isolinux for old systems that cannot handle isolinux? The only other reason I can think of to have a second bootable CD is to make one without a logo, or with serial console support. -- see shy jo signature.asc Description: Digital signature
Re: Bug#283137: Problem when booting from second CD
reassign 283137 debian-cd thanks Margarita Manterola wrote: > This report was done with RC2 CDs, downloaded via bittorrent > > Known by my will to do weird things, this time I tried booting from the > second CD, instead of the first. It listed only "linux" and "expert" as > booting methods, so I chose "linux" > > But I couldn't get really far, because quite early in the installation > (just after reading the CD's data), it stated that the CD didn't contain > the correct kernel modules (there was a "mismatch" between the modules and > the kernel version), and took me back to the menu. Proably because there are no udebs at all, let alone kernel udebs, on the second CD. So I'm reassigning this to debian-cd; if the second full CD is intended to be bootable, it needs to have the d-i udebs on it. -- see shy jo signature.asc Description: Digital signature
time for another debian-cd release?
There are several changes in debian-cd CVS that are needed to work with current d-i, and I doubt d-i will be changing any more before release. So perhaps it's a good time to upload a new version of debian-cd? -- see shy jo signature.asc Description: Digital signature
Re: Bug#275508: sarge installer hang-ups
Obbie and RoZ wrote:
> The link to the image I used was on this page...
> http://ftp.acc.umu.se/pub/cd-images/debian-weekly/i386/
>
> I used the file 'sarge-i386-1.iso.
>
> BTW, where can I find md5 checksums for these files? ("check cd
> validity" checked out ok)
>
> >>when trying to detect network hardware, all I get is the list of IDE
> >>devices from the CD detection stage. (I should get a list of network
> >>cards, shouldn't I?)
The current full CDs are strill being built with the initrds and kernels
of rc1 of the installer, from the debian archive, but recently we
stopped using the kernel versions used by those kernels and initrds. So
the CD you downloaded boots a kernel that does not match the other
modules on the CD.
This might be fixed in the next full CD build, since we're recently
updated the kernels and initrds in unstable to match. I forget if these
CDs are built against the versions in unstable or those in testing.
Anyway, it will certianly be fixed before the next release candidate,
and in the meantime, use some other CD, such as a netinst CD>
--
see shy jo
signature.asc
Description: Digital signature
Re: Red screen - possible cause?
Mariusz Matuszek wrote: > > Mariusz Matuszek wrote: > > > I was installing 'linux26' using the installer daily build from 25th (or > > > 26th) Sept. on my Toshiba Tecra 8000 laptop. I experienced the 'red > > > screen' at one stage of installation (package consistency check) and got > > > rid of it by burning the netinstall image once more, but this time using > > > the --pad option of cdrecord. This second CD worked without problems. > > > > It sounds to me like you experienced an error message, which is intended > > to use a red background. If you didn't have a red background from the > > very beginning, you did not see the red screen problem. > > > > Uh oh - sorry for taking your time then. Wanted to help. While I have your > attention though, please check if d-i images are generated with padding or > not. If not then maybe it is worth to pad them? File size increase is > minimal (max. 32kB) and it would reduce the number of 'd-i CD not working' > error reports from people with older hardware later on. If you mean running mkisofs -pad, that adds 300k I think. Forwarding to debian-cd for consideration. > Regarding other point I made in my first email (misconfiguration of sound > on Toshiba Tecra) whom should I contact to file this as a bug and with > what additional information? If it simply failed to load a module for a card that is on the PCI bus, file a bug on discover1-data. If it's some other bus or the module loaded but did not work, file an installation report or a bug on the kernel. -- see shy jo signature.asc Description: Digital signature
status of d-i kernel transition
An update of the table of kernel versions. This time I've added a column for debian-cd, which reflects the kernel(s) that go on the netinst (from the debian-installer+kernel file). Quite a mess there, the rest of the updates to the new kernel are done, except for hppa and apus. I've still not checked to see what kernel-images are available in testing yet. archudebs build/config rootskel base-installer debian-cd i3862.4.27/2.6.8 2.4.27/2.6.8 2.4.27/2.6.8 2.4.27/2.6.8 alpha 2.4.272.4.27 2.4.27 2.4.26/2.6.6 [3] amd64 2.6.8 2.6.8 N/A [4] arm 2.4.272.4.27 none [5] hppa2.4.272.4.25 [1] 2.4.272.4.27 2.4.26 [6] ia642.4.27/2.6.8 2.4.27/2.6.8 2.4.27 2.4.27/2.6.8 m68k2.2.25/2.4.27 2.2.25/2.4.27 2.4.25/2.4.27 mips2.4.272.4.27 2.4.26 [7] mipsel 2.4.272.4.27 2.4.26 [8] powerpc 2.4.27/2.6.8 2.4.27/2.6.8 2.4.27/2.6.8 2.4.25/2.6.7 [9] apus 2.4.252.4.25 2.4.25 [2] none s3902.4.272.4.27 2.4.27 N/A sparc 2.4.27/2.6.8 2.4.27/2.6.82.4.26 [11] [1] Note hppa is still using 2.4.25 for the d-i initrds. This will break as soon as 2.4.25 udebs are removed from the archive.. [2] Hi apus.. (bye apus?) [3] Note older 2.4.26 alpha kernel on CD, and it has 2.6 kernels for some reason. [4] Does not seem to be in debian-cd CVS [5] I checked and the arm netinst CD really has no kernel deb on it at all! [6] So hppa is fully out of sync between 2.4.2[5-7] kernels. [7] Mips out of date on CD. [8] Mipsel too.. [9] Powerpc CD outdated for both kernels. No apus kernels. [10] No s390 cds. [11] Sparc cds have old 2.4 kernel and no 2.6. I think this is not as bad as it looks, because apparently the debian-installer+kernel file is locally updated as part of the daily netinst build process. So newer kernels are included in that version for most architectures than what is listed in debian-cd cvs. A spot check of sparc shows that its daily netinsts really have 2.4.27. I wonder what that file is in CVS at all actually since it is automatically generated. -- see shy jo signature.asc Description: Digital signature
Re: ia64 boot???
Steve McIntyre wrote: > Using latest debian-cd CVS I can't make a bootable IA64 DVD: > + cp /mirror/debian/dists/sarge/main/installer-ia64/current/images/cdrom/boot.img . > cp: cannot stat > `/mirror/debian/dists/sarge/main/installer-ia64/current/images/cdrom/boot.img': > No such file or directory > make: *** [/mirror/debian-local/yacs/sarge-ia64/bootable-stamp] Error 1 > ERROR WHILE BUILDING OFFICIAL IMAGES !! The issue is that the ia64 images have been reorganised since rc1. It used to be in images/boot.img. I've just updated cvs to fall back to the old location. -- see shy jo signature.asc Description: Digital signature
Re: Bug#269163: base install fails on HP ProLiant dl360g3 (using 20040830/netinst)
Matt Taggart wrote:
> 0.) HP ProLiant systems have a remote management device called an "intergrated
> Lights Out" ("iLO"). This device intercepts the system's vga text and keyboard
> and makes it available via telnet. As long as the system stays in vga text
> mode it works great but if you try to use framebuffer it tells you "the system
> is in graphics mode". So I am able to start the installer with
> "debian-installer/framebuffer=false" and that works fine. The problem is that
> the initial bootloader uses a framebuffer splash screen. If you know to hit F1
> at that point then you get the text back and boot without framebuffer. Is
> there going to be be boot media for i386 that doesn't use the spash screen?
That's nasty, whoever designed that should be spanked. If the system
doesn't want to work in graphics mode, it should not pretend there's a
graphics capable card there, then syslinux would not use graphics
mode...
I don't think we have plans for a non-splash-enabled CD right now. Maybe
we should make the second cd in a full CD set bootable and make it not
use a splash screen.
> 5.) During the base install, the installer complained "debootstrap exited with
> an error (return value 1)" /var/log/messages says
> ===
> Errors were encountered while processing:
> exim4-daemon-light
> at
> exim4
> exim4-config
> mailx
> exim4-base
> ===
>
> looking in the logs it appears to be exim4-config with the problem,
debootstrap was broken a few days ago and you got a CD with the broken
debootstrap on it.
--
see shy jo
signature.asc
Description: Digital signature
Re: Testing of Sarge RC1
Steve Glines wrote: > The release boots just fine from a CD-ROM but when it gets to "detect > and mount CD-ROM" it fails to detect the cd-rom it just booted from. Well, this rather begs the question of what kind of CD drive you booted from, doesn't it? (And if it's say, scsi, what controller card it's on.) -- see shy jo signature.asc Description: Digital signature
Re: No SARGE jigdos this week?
Rahmat M. Samik-Ibrahim wrote: > No SARGE jigdos this week? IIRC they're not being built while some updates are done to the build system. -- see shy jo signature.asc Description: Digital signature
Re: Processed: Re: Bug#262043: cdimage.debian.org: I am using the daily sarge iso images to create a local mirror. Instalation fails attempting to partition a disk
Steve Glines wrote: > I just tried this again using the vmlinuz and initrd.gz found at > http.us.debian.org/debian/dists/testing/main/installer-i386/current/images/monolithic > but instead of using a local mirror created from a downloaded CD iso I > used a real mirror (ftp.us.debian.org as a mirror) and it worked > flawlessly. I believe the flaw is not in partman (which works when > downloaded from a mirror) but in the CD iso images which fail to load > the right partman package. I explained why what you're trying to do with the netinst CDs won't work, and why we will not support it in <[EMAIL PROTECTED]>. That message also explains why I reassigned the bug in partman, instead of closing it out of hand. That message was CCed to you. -- see shy jo, who hates repeating himself signature.asc Description: Digital signature
Bug#262043: cdimage.debian.org: I am using the daily sarge iso images to create a local mirror. Instalation fails attempting to partition a disk
reassign 262043 partman retitle 262043 does not behave well if no disk is detected tag 262043 d-i severity 262043 normal thanks This is because the netinst CD image is not designed to be a usable debian mirror. In lacks udebs for all the disk drive modules that are compiled into the CD initrds, and since the netboot initrd does not have any disk drivers, you get none. It's illogical to try to use the netinst CD as a "mirror" anyway for offline installs. If you're not online, then the netinst CD does not install enough of debian to be generally useful. If you use the full CD it will work ok; there are also plenty of more standard ways to set up a partial debian mirror. I'm reassigning this bug to partman as any hangs at 55% are bugs, and as there's an known bug that it should do something smarter if no disk is detected. -- see shy jo signature.asc Description: Digital signature
Re: debian-cd doesn't build sarge (again)
Jan Kesten wrote: > Just an idea: What about placing a $Id: $ some where in the headers? > Tomorrow I'll have a deeper look at it, if think it's a mispaced if..fi Fixed. I also fixed the atrocious indentation that let me make such a mistake in the first place. -- see shy jo signature.asc Description: Digital signature
CVS access
Am I right that debian-cd CVS is still only available to DD's after the compromise and later CVS holes? I cannot seem to do an anonymous checkout anymore. This is hard for non-DDs who want to get a current debian-cd CVS checkout to work from. I think debian-cd should move to alioth, so its CVS can be publically available. Anything holding this move up? -- see shy jo signature.asc Description: Digital signature
debian-edu branch for debian-cd
I've made a small debian-edu branch in debian-cd CVS that holds just the changes needed to build debian-ed CDs. It's a small diff and I have plans to make it smaller by, eg, adding an option to debian-cd to limit the kernels on the CD to only the ones used by d-i, and another to drop the 2.6 kernel from the CD entirely, and another to set the default debconf priority for d-i. Ideally there would be no diff at all, and debian-edu could be built with an appropriate CONF.sh and an installed debian-cd package, but maybe that won't be doable so for now I'll maintain this minor branch. I've also added a build/ directory to debian-edu CVS that contains the rest of the stuff needed to build debian-edu CDs. I'd like to set up the "builder" user on developer.skolelinux.no to build this, rather than having it build as my user, if someone with access can help me do so. -- see shy jo signature.asc Description: Digital signature
Re: non-US
Steve McIntyre wrote: > What are we going to do about non-US for the sarge release? I notice > the images on gluck don't seem to contain any non-US files at all. Is > that how we want to proceed: just drop non-US? Even if you produce CDs with non-US on them, base-config will ignore it and the installed system will not know about the (few, generally outdated and broken) packages in non-US. And this isn't likely to change unless something changes to make non-US generally useful again. So you might as well not include it. -- see shy jo signature.asc Description: Digital signature
Re: revising the first cd contents...
Chris Cheney wrote: > "kde-core" is enough to get KDE running, it includes arts/kdelibs/kdebase, > but it doesn't include any of the other official KDE packages. It does > include basic apps like kate, konqueror and konsole. The "kde" package > installs the full official KDE release, but doesn't include 3rd party > apps they are included in the "kde-extras" package instead. Would the KDE people be satisfied if the first debian CD installed a KDE that was only kde-core for the desktop task? Installs from more than just the first CD would include all of KDE as they do now, and could even include the kde-extras stuff if you want me to add it. -- see shy jo signature.asc Description: Digital signature
Re: revising the first cd contents...
I wrote: > Maybe part of the problem is that the standard system takes 459 MB on > the CD. I've had problems in this area with preparing debian-edu CDs as > well; once the standard system is included, there is just not much space > left on the CD for interesting stuff. > > I didn't think standard was supposed to be so big. In a clean chroot, if > I do a tasksel -irsn (install important, required, standard only), it > downloads 52 mb. There are less than 100 mb used for the base system on > a netinst CD. So what are the other 300+ mb that is included in "standard"? I've attached the list of packages that is being added as "standard" to the i386 sarge cd #1. Indeed, if I tell apt to install this list of packages in a clean chroot, it wants to download 386 mb of files. If I remove the kernel images and kernel-pcmcia-modules, that drops to a reasonable 55 mb. So Josselin was right. If I only remove the old 2.4.25 and 2.6.5 kernels, that saves 159 mb. I think this would be a good first step; we don't need old kernels on the CD. Would 159 mb be enough saved space to fit the desktop task? Could we remove the optimised kernels? That would reduce the size to 92 mb, and give us space for a full desktop environment, easily. This would then be the same as the netinst CDs, which only contain the i386 kernel. -- see shy jo signature.asc Description: Digital signature
Re: revising the first cd contents...
Josselin Mouette wrote: > The "gnome" metapackage is for an overblown desktop with all options. > The official GNOME release is in the "gnome-desktop-environment" > package. To get numbers, maybe you should look at sid as there are some > changes with GNOME 2.6. Ok, I'll make tasksel only require gnome-desktop-environment be available, though still install all of gnome if possible. > > I didn't think standard was supposed to be so big. In a clean chroot, if > > I do a tasksel -irsn (install important, required, standard only), it > > downloads 52 mb. There are less than 100 mb used for the base system on > > a netinst CD. So what are the other 300+ mb that is included in "standard"? > > Maybe the kernel images? I remember they can be pretty big... IIRC, all the kernels do use 100 mb or something like that, but I don't think it's responsible for all of it. -- see shy jo signature.asc Description: Digital signature
Re: revising the first cd contents...
Santiago Garcia Mantinan wrote: > We have a problem with the first cd as we don't even have any xserver there, > so I'm trying to go through that and as I don't have much experience with > deiban-cd code myself, I'll try to comment here things that look weird to me > or that I think should be changed. > > The target should be to have really the packages we and our users want on > the first cd, for example, Joey Hess wanted the desktop task to be > available, but this task depends on both x-window-system-core, kde and > gnome. Testing on a newly base installed bachine, tells me that installing > desktop task needs to download 353 MB, and we know that our netinst cds > (debian installer + base) is already 110 MB in size, adding them would mean > 465 megs, leaving almost 200 megs free for other stuff, not bad at all, but > are this real numbers for our dear debian-cd? I don't think so. > > The thing is that on the netinst cds we just have the base stuff, but on > full cds we have all the standard system, and also we add recommends and > suggests, and also that we have a forcd1 task that adds stuff to cd1 and > doesn't add the packages needed for the desktop task. > > I have done some tests and we can have on our first cd both > x-window-system-core, kde-core and gnome-core as well as all the stuff we > add in forcd1 task, this is using normal options, adding recommends and > suggests. Note that I added -core versions of kde and gnome, and not the > full kde and gnome, which wouldn't fit. I don't know however if this would > give good contents for this cd. I don't know if kde-core and gnome-core are sufficient to get a working kde and gnome environment. I doubt it, especially for KDE, but if they are I can make tasksel install them, and pull in the full kde and gnome only if it's available. KDE and GNOME people, please let us know. > Trying to add full kde and gnome (not the -core stuff) resulted on not > fitting on the first cd, not even if I choose just kde or gnome and not > both. This is however adding recommends and suggests. Have you or anyone else been able to check if the full kde and gnome fit w/o recommends and suggests included? If apt wants 353 mb for the desktop task as you say, then it seems it should fit on a CD with some room to spare for other things. But: > I've done some different tests, this are some numbers I got from them: > > Normal build (with recommends and suggests): > Standard system already takes 481498058 bytes on the first CD. Maybe part of the problem is that the standard system takes 459 MB on the CD. I've had problems in this area with preparing debian-edu CDs as well; once the standard system is included, there is just not much space left on the CD for interesting stuff. I didn't think standard was supposed to be so big. In a clean chroot, if I do a tasksel -irsn (install important, required, standard only), it downloads 52 mb. There are less than 100 mb used for the base system on a netinst CD. So what are the other 300+ mb that is included in "standard"? > Trying to add x-window-system-core... > $cd_size = 524856070, $size = 25958248 > Trying to add gnome-core... > $cd_size = 550814318, $size = 81092036 > Trying to add kde-core... > $cd_size = 631906354, $size = 10605184 > > Modified build (without recommends and suggests): > Standard system already takes 424595680 bytes on the first CD. > Trying to add x-window-system-core... > $cd_size = 500982974, $size = 25958248 > Trying to add gnome-core... > $cd_size = 526941222, $size = 34316326 > Trying to add kde-core... > $cd_size = 561257548, $size = 44965402 > > As you can see, removing recommends and suggests get's us 36 megs of space > on the first cd. The increment in size on adding kde-core to the modified > build with respect to the normal build, is caused because in a normal build > gnome's suggests and recommends pull a lot of thing on which kde depends, > like qt. Why do we include recommends and suggests on the CD? It doesn't seem like the best use of limited space. > Other numbers taken from a freshly installed base from sarge: > > installing x-window-system-core gnome and kde (task desktop) downloads 353 MB > installing x-window-system-core will download 43 MB > installing x-window-system-core + gnome will download 197 MB > installing x-window-system-core + kde will download 215 MB Well, that kind of raises the question: Maybe it's time to put just one of KDE or GNOME on the first CD. How would we make such a decision though? I'm not interested in large flamewars. > Well, that is the data I've got, maybe it is not too usefull, I know this, > but it is all I could get in this last days (not too much free time lately &
Re: Bug#253033: installation-reports
Steve McIntyre wrote: > Hmmm. That wasn't very successful. Netcfg loaded fine off the CD, but > only after I loaded it by hand. The 3c59x driver for the network card > in the test machine just didn't get loaded. > > Looking at the *nic* .udebs on the image, they seem quite old (9th > May); is that normal? So I had a look at this CD. It seems to have a rather old d-i initrd on it, with a 2.4.25 kernel. This is a problem, since all the kernel udebs on the CD are for the 2.4.26 kernel. I noticed when partman didn't have support for the ext3 filesystem, since ext3-modules was not loaded as there was no version for 2.4.25 on the CD. Your nic modules problem is probably the same. The initrd on the CD is version 20040429, which is the one for d-i beta4. I don't know why the full CDs are being built against the beta4 initrds, but this is a problem. I told jigdo to use http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/sarge-i386-1.jigdo, and my iso has a md5sum of f0b66636c58c4d2e455f26db5519bff5. -- see shy jo, hoping Manty's new mail filtering will work signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
Steve McIntyre wrote: > Hmmm. That wasn't very successful. Netcfg loaded fine off the CD, but > only after I loaded it by hand. The 3c59x driver for the network card > in the test machine just didn't get loaded. > > Looking at the *nic* .udebs on the image, they seem quite old (9th > May); is that normal? I don't know about the dates, if the nic-modules udeb is for the 2.4.26 kernel and is version 0.62, then it's current. I think that the problem with netcfg is that it's not in .disk/udeb_include for these images; its priority does not cause it to be loaded by default, though we should revisit that since we seem to want it everywhere. Anyway, listing it, ethdetect, pcmcia-cs-udeb, and wireless-tools-udeb in .disk/udeb_include may fix that. -- see shy jo signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
Steve McIntyre wrote: > >See http://lists.debian.org/debian-cd/2004/05/msg00036.html > > When was the last time you checked? Looking at the jigdo file for the > latest sarge image #1: I have not tried it since I wrote the above mail. I'll download it tonight and try it tomorrow. -- see shy jo signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
Steve McIntyre wrote: > I must have blinked and missed these. If you can give me a list of > which files are needed, or a pointer as to how to work it out I'll get > onto this later today for you. See http://lists.debian.org/debian-cd/2004/05/msg00036.html -- see shy jo signature.asc Description: Digital signature
