swapping master & slave HDs: what to change? (solved - pls comment!)
d I want to scream". If all goes well, you'll boot into a fully functioning system, ready to reinstall the bootloader(s). 8) INSTALL GRUB Get grub on your system if not there already, as a Debian package. As root: apt-get install grub Prepare a /boot/grub/ directory. mkdir /boot/grub Grub is larger that most other bootloaders. It puts code in three different places: 1) in the boot record (or the MBR) 2) in the boot sector ABOVE the boot record (the stage 1.5 goes here) 3) in the filesystem specified in the "system" root, in /boot/grub/. This implies boot will fail if you wipe /boot/ or /boot/grub , even if the kernel is somewhere else. For a multiboot system, it's my preference to install grub into EACH SYSTEM TO BE BOOTED and use the easily reinstalled GAG as boot-selector. 9) INSTALL THE BOOTLOADER Write the simplest possible version of /boot/grub/menu.lst: default=0 #boot the 1st (and only) entry delay=10 #delay in s before booting default title root=(hd0,4) kernel=/vmlinuz2.8.39 root=(hd0,0) ro Save this file, then run grub-install Where can be expressed either in grubian language or in fstabese language. As seen in 8), I prefer to have each system equipped with its own bootloader. So, in this case, I would select the boot partition ( /dev/hda5, aka (hd0,4) ) as the boot device, and use GAG to point there. ORIGINAL MESSAGE From: SpamHog ([EMAIL PROTECTED]) Subject: swapping master & slave HDs: what to change? Newsgroups: linux.debian.user Date: 2004-07-16 03:50:08 PST -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: swapping master & slave HDs: what to change? (solved - pls comment!)
Alvin Oga <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > if of is the new target disk, it will wipe out your partition table of > your new disk ( bs=446 or bs=448 is better ) if you want to preserve > the partitions on the target disk I'd never advocate if = source disk, of = destination disk with bs=512! That was in the BACKUP section, so that one could return to the status quo ante in case of shit | fan. Interesting point: what's in bytes 447 and 448? BR from SpamHog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
swapping master & slave HDs: what to change?
I have multiple Debian installs on 2 IDE HDs on the same channel. I want to turn the SLAVE into MASTER & viceversa. Here's my planned checklist - am I missing anything? For ease of changing things around, I keep a simple, self-installing graphic boot _selector_ (GAG) in the MBR of /dev/hda, and I keep the boot _loaders_ proper (lilo & grub), into each of the boot partitions. For each installed system, I plan to: 1) change fstab file Backup, swap all references to hdax and hdbx. 2) reinstall the bootloader - Backup config/menu files. - Change the config/menu files to reflect situation after the swap. - Reinstall bootloader into the respective boot device. I will then physically swap HDs, and use shorting settings for cable select or swap master and slave. Anything else? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: swapping master & slave HDs: what to change?
Thank you for your reply, John!
You have just opened to me
vast new expanses of ignorance
I didn't know I possessed.
> What do you hope to achieve?
Justice and peace in our time. I also want to themove the current 8GB
master and turn the recently added and thoroughly tested 40GB slave
into master, use it as the "anchor" drive, and keep the bootloader
there. Transient drives will be attracted with an offer of free beer,
snared and put in as slaves for testing, data recovery etc.
Otherwise, I might play with the BIOS boot prority, right? But what
would then happen to partition names? Wouldn't the 40GB switch from
hdb to hda depending on whether a master is there or not? Or is the
jumper-assigned slave status imply hdb no matter what?
> You won't have a working LILO until _after_ your first successful reboot
> whereapon you must run lilo.
Running lilo? Do you mean the bootloader installer OR the bootloader?
It looks like a chicken and egg situation. You probabaly mean that I
have to have the system somehow up and running in the final geometry
BEFORE running lilo will result in the effective installation of the
boot code.
Now I think I remember lilo install runs that failed because my choice
of install target partition and kernel address didn't match the kernel
and disk map files , I guess. But can't I choose / tweak files to
allow for installing wherever I want, and pointing to the kernel I
want? Is it really such a messy proposition?
After all there are some hints in the manpage switch descriptions:
-P {fix|ignore}
Fix (or ignore) `corrupt' partition tables, i.e.,
partition tables with linear and sector/head/cylin-
der addresses that do not correspond.
-m map-file
Use specified map file instead of the default.
> _I_'d replace lilo first,. except I'd not be running it:-)
Uh? What would you _replace_? The lilo package? Why replace it?
> Have a rescue CD handy.
A whole box of them!
>> http://portgeographe.environmentaldisasters.cds.merseine.nu
Nice pics! The end of the world is not that far, after all. Yuckkk!
Thanks again...
Filippo / SpamHog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: swapping master & slave HDs: what to change?
John Summerfield <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... >> Grub is Grand And I thought that "Grand Unified Bootloader" was hubristic! Until recently I used automatically installed lilo or grub rather indifferently, both as bootloaders and bootselectors. This way I could have endless hours of fun looping between 3-4 different boot menus referring to each other, without ever doing a full boot. A couple of months back I converted to GAG as boot selector. Installing it or backing it up to FD requires just seconds. It is strictly a boot selector - you have to have bootloaders on all partitions you intend to boot from. On the top of looping between menus, I now also get nice icons that very visually remind me what the heck I installed on /dev/hdxy (there are even icons with the SCO tree, the hurd jumble, and the OpenBSD blowfish...) + I can change the default boot in a few keystrokes, hide partitions, add passwords by entry, and do a few other nice tricks. As a result of your exhortation I just took the dusty GRUB manual out of the document dump and put it on top of my nighttime reading pile. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
from Announce: 3.0r3 "i386 kernels cannot be exchanged" - why?
What's the connection between "i386 kernels" and "local or vendor-provided modules"? Does it mean that non-i386 architectures run a limited number of stock kernels without bizarre built-in modules? So, the QUESTIONS: - Do ALL i386 kernels contain such modules? Or what else? - What are the implications? - Is one stuck with vulns for now? If so, till when? Preemptive Gratitude from the SpamHog! http://filippo.ru.ru -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: from Announce: 3.0r3 "i386 kernels cannot be exchanged" - why?
Thank you Adrian! > (and you didn't give a link, and I won't go hunting for it), The article I refer to is this: From: Martin Schulze ([EMAIL PROTECTED]) Subject: Preparation of Debian GNU/Linux 3.0r3 Newsgroups: linux.debian.announce.devel Date: 2004-03-26 12:50:12 PST You can also read it at: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=linux.debian.announce.devel&safe=off&selm=1E6rf-jw-5%40gated-at.bofh.it (on one line) It is not yet available in the debian-announce archive. The passage I refer to is the following: quote>>> Due to the number of recent kernel vulnerabilities this update will contain several updated kernel packages. This poses a threat to our users since the correction for do brk() (CAN-2003-0961) changes the binary compatibility of the kernel, hence local or vendor-provided modules won't work anymore. As a result i386 kernels cannot be exchanged, but for most other architectures this is possible. <<< /quote So I still wonder if ALL i386 kernels contain such vendor-provided modules. You say compliling everything from source will take care of the binary API mismatch - did I get it right? BR+Tnx! SpamHog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages in a stable i386 base install?
> Since net-install can give you a minimal base system without a network > then yes, all base debs will be there. You could just look at the list > of debs supplied on the netinst.iso. Thank you Douglas! I did just that, and the following few lines distill the difference between the debs list of grml-medium (a 160meg distro, from grml.org) and the packages found in the netinstall Debian base, minus again anything X- or sound related and anything grml-specific I could find and very few other things I see no use for (e.g. jed): acpi-support acpi-support-base agrep ash atftp atftpd bc bing bridge- utils bsdutils buffer chntpw console-data console-terminus cpp cpp-4.2 curl dante-client dash dctrl-tools ddrescue debconf-utils deborphan dhcp3-client dhcp3-common dhcp3-server dmsetup dns2tcp e3 ethtool file- rc finger firmware-ipw3945 fnord fuse-utils gawk genisoimage gpgv gpm groff-base guessnet hdparm htop hwinfo ifplugd inetutils-inetd info initscripts ipcalc iproute ipsec-tools iptstate iputils-ping ipw3945d ipw-firmware keychain klibc-utils knockd less links live-initramfs localepurge lockfile-progs login lrzsz lsb-base lsb-release lsof md5deep memtest86+ memtester menu mercurial mgetty mime-support mkisofs most mount mpack mtools mtr-tiny multitail ncftp ncurses-base ncurses-bin net-tools nfs-common ntfsprogs ntpdate nvclock nvi openssh- client openssh-server passwd patch perl-base perl-modules policyrcd- script-zg2 portmap postfix powermgmt-base powernowd ppp pppoeconf prism54-firmware procinfo pump python python2.4 python2.4-minimal python2.5 python2.5-minimal python-apt python-central python-minimal python-support radeontool readline-common realpath resolvconf rsync rungetty screen scsiadd ser2net setserial sharutils smartmontools socket squashfs-tools ssl-cert statserial symlinks syslinux syslog-ng sysutils sysvinit-utils tcpd tcpdump telnet timeout tofrodos toshset unp unzip unzoo vbetool vim-tiny vlan vlock w3m whiptail wipe wpasupplicant zip zsh -- Can anyone spot something obviously USELESS in or MISSING from a service-testing-rescue mini-install? -- Next, I'll do a base install, run the above through apt-get and report here on what else, if anything, is already included and what won't install. I hope to reach the point where a single shot (of apt-get, debfoster, or a metapackage) does it all.
Re: List of packages in a stable i386 base install?
Thank you again Douglas! I'll look at all the packages you find objectionable. Some are rarely used, of course, but my goal is to put together a rather complete but fully standard Debian stable CLI-only rescue install, mostly because I didn't find one, and I generally find such a separate on-spindle install to be convenient, and I put it into all my boxes. Now I have a fresh base install ready in a 1-GB "rescue" partition. Once the list is ready I'll make sure all the packages are indeed installable, then I'll try to make a metapackage pulling them all in. Stay tuned... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages in a stable i386 base install?
On Feb 5, 3:30 pm, "Douglas A. Tutty" <[EMAIL PROTECTED]> wrote: > What's wrong with just GRML? What's wrong with MS-DOS? What's wrong with AOL? :-) For starters, grml medium wasn't even out of beta last time I checked, and came with a nice big proviso. The usual other criticisms apply. Or don't. Maybe. Only Debian Stable Is Absolutely Beyond Reproach. (c) (tm) ;-)
Re: List of packages in a stable i386 base install?
On Feb 5, 3:30 pm, "Douglas A. Tutty" <[EMAIL PROTECTED]> wrote: > What's wrong with just GRML? What's wrong with MS-DOS? What's wrong with AOL? :-) For starters, grml medium wasn't even out of beta last time I checked, and came with a nice big proviso. The usual other criticisms apply. Or don't. Maybe. Only Debian Stable Is Absolutely Beyond Reproach. (c) (tm) ;-)
package list for CLI-only admin/service install
On my boxes I install a small Debian stable on its own partition for service and rescue purposes, an alternative to the many live-CD distros. I've been looking for a Custom Debian Distributions or package list or metapackage which would pull in plenty of CLI-only admin - rescue - network - security tools, a few key servers (file, ssh,, and little more), basic clients for communicating (http, irc, etc etc) many drivers, but no X. I have also tried to lift the package list from existing live-cd distros, but it did not work out - and would have contained distro- specific packages anyway, which is something I'd rather avoid. Does anybody keep such a "pure Debian CLI tools" metapackage or package list or CDD with such a selction of apps? TIA for all the wisdom I will receive! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package list for CLI-only admin/service install
On Jan 17, 12:50 pm, Martin Marcher <[EMAIL PROTECTED]> wrote: > > i'm also open to suggestions Hmmm, I'll readup on metapackages. Never maintained anything, but how hard would it be to prepare ONE dummy .deb that pulls all the CLI admin/rescue tools I want?. After a standard net-install one would just do a wget and a dpkg. As an alternative, debfoster + a long install list. I could start from the app list of a live cd. Doesn't look too hard. Once I give it a try I'll post on whether I overrated the task.
Re: package list for CLI-only admin/service install
Interesting stuff all this! Joseph: your metapackage is a great starting point. I'll see if I understand it enough to hack it up for needs. Thanks to all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
List of packages in a stable i386 base install?
I am selecting a set of add-on packages for a small "service & rescue" install. I would like to know what is already included in the base install, and in general I'd like to see the latest version of this list of thigs. My guess is that it might not be included in the minimal net-install boot images but that it should be in a base install .iso, designed to be run all from CD. I looked into the latter (CD1, e.g. debian-40r2-i386-CD-1.iso, right?) and searched online but could not find it. I hope I'm not the only one who ever wondered . . . -- Where is the current list of packages included in a stable base i386 install, both in the .iso and online? (i.e. BEFORE installing it, that is!!!) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cloning a system to another partition - what to change?
I am cloning a 1-partition system (3.1/i386) from /dev/hda5 to /dev/hda6, and intend to install grub in that partition. No need to change drivers, etc. - *only* the root device. I already did the following: - copied all files in the / tree to a filesystem on /dev/hda6 - amended /etc/fstab to mount /dev/hda6 on / - amended /boot/grub/menu.lst to have (hd0,5) as root root=(hd0,5) kernel=/boot/vmlinuz-2.6.8-2-686 root=(hd0,5) - PROBLEM (I think): I also tried to make an initrd image (in the original system) to reflect the change in root device, thus producing a file to be later copied in place of the initrd image on the destination system: mkinirtd -r /dev/hda6 -o /root/initrd.img-hda6 The process repeatably ends without output, and without any error message. I am strictly following the manpage, and even tried to make another initrd.img with the same root: mkinirtd -o new-test-initrd-file but still with no output. If I install grub on the NEW system manually with a grub floppy, and specify the new-system kernel and root, but leave old initrd imgage, boot succeeds (probably using the NEW kernel etc.) but the running system eventually pivots onto the OLD partition. * Why is mkinitrd seemingly not acting as described on the man page? * How can I get the cloned system to boot using ONLY the new system? Filippo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cloning a system to another partition - what to change?
Thank you Hugo, but I am not really going to use Mondo instead of understanding what the issue is. :-) Are you sure it rebuilds initrd.img to fit a new root partition?? (I use and like Mondo though, and might try it in a Serious Cloning Emergency - ...) Thank you too Mike, but I have already tried several times with either GNU/Linuxspeak "/dev/hda6" or Grubspeak "(hd0,5)" so it must be someting else. Moreover, 1) Being the "boot" root and the "running" root one and the same, the second root specification should be redundant anyway. 2) Funnier yet: /dev/hda5 is not mentioned at all in my grub commands. Why is grub grabbing it instead of e.g., /dev/hda1 or the floppy? Occam's razor: the initrd image was made with hda5 as root, man mkinitrd says one should spec the root if not the same as the current system root (if mkinitrd works, that is), so if not from me, the idea of latching onto hda5 is likely to come from it. :0 So, up the stream bar paddle esp. w.r.t. why mkinitrd now refuses to produce any initrd image. This is a strictly fresh and standard 3.1 install with no subsequent changes - I didn't touch any conffile! Ideas? Grateful but uncloned, I remain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cloning a system to another partition - what to change?
Thank you for clarifying! I'll never again root =(hdx,x) after a kernel. Yet, there must be something else munching up this boot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cloning a system to another partition - what to change?
Thank you for clarifying! I'll never again root =(hdx,x) after a kernel. Yet, there must be something else munching up this boot. Whence the hda5 reference comes is not explained even by a missing SECOND specification of hda6 as running root. Nothing anywhere specifies hda5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cloning a system to another partition - what to change?
Mike, I promise you, I never meant to touch the MBR! Once you bide grub (either interactively or from any boot sector of any partition) root (hdx,y) you overrule the spell in the MBR. You can install several distros and have each recognize all the preexisting ones during the instal, and add them to the boot menu, either by directly calling the respective kernels, or by calling whatever bootloader is esconced into the corresponding partitions (e.g. xBSD or Windows, or other instances of grub, or lilo). Likewise, you can have a pure boot selector like GAG kick-starting any of a number of instances of grub on as many partitions. In turn, any of those will have its own onboard menu allowing to select some other OS beside the default. I normally do that. You can spend your day on a merry-go-round between grub menus calling up each other, and eventually boot a system of choice when dusk comes. That's not the problem. I cleaned up everything and did a few extra installs for testing: 1) Current situation, with fresh install and fresh system copy: - original system on hda8 (all, cept swap); grub is on same partition - (MBR has a different grub on it, never called upon, pointing to hda1 (Scientific Linux), but this is irrelevant here) - system copy on hda10, no grub yet installed in BR of this partition 2) Adjustments made WITHIN the cloned system on hda10: - necessary for mounting the root partition: changed the / line in /etc/fstab to point at /dev/hda10 - (preparing for planned grub-install, not expected to affect 1st boot: changed the root lines in /boot/grub/menu.lst to point to (hd0,9), and the kernel lines to root=/dev/hda10) 3) booted with GAG, pointed to /dev/hda8 (no mention of kernel, GAG can't do that), the local grub kicks in, & original system boots flawlessly 3) Booted original system with *generic* grub diskette, without any partition info: gave commands at grub prompt root (hd0,7) kernel=/boot/vmlinuz-2.6.8-2-686 root=/dev/hda8 initrd=/boot/initrd.img-2.6.8-2-686 boot and the original system boots flawlessly this way as well. (I can likewise boot the other distro on hda1 with the proper commands). 4) Booted _cloned_ system with generic grub diskette: root (hd0,9) kernel=/boot/vmlinuz-2.6.8-2-686 root=/dev/hda10 initrd=/boot/initrd.img-2.6.8-2-686 boot Boot starts, but I get these error messages: VFS: Cannot open root device "hda 10" or unknown-block(0,0) Please append a correct "root=" boot option. Kernel panic: VFS: Unable to mount root fs or unknown-block(0,0) Notice that mkinitrd has an option specifically designed to create an initrd.img "rooted" on a different partition. I assume the original system's image is rooted on the original system's partition... Working on the original system I tried to create an initrd.img specifying the root of the cloned one: mkinitrd -r /dev/hda10 -o ./newimage.img but mkinitrd apparently never produces _any_ output on a standard Debian system. I can easily work around this dreary s%^$ by reinstalling multiple times (or use Mondo h, I am unconvinced...) but I hate to leave the issue unsolved. Does initrd.img be SPECIFIC to the root partition, yes, no, or under what circumstances? If not, why ain't the above working? If indeed, why ain't mkinitrd working? G >:-( Yearning for elightment, I remain. 'Hog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cloning a system to another partition - what to change?
?!?! Solved it isn't, but this workaround is FAST : 1 - boot the original system (say, on hda8), get root 2 - get into the cloned system (say, on hda10) mkdir /mnt/hda10 mount /dev/hda10 /mnt/hda10 3 - fix /dev/hda10 /mnt/etc/fstab and /dev/hda10 /mnt/grub/menu.lst as described in previous message, to make hda10 the center of everything 4 - chroot into the cloned system and start the grub console: chroot /mnt/hda3 /bin/bash grub 5 - now, at the grub prompt: root (hd0,9) setup (hd0,9) quit This installs grub in the BR of /dev/hda10, with the parameters from /boot/grub/menu.lst, as from previous message. At this point, either with grub or with GAG, I can kickstart the /dev/hda10 partition, the local instance of grub correctly boots the kernel and the *UNMODIFIED* initrd.img. Now, all parameters being absolutely the same (mutatis mutandis) - for original and clone - for interactive with boot floppy and installed grub I really don't understand why they both boot via GAG and chainloading grub, but only the original system boots via a direct, interactive root and kernel call. Any idea? Assuaged but befuddled, I get on with life. 'Hog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Does Debian-Installer change over time?
On a couple of i-386 test machines I am noticing install problems that appear to change over time. I use floppies, and therefore download the install package from a repository every time. I know that if video card recognition works, then fail, then works again, this has noting to do with D-I proper. But what if (as since yesterday), the hardware recognition fails immediately on two separate comps, no matter if I choose stable or testing from the expert install script? A Slackware based distro just recognised everything without any visible problems. Is it something preternatural or does D-I actually change over time, e.g. due to upstream drivers or components seeping in? I have a sample set of install logs (290kB). If you wish, tell me what to post. TIA, Filippo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
