Bug#728359: debian-installer: Install bootloader earlier?
Package: debian-installer Severity: wishlist Tags: d-i Hello, I haven't got replies to my post on debian-boot, so I'm archiving this topic as a whishlist bug: I've been wondering why the bootloader is installed only at the very end of the installation. This means that an aborted installation (eg. due to power failure or system crash) leaves the system in an unbootable state. Would it be possible to install the bootloader before tasksel is being run? That should significantly reduce the time window during which a crash yields an unbootable system. Cheers, Thiemo -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131031080201.9329.75041.reportbug@kiste
Bug#722898: wording change and wrap up
> I just committed and uploaded everything. Thank you very much. > Sorry for the delay. Not to worry! I think that it would be very nice to include the speed improvements into one of the next point releases (after they have received some coverage in testing). To minimize the risk for breakage while still getting the largest part of the speed increase, I'd suggest to backport just these two patches: * Set blocksize to 512k * Allocate buffer from heap instead of stack (Actually, the heap-instead-of-stack patch isn't even necessary, if it can be guaranteed that the stack size is larger than ~600k on all supported architectures.) Cheers, Thiemo -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOGcq_6Ev0Xw=nnqfezhmag2l4hhygcyoop+e-akkvimdfl...@mail.gmail.com
Bug#728359: debian-installer: Install bootloader earlier?
Quoting Thiemo Nagel (thiemo.na...@gmail.com): > Package: debian-installer > Severity: wishlist > Tags: d-i > > Hello, > > I haven't got replies to my post on debian-boot, so I'm archiving this topic > as a whishlist bug: > > I've been wondering why the bootloader is installed only at the very end of > the installation. This means that an aborted installation (eg. due to power > failure or system crash) leaves the system in an unbootable state. Would it be > possible to install the bootloader before tasksel is being run? That should > significantly reduce the time window during which a crash yields an unbootable > system. When I saw your first mail, my thought was indeed "hey, why not?". However, if the BL is installed very late, I guess there is a very good reason that probably dates back to the early days of D-I. Hence CC'ing Joey in order to get his input here. Joey, do you remember why bootloaders are only installed after apt-setup and the like and not just after base-installer? I bet there is a reason..:-) signature.asc Description: Digital signature
Bug#728359: debian-installer: Install bootloader earlier?
Christian PERRIER, le Thu 31 Oct 2013 11:10:39 +0100, a écrit : > Hence CC'ing Joey in order to get his input here. Joey, do you > remember why bootloaders are only installed after apt-setup and the > like and not just after base-installer? I bet there is a reason..:-) The same question actually arises also for the brltty&speakup finish-install. Currently blind users have to proceed up to the end to get the installed system accessible. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131031104100.gl7...@type.youpi.perso.aquilenet.fr
Bug#728359: debian-installer: Install bootloader earlier?
Christian PERRIER wrote: > Hence CC'ing Joey in order to get his input here. Joey, do you > remember why bootloaders are only installed after apt-setup and the > like and not just after base-installer? I bet there is a reason..:-) The only reason I can think of is that it helps prevent accidentially rebooting the computer half way through the install and encountering a strange half-installed system. -- see shy jo signature.asc Description: Digital signature
Bug#728359: debian-installer: Install bootloader earlier?
On Thu, Oct 31, 2013 at 12:20:14PM -0400, Joey Hess wrote: >Christian PERRIER wrote: >> Hence CC'ing Joey in order to get his input here. Joey, do you >> remember why bootloaders are only installed after apt-setup and the >> like and not just after base-installer? I bet there is a reason..:-) > >The only reason I can think of is that it helps prevent accidentially >rebooting the computer half way through the install and encountering a >strange half-installed system. Definitely, yes. If for some reason the installation is aborted, there is a good chance that the system will at least reboot to the other side of a dual-boot instead of leaving things dead. There are also potential issues here with ordering - the bootloaders may depend on quite a lot of packages and/or state in the system being installed. -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131031162818.gb25...@einval.com
Bug#728359: debian-installer: Install bootloader earlier?
>>The only reason I can think of is that it helps prevent accidentially >>rebooting the computer half way through the install and encountering a >>strange half-installed system. > > Definitely, yes. If for some reason the installation is aborted, there > is a good chance that the system will at least reboot to the other > side of a dual-boot instead of leaving things dead. > > There are also potential issues here with ordering - the bootloaders > may depend on quite a lot of packages and/or state in the system being > installed. Well, what I propose is to install the bootloader (and run the finish.d scripts) after the base system has been installed. Or, in other words, to postpone tasksel until after bootloader installation (and finish.d scripts). I don't see how this could result in an unbootable system as this is basically the same as running the installation full-cycle without selecting anything in tasksel. -- Cheers, Thiemo -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caogcq_75rwuheuxqxwkfemdd1scitwxuykautz2ljbo_v0g...@mail.gmail.com
Bug#728397: installation-reports: Debian 7 Wheezy CDs not bootable on iMac
Package: installation-reports Severity: normal Hi, I had to install Debian on my brothers 24 inch iMac (late 2006) with Intel CPU. First I tried Debian 7.1 multiarch netinst CD, then 7.2 amd64 netinst CD and then 7.1 i386 netinst CD. All these three were unbootable on that machine, while they worked fine on my Thinkpad T60. Then I tried with a Debian 6.0 i386 netinst CD, and that worked. So, I installed Debian Squeeze and dist-upgraded to Wheezy. I assume there is something wrong with the Debian 7 images? Greetings Holger
Bug#668128: marked as done (task-desktop: please adjust xorg depends to allow having just one input/video driver installed)
Your message dated Thu, 31 Oct 2013 20:10:08 +0100 with message-id <20131031191008.ga15...@mraw.org> and subject line Re: Bug#668128: task-desktop: please adjust xorg depends to allow having just one input/video driver installed has caused the Debian Bug report #668128, regarding task-desktop: please adjust xorg depends to allow having just one input/video driver installed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 668128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668128 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: task-desktop Severity: wishlist Currently task-desktop uses these depends on video, input drivers: Depends: ... xserver-xorg-video-all, xserver-xorg-input-all It would be good if it could use these depends instead: Depends: ... xserver-xorg-video-all | xorg-driver-video, xserver-xorg-input-all | xorg-driver-input This way people with laptops would be able to remove drivers that they do not need and save some disk space. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- Julien Cristau (2012-04-10): > On Mon, Apr 9, 2012 at 10:25:53 +0800, Paul Wise wrote: > > > Package: task-desktop > > Severity: wishlist > > > > Currently task-desktop uses these depends on video, input drivers: > > > > Depends: ... xserver-xorg-video-all, xserver-xorg-input-all > > > > It would be good if it could use these depends instead: > > > > Depends: ... xserver-xorg-video-all | xorg-driver-video, > > xserver-xorg-input-all | xorg-driver-input > > > > This way people with laptops would be able to remove drivers that they > > do not need and save some disk space. > > > Please don't. The drivers are tiny, so it doesn't save much, and it > makes it more likely to result in broken installs. So I think this is a > bad idea. Agreed, closing accordingly. Mraw, KiBi. signature.asc Description: Digital signature --- End Message ---
Bug#666977: marked as done ([src:tasksel] Please remove dependencies of tasks on tasksel)
Your message dated Thu, 31 Oct 2013 20:13:29 +0100 with message-id <20131031191329.ga15...@mraw.org> and subject line Re: Bug#666977: [src:tasksel] Please remove dependencies of tasks on tasksel has caused the Debian Bug report #666977, regarding [src:tasksel] Please remove dependencies of tasks on tasksel to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 666977: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666977 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: tasksel Version: 3.08 Severity: wishlist This is similar to #413250, making tasks usable without having to install tasksel. Now having packages for tasks is great (although it does make a fair amount of task packages!), as tasks can now be used without using tasksel. But tasks cannot yet be used without *installing* tasksel, as installing these tasks requires the administrator to also install tasksel. For example, task-kde-desktop depends on tasksel. The only reason task-kde-desktop depends on tasksel is that /usr/share/doc/task-kde-desktop is a symlink to /usr/share/doc/tasksel. This contains tasksel's changelog, README, TODO and copyright. TODO and README are more confusing than helpful for tasks. That leaves the changelog and copyright. Only the changelog has a significant size. These could either be duplicated in all task packages, or a new dependency package could be created (for example, tasks-common or tasksel-common). I wouldn't mind a dependency on tasksel-data if tasksel-data wouldn't depend on tasksel. My problem with this dependency is not tasksel itself, but tasksel's dependency on aptitude. --- End Message --- --- Begin Message --- Filipus Klutiero (2012-04-02): > My problem with this dependency is not tasksel itself, but tasksel's > dependency on aptitude. kibi@arya:~$ apt-cache show tasksel|grep aptitude kibi@arya:~$ aptitude why tasksel aptitude i tasksel Depends apt i apt Suggests aptitude | synaptic | wajig Closing accordingly. Mraw, KiBi. signature.asc Description: Digital signature --- End Message ---
Adjusting kde-desktop task?
Hello, while looking briefly at the tasksel bug list, I saw #385650: tasksel: The kde-desktop task should list kaffeine(-mozilla) media player → http://bugs.debian.org/385650 Since that's quite old, I'm not sure it still applies, and I guess you Qt/KDE guys know better if there's anything that needs adjusting in kde-desktop. Do you have a patch for tasksel? :-) Mraw, KiBi. signature.asc Description: Digital signature
Bug#728359: debian-installer: Install bootloader earlier?
Thiemo Nagel writes: >>>The only reason I can think of is that it helps prevent accidentially >>>rebooting the computer half way through the install and encountering a >>>strange half-installed system. >> >> Definitely, yes. If for some reason the installation is aborted, there >> is a good chance that the system will at least reboot to the other >> side of a dual-boot instead of leaving things dead. >> >> There are also potential issues here with ordering - the bootloaders >> may depend on quite a lot of packages and/or state in the system being >> installed. > > Well, what I propose is to install the bootloader (and run the > finish.d scripts) after the base system has been installed. Or, in > other words, to postpone tasksel until after bootloader installation > (and finish.d scripts). I don't see how this could result in an > unbootable system as this is basically the same as running the > installation full-cycle without selecting anything in tasksel. Which is liable to be _very_ confusing, and could easily waste a lot of time and/or convince the victim that Debian is an incomprehensible mess. =-=-=- I suppose that could be mitigated if we created a file something like: /target/Instalation-In-Progress as soon as we mount the target system's root, which we'd delete just before unmounting the file system at the end of the install, and then check for that after the first boot and if found pause the boot with a big warning about an incomplete install. The first-boot-install-check script could offer to delete the file if found, and after that, delete itself to keep things tidy. I'm not sure that's a good idea though -- it seems somewhat fragile. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://ftp.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpVlQmhI9LZE.pgp Description: PGP signature
Changes for d-i, tasksel and d-cd
Hey folks,
Re some changes that we've spoken about in the past...
First of all, we spoke about switching to using the graphical
installer by default back last year at DC12. But we never actually
made the change then. I think it's time now, what do you guys think?
Secondly: xfce as default desktop? I'm tempted to do this regardless
of the current init debate, if nothing else just to give us a useful
*small* system from a single CD again.
Finally, I've been getting some useful feedback on the front of
exactly which images we should be making at this point, and I'm
thinking of dropping most of the CD options, leaving us with:
* netinst
* *1* single CD with more content (xfce, more useful stuff)
* DVD sets (and bigger)
I'm thinking more about what we could/should fit into the "useful
stuff" category, plus what we should call it ("recommended", "Debian
developer toolbox", "good stuff"? *grin*). I remember Bdale asking for
something like this last year at the debian-cd BoF at DC12, and there
were general murmurs of support. Can we add sensible extra tasksel
task(s) to cover the things that *we* consider useful? I'm thinking
about:
* misc devel utils
* tools for wireless
* all the bits you'd want to be able to configure your latest machine
so it comes up on the network automatically so you can
configure/install it further easily remotely
* ...
Thoughts?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131031233931.gd25...@einval.com
Re: Changes for d-i, tasksel and d-cd
Hi Steve!
Steve McIntyre (2013-10-31):
> First of all, we spoke about switching to using the graphical
> installer by default back last year at DC12. But we never actually
> made the change then. I think it's time now, what do you guys think?
That's something I stumbled upon again very recently, and yes, we should
probably do that like right now. :)
> Secondly: xfce as default desktop? I'm tempted to do this regardless
> of the current init debate, if nothing else just to give us a useful
> *small* system from a single CD again.
As I have said on various occasions those last days, I don't think it's
a call for me to make, but I don't think it's a bad idea.
On a personal note, I'm slightly sad for the GNOME folks since they've
been doing a great job to provide us with a nice support (including a11y
things etc.), but I guess Xfce should do just fine as well, and having a
small, useful system in a single CD looks a very fine thing to have
(again). As we saw lately, people still actively rely on a single CD, so
let's have that again! :) [and that's what you're mentioning a few lines
below anyway, oops.]
> Finally, I've been getting some useful feedback on the front of
> exactly which images we should be making at this point, and I'm
> thinking of dropping most of the CD options, leaving us with:
>
> * netinst
> * *1* single CD with more content (xfce, more useful stuff)
> * DVD sets (and bigger)
Doesn't look unreasonable to me at first glance, but remember I don't
know anything about d-i/cdimages.
> I'm thinking more about what we could/should fit into the "useful
> stuff" category, plus what we should call it ("recommended", "Debian
> developer toolbox", "good stuff"? *grin*). I remember Bdale asking for
> something like this last year at the debian-cd BoF at DC12, and there
> were general murmurs of support. Can we add sensible extra tasksel
> task(s) to cover the things that *we* consider useful? I'm thinking
> about:
>
> * misc devel utils
> * tools for wireless
> * all the bits you'd want to be able to configure your latest machine
>so it comes up on the network automatically so you can
>configure/install it further easily remotely
> * ...
>
> Thoughts?
I happened to have looked at some tasksel bug reports this afternoon,
and it looked like there was some kind of a 10-ish task limit that can
be proposed. The possibility of having 2 levels to have more choices was
brought up, but apparently never implemented. Maybe that {c,w}ould be a
prerequisite to having more options like those you mentioned?
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Changes for d-i, tasksel and d-cd
On Thu, 2013-10-31 at 23:39 +, Steve McIntyre wrote: [...] > * tools for wireless [...] Should be included in task-desktop and task-laptop. Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part
Bug#653717: marked as done (Missing current wireless networking packages)
Your message dated Fri, 01 Nov 2013 01:52:33 + with message-id <1383270753.2782.49.ca...@deadeye.wl.decadent.org.uk> and subject line Re: Missing current wireless networking packages has caused the Debian Bug report #653717, regarding Missing current wireless networking packages to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 653717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653717 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: task-laptop Version: 3.07 Severity: important iw is the more capable tool for wireless configuration of all modern Linux wireless drivers. Unfortunately we cannot yet remove the latter since some older drivers do not support the nl80211 API. crda is required for loading wireless regulatory information, without which the kernel will default to the built-in 'world' regulatory domain which has restricted channels and power levels. Ben. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Version: 3.15 This is more-or-less fixed: iw is now a dependency, and recommends crda. Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part --- End Message ---
Re: Uploading linux (3.11.5-1)
Thanks for the heads-up. Ben Hutchings (2013-10-13): > Notable packaging changes in 3.11: > > - armhf single-platform flavours were removed > - armhf has an 'armmp-lpae' flavour which, surprise, has LPAE enabled Ian is the arm* guy those days. :) > - ext4 module handles ext2 and ext3 filesystem types in all kernel > configurations; the corresponding udebs are gone I've just pushed a fix for debian-installer's pkg-lists: http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=4382120f71447f5fe73cbdf4fbeb88098c2c2966 which should fix some FTBFS after I switched from 3.10-3 to 3.11-1. FTR we'll need to bump the ABI on arm only as soon as Ben uploads a new linux package. From a very quick grep, things under d-i's packages/ directory that might need adjusting at some point: | kibi@arya:~/debian-installer/packages$ grep -rI modprobe|grep ext|sort | busybox/modutils/modprobe-small.c: Note: currently, help system shows modprobe --help text for all aliased cmds | kickseed/setup/hd:log-output -t kickseed modprobe -q ext2 || true | live-installer/support/extX: modprobe $1 || true | partman-basicfilesystems/init.d/kernelmodules_basicfilesystems: modprobe ext2 >/dev/null 2>/dev/null; then | partman-ext2r0/init.d/kernelmodules_ext2r0:if modprobe ext2 >/dev/null 2>/dev/null; then | partman-ext3/init.d/kernelmodules_ext3: modprobe ext3 >/dev/null 2>/dev/null; then | partman-ext3/init.d/kernelmodules_ext3: modprobe ext4 >/dev/null 2>/dev/null; then Ben just confirmed on IRC that both "mount -t ext[23]" and "modprobe ext[23]" should work transparently with ext4, so we should be mostly good. Except for things like this script, which relies on module names in /proc/modules: partman-basicfilesystems/init.d/kernelmodules_basicfilesystems → http://anonscm.debian.org/gitweb/?p=d-i/partman-basicfilesystems.git;a=blob;f=init.d/kernelmodules_basicfilesystems;h=f3d950d78ec7c457ca6572d094fdd6308410fa19;hb=HEAD > - linux-headers-*, linux-image-*, linux-source-* will no longer provide > virtual packages I didn't check yet whether d-i is affected by this change. > - A large number of probably useless drivers were disabled Shouldn't be too much of an issue for us. Mraw, KiBi. signature.asc Description: Digital signature
