Re: [Cooker] Rescue disk feature request
On Mon, 2002-07-29 at 20:16, Jason Bowman wrote: On Monday 29 July 2002 05:01 am, Adam Williamson wrote: Um, just to double-check the obvious...does the rescue disk include telnet? Yes, I know telnet Bad and ssh Good, but if you're doing this in a controlled and safe environment... So maybe this just shows my own lack of knowledge... I tried this but did not Actually, more likely to be mine :). I just thought you could do what you were doing with ssh through telnet instead; if not, then I guess you still have the problem :( -- adamw
Re: [Cooker] Rescue disk feature request: a suggestion
On Sunday 28 July 2002 09:18 am, Leon Brooks wrote: I like this ramdisk approach so that you can remove the cd. If you have enough RAM to support it, it's not hard to do. Making the rescue disk too big to run on a minimal machine is a very bad idea. snip I would still want to see nc included on the base rescue cd, but this way I could also make and support another rescue cd for larger systems. (As was debated elsewhere in this thread). How about proposing a `proper' rescue disk on MandrakeForum? I'm guessing that the CookerDrakes are going to be red-eyed and frantic for most of the next month, and unwilling to put scarce resources to a last-minute proposal, however good it is. The idea would be that your proposed rescue runs from CD in case the machine is minimal, but since CDs are so large you should then (or at boot) have the option of remounting with a RAMdisk chock full of interesting utilities (like mkisofs and cdrecord) dedicated to helping you get stuff off a dying box. .insert lots of cool ideas.. (=-0) This sounds like an interesting idea. I wouldn't mind putting some work into this (in between school of course : ) I don't quite understand whats involved in proposing a 'proper' rescue disk... I think at the moment I will delve into what else I can see of the mandrake rescue system, and experiment with mindi and other documentation I have been able to find. Specifically, in making a hardware independant rescue disk, I want to know how Mandrake's rescue disc detects and initializes hardware. In this I am not talking about the drvinst command, I have figured that one out. I'm talking about before the system completes its boot cycle, when a text based status bar is shown installing... say SCSI drivers. Are you man enough for the job? (-: Whether this is something Mandrake would officially support or include does not matter much to me. However, if I can create something good enough they would want to include it, then all the better! Cheers; Leon Later, Jason B.
Re: [Cooker] Rescue disk feature request
People could play with mindi to build their own rescue cdrom. I never tried myself but it is well explained in their documentation. Pascal Le Vendredi 26 Juillet 2002 18:53, Pixel a écrit : Any One [EMAIL PROTECTED] writes: [...] The rescue is not meant for having a basic working linux system, many other things are meant for it. The rescue is only meant for you to be able to mount your local partitions and rescue your mandrake system, whenever you can't boot anymore your mandrake system. Because of that aim, we limit the number of useless stuff which could make it become larger. We want it to stay small. That is your opinion. not really. The current rescue uses a ramdisk to put itself into. It allows to change the cdrom since it's not mounted. The drawback is that we can't inflate much the rescue otherwise even with 64MB of ram it won't fit. the goal of the rescue is not to be a live system. Having a mandrake rescue is important because to rescue a system you need a kernel with mandrake's functionalities, together with uptodate tools. Having a mandrake live system is not so important. It could be done, but it's not our priority for the time being. A better live would need a kernel with kmod and other important kernel features that are not in install kernel. PS: please reply below quoted text, it helps! (i had to put it below myself)
Re: [Cooker] Rescue disk feature request
Jason Bowman [EMAIL PROTECTED] writes: I once had to save as much of a damaged filesystem as I could. It was damaged from a failed drive in a hardware raid configuration that was not rebuilt and it was slowly corrupting the drive... I wanted to save a copy of what was left of a 40gig partition before trying to locally repair the system. I obviously did not have any local diskspace to copy it to. In this case I could have used ssh or nc to stream the data off of the computer. There is already `ftp' in the rescue. PS: Since you were on the team that help create the rescue disk, could you point me to information on how you created it? I am currently looking into Pixel created it at first. There is not much documentation on it ;p. other resources, but I like this ramdisk approach so that you can remove the cd. I would still want to see nc included on the base rescue cd, but this way I could also make and support another rescue cd for larger systems. (As was debated elsewhere in this thread). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Rescue disk feature request: a suggestion
On Sun, 28 Jul 2002 20:40, Guillaume Cottenceau wrote: Jason Bowman [EMAIL PROTECTED] writes: I once had to save as much of a damaged filesystem as I could. It was damaged from a failed drive in a hardware raid configuration that was not rebuilt and it was slowly corrupting the drive... I wanted to save a copy of what was left of a 40gig partition before trying to locally repair the system. I obviously did not have any local diskspace to copy it to. IDE disks that size are around AUD$100 wholesale, probably less in some places: if you need the data that badly, buy a spare IDE drive, set it up with a minimal system, and keep it handy! PS: Since you were on the team that help create the rescue disk, could you point me to information on how you created it? Pixel created it at first. There is not much documentation on it ;p. Yup, that sounds like Pixel: too busy being creative to do mundane things like document it... (-: I like this ramdisk approach so that you can remove the cd. If you have enough RAM to support it, it's not hard to do. Making the rescue disk too big to run on a minimal machine is a very bad idea. It would be an interesting experiment to practise some RAMdisk rescues on a suitably equipped machine, and monitor the page tables to see what actually gets read/written from the RAMdisk. There might be a few surprises in there which enable a significantly smaller rescue disk. The idea of a carefully compressed virtual drive to hold seldom-accessed things like kernel modules also has merit. On a fast machine (ie anything manufactured this year), a totally compressed RAMdisk might be worth the speed penalty. I would still want to see nc included on the base rescue cd, but this way I could also make and support another rescue cd for larger systems. (As was debated elsewhere in this thread). How about proposing a `proper' rescue disk on MandrakeForum? I'm guessing that the CookerDrakes are going to be red-eyed and frantic for most of the next month, and unwilling to put scarce resources to a last-minute proposal, however good it is. The idea would be that your proposed rescue runs from CD in case the machine is minimal, but since CDs are so large you should then (or at boot) have the option of remounting with a RAMdisk chock full of interesting utilities (like mkisofs and cdrecord) dedicated to helping you get stuff off a dying box. Depending on how trashed the existing partitions are, it would also be nifty to be able to scoop out the existing module and network config with a single command, even (maybe using transparent write-cacheing on a CD) have an option for use when the program side of the machine is trashed (drive dies? or maybe r00t3d?) but config and data are intact (ie copy most of /etc and some of /var onto the CD then do init 3) to get the machine limping again in minutes. Much of the work could be done using Mindi-type tricks. The perfect CD to leave in the drive, methinks. Another rooly-kool option would be a compressed CD that boots, makes data partitions and basic config on a hard drive, then starts running and slowly in background copying utilities across to the hard drive until if the machine is rebooted it comes up on the hard drive alone. `Mandrake Stealth Install,' I can see it now. (-: Especially the Windows version, the one that parses _enough_ network/IIS/user configuration out of an existing Windows partition before it starts. The perfect virus payload... or label the CD `Windows Cleaner' and hand it to a friend... (=-0) Are you man enough for the job? (-: Cheers; Leon
Re: [Cooker] Rescue disk feature request
On Sunday 28 July 2002 08:40 am, Guillaume Cottenceau wrote: Jason Bowman [EMAIL PROTECTED] writes: I once had to save as much of a damaged filesystem as I could. It was damaged from a failed drive in a hardware raid configuration that was not rebuilt and it was slowly corrupting the drive... I wanted to save a copy of what was left of a 40gig partition before trying to locally repair the system. I obviously did not have any local diskspace to copy it to. In this case I could have used ssh or nc to stream the data off of the computer. There is already `ftp' in the rescue. Basically I want a dd if=/dev/sda5 | ssh host 'cat savefile'. I can easily do this with ssh or netcat. Someone mentioned using a FIFO but I have never done that... besides feeling that there should be an easier way. I couldn't figure out how to use ftp to stream the data into another program... (Ok, so this could just be my problem : ) - Jason B.
Re: [Cooker] Rescue disk feature request
On Friday 26 July 2002 06:01 am, Guillaume Cottenceau wrote: The rescue is not meant for having a basic working linux system, many other things are meant for it. The rescue is only meant for you to be able to mount your local partitions and rescue your mandrake system, whenever you can't boot anymore your mandrake system. Because of that aim, we limit the number of useless stuff which could make it become larger. We want it to stay small. I once had to save as much of a damaged filesystem as I could. It was damaged from a failed drive in a hardware raid configuration that was not rebuilt and it was slowly corrupting the drive... I wanted to save a copy of what was left of a 40gig partition before trying to locally repair the system. I obviously did not have any local diskspace to copy it to. In this case I could have used ssh or nc to stream the data off of the computer. I could have also used samba, but I agree that for a rescue disk samba is too much. You could argue the same about ssh, but nc is a much lighter weight and general network utility. For these reasons I would argue that nc should be included into the rescue disk. I see the rpm for nc is 106.80 kB, and the executable is only 17.7K. Thank you, Jason B. PS: Since you were on the team that help create the rescue disk, could you point me to information on how you created it? I am currently looking into other resources, but I like this ramdisk approach so that you can remove the cd. I would still want to see nc included on the base rescue cd, but this way I could also make and support another rescue cd for larger systems. (As was debated elsewhere in this thread).
Re: [Cooker] Rescue disk feature request
Todd Lyons wrote: Any One wrote on Fri, Jul 26, 2002 at 07:10:14PM -0400 : Guillaume Cottenceau wrote: I think that I am the only one who subscribe to this list who is not involved in any kind of programming. I am just average Joe user who No you are not. But we are definitely in the minority. What about menu where the user will able to choose the RAM disk size or even better make it a portion of detected system RAM size but the 64 MB minimum? 256 MB RAM and more is not uncomon this days (on my old PII I do have only 192 MB RAM). True, but how much base system has to be loaded before enough is present to detect memory size so that you can then adjust how much more you can load in? Plus, don't forget that every meg you use as disk space on CD1 for the new (or multiple) ramdisks takes away from vital base system packages that can be put on CD1. Linux has built a great reputation on reusability of older hardware. We already catch a lot of flak from requiring 64 Megs (32 Megs in text mode). It boils down to the fact that you can't please everybody all the time. You want more stuff available in rescue mode. You want to be able to run a system from rescue mode. Well you can. Tell it to detect and mount all the partitions, then run 'chroot /mnt' and then start your services the way you want. Building all of that onto a CDRom takes valuable developer resources away from development of other things. I don't want to see us spend time on this when there is so little to be gained. But I'm not a boss, so my opinion counts for so little. And I suppose that's what we must work on, seperating fact from opinion. Most of my rambling has been opinion, so probably should be regarded as such. GC and the rest of the crew would be the authority because there are technical reasons behind all of their decisions. Blue skies... Todd Todd: Blue skies... means sunshine too :) Thanks for the sunshine... in this matter. Irek Stroinski
