[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] Bad quality of updates from SuSE ftp server



It is very strange but here is, what formed the solution!!!

After mounting the partitions,
chroot sysimage bash
started Yast.
	Uninstalled k_athlon...
	installed k_athlon...old
exit yast

mkinitrd
lilo
umount all
reboot.

It looks that the ft3xx driver now is loaded and working properly, not
sure how...since I only installed the driver in the rescue option.
As a result on startup before bios, fasttrack initializes and lilo
starts up the system.
Everything is working fine.

Thank you for your help & advice Sandu.
I will be a lot more carefull from now on.
 
-savvas


Στις 09/Σεπ/2004, ημέρα Πέμπτη και ώρα 16:06, ο/η Sandu Mihai έγραψε:
> The mkinitrd command must be run from inside a CHROOTED shell onto the 
> sysimage directory.
> After the mounts, do:
> chroot sysimage bash
> 
> then run /sbin/mkinitrd
> 
> Savvas Ladopoulos wrote:
> 
> >Sorry for the delay, had to do some reading. 
> >
> >I was able to mount the system and did : 
> >
> >Boot rescue
> >mkdir sysimage
> >mount /dev/sda2 sysimage
> >mount /dev/sda1 sysimage/boot
> >mount /dev/system/Home_VOlume  sysimage/home
> >mount /dev/system/Var_VOlume  sysimage/var
> >mount /dev/system/Usr_VOlume  sysimage/usr
> >mount /dev/system/Opt_VOlume  sysimage/opt
> >mount /dev/system/Srv_VOlume  sysimage/srv
> >mount /dev/system/Tmp_VOlume  sysimage/tmp
> >
> >/sbin/mkinitrd
> >exit
> >umount sysimage/tmp
> >umount sysimage/srv
> >umount sysimage/opt
> >umount sysimage/usr
> >umount sysimage/var
> >umount sysimage/home
> >umount sysimage/boot
> >
> >sync 
> >reboot
> >
> >however i do get the same kernel panic!
> >The good thing is that i was able to mount the Reiserfs.
> >Mkinitrd did not load the fasttrack driver as seem from boot output.
> >even if it was seen when run mkinitrd.
> >
> >-savvas
> >
> >
> >
> >
> >Στις 08/Σεπ/2004, ημέρα Τετάρτη και ώρα 08:13, ο/η Sandu Mihai έγραψε:
> >  
> >
> >>On a second tought:
> >>
> >>Boot rescue
> >>Mount system under a directory
> >>chroot  directory bash
> >>/sbin/mkinitrd
> >>exit
> >>reboot
> >>
> >>Eg. for a system that has:
> >>/dev/sda1 - boot
> >>/dev/sda2 - root
> >>/dev/sda3 - var
> >>/dev/sda4 - swap
> >>
> >>Boot rescue
> >>mkdir sysimage
> >>mount /dev/sda2 sysimage
> >>mount /dev/sda1 sysimage/boot
> >>mount /dev/sda3 sysimage/var
> >>    
> >>
> > 
> >  
> >
> >>/sbin/mkinitrd
> >>exit
> >>umount sysimage/var
> >>umount sysimage/boot
> >>umount sysimage
> >>sync
> >>sync
> >>sync
> >>ctrl-alt-del
> >>
> >>It seems that the kernel update probably did not run mkinitrd to refresh 
> >>the initrd (are you using SCSI or  Ext3/Reiserfs probably).
> >>
> >>Sandu Mihai
> >>GTS Telecom Network Engineer
> >>RHCE #807202946505274
> >>
> >>S andu Mihai wrote:
> >>
> >>    
> >>
> >>>First of all,
> >>>
> >>>it is bad practice (tm) to directly update an important production 
> >>>server. Even with a trusted method of updates.
> >>>One of the good practices include :
> >>>- mirroring internally an external available source
> >>>- testing updates on a set of servers / a server that mirror the 
> >>>behavior of the real target of updates
> >>>- never let an external program directly update the kernel, rather do 
> >>>it by hand using rpm -i and not rpm -F, and then add the new kernel in 
> >>>Grub/Lilo if rpm -i dose not do it automatically (Redhat seemed to do 
> >>>that)
> >>>You can undo that by :
> >>>Booting in rescue mode, mounting the partitions of the system under a 
> >>>created directory in the RAM disk, copy the k_athlon...rpm from the 
> >>>first install CD in that directory, chroot <directory> bash, rpm -i 
> >>>k_athlon....rpm, vi /etc/lilo.conf or vi 
> >>>/boot/grub/menu.lst,/sbin/lilo (only if using lilo), exit
> >>>Then, umount the partitions mounted under the directory, reboot.
> >>>These are basic rescue methods one should be aware of , in case ugly 
> >>>things happen to kernel, or to some interesting files of the system 
> >>>(/etc/fstab is my favorite)
> >>>Sorry for the not quite detailed description of the rescue steps, if 
> >>>these steps are really requested by the list I will then send a 
> >>>near-to-reality-step-by-step scenario.
> >>>
> >>>Best regards,
> >>>
> >>>Sandu Mihai
> >>>GTS Telecom Network Engineer
> >>>RHCE #807202946505274
> >>>
> >>>Savvas Ladopoulos wrote:
> >>>
> >>>      
> >>>
> >>>>Just read "Bad quality of updates from SuSE ftp server" and now I
> >>>>understand what went wrong to my suse 9.0 update via YOU. Thank you all.
> >>>>
> >>>>However, I need some quidance on what to do next. I am left with "kernel
> >>>>panic: VFS can not mount root fs on 08:02".
> >>>>I managed with rescue to mount boot but I am not sure if I can undo the
> >>>>2.4.21-243-athlon image to the previous version of 2.4.21-99-athlon?
> >>>>
> >>>>please any advise is much appreciated.
> >>>>
> >>>>-Savvas
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 
> >>>>
> >>>>        
> >>>>
> >>>      
> >>>
> >
> >
> >  
> >



-- 
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here