Bug#774232: recommend using a wired connexion
On Sun, Jan 29, 2023 at 09:39:41PM -0500, Antoine Beaupré wrote: > On 2019-03-18 21:03:14, Paul Gevers wrote: > > Hi Antoine, > > > > On 16-03-2019 15:46, Antoine Beaupré wrote: > >> On 2019-03-16 15:18:27, Paul Gevers wrote: > >>> On Mon, 05 Jan 2015 15:59:51 -0500 Antoine =?utf-8?Q?Beaupr=C3=A9?= > >>> wrote: > On 2015-01-05 15:52:23, Andrei POPESCU wrote: > > There might however be an issue with remote upgrades over wireless > > connections handled by Network Manager as it still reinitializes the > > connection on service restart, so doing a remote upgrade over wireless > > could under specific circumstances lead to problems. > > That. Exactly. :) I would be terrified of doing a remote upgrade over > wifi, and that's probably because I know a little more what I am doing > than the average Debian user - so I think it makes sense to warn against > that particular foot-shooting device. > >>> > >>> I expect this is still an issue, but I wonder how hypothetical this is. > >>> Is there any evidence that this is a real issue? I would update remotely > >>> over WiFi myself, but ... > >>> > >>> So, if we want to share our worries, how to phrase this? Does the > >>> following make sense? > >>> """ > >>> Upgrading systems remotely that are connected via WiFi managed by > >>> Network Manager isn't recommended. Network Manager re-initializes the > >>> connection on service restart which could lead to problems under certain > >>> circumstances. > >>> """ > >> > >> The thing is am I do not believe the Debian package restarts network > >> manager automatically. I have needrestart here for stuff like that, and > >> even *that* blocks that automated restart by default... > > > > So you changed you mind since you filed the bug? Or am I > > misunderstanding you now? > > So I'm not sure anymore. It's been a *long* time now, and I am not sure > exactly why I filed that bug... I wish I had been more explicit on the > "why" back then and an actual failure mode I experienced. I'm pretty > sure there *was* something, but I can't trace it right now. > > Now that we're working on bookworm, I think I agree that we should move > on. I suspect the connection manager does get restarted on upgrade. I'm on Devuan chimaera, so things may be different for me. But whenever I do an upgrade, I start by overriding the entry in rexolv.conf that the connection manager put there ao that I get a regular DNS location (I usually choose 8.8.8.8 because I can remember it.) (why do I do that? Because long long ago the connection manager seems to have memorized a particular one of Devuan's mirrors and now it always gives me that one and it happens to be broken). I will get it even if it is no longer i the list of Devuan mirrors.. But 8.8.8.8 gets me a new one, and that one works. The entire upgrade than works cleanly, but afterward, if I look at resolv.conf, it has again been overwritten by the connection manager, So I conclude that it has been restarted. So I conclude that the upgrade does indeed restart the connection manager. No problem on my laptop. But I imagine it could cause problems on a remote device it I were to lose contact. -- hendrik > > I still think that people should use a wired connexion for upgrades, but > I am not feeling so strongly about this that it should be part of the > upgrade procedure. In fact, I believe I have myself done upgrades over > wifi without too much problems recently. > > I don't actually buy the "wifi firmware goes away" theory anymore, and > if network manager restarts, who cares? You already have the packages > downloaded at this point and the worse that could happen there is that > you lose your network, which is something a reboot (which you need to do > anyways) would do as well. > > So yeah, let's move on, and thanks for nursing all those bugs all those > years. :) > > a. > -- > La propriété est un piège: ce que nous croyons posséder nous possède. > - Alphonse Karr >
Bug#993819: release-notes: Please document the removal of wicd
On Thu, Sep 09, 2021 at 09:35:05PM +0200, Paul Gevers wrote: > Hi Hendrik, > > On 09-09-2021 21:27, Hendrik Boom wrote: > > Here is the text I have included in the current draft upgrade > > instructions for Devuan: > > > > Warning: `wicd` will no longer be available after the upgrade, so if > > you use it to connect to the internet through wifi, you will be cut > > off. To prevent this, you should change to a connection manager that > > *will* still be available, such as `connman`. If you want a convnient > > graphical interface, without which making connections can be difficult, > > you should install `connman-gtk`. You should do this *before* you > > start the upgrade, or you will have trouble reconnecting if things go > > wrong. > > Isn't NetworkManager the default graphical manager nowadays? Or is there > a link with systemd such that you wouldn't mention it for Devuan? No > judgement intended, just wanting to have the facts straight. When I installed devuan a few releases ago it gave me connman. So I knew it worked. And I tested it on chimaera. network-manager is also available on Devuan, so I guess, there's no systemd issue. But I am loathe to recommend something I hadn't tested on chimaera. -- hendrik > > Paul > >
Bug#993819: release-notes: Please document the removal of wicd
On Tue, Sep 07, 2021 at 06:54:05AM +0200, Joost van Baal-Ilić wrote: > Hi, > > On Mon, Sep 06, 2021 at 05:23:45PM -0400, Hendrik Boom wrote: > > On Mon, Sep 06, 2021 at 10:01:10PM +0100, Roger Lynn wrote: > > > Package: release-notes > > > Severity: important > > > > > > Please document the removal of wicd in Bullseye. This seems particularly > > > dangerous if the upgrade is being done over a network connection being > > > managed > > > by wicd as it seems likely that the connection will be lost when wicd is > > > removed (due to dependency problems). It would also be helpful if > > > alternatives > > > could be suggested. > > > > I already did that in the draft upgrade instructions for Devuan, as > > something to be done before anything else. > > > > SHould I send a copy of the paragraph to this list? > > Yes, that would be helpful, and please do Cc 993...@bugs.debian.org . Here is the text I have included in the current draft upgrade instructions for Devuan: Warning: `wicd` will no longer be available after the upgrade, so if you use it to connect to the internet through wifi, you will be cut off. To prevent this, you should change to a connection manager that *will* still be available, such as `connman`. If you want a convnient graphical interface, without which making connections can be difficult, you should install `connman-gtk`. You should do this *before* you start the upgrade, or you will have trouble reconnecting if things go wrong. -- hendrik > > Thanks, Bye, > > Joost >
Bug#956877: release-notes: Upgrade from XFS removes mount option "barrier|nobarrier"
On Sun, May 03, 2020 at 09:34:34AM +0200, Niels Thykier wrote: > Paul Gevers: > > Dear Benedikt, all, > > > > On 16-04-2020 10:44, Benedikt Tuchen wrote: > >> While doing an upgrade from Stretch to Buster on a Laptop with XFS > >> Filesystem in use. After the upgrade the laptop doesn't boot into > >> the system because of the removed "barrier|nobarrier" mount option > >> for XFS in version 4.19. > >> > >> I think this issue should be mentioned in the "5. Issues to be aware > >> of for buster" part of the release-notes in Buster. > > > > What is exactly the problem? Does everybody with XFS run into this > > issue? Do you have a solution for the problem that we can mention? Or, > > phrased differently, what should the user do if they have an XFS > > filesystem and want to upgrade to buster? > > > > Paul > > > > They would have to remove the "barrier" or "nobarrier" keyword if they > use either in their fstab (or in scripts that passes that mount option > explicitly). > > If I try to mount an XFS file system with "barrier" (or "nobarrier"), I > get cryptic errors like this: > """ > mount: : wrong fs type, bad option, bad superblock on , > missing codepage or helper program, or other error. > """ > > (using mount -o ...,barrier - I don't remember if the fstab message is > better) Would that refer to the write battier on the hard drive? Isn't that essential to the safe operation of XFS? -- hendrik
Bug#919813: recognising devuan
So the remaining problem is that the Debian Buster os-prober did not recognise Devuan ascii. -- hendrik
Bug#919813: comparison with earlier release
Just for comparison, on Devuan ascii (stretch wirhout systend), I get: root@midwinter:/home/hendrik# os-prober File descriptor 8 (socket:[13898]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 9 (socket:[13899]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 10 (socket:[16454]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 11 (socket:[16455]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 18 (socket:[13991]) leaked on lvs invocation. Parent PID 2831: /bin/sh /dev/sda6:Debian GNU/Linux buster/sid:Debian:linux root@midwinter:/home/hendrik# Here it also does not recognise the OS it runs on, but it *does* recognise Debian. Could the problem be that it is does not recognise (a) its own OS, nor (b) any OS those root partition in on an LVM volume, even if its /boot is on a primary partition? -- hendrik
Bug#919813: os-prober fails to find any os's at all.
Package: os-prober Version: 1.77 os-prober fails to find any os's at all after a new Debian buster install, not even the installed and running DEbian buster. The install was done using the net-install CD on a USB stick on 2019 01 18, downloaded immediately before the installation. root@buster:/home/guest# os-prober root@buster:/home/guest# This was run the day after installation. The machine actually has two Linux systems installed: * the newly installed Debian buster. * /boot on /dev/sda2, and / on /dev/sda6. * Installed yesterday. * An older Devuan ascii. * /boot on /dev/sda1, and other partitions in an LVM on /dev/sda3 * Installed a few months ago. Both are now bootable from the grub2 boot menu installed by using the debian installer to install buster yesterday. Presumably the installer used os-prober succesfully, but the os-prober I installed today using aptitude does not work. Could they be different versions? I'm not aware of anything unusual about the enviromnent. It'a a Purism laptop. -- hendrik
Bug#762829: Now misclassified as Java
The example Pascal program in the original bug report is now misclassified as Java source. This is on a new buster install as of 2019 01 19. guest@buster:~$ file Downloads/emil23m.pas Downloads/emil23m.pas: Java source, ASCII text guest@buster:~$ file --version file-5.35 magic file from /etc/magic:/usr/share/misc/magic guest@buster:~$ -- hendrik
Bug#686754: why 686754 is not a bug
I hit this bug, read the previous messages, and wondered why it had not been fixed in so long. I resolved to fix it myself, and spent some time reading the code. But then I was diverted to other tasks, and when I returned to the bug a week later, it suddenly dawned on me why it was not a bug. When grub-install uses its varous tools to survey the disk and make proper boot stanzas, it tries as much as possible to figure out how the other OS's want to be booted and place that information in its boot stanzas. And the copied OS plainly states how it wants to be booted in its copied boot stanzas -- namely, exactly like the originally uncopied OS, so in the newly created boot stanza, that's exactly what it gets -- a copy of the copy of the original stanza. So that's what we get. And to fix it we have to make sure that the copied system is altered to refer to itself, just as its /etc/fstab is altered to refer to itself. -- hendrik
Bug#791794: RAID device not active during boot
On Sat, Jul 11, 2015 at 10:16:15AM +0200, Nagel, Peter (IFP) wrote: > The problem might be related to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789152. > However, in my case everything seems to be fine as long as all > harddisks (within the RAID) are working. > The Problem appears only if during boot one (or more) disk(s) out of > the RAID device have a problem. > > The problem might be related to the fact that jessie comes with a > new init system which has a stricter handling of failing "auto" > mounts during boot. If it fails to mount an "auto" mount, systemd > will drop to an emergency shell rather than continuing the boot - > see release-notes (section 5.6.1): > https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system Would a temporary work-around be to use another init system? > > For example: > If you have installed your system to a RAID1 device and the system > is faced with a power failure which (might at the same time) causes > a damage to one of your harddisks (out of this RAID1 device) your > system will (during boot) drop to an emergency shell rather than > boot from the remaining harddisk(s). > I found that during boot (for some reason) the RAID device is not > active anymore and therefore not available within /dev/disk/by-uuid > (what causes the drop to the emergency shell). > > A quickfix (to boot the system) would be, to re-activate the RAID > device (e.g. /dev/md0) from the emergency shell ... > > mdadm --stop /dev/md0 > mdadm --assemble /dev/md0 > > ... and to exit the shell. > > Nevertheless, it would be nice if the system would boot > automatically (as it is known to happend under wheezy) in order to > be able to use e.g. a spare disk for data synchronization. After all, isn't it the whole point of a RAID1 that it can keep going when one of its hard drives fails? I currently have this situation on a wheezy system, and it will continue until I have the replacement physical drive prepared for installation. The RAID1 is running fine with just one physical drive. It would be seriously inconvenient to be unable to boot in a straightforward manner. It's not as if it's being quiet about the matter -- I keep getting emails elling me that one of the drives is missing. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760897: release-notes: systemd switch: customised init scripts
On Thu, Jan 15, 2015 at 11:12:19AM +1100, Stuart Prescott wrote: > Hi Niels, > > > +If needed be, it is possible to override the systemd unit file to > > +have it start the sysvinit script. For more information on > > +systemd unit files, please have a look at the following resources. > > s/If needed be/If needed/ or s/If needed be/If needs be/ (the first is better > for formal language). Still better would be s/If needed be/If necessary/ -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Mon, Dec 15, 2014 at 05:00:32PM +0100, Svante Signell wrote: > +It is also a good idea to install > + sysvinit-core, sysvint and sysvinit-utils Might you mean sysvinit instead of sysvint ? > + as the first packages when upgrading. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533267: release-notes: Purging uninstalled packages
On Mon, Nov 24, 2014 at 08:01:10AM +0100, Niels Thykier wrote: > +It is generally advisable to purge removed packages. This is > +especially true, if these have been removed in an earlier release ^ English does not use a comma here, though some other languages do. > +upgrade (e.g. from the upgrade to &oldreleasename;) or from > +third-party vendors. In particular, old init.d scripts have been > +known to cause issues. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695378: closed by Holger Levsen (closing squeeze-wheezy upgrade report from within the wheezy release cycle)
I'm in complte agreement with closing this bug. A few months later, I upgraded from squeeze to wheezy successfully, and wheezy has been running on my server ever since. I submitted this bug report while wheezy was still in development, in the hope that it would help debug the upgrade process. Mission accomplished. I'd like to thank everyone for the work they have put into this. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700461: still not in testing; possible deeper problem
The patch was to add the O_LARGEFILE option fo several I/O calls in its core/adb/sysdeps.h file/ I find myself wondering why this fix hasn't even arrived in sid yet, as far as I can tell. It appears to be a serious bug, since it's possible that someone might thingk he has performed a backup and find, when it's time to restore, that it is seriously defective. Not something that should languish in limbo. I downloaded the source package, applied the patches, installed it, and then finally was able to back up my Transformer TF101. I haven't been able to test whether the backup can be restored, not having a spare Android device to restore it to. I hope someone with more hardware hsd performed this test. WHile applying the patches, I looked up the option O_LARGEFILE, just to check that I understood what the patch did. I discovered that it is not a standard option. And one source (http://stackoverflow.com/questions/2888425/is-o-largefile-needed-just-to-write-a-large-file) said it should not be used. Instead, one is to add -D_FILE_OFFSET_BITS=64 to CFLAGS, and " you'll never have to worry about anything". Now this looks like is something that should be in Debian's standard package build system, since the problem potentially affects every package that reads and writes files. I'd welcome the arrival of the present patches in testing, just so I don't have to maintain my own variant of the package, but it seems there's a more general problem to be solved with package builds. Where do I report this? (For the record, I'm doing this on a 32-bit intel system running jessie that places the backup on an NSF-mounted volume that resides on a AMD64 server running 64-bit wheezy.) -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751294: chromium does not display any web page or settings
> > > Have you tried with the i386 version of chromium? It could be that > > > it only affects i386 and not amd64. > > > > Quite possible, I can definitely reproduce it on i386. > > OK, I am bumping the severity again to prevent migration to testing > for now. Too late! It has already propagated to testing. Now it's a priority to get the next version into testinng. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708811: problem solved
I have no further issues with wheezy, except maybe the disappearance of pornview, which was my preferred slide viewer (it doesn't actually check whether the images are porn, so it works fine for landscapes and such), but that's really a different issue. But the old version from squeeze still works on wheezy. Go ahead and close the report. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708811: problem solved
Yes, it looks like that was the problem with dhcp. I put a dhcpd.conf in /etc/dhcp/ instead of /etc/, and it all works now. That file should have been in the new place even in squeeze, so this is definitely not a squeeze->wheezy upgrade problem. I was still using he dhcp server from etch, in fact, with the dhcpd.conf in /etc instead of /etc/dhcp, so if it was an upgrade problem, it was one that happened long, long ago, and is probably not worth trying to track down now. Now running happily on wheezy. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708811: most problems fixed. dhcp server still not functioning
That does look to be the problem., thanks. It is a server I want, and the old server (dating back to etch, I have no idea why the successive upgrades all the way to squeeze didn't replace it) was configured at /etc/dhcpd.conf instead of /etc/dhcp/dhcpd.conf. Probably a problem with a long-obsolete upgrade. I've edited the proper script now, and will try it out as soon as I get the chance to reboot the server to wheezy again. (yes, I dual-boot between squeeze and wheezy; it gives me a useful fallback in case of trouble like this) -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708811: most problems fixed. dhcp server still not functioning
Well, the thought involved in writing the upgrade report was helpful. It forced me to sit and think while waiting for a reply. Even without a reply, that helped. I did some more hacking. Of course I should have tried apt-get -f install. That indeed fixed most of the problems. But didn't get the dhcp server to work. Now the dhcp I was running turned out to date back to etch. Just possibly it was too out-of-date to work any more. But installing the current isc-dhcp-server doesn't work either. running /etc/init.d/isc-dhcp-server start gives me a FAILED message with a request to look up details in syslog. But /etc/var/syslog hasn't been updated for two days. What's wrong here? Should I be looking elsewhere for the log messages from the dhcp server? -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695378: upgrade from squeeze to wheezy almost successful.
Package: upgrade-reports Severity: important Tags: wheezy Upgrading 64-but squeeze to 64-bit wheezy on a AMD-64. /boot is (now) on an ordinary partition, and / is on LVM on RAID. I started with this upgrade from squeeze to wheezy a few weeks ago. It has been only partially successful, and the resulting system is not yet ready to take the place of squeeze on my server. As it stands now, wheezy will not boot properly without manual intervention, and one critical applicaiton (gnucash) will not run at all. Fortunately, I still have a running copy of squeeze on my system, so the failed upgrade has little effect on day-to-day operation. This is my second attempt to upgrade from squeeze to wheezy. (The first was a comedy of errors, mostly mine.) What is wrong when I boot the new system When I boot wheezy, it stops with an initramfs prompt, having waited unsuccessfuly for the root file system. Now the root file system is on LVM on RAID. Presumably the LVM did not get activated properly after the RAID is discovered (I say some discussion of this on an archlinux bulletin board). The workaround is manual intervention, namely, issuing the command vgchange -a y at the initramfs prompt. It replies, 9 logical volume(s) in volume group "VG1" now active. I close the shell with control-D, and booting proceeds. Until it starts to start up gdm. X starts up, and I get a warning popup telling me There was an error loading the theme spacefun. Couldn't recognize the image format for file '/usr/share/gdm/themes/debian-spacefun/boundingbox.png I click OK; then am told There was an error loading the theme, and the default theme could not be loaded. Attempting to start toe standard greeter. I click OK. The standard greeter works fine. -- What's wrong after the successful boot -- First of all, networking is down. The usual start scripts have indeed been run from rc.local, but they failed. But manual intervention seems to help. ifconfig tells me there are no interfaces, which is probably why setting up masquerading fails. As root, I can issue ifconfig eth0 up ifconfig eth1 up and these interfaces come up nicely. Then I can run the usual local start scripts and they work properly. So the problem seems to be that eth0 and eth1 somehos missed the boat and have nut been started automatically. Also, the dhcp server isn't working. How do I manually restart it? -- User software troubles -- User problems are probably caused by the large number of broken packages and when that gets resolved this set of problems will probably vanish. But just for completeness I'll describe the symptoms. I log in as a user and start my usual icewm. A lot of the boxes in the toolbar are univorm grey. These are the ones that I would click on to get 'favorite applications', 'show Desktop', 'Window Lit Menu', 'xterm', and 'WWW'. I can identify them by using the text that show up when I hover the nouse pointer over them. All that textt, and the actual text in the menus shows up fine. The '1', '2', '3', and '4' to indicate alternate workspaces look just fine. Starting an xterm using the box that usually has the terminal icon gives me nothing. But I can get a terminal with and extremely small font through the menu. (blank) -> programs -> applicatinons -: Terminal Emulator -> Xterm. THis is presumably toe ancient xterm that comes with X. Trying to run gnucash from this sams set of menus fails, wit a large warning box: Cannot find default values. The configuration data used to specify default vaues for gnucash cannot be found n the default system locations. Without the data gnucash will still operate properly but it may require some extra time to set up. Do yu wish to set the configuration data? THen An error occurred while loading or saving configuration informatino for gnucash. Some of your configuraito settings may not work properly. I can click on Details and get nothing. I can click on OK and also get nothing. Asking it to go ahead and set defaults doesn't help. Upgrade history. I upgraded starting with a copy of the running squeeze system. I performed tha various checks in the release notes, did the minimal upgrade and the kernel upgrade. When the time came to reboot I found that it wouldn't. It took me a week to establish bootability of the wheezy partition. The problems I ran into were: * The configuration file for lilo was wrong -- my fault. A disk drive I had booted from long ago wasn't there any more (it's gone to the graveyard of aging hard drives) and there was still a stanza referring to it. I had last run lilo when it was present. Running it during the upgrade failed: lilo won't accept stanzas that re
Bug#631116: awkward workaround
By holding one key down all the time, all the other keys I type register properlt. For example, while holding the 'a' key down with one hand, I can easily type 'xterm' with the other. Then, of course, I can use xterm, which does not have this problem. THis may be why Greg Sharp has some success by typing two keys in rapid succession -- the first key is oftern still held down while he types the second. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612250: release-notes: Loss of keyboard and mouse may occur during upgrade
On Mon, Feb 07, 2011 at 08:48:39AM +0100, Javier Fernandez-Sanguino wrote: > On 7 February 2011 07:27, Karl O. Pinc wrote: > > During upgrade the text console was lost and replaced with a gdm login > > screen. The second time this occurred neither the keyboard or mouse > > would respond. Unplugging and replugging each of these USB devices > > resovled the problem. > > Thank you for your patch we will consider it for the Release Notes. As > for this issue, since the move from text console to gdm is quite > common (and confuses users) we are consider asking the users, when > upgrading, to stop the gdm service so that there is no switch back and > forth. We still have to consider the best approach to this issue, > however. On my laptop, there is internet connection while a user is logged and using gnome. When the user logs out, the connection is broken. Would stopping gdm have the effect of logging out the user? If so, gdm should be stopped only after all the packages have been downloaded, and before they start to be installed. Is there a good moment for the user to detect this moment? -- hendrik k -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608704: closed by Simon Paillard (Re: Bug#608704: release-notes: recommend to close any running X server?)
On Tue, Jan 04, 2011 at 07:42:00AM -0800, Steve Langasek wrote: > On Tue, Jan 04, 2011 at 10:06:12AM +0100, Holger Wansing wrote: > > ow...@bugs.debian.org (Debian Bug Tracking System) wrote: > > > This is an automatic notification regarding your Bug report > > > which was filed against the release-notes package: > > > > #608704: release-notes: recommend to close any running X server? > > > > It has been closed by Simon Paillard . > > > Simon Paillard wrote: > > > > I want to ask, if it would make sense to advice the user, to > > > > close any running X server when doing an dist-upgrade. > > > > Actually already advised: > > > http://www.debian.org/releases/squeeze/i386/release-notes/ch-upgrading.fr.html#upgrade-preparations > > > No, that's not correct. > > The release-notes recommend to not _use_ the x server for upgrade, > > but you can have an x server running. > > It is not recommended to shutdown any running x servers on the > > machine! > > That's not the same. > > And that's what I asked for. > > > Shall I reopen? > > Why do you want users to shut down their X server during the upgrade? I > don't think this is a sound recommendation. Even recommending to not run > the upgrade under X is, IMHO and IME, a paranoid recommendation that we > include only for the benefit of a very small number of users who might be > impacted. gdm certainly doesn't break running X sessions when upgraded. I find gdm crashing even when there's no upgrade going on. When a session ends, it seems unable to put up a new login screen. When that happens, it has also disabled the functions keys that would take you to an exiting plain-text terminal session (such as ctl-alt-F1). The machine has effectively become unusable. There's been a bug logged against gdm anout this; it seems to have been caused by an error in a script (wrong file name for accessing gdm) and fixed. The gdm I have in my squeeze is more recent than this fix, but the problem still persists on my system. It has made it suficiently unusable that I'm now booting lenny from another partition just to get work done. I can well understand the fear that this might happen on an upgrade. But I suspect the solution is to make sure that gdm is really fixed, so that only the paranoid need shut down X. Failing that, a warning in the release notes might still be useful. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608704: release-notes: recommend to close any running X server?
On Sun, Jan 02, 2011 at 09:49:26PM +0100, Holger Wansing wrote: > Package: release-notes > Severity: wishlist > > > Hello, > > I want to ask, if it would make sense to advice the user, to > close any running X server when doing an dist-upgrade. > > Pro: > you would reduce the risk of getting an unaccessable system, > when during new startup of e.g. gdm an error occures and X > is not responding/is hanging and you cannot switch back to > virtual console. > (I did a test dist-upgrade some time ago, and I had exactly > this problem: when restarting gdm, the system hung up, keyboard > was not responding, I had no chance to switch to virtual console. > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604724) I have this problem in squeeze even without doing any upgrade. After logging out from an X session that was started fro gdm, the system is hung up as described. Perhaps the real solution would be to fix gdm? I have no way to shut down X as recommended. The only thing I can do is to boot the system without X in the first place. Of course, this is already a squeeze system, so it may not be relevant to the lenny->squeeze upgrade. -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557245: large packages dropped from CDs
On Sun, Jan 02, 2011 at 07:11:11PM +0100, Julien Cristau wrote: > +Note that some packages larger than 300,000,000 bytes (and any packages > +depending on them) are excluded from the CD set. They are > +still included in the DVD and Blu-ray disks, though. maybe mention and of course they can still be installed from the online repositories. This might help beginners. -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110102182353.gb31...@topoi.pooq.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
