Re: [Fwd: Re: [Cooker] Oxygen upgrade difficulties]
Axalon Bloodstone wrote: > > See the archives about ncurses i refuse to fix it again if it's just going > to get lost ;) > Without having to check the archives, there seems to be no need for ncurses being in /lib instead of /usr/lib. The spec said something about it being needed by sh, but it's not. acroread.desktop seems to be missing form the acroread RPM, just while we're on the subject. But how is it a file gets in the file list but doesn't get installed? -- Sincerely, David Walluck <[EMAIL PROTECTED]>
Re: [Fwd: Re: [Cooker] Oxygen upgrade difficulties]
On Sat, 1 Jan 2000, David Walluck wrote: > Oops.. this went to the wrong place... > > Original Message > Subject: Re: [Cooker] Oxygen upgrade difficulties > Date: Fri, 31 Dec 1999 17:13:32 -0500 > From: David Walluck <[EMAIL PROTECTED]> > To: Jacques Le Marois <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > Jacques Le Marois wrote: > > David, > > > > Just curious - how do you upgrade daily ? This could be useful for > > others users... > > > > Jacques > > Let me clarify what I meant by `upgrade daily'. I meant that each day I > go online and get the Cooker updates for that day. I do this as a cron > job. I can't use rsync because I only have about 100M free, so there is > not enough room to mirror the entire distribution. I use a perl script I > found called rhupd, which unfortunately doesn't seem to be being > maintained. I'll attach it here because it is only 12K. > > In your cron you might want to do something like this: > > cd /home/cooker > rhupd -a > cooker-updates-`date +%Y%m%d`.log 2>&1 > rpm -Uvh --nodeps --force *.rpm > cooker-install-`date +%Y%m%d`.log 2>&1 > rm -rf *.rpm > > Unfortunately, there's still many conflicts between packages which > requires a --force. The --nodeps is needed because a required update > might not be mirrored yet. I've never had anything break because of > this, though. Also, sometimes the updates aren't recognized. For > example, Mesa-3.1 is newer than Mesa-3.1cvs, but numerically it's > not, so you'd have to realize this and grab the update yourself. This > has worked well for me so far, and hopefully it will be useful for > others as well. > > I suggested that MandakeUpdate use the Cooker mirrors while in Cooker, > and then switch to Oxygen mirror for the release RPM. This would let us > upgrade daily using MandrakeUpdate. Unfortunately, this is a graphical > program and can't easily be automated. What I'd really like to see is > someone from Mandrake pickup this rhupd script and maybe do something > like this in the Mandrake release. There is also a program called > autorpm, but I found this to be too cumbersome. > > One other thing I'd like to mention is the rpmverify script that can be > found in Mandrake Contrib. This is very useful for finding failed > dependencies or missing files in packages. For example, the script > exposed problems with the ncurses, acroread, and initscripts RPMS, among > others. Some of these, like the ncurses symlinks bug, have been in the > bug database for a long time and never been fixed. > See the archives about ncurses i refuse to fix it again if it's just going to get lost ;) You stated the Mesa versions backwards but we get the idea, we'll be makeing minor changes to the release numbering scheme after 7.0 to cooker packages, so in theory you'll be able todo actual upgrades from cooker -> cooker cooker -> beta stable -> cooker cooker -> stable And all the combo's of the above, should be fully functional after the next stable release. -- MandrakeSoft http://www.mandrakesoft.com/ --Axalon
[Fwd: Re: [Cooker] Oxygen upgrade difficulties]
Oops.. this went to the wrong place... Original Message Subject: Re: [Cooker] Oxygen upgrade difficulties Date: Fri, 31 Dec 1999 17:13:32 -0500 From: David Walluck <[EMAIL PROTECTED]> To: Jacques Le Marois <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Jacques Le Marois wrote: > David, > > Just curious - how do you upgrade daily ? This could be useful for > others users... > > Jacques Let me clarify what I meant by `upgrade daily'. I meant that each day I go online and get the Cooker updates for that day. I do this as a cron job. I can't use rsync because I only have about 100M free, so there is not enough room to mirror the entire distribution. I use a perl script I found called rhupd, which unfortunately doesn't seem to be being maintained. I'll attach it here because it is only 12K. In your cron you might want to do something like this: cd /home/cooker rhupd -a > cooker-updates-`date +%Y%m%d`.log 2>&1 rpm -Uvh --nodeps --force *.rpm > cooker-install-`date +%Y%m%d`.log 2>&1 rm -rf *.rpm Unfortunately, there's still many conflicts between packages which requires a --force. The --nodeps is needed because a required update might not be mirrored yet. I've never had anything break because of this, though. Also, sometimes the updates aren't recognized. For example, Mesa-3.1 is newer than Mesa-3.1cvs, but numerically it's not, so you'd have to realize this and grab the update yourself. This has worked well for me so far, and hopefully it will be useful for others as well. I suggested that MandakeUpdate use the Cooker mirrors while in Cooker, and then switch to Oxygen mirror for the release RPM. This would let us upgrade daily using MandrakeUpdate. Unfortunately, this is a graphical program and can't easily be automated. What I'd really like to see is someone from Mandrake pickup this rhupd script and maybe do something like this in the Mandrake release. There is also a program called autorpm, but I found this to be too cumbersome. One other thing I'd like to mention is the rpmverify script that can be found in Mandrake Contrib. This is very useful for finding failed dependencies or missing files in packages. For example, the script exposed problems with the ncurses, acroread, and initscripts RPMS, among others. Some of these, like the ncurses symlinks bug, have been in the bug database for a long time and never been fixed. -- Sincerely, David Walluck <[EMAIL PROTECTED]> #!/usr/bin/perl # # rhupd - fetch redhat package manager updates from the network # $Revision: 1.16 $ # # Author/Maintainer: Stig HackVän <[EMAIL PROTECTED]> # Latest Version:http://hackvan.com/pub/stig/src/linux/ # # USAGE: rhupd [-afnqu] [ known_mirror_host | [user@]host:/path/to/rpm_directory ] # # -a - get all files without prompting # -f - force download even if file already exists in current directory # -n - identify packages that are "new" (e.g. not yet installed) # -r - redhat release directory # -u - identify "updates" packages (e.g. don't mention older versions) # -q - quiet operation (intended for late-night cron invocation) # -v - verbose operation (intended for debugging) # # rhupd queries the set of installed packages on the local machine. It # then connects to the redhat repository of your choice via ftp, examines # the list of available updates there, and informs you of any packages that # have had their patch level increased or version number changed. You can # then choose to have all of the indicated packages downloaded, or # individually select which packages to download. The transferred RPMs are # placed in the current working directory. They can then be installed on # your system by using the command rpm -u , where is one of # the downloaded RPMs. # # Note that if there is an update to RPM or GLINT, these should be updated # first! # # # $Header: /u/stig/bin/RCS/rhupd,v 1.16 1998/10/27 00:54:33 stig Exp stig $ # # $Log: rhupd,v $ # Revision 1.16 1998/10/27 00:54:33 stig # add updates.redhat.com # use "user@" as login name # fix bug in ftp://user@host/path regex # # Revision 1.15 1998/05/29 17:11:37 stig # added -r flag to permit 'rhupd -ar 5.1' as a means of upgrading to a new release of redhat # # Revision 1.14 1998/03/07 05:51:20 stig # Automatically detect redhat version number (works for 4.2 or 5.0, may break in future) # # Revision 1.13 1998/02/26 21:50:01 stig # Fixed handling of prompt input. I always use it in batch mode... # # Revision 1.12 1998/02/26 21:38:35 stig # Updated default paths to point to one of the redhat 4.2 mirror sites. # # Revision 1.11 1997/10/16 17:56:25 stig # retry login if server is busy. # # Revision 1.10 1997/07/26 05:15:20 stig # added restarting capability for partial transfers # # fixed version compar
Re: [Cooker] Oxygen upgrade difficulties
> Actually, I spent several hours writing an image file of my entire > production drive to a secondary removable, as is my practice every > week. These images, however, were then burned to CD-R as a snapshot of my > pre-Beta system, both for future reference and as a means to get myself > "To-Where-I-Was-Before." But I do agree that it is foolish for anyone who > isn't prepared to lose everything to even consider installing the Beta over > a working system. > > Anton I disagree. The only thing I see as causing problems is a patched kernel, so if you're worried you can go with Linus' vanilla kernel. I have been using Mandrake Cooker from the start, and I'm happy to say that I have had no data loss related to the installation of Mandrake Cooker, which I update daily. -- Sincerely, David Walluck <[EMAIL PROTECTED]>
Re: [Cooker] Oxygen upgrade difficulties
At 01:51 PM 12/29/99 +0100, you wrote: >Anton Graham <[EMAIL PROTECTED]> writes: > > > 4 Primary 7260435 12706469 0 5446035 Linux extended > (85)None (00) > >wow, i didn't know this one! first time i see it ;-) > >corrected by now... in the meantime, to be able to test, i suggest you toggle >the 0x85 in 0x5. I'll try that in the morning. Thanks.
Re: [Cooker] Oxygen upgrade difficulties
At 04:01 AM 12/29/99 -0700, you wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >This might sound like "nuts" but are these people backing up their data when >installing the upgrade over their original? > >Just curious...lmao already read some posts were people actually think "beta" >means "final release" for some reasonlol. Actually, I spent several hours writing an image file of my entire production drive to a secondary removable, as is my practice every week. These images, however, were then burned to CD-R as a snapshot of my pre-Beta system, both for future reference and as a means to get myself "To-Where-I-Was-Before." But I do agree that it is foolish for anyone who isn't prepared to lose everything to even consider installing the Beta over a working system. Anton
Re: [Cooker] Oxygen upgrade difficulties
Anton Graham <[EMAIL PROTECTED]> writes: > 4 Primary 7260435 12706469 0 5446035 Linux extended (85)None (00) wow, i didn't know this one! first time i see it ;-) corrected by now... in the meantime, to be able to test, i suggest you toggle the 0x85 in 0x5. thanks, cu Pixel.
Re: [Cooker] Oxygen upgrade difficulties
If, like me, don't want to keep on installing o/s such as *cough* windows every time, then getting another hard drive or 2 is ideal. a little expensive I know.but a price to pay for retaining data. Prashant. - Original Message - From: "Roger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 29, 1999 11:01 AM Subject: Re: [Cooker] Oxygen upgrade difficulties > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This might sound like "nuts" but are these people backing up their data when > installing the upgrade over their original? > > Just curious...lmao already read some posts were people actually think "beta" > means "final release" for some reasonlol. > > > > On Wed, 29 Dec 1999, you wrote: > > > > This afternoon, I received a disc containing the 7.0 Beta (Oxygen) from > > CheapBytes. The time stamp on the gi_cdrom.img is 21 Dec 99 20:32. The > > boot.cat time stamp is 22 Dec 99 16:05. > > > > When trying to perform an upgrade from 6.1 (Helios), it reports an > > inability to read the partition table on the hard disk. The following > > dialog states that /dev/hda2 is not a valid root partition and that I > > should select another. I am then informed there is no valid root > > partition, and it sends me back to the inability to read partition table > > dialog. This occurs both in Custom and Expert modes. > > > > My partition table is attached as is the dmesg output and the relevant > > messages from the third VC. > > > > /dev/hda2 is indeed not a root partition, it mounts as /boot (as many > > people who must dual boot have done due to BIOS limitations). But, I am > > not being given the option of selecting the correct partition. > > > > - > Content-Type: text/plain; name="unnamed" > Content-Transfer-Encoding: 7bit > Content-Description: > - > > - > Content-Type: text/plain; name="unnamed" > Content-Transfer-Encoding: 7bit > Content-Description: > - > > - > Content-Type: text/plain; name="unnamed" > Content-Transfer-Encoding: quoted-printable > Content-Description: > - > > - -- > > > Sent from: > > Lattitude (deg): 32.7130 > Longitude (deg): -117.1530 > Altitude (ft): 410.0 > GMT to Local (hrs): -8.0 (daylight savings enabled) > > - > > Created with Linux-Mandrake 6.1! > > http://www.linux-mandrake.com/ > > Currently Beta Testing Mandrake Ver 7.0 (CODE NAMED: OXYGEN) > > -BEGIN PGP SIGNATURE- > Version: PGP 6.5.1 > > iQA/AwUBOGnqmJWnEdBpryyVEQLY6ACgqrkzI+SMhWSmaFkKr3VV4lwo7DsAoPgR > 0G/c6mhW8dt70x15tbuFGthF > =Dpq5 > -END PGP SIGNATURE- >
Re: [Cooker] Oxygen upgrade difficulties
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This might sound like "nuts" but are these people backing up their data when installing the upgrade over their original? Just curious...lmao already read some posts were people actually think "beta" means "final release" for some reasonlol. On Wed, 29 Dec 1999, you wrote: > > This afternoon, I received a disc containing the 7.0 Beta (Oxygen) from > CheapBytes. The time stamp on the gi_cdrom.img is 21 Dec 99 20:32. The > boot.cat time stamp is 22 Dec 99 16:05. > > When trying to perform an upgrade from 6.1 (Helios), it reports an > inability to read the partition table on the hard disk. The following > dialog states that /dev/hda2 is not a valid root partition and that I > should select another. I am then informed there is no valid root > partition, and it sends me back to the inability to read partition table > dialog. This occurs both in Custom and Expert modes. > > My partition table is attached as is the dmesg output and the relevant > messages from the third VC. > > /dev/hda2 is indeed not a root partition, it mounts as /boot (as many > people who must dual boot have done due to BIOS limitations). But, I am > not being given the option of selecting the correct partition. > - Content-Type: text/plain; name="unnamed" Content-Transfer-Encoding: 7bit Content-Description: - - Content-Type: text/plain; name="unnamed" Content-Transfer-Encoding: 7bit Content-Description: - - Content-Type: text/plain; name="unnamed" Content-Transfer-Encoding: quoted-printable Content-Description: - - -- Sent from: Lattitude (deg):32.7130 Longitude (deg):-117.1530 Altitude (ft): 410.0 GMT to Local (hrs): -8.0 (daylight savings enabled) - Created with Linux-Mandrake 6.1! http://www.linux-mandrake.com/ Currently Beta Testing Mandrake Ver 7.0 (CODE NAMED: OXYGEN) -BEGIN PGP SIGNATURE- Version: PGP 6.5.1 iQA/AwUBOGnqmJWnEdBpryyVEQLY6ACgqrkzI+SMhWSmaFkKr3VV4lwo7DsAoPgR 0G/c6mhW8dt70x15tbuFGthF =Dpq5 -END PGP SIGNATURE-
[Cooker] Oxygen upgrade difficulties
This afternoon, I received a disc containing the 7.0 Beta (Oxygen) from CheapBytes. The time stamp on the gi_cdrom.img is 21 Dec 99 20:32. The boot.cat time stamp is 22 Dec 99 16:05. When trying to perform an upgrade from 6.1 (Helios), it reports an inability to read the partition table on the hard disk. The following dialog states that /dev/hda2 is not a valid root partition and that I should select another. I am then informed there is no valid root partition, and it sends me back to the inability to read partition table dialog. This occurs both in Custom and Expert modes. My partition table is attached as is the dmesg output and the relevant messages from the third VC. /dev/hda2 is indeed not a root partition, it mounts as /boot (as many people who must dual boot have done due to BIOS limitations). But, I am not being given the option of selecting the correct partition. Partition Table for /dev/hda FirstLast # Type Sector Sector Offset Length Filesystem Type (ID) Flags -- --- - -- - -- - 3 Primary045359 6345360 Compaq diagnostic (12) None (00) 2 Primary4536090719 045360 Linux (83) Boot (80) 1 Primary90720 7260434 0 7169715 Win95 FAT32 (LBA) (0C) None (00) 4 Primary 7260435 12706469 0 5446035 Linux extended (85)None (00) 5 Logical 7260435 7465499 63 205065 Linux (83) None (00) 6 Logical 7465500 7629929 63 164430 Linux (83) None (00) 7 Logical 7629930 7937999 63 308070 Linux (83) None (00) 8 Logical 7938000 8184644 63 246645 Linux (83) None (00) 9 Logical 8184645 8431289 63 246645 Linux (83) None (00) 10 Logical 8431290 8628794 63 197505 Linux swap (82)None (00) 11 Logical 8628795 12706469 63 4077675 Linux (83) None (00) * trying to mount partition hda2 <4>Linux version 2.2.14-BOOT1 ([EMAIL PROTECTED]) (gcc version 2.95.2 19991024 (release)) #9 Tue Dec 21 18:38:32 CET 1999 <4>Detected 200468539 Hz processor. <4>Console: colour dummy device 80x25 <4>Calibrating delay loop... 80.08 BogoMIPS <4>Memory: 94856k/98304k available (852k kernel code, 412k reserved, 1228k data, 64k init) <4>Dentry hash table entries: 16384 (order 5, 128k) <4>Buffer cache hash table entries: 131072 (order 7, 512k) <4>Page cache hash table entries: 32768 (order 5, 128k) <4>CPU: Intel Pentium 75 - 200 stepping 0c <6>Checking 386/387 coupling... OK, FPU using exception 16 error reporting. <6>Checking 'hlt' instruction... OK. <6>Checking for popad bug... OK. <6>Intel Pentium with F0 0F bug - workaround enabled. <4>POSIX conformance testing by UNIFIX <4>PCI: PCI BIOS revision 2.10 entry at 0xf42b2 <4>PCI: Using configuration type 1 <4>PCI: Probing PCI hardware <3>PCI: 00:00 [0e11/4000/000600] has unknown header type ff, ignoring. <3>PCI: 00:01 [0e11/4000/000600] has unknown header type ff, ignoring. <3>PCI: 00:02 [0e11/4000/000600] has unknown header type ff, ignoring. <3>PCI: 00:03 [0e11/4000/000600] has unknown header type ff, ignoring. <3>PCI: 00:04 [0e11/4000/000600] has unknown header type ff, ignoring. <3>PCI: 00:05 [0e11/4000/000600] has unknown header type ff, ignoring. <3>PCI: 00:06 [0e11/4000/000600] has unknown header type ff, ignoring. <3>PCI: 00:07 [0e11/4000/000600] has unknown header type ff, ignoring. <6>Linux NET4.0 for Linux 2.2 <6>Based upon Swansea University Computer Society NET3.039 <6>NET4: Unix domain sockets 1.0 for Linux NET4.0. <6>NET4: Linux TCP/IP 1.0 for NET4.0 <6>IP Protocols: ICMP, UDP, TCP <4>TCP: Hash tables configured (ehash 131072 bhash 65536) <4>Starting kswapd v 1.5 <4>vesafb: framebuffer at 0x4400, mapped to 0xc6802000, size 16384k <4>vesafb: mode is 640x480x16, linelength=1280, pages=26 <4>vesafb: protected mode interface info at c000:7e6b <4>vesafb: scrolling: redraw <4>vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0 <4>Console: switching to colour frame buffer device 80x30 <4>fb0: VESA VGA frame buffer device <6>Detected PS/2 Mouse Port. <4>RAM disk driver initialized: 16 RAM disks of 32000K size <4>PCI_IDE: unknown IDE controller on PCI bus 00 device 79, VID=0e11, DID=ae33 <4>PCI_IDE: not 100% native mode: will probe irqs later <4>ide0: BM-DMA at 0x1010-0x1017, BIOS settings: hda:pio, hdb:pio <4>ide1: BM-DMA at 0x1018-0x101f, BIOS settings: hdc:pio, hdd:pio <4>hda: ST36531A, ATA DISK drive <4>hdc: CREATIVE CD-RW RW4224E, ATAPI CDROM drive <4>hdd: HITACHI CDR-7930, ATAPI CDROM drive <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 <4>ide1 at 0x170-0x177,0x376 on irq 15 <6>hda: ST36531A, 6204MB w/128kB Cache, CHS=13446/15/63 <4>hdc: ATAPI 24X CD-ROM CD-R/RW drive, 1860kB Cache <6>Uniform CDROM driver Revision: 2.56 <4>hdd: ATAPI 8X CD-ROM drive, 128kB Cache <6>Floppy drive(s): fd0 is 1.44M <6>FDC 0 is a National Semiconductor PC87306 <6>md driv
