Re: Upgrade problems?
Adding this up here as a quick read: If this was installation via debs, I'm out of the conversation. If it was about untarring [zipped files] and you can repeatedly reproduce the issue now that you have seen this, PLEASE don't share the package name(s) publicly. They could be... dissected and then reconstructed for less than moral purposes. Cindy :) On 7/22/21, Cindy Sue Causey wrote: > On 7/21/21, Tixy wrote: >> On Wed, 2021-07-21 at 12:04 -0400, Frank McCormick wrote: >>> On 2021-07-21 10:52 a.m., Kushal Kumaran wrote: >>> >>> frank@fedora ~$ stat / >>>File: / >>>Size: 4096Blocks: 8 IO Block: 4096 directory >>> Device: 806h/2054d Inode: 2 Links: 18 >>> Access: (0555/dr-xr-xr-x) Uid: (0/root) Gid: ( 1000/ frank) >>> Context: system_u:object_r:root_t:s0 >>> Access: 2021-07-21 10:22:56.572440309 -0400 >>> Modify: 2021-06-26 15:48:58.771330459 -0400 >>> Change: 2021-06-27 10:10:28.333447227 -0400 >>> Birth: 2021-06-11 13:38:48.0 -0400 >>> >>> Looks like owned by root but access by frank ? >>> >>> Will chown work ? >> >> Also looks like / is not writeable by root, what have you done to your >> system? >> >> Didn't you have directory permissions problems before? A quick search >> throws up https://lists.debian.org/debian-user/2020/10/msg00059.html > > > My apologies if my thread trimming glitched any. That thing about "/", > were your packages e.g. deb packages or did you untar a package or a > few? > > It's about a bug I tried to submit to Security a couple years ago. I > got shut down, kind of a cyber hand thrown up in my face. STILL "not > amused". > > It was about my own "/" multiple times over becoming owned by > something else every time I untarred one particular package. The > package would reach up two or three or so parent directories to take > over the "/" directory. > > Cindy. :) > -- > Cindy-Sue Causey > Talking Rock, Pickens County, Georgia, USA > > * runs with birdseed *
Re: Upgrade problems?
On 7/21/21, Tixy wrote: > On Wed, 2021-07-21 at 12:04 -0400, Frank McCormick wrote: >> On 2021-07-21 10:52 a.m., Kushal Kumaran wrote: >> >> frank@fedora ~$ stat / >>File: / >>Size: 4096Blocks: 8 IO Block: 4096 directory >> Device: 806h/2054d Inode: 2 Links: 18 >> Access: (0555/dr-xr-xr-x) Uid: (0/root) Gid: ( 1000/ frank) >> Context: system_u:object_r:root_t:s0 >> Access: 2021-07-21 10:22:56.572440309 -0400 >> Modify: 2021-06-26 15:48:58.771330459 -0400 >> Change: 2021-06-27 10:10:28.333447227 -0400 >> Birth: 2021-06-11 13:38:48.0 -0400 >> >> Looks like owned by root but access by frank ? >> >> Will chown work ? > > Also looks like / is not writeable by root, what have you done to your > system? > > Didn't you have directory permissions problems before? A quick search > throws up https://lists.debian.org/debian-user/2020/10/msg00059.html My apologies if my thread trimming glitched any. That thing about "/", were your packages e.g. deb packages or did you untar a package or a few? It's about a bug I tried to submit to Security a couple years ago. I got shut down, kind of a cyber hand thrown up in my face. STILL "not amused". It was about my own "/" multiple times over becoming owned by something else every time I untarred one particular package. The package would reach up two or three or so parent directories to take over the "/" directory. Cindy. :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: Upgrade problems?
On 7/21/21 12:24 PM, Greg Wooledge wrote: On Wed, Jul 21, 2021 at 12:04:13PM -0400, Frank McCormick wrote: frank@fedora ~$ stat / File: / Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 806h/2054d Inode: 2 Links: 18 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 1000/ frank) Context: system_u:object_r:root_t:s0 Access: 2021-07-21 10:22:56.572440309 -0400 Modify: 2021-06-26 15:48:58.771330459 -0400 Change: 2021-06-27 10:10:28.333447227 -0400 Birth: 2021-06-11 13:38:48.0 -0400 Looks like owned by root but access by frank ? Will chown work ? Your hostname is "fedora"? Um. Skipping that for now Yes, chown would work, although chgrp would be the more "natural" pick. Either chown 0:0 / or chgrp 0 / While you're poking around in there, the permissions are also different from what one would normally expect on Debian. chmod 755 / Then again, if this isn't actually a Debian host, the 555 permissions on the root directory might be normal. Good grief! This comment stirred my memory and I realized I had rebooted into Fedora 34 AFTER I had updated Debian Bullseye. >Your hostname is "fedora"? Um. Skipping that for now > Nevertheless, I am still pullzed by those errors. Back in Debian is redid the debug suggestions. frank@franklin:~$ stat / File: / Size: 4096Blocks: 8 IO Block: 4096 directory Device: 801h/2049d Inode: 2 Links:18 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2021-07-21 10:28:15.256580076 -0400 Modify: 2021-07-21 10:14:11.300131364 -0400 Change: 2021-07-21 10:20:43.718277098 -0400 Birth: 2020-07-12 12:23:46.0 -0400 (sorry about the wrapping) frank@franklin:~$ ls -ld / drwxr-xr-x 18 root root 4096 Jul 21 10:14 / So "/" is owned by root with proper permissions! What now ?? Sorry folks. Frank -- Frank McCormick
Re: Upgrade problems?
On Wed, Jul 21, 2021, 12:57 PM Greg Wooledge wrote: > On Wed, Jul 21, 2021 at 12:39:49PM -0400, Kenneth Parker wrote: > > > > Access: (0555/dr-xr-xr-x) Uid: (0/root) Gid: ( 1000/ frank) > > > Actually, access 555 means everyone can Read and Execute, but nobody can > > Update. > > > > Root usually overrides that, which could explain why it still works. > > Yes. > > > Will chown work ? > > > > > > > Actually, chmod might work better. My system has 755, owned by Root. > > Meaning only Root can Update, but everybody can Read and Execute. > > None of that explains why systemd says the thing is considered "unsafe". > It's "unsafe" because it's owned by group "frank". > How did I miss that? The only reason I can think of, for a different Group would be for something like /var/log, so someone other than Root can read the Logs. Thus, changing the GID back to 0 is the main issue (for suppressing the > warning messages). Fixing the perms from 555 to 755 is just for a bit > of extra consistency. > That, and other layers of Security, such as selinux, where Root isn't always "god". Thanks for the clarification. Kenneth Parker >
Re: Upgrade problems?
On Wed, Jul 21, 2021 at 12:39:49PM -0400, Kenneth Parker wrote: > > Access: (0555/dr-xr-xr-x) Uid: (0/root) Gid: ( 1000/ frank) > Actually, access 555 means everyone can Read and Execute, but nobody can > Update. > > Root usually overrides that, which could explain why it still works. Yes. > Will chown work ? > > > > Actually, chmod might work better. My system has 755, owned by Root. > Meaning only Root can Update, but everybody can Read and Execute. None of that explains why systemd says the thing is considered "unsafe". It's "unsafe" because it's owned by group "frank". Thus, changing the GID back to 0 is the main issue (for suppressing the warning messages). Fixing the perms from 555 to 755 is just for a bit of extra consistency.
Re: Upgrade problems?
On Wed, Jul 21, 2021, 12:12 PM Frank McCormick wrote: > On 2021-07-21 10:52 a.m., Kushal Kumaran wrote: > > > On Wed, Jul 21 2021 at 09:26:41 AM, Frank McCormick < > debianl...@videotron.ca> wrote: > >> Got a bunch of strange errors during this morning upgrade of Bullseye. > >> > >> > >> Setting up systemd (247.3-6) ... Detected unsafe path transition / → > >> /run during canonicalization of /run. Detected unsafe path transition > >> / → /run during canonicalization of /run/lock. Detected unsafe path > >> transition / → /var during canonicalization of /var. Detected unsafe > >> > /snip/ > > frank@fedora ~$ stat / >File: / >Size: 4096Blocks: 8 IO Block: 4096 directory > Device: 806h/2054d Inode: 2 Links: 18 > Access: (0555/dr-xr-xr-x) Uid: (0/root) Gid: ( 1000/ frank) > Context: system_u:object_r:root_t:s0 > Access: 2021-07-21 10:22:56.572440309 -0400 > Modify: 2021-06-26 15:48:58.771330459 -0400 > Change: 2021-06-27 10:10:28.333447227 -0400 > Birth: 2021-06-11 13:38:48.0 -0400 > Looks like owned by root but access by frank ? > Actually, access 555 means everyone can Read and Execute, but nobody can Update. Root usually overrides that, which could explain why it still works. Will chown work ? > Actually, chmod might work better. My system has 755, owned by Root. Meaning only Root can Update, but everybody can Read and Execute. Thanks > Good luck. Kenneth Parker
Re: Upgrade problems?
On Wed, 2021-07-21 at 12:04 -0400, Frank McCormick wrote: > On 2021-07-21 10:52 a.m., Kushal Kumaran wrote: > > > On Wed, Jul 21 2021 at 09:26:41 AM, Frank McCormick > > wrote: > > > Got a bunch of strange errors during this morning upgrade of Bullseye. > > > > > > > > > Setting up systemd (247.3-6) ... Detected unsafe path transition / → > > > /run during canonicalization of /run. Detected unsafe path transition > > > / → /run during canonicalization of /run/lock. Detected unsafe path > > > transition / → /var during canonicalization of /var. Detected unsafe > > > > /snip/ > > frank@fedora ~$ stat / > File: / > Size: 4096 Blocks: 8 IO Block: 4096 directory > Device: 806h/2054d Inode: 2 Links: 18 > Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 1000/ frank) > Context: system_u:object_r:root_t:s0 > Access: 2021-07-21 10:22:56.572440309 -0400 > Modify: 2021-06-26 15:48:58.771330459 -0400 > Change: 2021-06-27 10:10:28.333447227 -0400 > Birth: 2021-06-11 13:38:48.0 -0400 > > Looks like owned by root but access by frank ? > > Will chown work ? Also looks like / is not writeable by root, what have you done to your system? Didn't you have directory permissions problems before? A quick search throws up https://lists.debian.org/debian-user/2020/10/msg00059.html -- Tixy
Re: Upgrade problems?
On Wed, Jul 21, 2021 at 12:04:13PM -0400, Frank McCormick wrote: > frank@fedora ~$ stat / > File: / > Size: 4096 Blocks: 8 IO Block: 4096 directory > Device: 806h/2054d Inode: 2 Links: 18 > Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 1000/ frank) > Context: system_u:object_r:root_t:s0 > Access: 2021-07-21 10:22:56.572440309 -0400 > Modify: 2021-06-26 15:48:58.771330459 -0400 > Change: 2021-06-27 10:10:28.333447227 -0400 > Birth: 2021-06-11 13:38:48.0 -0400 > > Looks like owned by root but access by frank ? > > Will chown work ? Your hostname is "fedora"? Um. Skipping that for now Yes, chown would work, although chgrp would be the more "natural" pick. Either chown 0:0 / or chgrp 0 / While you're poking around in there, the permissions are also different from what one would normally expect on Debian. chmod 755 / Then again, if this isn't actually a Debian host, the 555 permissions on the root directory might be normal.
Re: Upgrade problems?
On 2021-07-21 10:52 a.m., Kushal Kumaran wrote: On Wed, Jul 21 2021 at 09:26:41 AM, Frank McCormick wrote: Got a bunch of strange errors during this morning upgrade of Bullseye. Setting up systemd (247.3-6) ... Detected unsafe path transition / → /run during canonicalization of /run. Detected unsafe path transition / → /run during canonicalization of /run/lock. Detected unsafe path transition / → /var during canonicalization of /var. Detected unsafe /snip/ frank@fedora ~$ stat / File: / Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 806h/2054d Inode: 2 Links: 18 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 1000/ frank) Context: system_u:object_r:root_t:s0 Access: 2021-07-21 10:22:56.572440309 -0400 Modify: 2021-06-26 15:48:58.771330459 -0400 Change: 2021-06-27 10:10:28.333447227 -0400 Birth: 2021-06-11 13:38:48.0 -0400 Looks like owned by root but access by frank ? Will chown work ? Thanks
Re: Upgrade problems?
On Wed, Jul 21 2021 at 09:26:41 AM, Frank McCormick wrote: > Got a bunch of strange errors during this morning upgrade of Bullseye. > > > Setting up systemd (247.3-6) ... Detected unsafe path transition / → > /run during canonicalization of /run. Detected unsafe path transition > / → /run during canonicalization of /run/lock. Detected unsafe path > transition / → /var during canonicalization of /var. Detected unsafe > path transition / → /var during canonicalization of /var/lib. Detected > unsafe path transition / → /var during canonicalization of > /var/lib/systemd. Detected unsafe path transition / → /run during > canonicalization of /run. Detected unsafe path transition / → /run > during canonicalization of /run/systemd. Detected unsafe path > transition / → /run during canonicalization of /run/systemd. Detected > unsafe path transition / → /run during canonicalization of > /run/systemd. Detected unsafe path transition / → /run during > canonicalization of /run/systemd. Detected unsafe path transition / → > /run during canonicalization of /run/systemd. Detected unsafe path > transition / → /run during canonicalization of /run/systemd. Detected > unsafe path transition / → /run during canonicalization of > /run/systemd. Detected unsafe path transition / → /run during > canonicalization of /run/systemd/netif. Detected unsafe path > transition / → /run during canonicalization of > /run/systemd/netif. Detected unsafe path transition / → /run during > canonicalization of /run/systemd/netif. > > Your / directory is not owned by root. (`ls -ld /` or `stat /` to check) > So far, doesn't seem to affect the operation of the computer. > > > Thanks -- regards, kushal
Re: Upgrade problems (wheezy->jessie)
Hi jpff wrote: > 1) Why will vmlinuz-3.16.0-4-amd64 not load (says loading and the does > nothing for over 30mins) when vmlinuz-3.2.0-4-amd64 does load? > don't know - I had same issue In my case I found out that initrd was broken. I still have to unpack the initrd copy /sbin/switch_root and package initrd again, so that I can boot. Why this - I don't know ... > 2) Is it OK to run with the older kernel? > yes, I ran jessie almost 2y with 3.2.0.4-amd64 - nothing wrong happened, no problems > 3) More importantly will it happen on Jessie->Stretch as climbing up > to dismantle the local net is hard (I have a balance issue) or is > there a way of testing before rebooting? > Perhaps you make a copy to virtual machine or another computer and try it there first changes are usually not applied directly to productive systems, you do it on a test system first and take notes - best write step by step guide further more read carefully the upgrade instructions provided by debian. If you stick to them, you usually won't have problems. regards
Re: Upgrade problems (wheezy->jessie)
On 09/20/17 08:32, jpff wrote: I seem to need to upgrade to Debian stretch to install my printer as it needs hplip 3.16.11, ad I was running wheezy. ... While some people succeed at major version upgrades, the few times I have attempted it resulted in breakage, frustration, and lots of wasted time and energy. Now I backup my configuration settings, remove the old system drive, take an image of the old system drive, install a new/ zeroed/ secure erased system drive, do a fresh install, migrate my configuration settings, and test each subsystem as I go. If everything works, I'm done. If not, I lower my expectations, find another distribution, and/or build another computer, and restart from "do a fresh install". I have reached two conclusions: 1. Upgrading software is the act of replacing an existing, partially-known set of bugs with a another set of bugs -- some old, some new, some known, some unknown. 2. Software distributors never fix 100% of their bugs -- they make a new release, abandon the old release, and declare victory. David
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
[Kevin Mark] I thought that 'reinstall' seems very time consuming and thought that there may be a diffent way to do it. Would this work for (most|all)? cheers, Yes, I believe so. So the latest incarnation of the script to fix this problem uses this apporach. It is in sysv-rc version 2.86.ds1-19. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
[Bastian Venthur] Looks like there is still something left to do for the user after this step. Eg, on my machine KDM did not start up automatically anymore, as well as WLAN. Those are two things I encountered directly and are probably easy to fix, but I'm quite uncertain if there is something else broken in the background I'm not aware of. I suspect you ran into the problem with removed but not purged packages being reinstalled, where they would throw out conflicting packages which were installed. fam would for example throw out kde. Is there an easy solution to check and fix all involved packages at once? You can look in /var/log/dpkg.log for the packages that was removed, and reinstall them. Again, sorry for the mess. :( Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
On Sat, Sep 09, 2006 at 17:25:41 -0700, Paul Scott wrote:
Petter Reinholdtsen wrote:
Sorry for the noise. Here is yet another script fragment, this time
to extract the list of installed and upgraded packages in the
dangerous period. I did not know about the /var/log/dpkg.log file
before this morning.
sed -n /installed sysvinit 2.86.ds1-16/,/installed sysvinit
2.86.ds1-18/p /var/log/dpkg.log |
awk '/ upgrade / { print $4 } / installed / { print $5 }' | sort -u
These packages, if they contain an init.d script, are the ones needing
a reinstall.
At the moment I have to carry the files on a floppy to the problem
computer (a half hour away) since this broke my wireless. I am going to
try hostapd, wireless-tools, and pcmciautils. Does that sound about right?
Also sysvinit 2.86.dsl-18 is not yet available for sid AFAICT.
You can wget version -19 directly from the main Debian server:
http://ftp.us.debian.org/debian/pool/main/s/sysvinit/sysv-rc_2.86.ds1-19_all.deb
and install it with dpkg -i. This version has a suggestion for a
better way to fix all links: As others have already pointed out in the
bug report and in this thread, it is sufficient to run dpkg-reconfigure
-u on the broken packages. That is a lot faster than the reinstall,
especially for you since it should work without net access.
--
Regards,
Florian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
Petter Reinholdtsen wrote:
Sorry for the noise. Here is yet another script fragment, this time
to extract the list of installed and upgraded packages in the
dangerous period. I did not know about the /var/log/dpkg.log file
before this morning.
sed -n /installed sysvinit 2.86.ds1-16/,/installed sysvinit
2.86.ds1-18/p /var/log/dpkg.log |
awk '/ upgrade / { print $4 } / installed / { print $5 }' | sort -u
These packages, if they contain an init.d script, are the ones needing
a reinstall.
At the moment I have to carry the files on a floppy to the problem
computer (a half hour away) since this broke my wireless. I am going to
try hostapd, wireless-tools, and pcmciautils. Does that sound about right?
Also sysvinit 2.86.dsl-18 is not yet available for sid AFAICT.
Paul Scott
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
Hi Petter, On Fri, Sep 08, 2006 at 07:22:53PM +0200, Petter Reinholdtsen wrote: In version 2.86.ds1-16 of the sysv-rc package released 2006-09-06, the update-rc.d script was broken. When used to to update symlinks it would remove all symlinks for a init.d script if such symlinks existed, and add them if they were missing. This broke all packages being upgraded after the new version was installed, as their init.d scripts will no longer be executed. This problem was fixed in version 2.86.ds1-18, but the broken packages will stay broken until their postinst scripts are executed again. Those with packages being broken from this bug can fix it by using 'apt-get --reinstall install package' on the affected packages. A quick way out is to reinstall all the packages with scripts in /etc/init.d/. for p in `dpkg -S /etc/init.d/*|cut -d: -f1|sort -u`; do apt-get --reinstall install -y $p done I'm sorry for the problems I have caused. Friendly, -- As a test, on my working unstable system, I did this: I made a note of the current links for 'cron' ran 'rm /etc/rc*.d/*cron' ran '/etc/init.d/cron stop' ran 'bash /var/lib/dpkg/info/cron.postinst' and found it to restore the default setup. I thought that 'reinstall' seems very time consuming and thought that there may be a diffent way to do it. Would this work for (most|all)? cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
Sorry for the noise. Here is yet another script fragment, this time
to extract the list of installed and upgraded packages in the
dangerous period. I did not know about the /var/log/dpkg.log file
before this morning.
sed -n /installed sysvinit 2.86.ds1-16/,/installed sysvinit 2.86.ds1-18/p
/var/log/dpkg.log |
awk '/ upgrade / { print $4 } / installed / { print $5 }' | sort -u
These packages, if they contain an init.d script, are the ones needing
a reinstall.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
[Petter Reinholdtsen] A quick way out is to reinstall all the packages with scripts in /etc/init.d/. This way proved to be too quick, trying to reinstall removed but not purged packages with init.d scripts left behind in /etc/init.d/. I recommend using something like this instead, to only reinstall the installed packages: for p in `dpkg -S /etc/init.d/*|cut -d: -f1|sort -u`; do if dpkg --get-selections $p | grep -qw install ; then echo reinstalling $p apt-get --reinstall install $p fi done I dropped the '-y' flag too, to leave more manual control over the process, after a report from a user getting a lot of KDE removed when the removed fam package tried to reinstall and throw out KDE. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems for sysvinit 2.86.ds1-16 - 2.86.ds1-18
Petter Reinholdtsen wrote: Those with packages being broken from this bug can fix it by using 'apt-get --reinstall install package' on the affected packages. A quick way out is to reinstall all the packages with scripts in /etc/init.d/. for p in `dpkg -S /etc/init.d/*|cut -d: -f1|sort -u`; do apt-get --reinstall install -y $p done Looks like there is still something left to do for the user after this step. Eg, on my machine KDM did not start up automatically anymore, as well as WLAN. Those are two things I encountered directly and are probably easy to fix, but I'm quite uncertain if there is something else broken in the background I'm not aware of. Is there an easy solution to check and fix all involved packages at once? Cheers, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems..
On Sun, 28 Jun 1998, Gregory Guthrie wrote: I just did an upgrade bo -- hamm using autoup.sh. Amazing. But, there are a number of steps which left me cold; and flipping a coin for the right action. 1) during the autoup it had several conflicts, adn it was not clear to me if I needed to do anything about them. E.g. I think it tried to remove something that depended on Perl, but I had perl installed, or something... dependency problems .. libwww-perl depends on Perl, but perl is not installed. ... libnet Anyway, there was no clear indication if all was OK, if it was a comment, or if some remedial action was needed (later)., Take a look at the autoup.sh script itself. It should give you a fairly clear picture at what it is attempting to do and possibly the means to understand what is happening here. 2) After update, it says now use dselect to upgrade the rest of your system, then reboot. ?? How do I know what to upgrade? I would like to say; whatever needs an upgrade, if I have it installed, do it. Instead, I had to go through dselect, look at hundreds of packages, try to remember which I had selected, and decide if they need update. Am I missing something here? You need to run [A]cess to change from stable to dists/frozen/main, dists/frozen/contrib, dists/frozen/non-free. Then run [U]pdate to get the Packages files corresponding to frozen. Then when you run [S]elect, you will see a large list of new and updated packages. It should indicate that the updated packages, which are all the packages currently installed for which there are new hamm versions, have been selected for upgrading. At this point, you should probably run [I]nstall without changing anything, but you might want to see if anything you do not want/need is marked for installation (it does happen). You might have to run [I]nstall more than once to resolve things. Bob Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Upgrade problems..
On Thu, 9 Jul 1998, Gregory Guthrie wrote: Bob, thanks for the information.. I wish this was in the autoup.sh documentation! In addition to autoup.sh, there is the libc5-libc6 mini-HOWTO, which should be required reading, even for those using the script. Watching the recent traffic on upgrade problems, and issues makes me wonder.. One concluded that it isin't automatic, and you really have to know all the dependencies, that dselect will only have shallow knowledge of local dependencies. As I understand, apt can handle dependencies a bit better than dselect. If you install apt, it appears as an additional method for deselect, so you can still use dselect. It also supports http, which seems to work a bit faster (no login, max ftp users, etc.) This raises the question, how much Unix expertise do you need to be able to live with Linux, Debian..? Well I started with practically none (a UNIX for Dummies book, in fact). I've learned a lot in the last 3+ years of using Linux (Slackware, Red Hat and Debian), but I've still got a lot to learn. This list itself has been a real asset in the process. In fact, a lot of the dependencies are not Unix general, but specific to a particular environment, Emacs, man, troff, X11, etc... Are we at the simplest way? what is next? I know our Solaris system does not have any upgrades this complex. I am not sure how they manage their upgrades... The rexx-bo upgrade was nowhere near as complex as bo-hamm. Libc6 increased the complexity of the upgrade immensely. I would expect the upgrade to slink will go much more smoothly. Bob Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Upgrade problems..
Bob, thanks for the information.. I wish this was in the autoup.sh documentation! Watching the recent traffic on upgrade problems, and issues makes me wonder.. One concluded that it isin't automatic, and you really have to know all the dependencies, that dselect will only have shallow knowledge of local dependencies. This raises the question, how much Unix expertise do you need to be able to live with Linux, Debian..? In fact, a lot of the dependencies are not Unix general, but specific to a particular environment, Emacs, man, troff, X11, etc... Are we at the simplest way? what is next? I know our Solaris system does not have any upgrades this complex. I am not sure how they manage their upgrades... Gregory Guthrie At 04:10 PM 7/9/98 -0700, Bob Nielsen wrote: On Sun, 28 Jun 1998, Gregory Guthrie wrote: I just did an upgrade bo -- hamm using autoup.sh. Amazing. But, there are a number of steps which left me cold; and flipping a coin for the right action. ... Take a look at the autoup.sh script itself. It should give you a fairly clear picture at what it is attempting to do and possibly the means to understand what is happening here. You need to run ... Then when you run . At this point, you should probably run ... You might have to run ... more than once to resolve things. Dr. Gregory Guthrie [EMAIL PROTECTED] (515)472-1125Fax: -1103 Computer Science Department College of Science and Technology Maharishi University of Management (Maharishi International University 1971-1995) -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Upgrade problems..
2) After update, it says now use dselect to upgrade the rest of your system, then reboot. ?? How do I know what to upgrade? I would like to say; whatever needs an upgrade, if I have it installed, do it. Instead, I had to go through dselect, look at hundreds of packages, try to remember which I had selected, and decide if they need update. Am I missing something here? Yes. Dselect will automatically mark the packages with newer version available for upgrade. You may still look through them, and mark for removal the ones you don't need to avoid extra time for download. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems
When Tod Detre wrote, I replied: Are you using apt as your access method? I've started using this and specifying a list of sites to use for access and am delighted with the results. I recently ran dselafter not having done so for an extended period. I downloaded something (I forget just what) and dselect automatically brought down ~25-30 applications which had been upgraded since last I ran dselect. It took several re-starts to get the required packages (my ISP hangs up after six hours) but other than restarting ppp (which I could let diald or something handle weere I a bit less paranoid) and hitting RETURN a few times in dselect, things went swimmingly. Two or three files in parallel from different mirrors kept my 33600 modem pulling ~4kb/s - Nice job!! Ok I upgraded to Hamm, but now dselevt is unhappy. It's probubly my config error but I don't know what. When ever I try to install stuff it wants to upgrade alot of stuff (expected it wants to put newer versions on.) but when it trys to get the file it can't find them. I ftped myself to ftp.debian.org and found the files where dselect was supposedly looking for them. I'm using ftp.debian.org directory /debian/hamm dists main non-free contrub it gets the lists just fine, but can't get the files Tod Detre |Losers whine about their best, winners go home and @%^ the | prom queen. -Sean Connery (The Rock) |It is TOD not TODD! Do you see God spelling his name | Godd? -Me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ralph Winslow [EMAIL PROTECTED] Insert sardonic phrase here -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade problems
On Sat, 27 Jun 1998, Tod Detre wrote: Ok I upgraded to Hamm, but now dselevt is unhappy. It's probubly my config error but I don't know what. When ever I try to install stuff it wants to upgrade alot of stuff (expected it wants to put newer versions on.) but when it trys to get the file it can't find them. I ftped myself to ftp.debian.org and found the files where dselect was supposedly looking for them. I'm using ftp.debian.org directory /debian/hamm dists main non-free contrub Try: Site: ftp.debian.org (or whatever mirror you prefer) directory: /debian distributions: dists/frozen/main dists/frozen/non-free dists/frozen/contrib This works consistently. You might want to try apt (http://www.debian.org/~jgg/apt_0.0.17-1_i386.deb), which adds another method to dselect as well as providing a command line method. Bob Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
