From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D252B1382CD for ; Sat, 25 Jun 2016 19:46:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 275BB941CF; Sat, 25 Jun 2016 19:46:24 +0000 (UTC) Received: from mail-vk0-f65.google.com (mail-vk0-f65.google.com [209.85.213.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E9310E0B3F for ; Sat, 25 Jun 2016 19:46:22 +0000 (UTC) Received: by mail-vk0-f65.google.com with SMTP id e187so1427059vkb.2 for ; Sat, 25 Jun 2016 12:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=/kLzeD98MGPD+BmkDYndZE3G3LcFPZ7d/q/1+N0fvTU=; b=GyIylTtaDh0afKtwFS9VK1O2wX5noKHOjZMjwIG1yIfBB2+Opc4RyKe2Gw2ri5yUds gFHUl74GLwn36OtkwkONkCp4EDBaWmXlT96fXuzP5T0YZ/qEaKogbK0C1IRP2OU1gc0h 4IjzKHN8oPlPQPvmB2iDhVtwno/BSqXvnJsY/d0FfFrqJDqShgk6EegMfiC7wMICzJGM L49y6GGki0OvEHgkaVF1ITKvsqQBP/JnnbgArHx42qRSlWC707F+1VuUUTDEMtbXzuJP hnIhGtQj7ETldOpwvMb9UKeTSJFfl1MwxqEoD/6Sq18Vj6RxUazfdjbaep7Xpox8bAHA L2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=/kLzeD98MGPD+BmkDYndZE3G3LcFPZ7d/q/1+N0fvTU=; b=F5Jmqa8lqtXKt3Na9rELOjIlo61aImDF3uqSTt1OF9TDWdpjG8tLp/isFuzy87OKfp u03+0B+QuZwtF81w6d1ecLm1NEWoey8S+wrTT4VmDvryy6hkEvLsIUaLTmlj0Dh/i16W yjLzYyVzseuiiGv50V4YAm3tVrWjgvroz3YGSl0mNbkMYUtZ9ANeNiTeO1FTsDcrMyyO cDeraJdA0wNlhgJYSRXY2587hJb6g5XItvRZges3vbCrlyfv/+wqdcoYx6yy9/JcKu0m YtE6PAA502S3Aj6b0Wu2pWAIkaj3SuT3wD1nyrR7EB/p7fjmXGyzZCj8Hqj3lkwgqUKd 84TQ== X-Gm-Message-State: ALyK8tLRvbcX/sdpvxhigZzAzM27ILjCGAIWyvKk9pRmyQsB8fD7DKgP6Xr3TQYniHSQCj+V1L1KuC/3q+OEjw== X-Received: by 10.176.1.108 with SMTP id 99mr5400749uak.49.1466883981928; Sat, 25 Jun 2016 12:46:21 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Sender: freemanrich@gmail.com Received: by 10.103.70.155 with HTTP; Sat, 25 Jun 2016 12:46:21 -0700 (PDT) In-Reply-To: References: From: Rich Freeman Date: Sat, 25 Jun 2016 15:46:21 -0400 X-Google-Sender-Auth: PLxvLgQQoq-Z0MWtcpAsN_LXpTs Message-ID: Subject: Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: ed6e0adf-4d6c-4f6f-b3a9-18911af590e0 X-Archives-Hash: bae78d05db40cd74eb3506897cf431be On Sat, Jun 25, 2016 at 2:33 PM, Helmut Jarausch wrote: > > I don't understand the 'root=' option on the boot line like > kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1 > It is pretty simple. If you're not using an initramfs, the kernel attempts to find the device you list and mount it as /, and then it runs whatever you pass in init=, or the canned list of init locations it has stored inside if you don't pass that. If you're using an initramfs, the kernel mounts it as / and runs its init, passing the root= parameter over to it. > > Having booted by SystemRescueCD from the cdrom device, my root device is > labelled /dev/sda1 > BUT trying to use that on the kernel boot line fails (the kernel cannot > find the root file system) > > By trial and error I've found that I have to use root=/dev/sdb1 > > but if I plug in an external drive (via USB) this doesn't work any more. As you've no doubt figured out, the issue is that these device names are assigned dynamically, and if your configuration changes (which I suppose might even include changing the boot device depending on your firmware), then these names can change. The kernel's logic is pretty basic and prone to these kinds of failures. > > So, I came up with root=UUID=uuid_number of the root file system. > > But to my surprise I now got a kernel panic > syncing: VFS: unable to mount root fs on unknown block(0,0) > > So, please tell me what I'm missing? The linux kernel doesn't have any concept of device UUIDs. It can only accept valid device names. The bit you're missing is that the kernel only interprets the root= parameter if you're not using an initramfs. If you're using an initramfs then the kernel just lets the initramfs mount root. The initramfs is basically a mini linux distro that can do just about anything it wants, and most have a way to handle devices identified by UUID. I'd suggest using dracut, which seems to be the most robust initramfs out there. To use it (or any other initramfs) there are basically a few steps: 1. Create an initramfs image in /boot (the syntax varies by tool). 2. Configure your bootloader to load the initramfs (the syntax varies by bootloader) 3. Pass an appropriate root= line to the kernel (the syntax varies by initramfs implementation, but most handle the syntax you gave, as well as the various udev paths that are based on UUIDs and labels and such). For dracut #1 is: dracut "" version (ie dracut "" 4.7.0-rc4) For grub1 #2 find the kernel line in your grub config file, and add a line: initrd (ie initrd initramfs-4.7.0-rc4.img) Use the same path in that as your kernel, so if your kernel has some kind of preceding directory path use the same for the initramfs. While you can often get away without using an initramfs, in general they tend to make the boot process more robust and they don't really have any impact on the system once it is running. They're loaded into a ramfs, and they typically delete themselves out of ram right before execing the real init. They just give you a LOT more options while booting (especially with dracut ; you'd probably be able to mount root off of iscsi over a vpn using it). -- Rich