Re: Reverting to GNOME for jessie's default desktop
Gunnar Wolf writes ("Re: Reverting to GNOME for jessie's default desktop"):
> And yes, many such computers are currently in use. And it would be a
> disservice not to provide CDs anymore. But that criteria should not be
> what guides our default for installation; a CD might not be able to
> have the full GNOME environment, but the computer using the CD would
> not be able to use it anyway.
Wouldn't such a computer be able to use xfce ? I have a computer from
2003-2005 that seems to be running xfce perfectly happily (and I have
reinstalled it recently).
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21476.57043.847379.678...@chiark.greenend.org.uk
Re: Reverting to GNOME for jessie's default desktop
Jordi Mallach writes ("Reverting to GNOME for jessie's default desktop"):
> It's been around 9 months since tasksel changed (for real) the default
> desktop for new installs. At the time of the change, it was mentioned
> the issue would be revisited before the freeze, around debconf time.
Fascinating as this discussion is, I think it is at risk of becoming
too much of a time sink. I think that it would be useful to have some
authoritative guidance from those in Debian who are responsible for
this decision. AFAICT that is the tasksel maintainers.
So I would appreciate it if the tasksel maintainers would let us know:
Do you intend to review (or are you reviewing) the decision taken in
July 2012 [1] ? If so, is this discussion here on -devel useful ? If
it is useful, what questions should we be focusing on ?
Ian.
[1]
http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commit;h=2a962cc65cdba010177f27e8824ba10d9a799a08
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21482.8088.55315.575...@chiark.greenend.org.uk
Bug#923091: That merged-usr is mandatory is RC
Control: severity -1 serious In #923091, Guillem (with dpkg maintainer hat on) asks for a base-installer option to allow installing buster without merged-usr. Guillem filed the bug as `wishlist' but given the controversy it seems to me that it should be RC if for no other reasons than social cohesion. CCing the TC FYI (they have already been involved in merged-usr debates via #914897) and the release team, in case they have an opinion. FAOD I am not a maintainer of base-files but AFAICT the base-files maintainer has not expressed an opinion about severity. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#923091: That merged-usr is mandatory is RC
(sending this because I got the release team address wrong)
Ian Jackson writes ("That merged-usr is mandatory is RC"):
> Control: severity -1 serious
>
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.
>
> Guillem filed the bug as `wishlist' but given the controversy it seems
> to me that it should be RC if for no other reasons than social
> cohesion.
>
> CCing the TC FYI (they have already been involved in merged-usr
> debates via #914897) and the release team, in case they have an
> opinion. FAOD I am not a maintainer of base-files but AFAICT the
> base-files maintainer has not expressed an opinion about severity.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#789798: Bug#792547: grub-installer: add option to _not_ install to UEFI boot order
Ian Jackson writes ("Bug#792547: grub-installer: add option to _not_ install to
UEFI boot order"):
> I see that Ian C updated this patch (in July 2015) and reported
> testing it successfully. Is it now OK ?
every Debian release I update our workaround to apply to the current
release. FTR, I am just updating our workaround to apply to buster.
(I see the grub2 package is RFH.)
Ian.
Bug#940028: debian-installer multi-console race with preseeding
I just experienced this bug. Thanks for some very useful hints and pointers from Colin Watson. This is particularly awkward to debug because one of the parallel invocations of d-i is usually invisible. And the precise results are the results of races and can be different from one run to another. In my tests I frequently saw: main-menu[330]: /var/lib/dpkg/status: No such file or directory Now that we have looked at the code I think that message is quite unlikely unless something is seriously wrong, such as a corrupted initramfs or this parallel execution bug. I mention this as a useful search term, hoping that affected users may find this bug report. You can see whether your configuration is going to be affected by looking at /proc/consoles in the installer environment: if it contains only one line, you are OK. If it has several you will be hit by this bug (which exists in buster and as of now has not yet been fixed, so is in current bullseye too). A workaround is to specify *exactly one* appropriate console= on the kernel command line. This causes the kernel to report only that console in /proc/consoles and the bug is avoided. FTR, the offending commit is https://salsa.debian.org/installer-team/rootskel/commit/b6048aafed7d73ba42da04d6f7a798710f271384 CCing its authors. Thanks, Ian.
Bug#940028: debian-installer multi-console race with preseeding
Ian Jackson writes ("debian-installer multi-console race with preseeding"):
> A workaround is to specify *exactly one* appropriate console=
> on the kernel command line. This causes the kernel to report only
> that console in /proc/consoles and the bug is avoided.
This seems to work only sometimes. In my experience it worked for an
arm64 server but not for an x86 PV Xen guest. There does not appear
to be another workaround that does not involve modifying the installer
initramfs.
Ian.
Bug#940028: debian-installer multi-console race with preseeding
Thanks for the patch. Unfortunately (due mostly to me flailing) my tests of this are so far inconclusive. I will get back to this in January. Regards, Ian.
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Package: debootstrap Version: debootstrap/1.0.110 Severity: serious Merged /usr is now the default in buster. As discussed on debian-devel, however, binary packages built on a merged-usr system are not installable on a non-merged-usr system. I think we would like ad hoc builds of packages from one buster machine to be installable on other buster machines. That is not compatible with the current approach. This was an unanticipated problem. The discussion on -devel has not reached a consensus on a way forward, and there is no transition plan. Accordingly, please revert this change for buster. IMO this revert should be done quickly, to minimise the number of installs which will generate broken packages. If you do not agree with my proposal, then I still think we should revert the change in sid/buster while the matter is discussed. This affects stretch-backports too, but I think it will be most convenient to file a separate bug for that. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#914898: debootstrap, stretch-backports: Please disabled merged /usr by default
Package: debootstrap Version: debootstrap/1.0.110~bpo9+1 Severity: serious In #914208 Simon McVittie writes: > [merge-/usr] is now the default in stretch-backports' debootstrap As discussed on debian-devel, however, binary packages built on a merged-usr system are not installable on a non-merged-usr system. Obviously we would like ad hoc builds of packages from one stretch machine to be installable on other stretch machines. I do not see any way in which this could be resolved for stretch. Accordingly, please urgently revert this change for stretch-backports. Ian. (I have CC'd debian-release@lists because this seems like it wants the attention of the stable release team. I wasn't able to find a separate contact address for the stable release team here https://www.debian.org/intro/organization and I have a vague memory that this is somehow the same list. Please redirect me if I am wrong.) -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Control: reassign -1 tech-ctte
Dear Technical Committee. I don't know if you are all aware of the
discussion surrounding this, so I will recap:
Recently debootstrap was changed to do merged-/usr by default, so that
/bin -> /usr/bin etc.
It was discovered that when this change took effect on the Debian
buildds, the buildds started to build packages which do not work on
non-merged-/usr systems.
This is a special case of a general problem: buster systems with
merged-/usr sometimes build packages which are broken on
non-merged-/usr systems.
Some people have suggested that this should be fixed by making
merged-/usr mandatory for buster. However, there is no transition
plan for this as yet and I don't think Debian is ready to commit to do
that.
So I believe that this change should be immediately reverted in sid
and buster, so that we do not prejudge the situation by increasing the
number of buster installs in the field which generate packages which
are broken on non-merged-/usr systemss.
I filed this bug against debootstrap but its maintainers do not agree:
Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled
merged /usr by default"):
> We already have a change queued to revert it for build chroots. I don't
> believe anything more is warranted at this stage.
Obviously I disagree. I think the question is urgent. Please would
you rapidly overrule the debootstrap maintainers.
After we have ceased introducing new lossage we can have a proper
conversation about what the plan ought to be for buster and bullseye.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled
merged /usr by default"):
> On 11/28/18 2:49 PM, Ian Jackson wrote:
> > This is a special case of a general problem: buster systems with
> > merged-/usr sometimes build packages which are broken on
...
> I'd suggest that this should be fixed by not shipping any packages that
> aren't built on buildds.
It would be quite a radical departure for Debian to no longer support
"I built this package for my mate to install on their computer".
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Hierarchical tasksel / Blends support (Was: Debian Installer Buster Alpha 5 release)
Andreas Tille writes ("Re: Hierarchical tasksel / Blends support (Was: Debian
Installer Buster Alpha 5 release)"):
> That's really relieving for me to hear since I was scared about the need
> to learn Perl to a way higher level than the basics I have and I admit
> there are lots of tasks on my desk regarding other Blends related
> things.
Although I support what you are doing here and I think it is
important, I don't have time to contribute properly. I can however
offer my services as an ad-hoc Perl consultant/tutor/whatever.
Catch me as Diziet on oftc or freenode, or email me here.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Steve McIntyre writes ("Bug#914897: tech-ctte: Should debootstrap disable
merged /usr by default?"):
> There is a deeper worry about builds that may be done against the
> "weak" background. Although buildd chroots are easily fixed up,
> there's going to be a (small, but unknown) set of maintainers who
> might be uploading binaries from merged systems. I think we're making
> good progress on source-only uploads and building in clean chroots
> etc., but... It's also likely not easy to pick up on "wrong" binary
> packages built this way.
I think this is a valid concern but puts it far too narrowly.
There is a persistent misunderstanding embodied in your comments here
(or rather, embodied in a significant omission): the notion that the
only reason to build a package on a Debian system is for upload to
Debian.
Once I put it like that, this notion is obviously false. What is
happening is that the conversation is focusing on our own needs,
within Debian to help us produce Debian, to the exclusion of the needs
of our users. That is a natural tendency of course, but we must
resist it.
Back in the wider world, of course many people build packages on
Debian systems for installation `somewhere else'. I have done it
myself and probably many of the people reading this message have too.
What is implicitly going on here is that it is mostly-tacitly[2] being
assumed (or declared) that `I built this .deb on my laptop[1] and gave
it to my friend' is wrongheaded.
I don't think doing that is wrongheaded. Certainly it is extremely
common; we don't have any public pronouncements saying it is somehow
wrong; and we have had little discussion where we as a project decided
that this was now a use case which we feel free to just break.
Personally I think that this is a very important thing to keep
working. It is the very core of users' collective software freedom.
And that software freedom needs to be easy to exercise in practice.
Despite a lot of excellent tooling, chroots are still not entirely
trivial to set up and maintain.
I would invite the TC to read this manpage, which is trying to explain
to a Debian user how to change the programs on their own computer
https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
and then consider how much even worse it would be if we had to write
about chroots too.
To TC members who are minded to uphold the current approach, I would
ask: can you please explicitly state your opinion on this ? That is:
Is it OK for a Debian user to build .deb on their laptop and give it
to their friend ? If it is OK, how will we make sure that it does
not pointlessly break ?
I readily admit that there are many ways that this can produce a
result significantly different to the official Debian package,
particularly because the package build system may configure itself
differently in the the presence of unexpected. The resulting package
is probably not going to be suitable for wide distribution.
But those kind of problems are (a) not serious in practice
(b) generally have obvious symptoms and (c) are easily worked around
by various means. Working around a usrmerge-generated failure is
difficult; it usually involves doing serious violence to the upstream
build system, or perhaps horrific rules file bodges.
Thanks,
Ian.
[1] Implicitly, without using a chroot.
[2] IIRC some people suggested this explicitly in the thread in
d-devel.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#924037: Please add anacron back to task-desktop and task-laptop
Package: task-desktop Version: 3.49 The rationale for this change is IMO not correct. Michael Biebl wrote: | all important cron jobs have a corresponding .timer unit This is not a sufficient condition. Firstly, it is necessary for all cron jobs, not just ones considered `important', to have a corresponding timer unit, for this change to be correct. Secondly, this change simply breaks systems without systemd. If (which I deny) it is a good idea to change this for systemd systems, measures should be taken to arrange that non-systemd systems still get anacron. For example, a dependency on systemd-sysv | anacron (Thirdly, and tangentially, for reasons explored further in the debian-devel thread, systemd timer units are not a suitable replacement for many applications.) Also I think that when changes are being made which might break non-systemd systems, the Debian Ecosystem Init Diversity team debian-init-divers...@chiark.greenend.org.uk should be consulted so that the appropriate fixes can be developed. Finally, this change is rather late wrt the freeze. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#1021918: #1021918: Kernel module blacklisting doesn't work
Control: retitle -1 Kernel module blacklisting doesn't work Control: tags -1 confirmed Hi. I just did an install of bullseye on an amd64 machine with a troublesome wifi interface - suspected hardware fault[1]. We did achieve a successful install, blacklisting the module for the bad hardware, but we did encounter a version of this bug. We edited the vmlinuz line in the installer image boot menu (we were using the non-graphical installer) to add modprobe.blacklist=rtw88_8723de The installer was able to find the USB wifi dongle we'd added, didn't touch the cursed hardware, and ran to completion. But, as described in this bug report, it had created a file /etc/modprobe.d/blacklist.local.conf containing just blacklist modprobe I deleted this using the installer shell before rebooting into the installed system. The installer had *not* included anything in GRUB_CMDLINE_LINUX. So the troublesome hardware *wasn't* blacklisted on our reboot. Happily nothing tried to use it. I manually created a file /etc/modprobe.d/rtw88.conf containing blacklist rtw88_8723de blacklist rtw88_8723d and that has resulted in a working setup. Thanks, Ian. [1] The fault results in periodic wifi breakage and strange symtoms with an older Debian release. With the bullseye installer, it causes the installer environment to reliably hang (crashed with no response even to capslock led). -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#602506: HP DL165 boot crash with lenny i386 686 but OK with -bigmem or amd64
Cyril Brulebois writes ("Re: Bug#602506: HP DL165 boot crash with lenny i386
686 but OK with -bigmem or amd64"):
> Either way, kernel selection was adjusted over the last release cycles,
> especially after kernel flavours were reduced to a bare minimum. I doubt
> this bug is still current, so closing for now.
Fair enough. I don't have a reasonable way to try to repro this right
now. If I do get a chance to try this with wheezy I will reopen this
bug if it is still present.
Thanks for your consideration.
Regards,
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21260.40119.532700.885...@mariner.uk.xensource.com
Bug#820818: partman is not able to resize nvme0n1p3 in d-i
Cyril Brulebois writes ("Re: Bug#820818: partman is not able to resize
nvme0n1p3 in d-i"):
> This is still welcome but probably not necessary given other bits of
> your bug report. I've just pushed a totally untested patch to the
> pu/resize-nvme-820818 branch:
>
> https://anonscm.debian.org/cgit/d-i/partman-partitioning.git/commit/?h=pu/resize-nvme-820818&id=348a501524e7a2cdd3e04d5ec1c9f9d2aead3743
>
> Would you be interested in testing an image with such an update?
Yes, if you're reasonably sure it won't mess anything else up. I can
(take a backup of my laptop and) provide a test partition for it to
try to resize.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#820818: partman is not able to resize nvme0n1p3 in d-i
Philip Hands writes ("Re: Bug#820818: partman is not able to resize nvme0n1p3
in d-i"):
> BTW I just pushed Ben's alternative suggetion to the
> pu/resize-nvme-820818-benh branch:
>
>
> https://anonscm.debian.org/cgit/d-i/partman-partitioning.git/commit/?h=pu/resize-nvme-820818-benh&id=62c696450a206d7ee08d570fef4c2923a03042a8
>
> (also untested)
Is it easy for you to make an image to give to me to test that ?
Ian.
Bug#820818: partman is not able to resize nvme0n1p3 in d-i
Package: partman-partitioning (I'm afraid I don't know the right package name nor the version number. I searched with a general web search for `reporting bugs debian-installer' and `reporting bugs partman', and looked on https://wiki.debian.org/DebianInstaller, and didn't find any guidance.) I asked the partitioner in the Stretch Alpha 5 amd64 debian-installer (firmware-stretch-DI-alpha5-amd64-netinst.iso) to resize an ext4 partition on an NVME device. I did this from: You are editing partition #3 of /dev/nvme0n1. This partition is [blah blah] ext4 [blah]. It failed, saying "Because of an unknown reason it is impossible to resize" etc. The log on VC4 says: Apr 12 18:00:03 partman: Error running 'tune2fs -l /dev/nvme0n1' Obviously that is not the right device name. I asked for a shell on another VC, and tune2fs -l /dev/nvme0n1p3 printed the kind of output I would expect. I hope this bug report is helpful. I can probably reproduce the problem and maybe save debug logs etc. The partition is actually the filesystem of the laptop vendor's[1] preinstalled Ubuntu trusty. So I will try to resize it from within the Ubuntu installation. I hope that when I make new partitions it will manage to choose the correct device to write to when it creates the filesystem... Thanks, Ian. [1] Dell, an XPS-2013 Developer Edition 2016. The laptop is booting in UEFI mode and the NVME SSD seems to have a GPT partition table.
Bug#820818: partman is not able to resize nvme0n1p3 in d-i [and 1 more messages]
Ian Jackson writes ("partman is not able to resize nvme0n1p3 in d-i"):
> It failed, saying "Because of an unknown reason it is impossible to
> resize" etc. The log on VC4 says:
>
> Apr 12 18:00:03 partman: Error running 'tune2fs -l /dev/nvme0n1'
>
> Obviously that is not the right device name. I asked for a shell on
> another VC, and
>
> tune2fs -l /dev/nvme0n1p3
>
> printed the kind of output I would expect.
More information: I was able to resize the partion by hand from the
debian-installer shell prompt, with resize2fs, sfdisk -l, nano, and
sfdisk. The result seems correct.
The rest of the installer seems to be able to write to the correct
devices. For example, it has already successfully run mkfs to create
my /boot on nvme0n1p5.
Ian.
Bug#601363: closed by Holger Levsen (dealing with old installation-reports and d-i related bugs)
reopen 601363 = thanks Holger writes: > thank you for submitting installation reports, much appreciated. Thanks for your attention. But I'm afraid I think you may have made a mistake with this particular bug. It wasn't an installation report. It was a request for a specific change in the software. I imagine that someone familiar with the code structure would be able to quickly see whether it was still relevant. I see no reason to think that it isn't. I also hope that my report contains enough information to find the relevant code and make the change I request. I'm afraid I can't easily reproduce this problem, but it does still sometimes happen with squeeze. I haven't yet upgraded the environment which (occasionally) experiences the bug to wheezy. Thanks, Ian. -- 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/20967.53575.55862.587...@mariner.uk.xensource.com
Bug#866401: Please print proper error message when download fails
Package: debootstrap Version: 1.0.67 I run an automated test system. Recently we had a test fail, because an invocation of "xt-install-image" from the xen-tools package failed. xt-install-image printed this: Installation method: debootstrap Running command 'xt-install-image --hostname=debian.guest.osstest --location=/tmp/enTikPkbpQ --dist=jessie --install-method=debootstrap --mirror=http://ftp.debian.org/debian --cache=yes --cachedir=/var/cache/apt/archives/ --arch=armhf 2>&1' failed with exit code 32512. Aborting See /var/log/xen-tools/debian.guest.osstest.log for details In that logfile (which was nominated by xt-install-image) there is only this: I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 75DDC3C4A499F1A18CB5F3C8CBF8D6FD518E17E1) I: Retrieving Packages I: Retrieving Packages E: Couldn't download dists/jessie/main/binary-armhf/Packages Running command '/usr/sbin/debootstrap --arch armhf jessie /tmp/enTikPkbpQ http://ftp.debian.org/debian 2>&1' failed with exit code 256. I think the final message was printed by xt-install-image, and the previous messages by debootstrap. My complaint is about this message: E: Couldn't download dists/jessie/main/binary-armhf/Packages I would like to know: * What URL (or other downlaod technique) was being used * What IPv4 or IPv6 address was being communicated with * Whether the error was due to - a corrupted file and if so please state the location of the corrupted copy and the expected checksum so that the corrupted file can be inspected to see what is wrong - an http error response and if so please print at least the HTTP status line and ideally log the error document somewhere - an http protocol violation and if so a description of what the violation was - a networking system call failure and if so which system call and what the errno value was - something else including appropriate details Thanks, Ian.
Bug#839046: debootstrap: enable --merged-usr by default
I had a conversation with Marco about this at FOSDEM. I'm sorry to say that I still don't understand why we would make this change. The links provided do not explain what the benefits are. And there are downsides. One obvious downside is reduced testing of existing systems which have filesystem layouts not easily compatible with "merged /usr" (or at least, not compatible without wholesale moving of stuff about, which seems like a risk which would need a substantial justification). Another bad consequence is that some existing configurations that do not, for whatever reason, mount /usr early, will be harder to set up. One may argue (as Russ cogently does) that the distinction between /usr and / cannot be coherently maintained as a distro-wide property of software if we take into account all the realistic use cases. But there are some traditional configurations where the distinction _can_ be maintained and we shouldn't break those things without a reason. Also, I fear that unless we provide a straightforward way to retain separate /usr, including an appropriate d-i command line option, we will get further pushback and anger from traditionalists. We risk reopening old wounds (see some of the less temperate responses earlier in the thread Ansgar links to as [1]). If there are benefits of changing the default arrangement of new installs, it would be worth thinking how those benefits could be obtained without the damage to our community (even if the objections are felt, by many people, to be technically unsound). Finally, I have to say that I think that this summary from Ansgar is not really accurate: > As mentioned earlier, I would like to see --merged-usr enabled by > default for Debian Stretch. The last discussion on -devel@[1] was > quite positive; I had some additional positive feedback on IRC. ... > [1] <https://lists.debian.org/debian-devel/2016/09/msg00269.html> That is a link to a message from Russ which mostly explains why mounting /usr early (ie in the initramfs, by default) is a good idea. That has now been implemented and has caused very little push-back. But this bug report requests something entirely different: it is about actually moving the contents of /bin into /usr/bin, etc. It is also not fair to say that the discussion was "quite positive". There was a good deal of opposition of various kinds, much of it quite heated. Thanks for your attention, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#694068: (solved) Re: wireless fail after stretch installation
bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> I think the idea needs to be talked over a little better, because using
> e/n/i for wireless by default after first boot has implications if the
> user (who is clueless) later installs a desktop environment.
If installing a desktop environment, after putting the wireless in
/e/n/i, does not work, then that is a bug in the desktop environment,
surely ?
In practice I would expect the config in /e/n/i to keep working
because nowadays network-manager will ignore things in /e/n/i. The
difficulty would only come if you
- used the installer to install a bare system over wifi
- later install network-manager or wicd
- then expect the system to give you a gui prompt for new wifi
networks, rather than expect to have to edit /e/n/i
It would be possible for the n-m and wicd packages to spot when this
is happening and offer to take over the interface. And I do think
that in the absence of code to do that, it would be more important to
make the barebones system work in the first place, than to improve the
behaviour you later install n-m.
(I'm not sure if what I say about wicd is right. I use n-m on
machines I have where the user needs to switch between various network
connections, wifi networks, etc.)
> I'd hate to see the bug tracker turned into a discussion forum though.
The bug tyracker is precisely the right place to discuss how to solve
a particular bug. So I have CC'd it.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#443245: root's .bashrc PS1 setting defeats debian_chroot
Package: rootskel
Version: 1.50
The default /root/.bashrc contains this line:
export PS1='\h:\w\$ '
That line isn't necessary because /etc/bash.bashrc does a similar but
better thing:
PS1='${debian_chroot:+($debian_chroot)[EMAIL PROTECTED]:\w\$ '
Indeed, the /root/.bashrc PS1 setting defeats attempts to set
debian_chroot (as an exported environment variable, or via /etc) to
affect root's prompt.
I think the PS1 setting in /root/.bashrc can safely be removed.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#602506: HP DL165 boot crash with lenny i386 686 but OK with -bigmem or amd64
Package: base-installer On an HP DL165 (AMD-based) system, lenny i386 does not install, although lenny amd64 works fine. The installer kernel boots properly and runs normally; the installation runs to completion (although I have to interactively ignore a couple of warnings about the cciss RAID controller[1], though the lenny amd64 installer kernel has no difficulty). However, when the installer reboots to try to boot the installed system, the installed system's kernel crashes on boot while enumerating the processors. See attached serial console log. It was suggested to me by Colin Watson that the cause might be that the installer is picking the wrong kernel flavour. From the serial log I see it chose 2.6.26-2-686. When I run the install again and select linux-image-2.6.26-2-486, the install completes successfully. Having done so and installed linux-image-2.6-686_2.6.26+17+lenny1_i386 and linux-image-2.6-686-bigmem_2.6.26+17+lenny1_i386. The 686-bigmem kernel boots fine. The vanilla 686 one crashes. This bug is against base-installer because Colin Watson suggested to me that the problem is that it's picking the wrong kernel flavour. However, perhaps I should also file a bug against the 686 kernel ? Ian. [1] Unable to determine geometry of file/device /dev/cciss/c0d0. You should not use Parted unless you REALLY know what you're doing! Warning! 1. Ignore [*] 2. Cancel Prompt: '?' for help, default=1> 1 processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 8 model name : Six-Core AMD Opteron(tm) Processor 2427 stepping: 0 cpu MHz : 2194.501 cache size : 512 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 6 apicid : 8 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 4392.39 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 8 model name : Six-Core AMD Opteron(tm) Processor 2427 stepping: 0 cpu MHz : 2194.501 cache size : 512 KB physical id : 0 siblings: 6 core id : 1 cpu cores : 6 apicid : 9 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 4389.20 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 2 vendor_id : AuthenticAMD cpu family : 16 model : 8 model name : Six-Core AMD Opteron(tm) Processor 2427 stepping: 0 cpu MHz : 2194.501 cache size : 512 KB physical id : 0 siblings: 6 core id : 2 cpu cores : 6 apicid : 10 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 4389.20 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 3 vendor_id : AuthenticAMD cpu family : 16 model : 8 model name : Six-Core AMD Opteron(tm) Processor 2427 stepping: 0 cpu MHz : 2194.501 cache size : 512 KB physical id : 0 siblings: 6 core id : 3 cpu cores : 6 apicid : 11 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16 popcnt lahf_lm c
Bug#602534: partman/exception_handler not preseedable
Package: partman-base Running the lenny i386 installer on an HP DL165, I get this warning: Unable to determine geometry of file/device /dev/cciss/c0d0. You should not use Parted unless you REALLY know what you're doing! Warning! 1. Ignore [*] 2. Cancel Prompt: '?' for help, default=1> As it happens I know that in my situation this warning is spurious and I want to fully automate the install, so after reading the installer syslog I added this to my preseed file: d-i partman/exception_handler select Ignore However, this merely changed the warning: Unable to determine geometry of file/device /dev/cciss/c0d0. You should not use Parted unless you REALLY know what you're doing! [Press enter to continue] This is of course useless for me because I'm trying an automated install. IMO the answer to this question should be preseedable somehow. Obviously some kind of pattern matching would be best, but in the meantime I don't mind if overriding this means I have to ignore _all_ partman exceptions - the knob should be there for me to do that if I want to. (For completeness: Colin Watson suggested I could use an early_command to remove db_fset partman/exception_handler seen false from /lib/partman/lib/base.sh.) Ian. -- 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/19668.16625.22601.177...@mariner.uk.xensource.com
Re: Bug#605009: serious performance regression with ext4
Olaf van der Spek writes ("Re: Bug#605009: serious performance regression with
ext4"):
> On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o wrote:
> > I am guessing you are doing (a) today --- am I right? =C2=A0(c) or (d)
> > would be best.
>
> Are there any plans to provide an API for atomic (non-durable) file
> updates, not involving fsync?
Yes. Such an API has already been defined by POSIX, SuSv3, et al.
It's called "rename".
dpkg used it correctly before filesystem bugs (and associated
intransigence by fs maintainers[1]) forced the current dpkg
maintainers to add a whole pile of pointless fsyncs.
dpkg does _not_ need durable updates; it just needs atomicity and
correctness. If after a crash the system is rewound to some earlier
state that's absolutely fine.
I'm told that the Linux fs maintainers have now accepted that
open("file.new",O_CREAT);
write();
close();
rename("file.new","file");
should not result, even after a crash, in "file" containing garbage.
If this is the case then all the fsyncs can be taken out again.
Ian.
[1] The view that fsync is the new IAC DONT RANDOMLY-LOSE.
--
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/19699.43281.82329.482...@chiark.greenend.org.uk
Re: Bug#605009: serious performance regression with ext4
Olaf van der Spek writes ("Re: Bug#605009: serious performance regression with
ext4"):
> Probably not an issue for dpkg, but in general:
> Don't you reset meta-data that way?
Yes. If you want to keep the metadata you must copy it.
> Require a second file (name), permission to write to it and assume
> it's on the same volume?
It will be on the same volume because it's in the same directory.
This is the standard way that ordinary files for which reliability was
important have been updated on Unix for decades. fsync is for files
which need synchronisation with things external to the computer (or at
least, external to the volume) - eg, email at final dot.
Ian.
--
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/19699.49032.353627.707...@chiark.greenend.org.uk
Bug#605717: !-based escape to shell for cdebconf text UI
Package: cdebconf Severity: wishlist It would be nice if at a cdebconf text prompt, you could say ! to get a subshell. This is particularly important in debian-installer; there are situations where things have gone wrong and you get into loops in the installer. If you're on a serial (or Xen PV) console you don't have the shell on tty2 available so you're basically stuck. (Sorry for not including a version tag; I'm talking about the version included in lenny's installer.) Thanks, Ian. -- 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/19703.52808.41820.484...@mariner.uk.xensource.com
Bug#566006: netcfg/dhcp_timeout values over 60 are not honoured
Package: debian-installer Version: lenny I've been trying to get a reliable fully automatic netboot install. The default value of netcfg/dhcp_timeout is rather too short for this kind of application so I decided to increase it to 150. Experimentation shows that values of greater than around 60 are ineffective. They affect the progress indication (which is based on % of the specified timeout) but after about 60s it fails anyway (perhaps with the progress indicator nowhere near 100%). I've done tests with values of (unset), 5, 60, 150, and 500, timing the results against a wall clock, and the effect seems to be consistent with an upper effective value of a little more than 60s. I conjecture that there are two parallel timeout mechanisms, one of which is controlled by netcfg/dhcp_timeout, but the other of which is fixed at 60 (or perhaps 65s - my timings are by eye so I'm not certain of the exact value). I don't have a record of the versions I downloaded but here are the MD5 checksums: b3d72aad69031b81d0350d609d71829c /tftpboot/pxe/debian-installer/i386/linux 4937c5134cd5c55bee2e696a29638bb1 /tftpboot/pxe/debian-installer/i386/initrd.gz If it would help to try a new version please let me know. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Continuing to use old kernels for installation after point releases
I have a setup at work which, amongst other things, regularly autoinstalls Debian. Because I don't want it to break unexpectedly, I prefer to keep using old installation kernels - for example, new kernels may have different requirements for non-free firmware etc., so I think it's not trivial to just use whatever kernel is in the most recent Debian point release. There are other reasons why someone might prefer to keep using an existing installer kernel even after a Debian point release: for example, doing otherwise would mean that the autoinstaller would have to check the Debian archive and perhaps suck down a new kernel/initramfs automatically and drop them into the pxe directory - and it seems to me that even such an arrangement would be subject to a race, where it would start to install with one set of images but by the time it comes along to get the other components they would be gone. At the moment keeping the same images is awkward, because (AFAICT) at a Debian point release the kernel modules required by the old kernel are removed from the archive. This makes the old netboot installer images break. This was extensively discussed in this thread: http://lists.debian.org/debian-devel/2011/11/msg00481.html I've just reread the thread. Some of it seemed rather bad-tempered and I'd like to distance myself from the criticism of the kernel team. I quite understand why it's considered a good idea to update the installation kernel. For most people that's the right thing to do. However, I'd still like to try to understand whether it is possible to make this work better for those of us who have setups where we launch the installer via pxe and we only want to take new kernel/initramfs versions when we explicitly choose to do so. If it's a question of needing someone to do some work, I have effort available for this. After all it'll stop my infrastructure at work breaking every time there's a Debian point release. Alternatively, perhaps I and others (since it's not just me that has this problem) are just going about things entirely the wrong way. In which case I'd be happy to help update documentation or whatever but at the moment I'm afraid I don't know what the better way would be. The simplest solution, suggested by several people in the thread, would be not to remove the old udebs from the archive. I don't know whether that's possible, but no-one seemed to give an authoritative answer to that suggestion previously. Thanks, Ian. -- 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/20263.63433.207098.950...@chiark.greenend.org.uk
Re: The current kernel doesn't support the Logical Volume Manager. You may need to load the lvm-mod module.
Philipp Kern writes ("Re: The current kernel doesn't support the Logical Volume
Manager. You may need to load the lvm-mod module."):
> On Tue, Jan 31, 2012 at 11:50:48PM +0300, George Shuklin wrote:
> > 2) We didn't download newer initrd/vmlinuz and using saved images to your
> > servers (some days before they works fine for long time, now stops)
>
> You should probably install one of the debian-installer-6.0-netboot-amd64
> packages on your TFTP boot server. Sadly netboot is not currently guaranteed
> to work across point releases.
Can't we make this work somehow ?
The old images are still in the archive in
installer-{amd64,i386}/
which suggests that they're supposed to work, but they are broken AIUI
by the lack of the appropriate udebs.
Would you agree that this is a bug ?
Ian.
--
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/20264.24906.751670.248...@chiark.greenend.org.uk
Re: The current kernel doesn't support the Logical Volume Manager. You may need to load the lvm-mod module.
Philipp Kern writes: > Currently we only ship udebs on CD images, which in turn cannot sanely be PXE > booted, AFAIK. > > I guess we can then conclude that keeping the old installer binaries doesn't > actually help anybody. Not even keeping those of r0. We should keep the old > sources around in squeeze-r0 though. For all of them. This is all rather unfortunate. Perhaps we could update the package name of the module udebs when the kernel is updated, and arrange for old installers to use the old udebs ? Ian. -- 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/20266.36721.845248.793...@chiark.greenend.org.uk
Re: The current kernel doesn't support the Logical Volume Manager. You may need to load the lvm-mod module.
Ian Jackson writes ("Re: The current kernel doesn't support the Logical Volume
Manager. You may need to load the lvm-mod module."):
> This is all rather unfortunate. Perhaps we could update the package
> name of the module udebs when the kernel is updated, and arrange for
> old installers to use the old udebs ?
Or perhaps we could somehow teach anna to install the older, working,
version of kernel module packages. I know nothing really about anna
but perhaps we could bake a version number into the initrd which would
tell it do download a particular manifest, or something.
Ian.
--
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/20266.37146.403590.192...@chiark.greenend.org.uk
Bug#616315: cdebconf in d-i via serial hides the option to go back
Package: cdebconf-text-udeb Version: 0.154 When running the squeeze installer via a serial console there should be something in the prompt to tell you that you can go back; you shouldn't have to read the help to know this. The help is very long and "go back" is an important option. Also I'm not convinced that having the "go back" option presented in the help text only when it's available is a good idea. I got the help text from one prompt, which happened to be one which didn't have a "go back" option, and that gave me the idea that it just wasn't possible. In case it's of any use, attached is a transcript of me struggling with it, before I got helpful advice on IRC to try "<". Thanks, Ian. Mar 3 12:10:22.099451 Partitions formatting ..33% Mar 3 12:10:22.319420 !! ERROR: Failed to create a file system Mar 3 12:10:22.331027 Mar 3 12:10:22.331061 The ext3 file system creation in partition #1 of SCSI.CCISS (-,0,0) Mar 3 12:10:22.331127 (cciss/c0d0) failed. Mar 3 12:10:22.335007 [Press enter to continue] Mar 3 12:18:27.714182 Mar 3 12:18:27.714251 Starting up the partitioner ..13%..22%..31%..40%..50%..63%..72%..81%..90%..100% Mar 3 12:18:29.413851 This is an overview of your currently configured partitions and mount points. Mar 3 12:18:29.850330 Select a partition to modify its settings (file system, mount point, etc.), a Mar 3 12:18:29.862297 free space to create partitions, or a device to initialize its partition table. Mar 3 12:18:29.874280 1. Guided partitioning Mar 3 12:18:29.874330 2. Configure software RAID Mar 3 12:18:29.874377 3. Configure the Logical Volume Manager Mar 3 12:18:29.882277 4. Configure encrypted volumes Mar 3 12:18:29.882329 5. Mar 3 12:18:29.882369 6. SCSI.CCISS (-,0,0) (cciss/c0d0) - 293.6 GB Compaq Smart Array Mar 3 12:18:29.894281 7. > #1 primary 289.4 GB B f ext3/ Mar 3 12:18:29.894344 8. > #5 logical4.1 GB F swapswap Mar 3 12:18:29.906286 9. SCSI.CCISS (-,0,1) (cciss/c0d1) - 146.7 GB Compaq Smart Array Mar 3 12:18:29.906421 10. > #1 primary 146.7 GB K lvm Mar 3 12:18:29.918292 11. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV MGT - 4.2 MB Linux device-mapper (linear) Mar 3 12:18:29.926314 12. > #1 4.2 MB Mar 3 12:18:29.926374 13. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-02b643ff-2044-42fc-b617-cf9a76f38270 - 25.8 GB Linux device-mapper (linear) Mar 3 12:18:29.950295 14. > #125.8 GB Mar 3 12:18:29.950358 15. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-08b420b5-6f61-47b2-85d0-1792d866678e - 16.8 MB Linux device-mapper (linear) Mar 3 12:18:29.969880 16. > #116.8 MB Mar 3 12:18:29.969942 17. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-148b1a50-0a2f-43ba-9430-8c1320195645 - 25.8 GB Linux device-mapper (linear) Mar 3 12:18:29.981944 18. > #125.8 GB Mar 3 12:18:29.994302 19. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-375de72f-c6de-46b6-bf52-fc01b598d4e8 - 25.8 GB Linux device-mapper (linear) Mar 3 12:18:30.002344 20. > #125.8 GB Mar 3 12:18:30.014291 21. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-3ebfc933-1b27-4b39-9c0f-fff57b37d929 - 25.8 GB Linux device-mapper (linear) Mar 3 12:18:30.026333 22. > #125.8 GB Mar 3 12:18:30.034298 23. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-4580d30e-7c83-4f29-a684-0bf6a9f50d0b - 21.5 GB Linux device-mapper (linear) Mar 3 12:18:30.046314 24. > #121.5 GB Mar 3 12:18:30.058286 25. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-61ad8a87-4e85-4679-ab4e-0b33f5b09d6f - 25.8 GB Linux device-mapper (linear) Mar 3 12:18:30.070308 26. > #125.8 GB Mar 3 12:18:30.070369 27. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-637d75dd-7217-4dcd-87f7-289da8f9b29c - 25.8 GB Linux device-mapper (linear) Mar 3 12:18:30.089903 28. > #125.8 GB Mar 3 12:18:30.089965 29. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-8fefd60a-e6c9-4ad9-9ef7-ed6c79caaec2 - 25.8 GB Linux device-mapper (linear) Mar 3 12:18:30.110088 30. > #125.8 GB Mar 3 12:18:30.110149 31. LVM VG VG_XenStorage-ec0bf0e3-b890-46ec-3bc2-bbca85298bc0, LV VHD-9368828d-3612-42f5-b429-bfee6c175d9a - 17.2 GB Linux device-mapper (linear) Mar 3 12:18:30.122360 32. > #117.2 GB
Bug#566316: Reproducible
I have discovered that: * This happens every time I give it a disk which has the layout I described in my first report. * The presence of cciss block devices is a red herring; I have reproduced the problem on a machine without them. Indeed the hardware doesn't appear to matter. * Whatever the partitioner does before it crashes destroys the preconditions for the bug. I have captured an image of a 400G hard disk in the bug-triggering state. After bzip2 it's only 2.1Gby so I have put it on a USB stick and will hope to give it to Colin Watson in person. md5sum: a581787538066d9dde0b13aa29b22e49 bug566316-diskimage.bz2 I can't publish the image because it contains a copy of Windows. Ian. -- 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/19590.14414.107477.126...@mariner.uk.xensource.com
Bug#595944: IWBNI rescue mode provided cfdisk somehow
Package: rescue-mode Version: 1.24 Severity: wishlist It would be nice to provide people with cfdisk in the rescue environment. There's already a cfdisk-udeb. 14:40 ([cfdisk-udeb] isn't used by d-i, but you could make use of it manually if you were desperate) 14:41 col: That would be very useful on a rescue disk. 14:41 Most of the other partitioners are terrible; the d-i partitioner UI is OK but very clumsy. 14:42 yes, perhaps so - if you want to file a bug on rescue-mode suggesting that it offer that, I could look into it at some point 14:42 I don't think I'd want to offer partman when your goal did not include assigning mountpoints 14:42 I was thinking you'd just run it by hand from "run a shell in the installer enviroment" (or VC2) 14:43 right, you could, but you'd have to say 'anna-install cfdisk-udeb' first 14:43 it'd be sort of nice if it were a menu option Thanks, Ian. -- 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/19590.16904.366601.761...@chiark.greenend.org.uk
Bug#684128: SI units (was Re: failure to communicate)
Daniel Pocock writes ("SI units (was Re: failure to communicate)"):
> It may actually be useful for the technical committee to review what is
> on the wiki and make some general statement about Debian's position (if
> they haven't done so in the past), and that can guide the way similar
> bugs are classified for jessie and beyond.
>
> 1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700
>
> 2. http://wiki.debian.org/ConsistentUnitPrefixes
You should try to address this through the policy process. If and
when we have competing policy proposals the TC might want to
arbitrate.
Ian.
--
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/20830.48721.962462.246...@chiark.greenend.org.uk
Bug#566316: Reproducible
I wrote: > * This happens every time I give it a disk which has the layout I >described in my first report. So I think the steps to reproduce are: * Unpack the image to a hard disk (or file which is going to be your test VM's virtual device). * Set up a local web server containing a preseed file like the one in my original report, edited for IP addresses etc. * Set up your PXE server appropriately. Mine looks like this: serial 0 115200 timeout 5 label overwrite menu label ^Overwrite menu default kernel debian-installer/i386/linux append vga=normal auto=true preseed initrd=debian-installer/i386/initrd.gz hostname=insider url=woking.cam.xci-test.com/~osstest/osstest/insider_preseed domain=cam.xci-test.com acpi=off noapic netcfg/dhcp_timeout=150 netcfg/choose_interface=auto DEBCONF_DEBUG=5 DEBIAN_FRONTEND=text -- console=ttyS0,115200n8 default overwrite * Boot the machine. It should boot, start d-i, bring up the network, load the preseed file, detect the hard disks, and then automatically partition the hard disk. If the bug triggers, the system will hang when partman_sever segfaults. You can ignore the "latecmd" in the preseed I was using; the installation falls over before then. Ian. -- 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/19591.37637.615000.305...@mariner.uk.xensource.com
Bug#601363: ERROR: Unable to automatically remove LVM data
Package: debian-installer I'm using the current lenny installer. I have a system with two disks, one of which I want erased as part of installer partitioning (and the other of which I will install later). However, I see this: !! ERROR: Unable to automatically remove LVM data Because the volume group(s) on the selected device also consist of physical volumes on other devices, it is not considered safe to remove its LVM data automatically. If you wish to use this device for partitioning, please remove its LVM data first. [Press enter to continue] This should be a question, rather than a fatal error, so that I can preseed it to make it go ahead. I don't care if it's not "safe"; I should have the option to destroy data. Ian. -- 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/19653.33495.246551.789...@mariner.uk.xensource.com
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
Josselin Mouette writes ("Re: CD1 without a network mirror isn't sufficient to
install a full desktop environment"):
> Le lundi 10 septembre 2012 à 20:08 +0200, Karsten Merker a écrit :
> > I am not going to repeat all the discussions about GNOME 3, but
> > at least from the impressions I have gotten around here, many
> > previous GNOME 2 users seem not to consider GNOME 3 / GNOME shell
> > a continuation of their existing environment, but instead see it
> > as a radical break, effectively as a different desktop
> > environment, and a lot of them seem to have adopted XFCE as the
> > "heir" of GNOME 2.
>
> Just because these people are noisy doesn’t make them numerous.
I have encountered numerous people who have been complained (not in
particular to me, just i general) about changes to GNOME. Not being a
GNOME user myself I don't really appreciate these complaints.
However, I have observed that these complainants have generally been
told by their peers to switch to xfce and been broadly satisfied with
the results.
I haven't seen anyone in my social circles praise these changes as
good for them.
Based on this, I think there is at the very least no reason to
reverse the decision to switch the Debian default to xfce.
> Furthermore, Debian (and Ubuntu too IIRC) makes “GNOME classic”
> available right from the login manager, with the default installation.
> Not considering gnome-panel 3.x a continuation of the existing
> environment is purely bad faith.
Please do not accuse fellow contributors of bad faith.
Ian.
--
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/20559.10558.139040.633...@chiark.greenend.org.uk
Bug#1082003: screen lock not installed or doesn't work?
#x27;t connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (wrapper-2.0:3191): dbind-WARNING **: 09:53:11.155: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (wrapper-2.0:3182): dbind-WARNING **: 09:53:11.155: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (wrapper-2.0:3195): dbind-WARNING **: 09:53:11.165: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (light-locker:3197): dbind-WARNING **: 09:53:11.169: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (xfce4-power-manager:3198): dbind-WARNING **: 09:53:11.171: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied ** (light-locker:3197): ERROR **: 09:53:11.172: session_id is not set, is /proc mounted with hidepid>0? Xfce Power Manager: Another power manager is already running (nm-applet:3199): dbind-WARNING **: 09:53:11.178: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (xfsettingsd:3209): dbind-WARNING **: 09:53:11.178: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (xfce4-notifyd:3217): dbind-WARNING **: 09:53:11.179: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (polkit-gnome-authentication-agent-1:3225): dbind-WARNING **: 09:53:11.182: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied Another notification daemon is running, exiting Another notification daemon is running, exiting (wrapper-2.0:3327): dbind-WARNING **: 09:53:11.238: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (thunar-volman:3408): dbind-WARNING **: 09:54:05.671: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied thunar-volman: Unsupported USB device type "usb". (thunar-volman:3429): dbind-WARNING **: 09:54:05.776: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied thunar-volman: Unsupported USB device type "usb-storage". (thunar-volman:3458): dbind-WARNING **: 09:54:06.862: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied thunar-volman: Unknown block device type "disk". -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#1082003: screen lock not installed or doesn't work?
FTR, changing the power management settings for "On lid close" to "Suspend" (in the power management settings from the XFCE tray battery icon in the top right) resulted in successful suspend/resume. So think probably the bug is that the intended screen locker/saver isn't installed, or maybe that it's not wired up properly somehow. Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
