I have two disks.
Debian Lenny/SRAID1
Do i have to make a separate /boot on each disk[how?], and then create SRAID1 on a remaining partition? or put the /boot on the RAID1?
Hi. I need to mount a usb disk during boot so that daemons writing to the disk start. The problem is that usb-storage takes time to set up block devices and it does this in the background so it depends on many factors if it makes it before mountall.sh is called. Is there some way this can be accomplished in debian without explicit sleep 20 in mountall.sh?
Also, is there some way to start daemons only after certain hardware becomes available?
thanks mk
On Wed, 23 Jun 2010 18:05:49 -0400 (EDT), Camaleón wrote:
OK, I found the problem. It’s a user error, but not an obvious one. Here’s the deal. At boot loader install time, lilo translates the root device specification into a number. In the general case, the number is a four-digit hexadecimal number, where the first two digits represent the major number and the second two digits represent the minor number. (However, a leading zero is usually suppressed.) When running under the 2.6.32-5 kernel, the root device, as viewed by the kernel, is major number 8, minor number 2. So lilo translated the root specification internally to “802″. At boot time, it is this number that is passed to the kernel as a boot parameter. For example,
root=802
However, the IDE driver and the SCSI driver use different major numbers. The SCSI driver uses major number 8. The IDE driver uses major number 3. The minor numbers were the same in this case. When booting the 2.6.32-3 kernel, lilo still passed
… root=802 …
as a kernel boot parameter. But under the 2.6.32-3 kernel, there is no such device. Thus, the kernel could not find the permanent root device; and the boot process hung. The solution was to use a direct specification of the UUID in /etc/lilo.conf instead of an indirect one via a udev symbolic link. For example, instead of specifying
root=/dev/disk/by-uuid/xxxxxxx…
I specified
root=”UUID=xxxxxxx…”
in /etc/lilo.conf. I then re-ran lilo. When this method of specifying the root device is used, lilo does not pass a major and minor number as a kernel boot parameter at boot time, but an actual UUID string, which both kernels are able to match. The 2.6.32-3 kernel matches it with major number 3, minor number 2 (/dev/hda2) and the 2.6.32-5 kernel matches it with major number 8, minor number 2 (/dev/sda2). Problem solved.
Note that it is OK to use a udev-created symbolic link for the “boot” specification, since that is used only at boot loader install time to determine where to write the boot block. It is not passed to the kernel at boot time.
I made some discoveries along the way which other users may find interesting. First, the program used by the Debian installer to format a swap partition does not assign a UUID. So you can’t specify your swap partition in /etc/fstab by means of a UUID until you reformat your swap partition using the regular mkswap command.
Second, in the process of diagnosing the problem I switched from MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy, which produces a relatively small initial RAM file system image (< 2M) to MODULES=most, which produces a huge "kitchen sink" initial RAM file system (~ 8M). I thought perhaps some missing modules in the initial RAM file system might be the problem. It wasn't. But in the process, I proved that lilo had no trouble loading this huge kernel + initrd combination, as long as the large-memory option was present in /etc/lilo.conf. This proves that the allegations made by some that lilo can't handle modern linux kernels because they are too big is a myth. The real problem is that lilo's boot loader installer was not getting run during a kernel install or upgrade, due to changes made to the kernel maintainer scripts. I have since switched back to MODULES=dep and I have re-run "update-initramfs -uk all" to rebuild the initial RAM file systems. At this size, even if large-memory is *not* present in /etc/lilo.conf, lilo should have no trouble loading it. I've tried that too.
OK, I’m sure it must be something simple, but I can’t figure out what.
I am running the “testing” release (Squeeze). I have two stock Debian kernels installed on my system: linux-image-2.6.32-3-686 and linux-image-2.6.32-5-686. My computer has a single hard disk, a traditional ATA IDE drive, also known as “PATA”. One important difference between these two kernels is that the -3 kernel uses the old IDE drivers, which results in my hard disk device name being /dev/hda. The -5 kernel uses the newer libata driver, which results in my hard disk device name being /dev/sda. In other words, the newer kernel uses a SCSI device naming convention instead of the traditional IDE device naming convention.
When I first installed the 2.6.32-5 kernel, it was from unstable, but this kernel has since migrated to testing. I didn’t like all the UUID changes that the dependencies of this kernel package wanted to make and instead changed all my system files (/etc/fstab, /etc/initramfs-tools/conf.d/resume, and /etc/lilo.conf) to use the new SCSI device naming conventions. After some initial issues with the nouveau driver, I have been running the -5 kernel successfully for some time.
Recently, however, for the purpose of testing some software, I decided I wanted to boot my old kernel (the -3 kernel). I knew that I would have to make some changes to the system files first, however. I decided to make use of udev aliases in these system files. For example, in /etc/fstab, instead of something like
/dev/sda1
I used something like
/dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04
After making changes of this nature to /etc/lilo.conf, /etc/fstab, and /etc/initramfs-tools/conf.d/resume, I rebuilt the initial RAM file systems for both kernels with “update-initramfs -uk all” while running the -5 kernel. Everything appeared to work fine. I then shutdown and rebooted my current kernel (the -5 kernel). It booted just fine. I then tried to boot my old kernel (the -3 kernel). It failed. The kernel and initial RAM file system were loaded just fine by the boot loader, but the -3 kernel couldn’t make the switch between the initial RAM file system and the permanent root file system. I got a few “device not found” error messages and it left me in an ash shell with “(initramfs)” as the boot prompt.
What did I do wrong? Is there a system file that I missed? Is this a missed dependency in the dependency-based boot system? I can still boot the -5 kernel just fine, but I can’t get the -3 kernel to boot. I tried searching the internet with the search words
Debian 2.6.32-3 2.6.32-5 “(initramfs)” “won’t boot”
but none of the hits looked promising to me.
Any ideas? My hunch is that the udev aliases might not yet exist at the time they are being referenced. But that’s just a wild guess at this point. The thing is though, it works fine for the -5 kernel.
Hello list,
I have had a laptop wearing Linux solely over the last few years and today I decided I’d install a Windows partition on it, with aim to dual boot. After preparing an NTFS partition by using the gparted live CD, I installed Windows 7 on the newly created partition. Thus, so far I have the primary partitions /dev/sda1, an ext3 partition holding my Squeeze installation, and /dev/sda2, holding my Windows installation. There’s also the /dev/sda3 “extended” partition and the /dev/sda5 “swap” partition. Here’s a gparted screenshot taken from within my debian installation to prove my claims: http://img199.imageshack.us/img199/1819/mypartitions.jpg
When the installation was finished, I would only boot into Windows 7. Somewhat accustomed to this loss of the Grub boot loader, I booted from my Squeeze installation CD, entered Rescue Mode and reinstalled GRUB in the MBR of my only hard drive (that corresponds to the /dev/sda1 partition). However, even though I reclaimed Grub, Grub would not detect my Windows partition on bootup, and give me the options of boot into debian. I tried reinstalling GRUB on other partitions, but Windows was (and still is) unbootable on startup.
I had a look at my grub.cfg and didn’t see a “menuentry” corresponding to the windows partition, even after running update-grub. What are the steps that I need to follow in order to dual boot my system? The only OS I have currently access to through Grub is Debian (with the option of two kernels, but that’s not really relevant).
Thanks.
i’ve squeeze and lenny installed and squeeze as a production system now. Recently installed grub2 (1.98) on squeeze on the MBR of hd0. Evereting goes well but i can’t boot lenny. The lenny file system partitions are for /boot ext3 and all others ext4. When i try to boot lenny i have this error message: exit_fill_super:extents feature note enabled this filesystem, use tunefs So can’t mount /dev on /root/dev, etc…..
grub.cfg: …/… menuentry “Lenny, kernel 2.6.28_mm01 (on /dev/sdc6)” { insmod ext2 set root=’(hd2,4)’ search –no-floppy –fs-uuid –set f26b56c1-4550-4815-b7bf-e5f114c6f9e4 linux /vmlinuz-2.6.28 root=/dev/sdc6 rootfstype=ext4 ro quiet vga=788 initrd /initrd.img-2.6.28 …./…
this kernel is a self-compiled with of course ext4 enabled on it and had never problems to boot before i installed grub2.
Seems ext4 not supported by grub2 ?
any help would be very appreciated. mess-mate
On 06/16/2010 10:03 PM, ABSDoug wrote:
(That’s the way for a newbie to engender cooperation.)
(Symbolic links are just about the single coolest feature of Unix-style file systems, and are just about everywhere in /etc, /usr, /var, …)
http://en.wikipedia.org/wiki/Symbolic_link
The name just about says it all: a *symbolic* link from one file to another. For example:
$ df /mnt/windows Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 36138212 19393344 16744868 54% /mnt/windows
$ ls -1 /mnt/windows/”Documents and Settings” All Users anabelle Compaq_Owner Default User Heather ian LocalService NetworkService Ron Ron Sr
$ ln -sf /mnt/windows/”Documents and Settings”/Ron/”My Documents” Windows_Docs
$ ls -aFl Windows_Docs lrwxrwxrwx 1 ron ron 52 Jun 16 22:47 Windows_Docs -> /mnt/windows/Documents and Settings/Ron/My Documents/
$ ls -aFl Windows_Docs/ total 13 drwxrwxrwx 1 root root 4096 Nov 29 2007 ./ drwxrwxrwx 1 root root 4096 May 17 2006 ../ -rwxrwxrwx 1 root root 74 Nov 29 2007 desktop.ini* drwxrwxrwx 1 root root 0 Nov 29 2007 My Music/ drwxrwxrwx 1 root root 4096 Nov 29 2007 My Pictures/ drwxrwxrwx 1 root root 0 Dec 13 2005 My Videos/
If this isn’t on topic, sorry ahead of time & perhaps you can point me in the right place?
I’ve been reading up on having a separate partition for your /home files. For quite some time, I’ve been using a ntfs partition named “storage” as it makes re-install or fresh install of OS much easier. While it’s WAAAAAY neat that two different distros of Linux can share the /home partition, I still need MS at times. I figure I can’t be the only one, but after looking on the net, I couldn’t decide the best way. I could use Linux to pull files off of the MS XP ntfs partition easy enough, but it seems cheesy. All the options to allow XP to see the Linux partition have permission issues as well as hidden extensions that can’t be hidden. Dangerous trumps cheesy. It would seem grabbing what I need in XP partition from within Linux is the answer… is there something I’ve overlooked? I’m gunna get into virtualization at some point, but I’m just not ready to nuke XP, there are times it’s the only thing I can get to work (like my Netbook internal 3G)
Thank Greg Madden, Neal Hogan, H.S. and Liam O’Toole!
IMO editting /etc/network/interfaces is neater than editting /etc/rc.local
I have etch and a ppp connection I want to make ppp connection every time Debian boot That is, run “pon” during boot What is the proper way to do that? Thanks!
