Re: should an end user stick to a kernel with an initrd?
On Wed, Oct 9, 2013 at 1:51 PM, Regid Ichira regi...@nt1.in wrote: It seems newer hardware is much more problematic in this sense. I think MS ovecomes this difficulty by somehow attaching a signature for each device. I don't have the details, don't know the pros and cons. On a UEFI box, partitions are assigned UUIDs similar to filesystem UUIDs. On my laptop, they are, as exposed by udev: # ll /dev/disk/by-partuuid/ total 0 lrwxrwxrwx 1 root root 10 2013-10-10 04:28 287521a3-432b-4992-ab68-327d92791ade - ../../sda2 lrwxrwxrwx 1 root root 10 2013-10-10 04:28 796cde65-0b7d-4ba4-8589-ee8e09ad47e2 - ../../sdb2 lrwxrwxrwx 1 root root 10 2013-10-10 04:28 9500362d-9b00-4168-9b47-04c2b0204965 - ../../sdb1 lrwxrwxrwx 1 root root 10 2013-10-10 04:28 f00e68a4-4645-44d6-b249-396e09b9844f - ../../sda1 Are you sure that Microsoft's using these partition UUIDs? Or are you referring to the fact that an EFI system partition (in Windows and in Linux) is identified by a UUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) at boot? This last UUID is a partition type and is recognized as ef00 by gdisk. (The 8300 of a regular Linux partition also has an equivalent UUID.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sxnxhwywlfs0bkso1ovw_fp826nopadqvklzw4nrev...@mail.gmail.com
Re: should an end user stick to a kernel with an initrd?
On Tue, Oct 08, 2013 at 11:08:50PM +0100, Roger Leigh wrote: On Fri, Sep 27, 2013 at 10:28:01PM +0300, Regid Ichira wrote: On Fri, Fri, 27 Sep 2013 13:34:56 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! 1. Saying traditional disks names not siigned in a predictable manner seem to contradict the fact that one can write root=/dev/hdd3 You can certainly write that into the fstab, but that won't guarantee that the device will be hdd3; it might be hdc3, hde3 etc. depending upon the presence of other devices and the initialisation order. For me, the enumeration of devices is guaranteeted. As already discussed in this thread, with older boards, the enumeration of IDE and SCSI devices is completely determined by their jumpers and wiring. I think that does not change with boards that won't boot usb devices. I can't tell about newer boards. in the kernel command line, such as in lilo. 2. I have 2 disks. It never happened to me. Try plugging in a USB storage device during early boot. On some systems this might end up initialised before the physical HDDs and then all the hard disks will be renamed and the fstab entries will be broken. On most systems the SATA drives will be initialised first, but this isn't guaranteed--a lot of this is asynchronous now; what if the HDD takes longer to spin up than normal, so gets registered later? You want guaranteed reliability, and UUIDs/LABELs give you that; the kernel device names might /seem/ stable on a given system, but that's really only a result of circumstance, not by design. It seems newer hardware is much more problematic in this sense. I think MS ovecomes this difficulty by somehow attaching a signature for each device. I don't have the details, don't know the pros and cons. 4. I think that the LABEL mechanism of /etc/fstab is different, predated, and more rigid, from that of a UUID. Again, it seem to me supported by some of the comments in https://lwn.net/Articles/331818/. Both are handled by udev today, to give you /dev/disk/by-label and /dev/disk/by-uuid. I don't think that labels are handled specially by the kernel in addition to that, since it can be potentially quite complex and filesystem-specific, but I could be wrong. Maybe they were in the past, or handled specially prior to udev? I don't know either. In general, I understand that the initrd issue is much more complex today then it was a few years ago. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131009175158.ga23...@nt1.in
Re: should an end user stick to a kernel with an initrd?
Am 09.10.2013 19:51, schrieb Regid Ichira: For me, the enumeration of devices is guaranteeted. As already For you it is (maybe), under a lot of circumstances it isn't. Is that so hard to understand. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: should an end user stick to a kernel with an initrd?
On Fri, Sep 27, 2013 at 10:28:01PM +0300, Regid Ichira wrote: On Fri, Fri, 27 Sep 2013 13:34:56 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! 1. Saying traditional disks names not siigned in a predictable manner seem to contradict the fact that one can write root=/dev/hdd3 You can certainly write that into the fstab, but that won't guarantee that the device will be hdd3; it might be hdc3, hde3 etc. depending upon the presence of other devices and the initialisation order. in the kernel command line, such as in lilo. 2. I have 2 disks. It never happened to me. Try plugging in a USB storage device during early boot. On some systems this might end up initialised before the physical HDDs and then all the hard disks will be renamed and the fstab entries will be broken. On most systems the SATA drives will be initialised first, but this isn't guaranteed--a lot of this is asynchronous now; what if the HDD takes longer to spin up than normal, so gets registered later? You want guaranteed reliability, and UUIDs/LABELs give you that; the kernel device names might /seem/ stable on a given system, but that's really only a result of circumstance, not by design. 4. I think that the LABEL mechanism of /etc/fstab is different, predated, and more rigid, from that of a UUID. Again, it seem to me supported by some of the comments in https://lwn.net/Articles/331818/. Both are handled by udev today, to give you /dev/disk/by-label and /dev/disk/by-uuid. I don't think that labels are handled specially by the kernel in addition to that, since it can be potentially quite complex and filesystem-specific, but I could be wrong. Maybe they were in the past, or handled specially prior to udev? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131008220850.gs4...@codelibre.net
Re: device naming (was: should an end user stick to a kernel with an initrd?)
On Mon, Sep 30, 2013 at 5:18 PM, Linux-Fan ma_sys...@web.de wrote: On 09/28/2013 04:54 AM, Ralf Mardorf wrote: I only want to mention that this never happened on my machine within the last = 10 years and I turn my PC often on and off. How often does it switch on your machine? Does anybody experience that sda became sdb after rebooting? I don't claim that this can't happen. I have a similar situation here: The device names never change -- sda is always the same disk etc. This may be true in some setups/motherboards. Others will have different experiences, e.g. when a motherboard has two or more disk controllers (e.g. one for SATA RAID and one for regular SATA), or you have a controller in a PCIe slot and use disks on either the controller or the motherboard, or you have several controllers in PCIe slots. -- Jan
Re: device naming (was: should an end user stick to a kernel with an initrd?)
On 09/28/2013 04:54 AM, Ralf Mardorf wrote: On Fri, 2013-09-27 at 14:41 -0400, Tom H wrote: [...] I couldn't care less how many disks you have. Defaulting to the use of UUIDs isn't some wacky whim but a well-reasoned technical decision, unless you want to claim to know more than the developers putting together distributions. This isn't a question of /dev/sdX works for me, yay! The issue is that device names aren't NECESSARILY stable (some would say that they've never been so) so, distributions are using UUIDs in order to avoid having any Linux user anywhere be unable to boot because sda is now sdc, sdb is now sda, and sdc is now sdb... I only want to mention that this never happened on my machine within the last = 10 years and I turn my PC often on and off. How often does it switch on your machine? Does anybody experience that sda became sdb after rebooting? I don't claim that this can't happen. I have a similar situation here: The device names never change -- sda is always the same disk etc. Still, I already experienced what happens when not using UUIDs, because I once installed my system on an external HDD when the main disk had failed. Booting from the external HDD always resulted in random device numbering (except for sr0 always being sr0...). Sometimes my boot HDD was sda, sometimes sdb, sometimes sdc. In the beginning it even failed because it said /dev/sda in my fstab but that was quickly corrected to a UUID. Linux-Fan. -- http://masysma.ohost.de/ signature.asc Description: OpenPGP digital signature
Re: should an end user stick to a kernel with an initrd?
With scsi, the disk address is determined by its physical connection to the scsi cable. This is absolutely not correct. SCSI device IDs have always been programmed at the endpoint device via DIP switches, jumpers, or a dial. There was one short lived exception to this. In the late 1990s the industry created the SCAM extension, or SCSI Configured Automatically. This was an effort to make it easier for non technically savvy end users to install external devices such as scanners, optical drives, tape drives, without need to manually set device IDs. Cable proximity of devices was not involved in SCAM enumeration and assignment. It was a negotiated protocol. However, it was removed from the SCSI specification not long after introduction because it caused many more problems than it solved, specifically, it would change the boot hard drive ID and prevent systems from booting. It also wreaked havoc on software RAID systems when it auto reassigned IDs of the member drives, which obviously destroyed the array. I never fell victim to this because I didn't buy into the Adaptec hype. They started enabling SCAM by default in their controllers. I simply disabled it, and assigned IDs as I always had. A number of my colleagues did buy into the easy install hype and were bitten by it. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5249d3a8.2030...@hardwarefreak.com
Re: should an end user stick to a kernel with an initrd?
On Sat, Sep 28, 2013 at 7:49 AM, Regid Ichira regi...@nt1.in wrote: On Fri, 27 Sep 2013 19:06:43 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:28 PM, Regid Ichira regi...@nt1.in wrote: On Fri, Fri, 27 Sep 2013 13:34:56 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! 1. Saying traditional disks names not siigned in a predictable manner seem to contradict the fact that one can write root=/dev/hdd3 in the kernel command line, such as in lilo. 2. I have 2 disks. It never happened to me. 3. In the old days, the way you physically attached the disks, be it IDE or SCSI, completely determined their enumeration in the hd and sd name space. I think that has not changed by newer kernels. I guess Sievers was reffering to that fact when he also points out that the device naming policy is already in the kernel Quote taken from https://lwn.net/Articles/331818/. Some of the comments in that URL seem to me supporting my claim. 4. I think that the LABEL mechanism of /etc/fstab is different, predated, and more rigid, from that of a UUID. Again, it seem to me supported by some of the comments in https://lwn.net/Articles/331818/. 5. Indeed, network interface enumeration was not that solid, and required user space tools to remedie. As I said, more or less, in a reply to Ralf, can you guarantee that no other Linux user will have a disk renamed? If I understand http://www.debian.org/releases/stable/i386/apcs04.html.en correctly, then yes. I can guarantee, as long as you don't have udev rules, or other deliberate commands for renaming, including, perhaps by initrd, that no other Linux user will have a disk renamed. Hotplug devices might differ. I am not sure if hotplug devices actually require such rules to guarantee stable names. Since you're so convinced of this why don't you file a bug against fstab for it to default to kernel device names rather than filesystem UUIDs? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=szegvoszc6rtl64oek4jnmunq2e+g0_enbakyhcndd...@mail.gmail.com
Re: should an end user stick to a kernel with an initrd?
On Sun, Sep 29, 2013 at 10:27 AM, Regid Ichira regi...@nt1.in wrote: On Sat, 28 Sep 2013 21:29:35 +0900 Joel Rees wrote: On Sat, Sep 28, 2013 at 8:49 PM, Regid Ichira regi...@nt1.in wrote: On Fri, 27 Sep 2013 19:06:43 -0400, Tom H wrote: [...] As I said, more or less, in a reply to Ralf, can you guarantee that no other Linux user will have a disk renamed? If I understand http://www.debian.org/releases/stable/i386/apcs04.html.en correctly, then yes. I can guarantee, as long as you don't have udev rules, or other deliberate commands for renaming, including, perhaps by initrd, that no other Linux user will have a disk renamed. Hotplug devices might differ. I am not sure if hotplug devices actually require such rules to guarantee stable names. Old information. All disks pretend to be SCSI now. That's sort of part of the problem, except, even when that page was correct, there were conditions not mentioned. If one drive spins up slow and comes up to speed out of order, the names change. For instance, you have three ATA disks attached in a certain order. They would usually be given the spin-up command in the order they are attached, and they would usually spin up in the same order. If, for some reason, they spin up out of order, your naming changes. I am not familiar with the ATA protocol. I'd rag on you for theorizing about a protocol you are not familiar with, but, hey, no one really knows what the protocol is. It's an ad-hoc mess that, on the one hand, allows implementers lots of room to cut corners, get a product to market, make profits, etc., but on the other hand, outside of the manufacturer's declaration of intended use, practically nothing is promised. And even in the manufacturer's declaration of intended use there are lots of weasel words. The upshot is that they only get excited if you can't get it to work with MSWindows, with the manufacturer supplied drivers, running according to the mostly unwritten rules Microsoft runs by and changes at their own convenience. ATA is one of the sins of Intel. Our sin is that we keep buying it from them. Are you saying that the kernel has no way to know the time on which each disk spined up? I don't think I said that at all. Doesn't the disk returns a SPINED_UP_AND_WAITING response, together with its unique address? Signal names are different, meaning is ever-so-slightly different, and, oh, the controller is supposed to know which drive it's talking to, so the disk doesn't bother saying. That's the whole reason for the channel and master/slave arrangement. Malformed star topology. The system and the hardware are supposed to cooperate to yield a unique ID if the system thinks such things are necessary, and the hardware, as I noted above, often cooperates by its own rules (if at all). SATA fixes some of that, maybe a lot of that, more so in recent devices, but the kernel developers don't think it is their responsibility to kick all the old hardware off the edge of the world, so they can't rely on new parts of the spec. (And those improved parts of the spec are still not uniformly and universally implemented in new hardware, so we aren't really talking about just eliminating old hardware from Linux support.) With scsi, the disk address is determined by its physical connection to the scsi cable. On the scsi cable, there is always a connector that is most closest to the scsi controller. And a connector that is next to the closest one, and so on. You know, that doesn't sound like any SCSI I know, so I can't address your theory at all beyond the above. The parallel SCSI devices I have include a rotary switch that sets a 3 (well, 4) bit ID that, concatenated to the bus id, becomes the SCSI id. Completely position independent. Looking at the entry on SAS on Wikipedia, it looks like manufactures are putting UUIDs in the devices themselves, comparable to the MAC address on a NIC, I suppose, so there should be no position dependency. With real SCSI devices, but we don't have those. Anyway, as Doug points out, it's not the devices themselves pretending to be SCSI, it's the drivers presenting them as SCSI. The drivers are manufacturing IDs with little reliable support from the devices themselves. Thus the tendency towards the sins of UUIDs. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iP99dEcfLMuQ3_=tHiWir=vs9ba5rhmcoe-cdkmodh...@mail.gmail.com
Re: should an end user stick to a kernel with an initrd?
On Fri, 27 Sep 2013 19:06:43 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:28 PM, Regid Ichira regi...@nt1.in wrote: On Fri, Fri, 27 Sep 2013 13:34:56 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! 1. Saying traditional disks names not siigned in a predictable manner seem to contradict the fact that one can write root=/dev/hdd3 in the kernel command line, such as in lilo. 2. I have 2 disks. It never happened to me. 3. In the old days, the way you physically attached the disks, be it IDE or SCSI, completely determined their enumeration in the hd and sd name space. I think that has not changed by newer kernels. I guess Sievers was reffering to that fact when he also points out that the device naming policy is already in the kernel Quote taken from https://lwn.net/Articles/331818/. Some of the comments in that URL seem to me supporting my claim. 4. I think that the LABEL mechanism of /etc/fstab is different, predated, and more rigid, from that of a UUID. Again, it seem to me supported by some of the comments in https://lwn.net/Articles/331818/. 5. Indeed, network interface enumeration was not that solid, and required user space tools to remedie. As I said, more or less, in a reply to Ralf, can you guarantee that no other Linux user will have a disk renamed? If I understand http://www.debian.org/releases/stable/i386/apcs04.html.en correctly, then yes. I can guarantee, as long as you don't have udev rules, or other deliberate commands for renaming, including, perhaps by initrd, that no other Linux user will have a disk renamed. Hotplug devices might differ. I am not sure if hotplug devices actually require such rules to guarantee stable names. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130928114922.ga2...@nt1.in
Re: should an end user stick to a kernel with an initrd?
On Sat, Sep 28, 2013 at 8:49 PM, Regid Ichira regi...@nt1.in wrote: On Fri, 27 Sep 2013 19:06:43 -0400, Tom H wrote: [...] As I said, more or less, in a reply to Ralf, can you guarantee that no other Linux user will have a disk renamed? If I understand http://www.debian.org/releases/stable/i386/apcs04.html.en correctly, then yes. I can guarantee, as long as you don't have udev rules, or other deliberate commands for renaming, including, perhaps by initrd, that no other Linux user will have a disk renamed. Hotplug devices might differ. I am not sure if hotplug devices actually require such rules to guarantee stable names. Old information. All disks pretend to be SCSI now. That's sort of part of the problem, except, even when that page was correct, there were conditions not mentioned. If one drive spins up slow and comes up to speed out of order, the names change. For instance, you have three ATA disks attached in a certain order. They would usually be given the spin-up command in the order they are attached, and they would usually spin up in the same order. If, for some reason, they spin up out of order, your naming changes. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iPLmugi9Gn-omLw4WdUyHgEq=ZCQb_q=8tfstymf-y...@mail.gmail.com
Re: should an end user stick to a kernel with an initrd?
On Sat, 2013-09-28 at 14:49 +0300, Regid Ichira wrote: Hotplug devices might differ. A hotplug device _is_ something different. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380371660.6343.6.camel@archlinux
Re: should an end user stick to a kernel with an initrd?
On Fri, 27 Sep 2013 23:17:40 -0400 (EDT), Ralf Mardorf wrote: On Fri, 2013-09-27 at 19:41 -0400, Stephen Powell wrote: But the correspondence between these Linux device names and the hardware device numbers varies widely from boot to boot. I can assure you of that from personal experience. So my question, if somebody experienced it already is answered. The s390x hardware platform is more susceptible to device name variations because of the extra online/offline layer. The kernel does not assign a major or minor device number to a DASD, nor does it assign it a user-space device name (/dev/dasda, /dev/dasdb, etc.) until the device is brought online. Under Debian, a DASD device is brought online by the sysconfig-hardware package, which in turn is invoked by udev. IDE and SCSI drives on the i386 or amd64 hardware platform do not have this extra layer of processing. But device name changes can happen on i386 and amd64 too. It's just less likely. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370315749.3415771.1380373177940.javamail.r...@md01.wow.synacor.com
Re: should an end user stick to a kernel with an initrd?
On Sat, 2013-09-28 at 08:59 -0400, Stephen Powell wrote: On Fri, 27 Sep 2013 23:17:40 -0400 (EDT), Ralf Mardorf wrote: On Fri, 2013-09-27 at 19:41 -0400, Stephen Powell wrote: But the correspondence between these Linux device names and the hardware device numbers varies widely from boot to boot. I can assure you of that from personal experience. So my question, if somebody experienced it already is answered. The s390x hardware platform is more susceptible to device name variations because of the extra online/offline layer. The kernel does not assign a major or minor device number to a DASD, nor does it assign it a user-space device name (/dev/dasda, /dev/dasdb, etc.) until the device is brought online. Under Debian, a DASD device is brought online by the sysconfig-hardware package, which in turn is invoked by udev. IDE and SCSI drives on the i386 or amd64 hardware platform do not have this extra layer of processing. But device name changes can happen on i386 and amd64 too. It's just less likely. As Joel mentioned If, for some reason, they spin up out of order, your naming changes. I consider to edit /dev/sd* entries in fstab to use the label or UUID instead and will take a look at grub.cfg too. Regards, Ralf PS: Perhaps someday I'll switch to UTC for the clock too ;) or stop using MBRs. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380374333.6343.31.camel@archlinux
Re: should an end user stick to a kernel with an initrd?
On Sat, 28 Sep 2013, Ralf Mardorf wrote: On Fri, 2013-09-27 at 14:41 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 2:13 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Fri, 2013-09-27 at 13:34 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! At least 2 disks are mounted, while I prefer to use labels, sd* anyway does work too. I couldn't care less how many disks you have. Defaulting to the use of UUIDs isn't some wacky whim but a well-reasoned technical decision, unless you want to claim to know more than the developers putting together distributions. This isn't a question of /dev/sdX works for me, yay! The issue is that device names aren't NECESSARILY stable (some would say that they've never been so) so, distributions are using UUIDs in order to avoid having any Linux user anywhere be unable to boot because sda is now sdc, sdb is now sda, and sdc is now sdb... I only want to mention that this never happened on my machine within the last = 10 years and I turn my PC often on and off. How often does it switch on your machine? Does anybody experience that sda became sdb after rebooting? I don't claim that this can't happen. I was about to point out that accessibility users of certain linux distributions due to necessities of accessibility support really do need initrd's. Fedora is one instance that comes to mind just to keep speakup working when the install is finished. Because the discussion turned in the direction it did though, it's probably a good idea for those intent on adding more devices to a system on a temporary or permanent basis to download and use lspci for the pci devices and lsusb both before and after devices get added to note the changes that may have happened on an pci or usb level. These levels probably are going to be more human-readable. --- jude jdash...@shellworld.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.bsf.2.01.1309280955140.26...@freire1.furyyjbeyq.arg
Re: should an end user stick to a kernel with an initrd?
On Sat, 28 Sep 2013 21:29:35 +0900 Joel Rees wrote: On Sat, Sep 28, 2013 at 8:49 PM, Regid Ichira regi...@nt1.in wrote: On Fri, 27 Sep 2013 19:06:43 -0400, Tom H wrote: [...] As I said, more or less, in a reply to Ralf, can you guarantee that no other Linux user will have a disk renamed? If I understand http://www.debian.org/releases/stable/i386/apcs04.html.en correctly, then yes. I can guarantee, as long as you don't have udev rules, or other deliberate commands for renaming, including, perhaps by initrd, that no other Linux user will have a disk renamed. Hotplug devices might differ. I am not sure if hotplug devices actually require such rules to guarantee stable names. Old information. All disks pretend to be SCSI now. That's sort of part of the problem, except, even when that page was correct, there were conditions not mentioned. If one drive spins up slow and comes up to speed out of order, the names change. For instance, you have three ATA disks attached in a certain order. They would usually be given the spin-up command in the order they are attached, and they would usually spin up in the same order. If, for some reason, they spin up out of order, your naming changes. I am not familiar with the ATA protocol. Are you saying that the kernel has no way to know the time on which each disk spined up? Doesn't the disk returns a SPINED_UP_AND_WAITING response, together with its unique address? With scsi, the disk address is determined by its physical connection to the scsi cable. On the scsi cable, there is always a connector that is most closest to the scsi controller. And a connector that is next to the closest one, and so on. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130929012711.ga6...@nt1.in
Re: should an end user stick to a kernel with an initrd?
On 09/28/2013 09:27 PM, Regid Ichira wrote: On Sat, 28 Sep 2013 21:29:35 +0900 Joel Rees wrote: /snip/ Old information. All disks pretend to be SCSI now. /snip/ I am not familiar with the ATA protocol. Are you saying that the kernel has no way to know the time on which each disk spined up? Doesn't the disk returns a SPINED_UP_AND_WAITING response, together with its unique address? With scsi, the disk address is determined by its physical connection to the scsi cable. On the scsi cable, there is always a connector that is most closest to the scsi controller. And a connector that is next to the closest one, and so on. I may be missing something, but I think there's a problem here. Even tho Linux treats the drives _as if_ they were SCSI, the _controller_ is SATA, _not_ SCSI, and so it is not required to know which disk is closest to the connector, etc. So unless The SATA controller and connector has that SCSI capability, the above argument does not hold water. --doug -- Blessed are the peacemakers..for they shall be shot at from both sides. --A.M.Greeley -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5247a407.5000...@optonline.net
Re: should an end user stick to a kernel with an initrd?
On Thu, 2013-09-26 at 22:33 +0100, Lisi Reisz wrote: On Thursday 26 September 2013 16:57:34 Regid Ichira wrote: I deliberately changed the subject of this message because I hope people will also pay attention to my previous message in the thread. At http://lists.debian.org/debian-user/2013/09/msg01150.html, which, I hope, this message will be a follow-up to, Stephen Powell wrote that, in general, initrd are desirable. You know more than Stephen Powell, Nothing quoted does claim this. but you do not know about threading?! You are always annoyed by something, many people don't know, named threading. Please inform them off-list and explain them what it is, or add it to a helpful reply. I guess you don't read my mails, perhaps you simply should filter all mails, that don't fit to your taste. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380265269.732.3.camel@archlinux
Re: should an end user stick to a kernel with an initrd?
On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380265950.732.9.camel@archlinux
Re: should an end user stick to a kernel with an initrd?
On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=Sx1+DkoV_0ygTb5jE=w98imywojqrs5s4sqs+cgxwl...@mail.gmail.com
Re: should an end user stick to a kernel with an initrd?
On Fri, 2013-09-27 at 13:34 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! At least 2 disks are mounted, while I prefer to use labels, sd* anyway does work too. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380305611.689.16.camel@archlinux
Re: should an end user stick to a kernel with an initrd?
On Fri, Sep 27, 2013 at 2:13 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Fri, 2013-09-27 at 13:34 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! At least 2 disks are mounted, while I prefer to use labels, sd* anyway does work too. I couldn't care less how many disks you have. Defaulting to the use of UUIDs isn't some wacky whim but a well-reasoned technical decision, unless you want to claim to know more than the developers putting together distributions. This isn't a question of /dev/sdX works for me, yay! The issue is that device names aren't NECESSARILY stable (some would say that they've never been so) so, distributions are using UUIDs in order to avoid having any Linux user anywhere be unable to boot because sda is now sdc, sdb is now sda, and sdc is now sdb... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=Swv=qan9had5xdxd3109c+x+ajlx7_srrtdb3j+-lk...@mail.gmail.com
Re: should an end user stick to a kernel with an initrd?
On Fri, Fri, 27 Sep 2013 13:34:56 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! 1. Saying traditional disks names not siigned in a predictable manner seem to contradict the fact that one can write root=/dev/hdd3 in the kernel command line, such as in lilo. 2. I have 2 disks. It never happened to me. 3. In the old days, the way you physically attached the disks, be it IDE or SCSI, completely determined their enumeration in the hd and sd name space. I think that has not changed by newer kernels. I guess Sievers was reffering to that fact when he also points out that the device naming policy is already in the kernel Quote taken from https://lwn.net/Articles/331818/. Some of the comments in that URL seem to me supporting my claim. 4. I think that the LABEL mechanism of /etc/fstab is different, predated, and more rigid, from that of a UUID. Again, it seem to me supported by some of the comments in https://lwn.net/Articles/331818/. 5. Indeed, network interface enumeration was not that solid, and required user space tools to remedie. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130927192801.ga3...@nt1.in
Re: should an end user stick to a kernel with an initrd?
On Thu, 26 Sep 2013 23:00:14 -0400 (EDT), Tom H tomh0...@gmail.com wrote: A lot more software?! Installing initramfs-tools will just pull in klibc-utils, libklibc, and busybox! Also, one can limit the size of the initial RAM file system itself by using modules=dep in /etc/initramfs-tools/conf.d/driver-policy. This attempts to include only items required for booting in the initial RAM file system. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/558304455.3410915.1380322665423.javamail.r...@md01.wow.synacor.com
Re: should an end user stick to a kernel with an initrd?
On Fri, Sep 27, 2013 at 3:28 PM, Regid Ichira regi...@nt1.in wrote: On Fri, Fri, 27 Sep 2013 13:34:56 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! 1. Saying traditional disks names not siigned in a predictable manner seem to contradict the fact that one can write root=/dev/hdd3 in the kernel command line, such as in lilo. 2. I have 2 disks. It never happened to me. 3. In the old days, the way you physically attached the disks, be it IDE or SCSI, completely determined their enumeration in the hd and sd name space. I think that has not changed by newer kernels. I guess Sievers was reffering to that fact when he also points out that the device naming policy is already in the kernel Quote taken from https://lwn.net/Articles/331818/. Some of the comments in that URL seem to me supporting my claim. 4. I think that the LABEL mechanism of /etc/fstab is different, predated, and more rigid, from that of a UUID. Again, it seem to me supported by some of the comments in https://lwn.net/Articles/331818/. 5. Indeed, network interface enumeration was not that solid, and required user space tools to remedie. As I said, more or less, in a reply to Ralf, can you guarantee that no other Linux user will have a disk renamed? All that Kay Sievers said was that the kernel names devices not that these names are stable across reboots. He has now used the same principle for NICs. The kernel assigns ethX names at boot and udev assigns names according to physical location that are used for IP setup no matter to which ethX the NIC corresponds. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=szyws+lpoapuyvnxm2dmqr_7pvt_4rijc-g6kmpv+q...@mail.gmail.com
Re: should an end user stick to a kernel with an initrd?
On Fri, 27 Sep 2013 14:41:54 -0400 (EDT), Tom H tomh0...@gmail.com wrote: I couldn't care less how many disks you have. Defaulting to the use of UUIDs isn't some wacky whim but a well-reasoned technical decision, unless you want to claim to know more than the developers putting together distributions. This isn't a question of /dev/sdX works for me, yay! The issue is that device names aren't NECESSARILY stable (some would say that they've never been so) so, distributions are using UUIDs in order to avoid having any Linux user anywhere be unable to boot because sda is now sdc, sdb is now sda, and sdc is now sdb... +1 Well said. By the way, even if you only have one hard disk, you can still get into trouble. For example, I have a one-hard-disk system where my hard disk normally shows up as /dev/sda and my CD-ROM drive normally shows up as /dev/sr0. But if I boot from the CD-ROM drive using a Debian installer CD in rescue mode, my CD-ROM drive shows up as /dev/sda and my hard disk shows up as /dev/sdb! Specifying the device name for the permanent root file system is not the only problem. Suspend/resume is another example. The suspend partition is identified by the Debian installer in /etc/initramfs-tools/conf.d/resume by means of a UUID. The Debian init scripts try to process a resume image *before* they attempt to mount the permanent root file system. (By the way, this tells you that /etc/initramfs-tools/conf.d/resume is one of the files that gets built in to the initial RAM file system; so if you change it you must rebuild your initial RAM file system.) If you don't use an initial RAM file system, you may have trouble with getting suspend/resume to work, or to work properly. Early loading of CPU microcode upgrades is another example. The point is that the architects of the Debian init scripts pretty much assume that an initial RAM file system is used, and they take advantage of that assumption when they write their init scripts. Although it is still possible to create a kernel that does not use an initial RAM file system, that doesn't mean that it is a good idea. As time goes on, one is likely to encounter more and more problems as the result of swimming upstream against the way the system is designed to work these days. On s390x hardware, I have a Debian Linux system that has four disks. These disks are assigned the device names /dev/dasda, /dev/dasdb, /dev/dasdc, and /dev/dasdd by the kernel. But the correspondence between these Linux device names and the hardware device numbers varies widely from boot to boot. I can assure you of that from personal experience. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/133244.3411509.1380325292433.javamail.r...@md01.wow.synacor.com
Re: should an end user stick to a kernel with an initrd?
On Fri, 2013-09-27 at 14:41 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 2:13 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Fri, 2013-09-27 at 13:34 -0400, Tom H wrote: On Fri, Sep 27, 2013 at 3:12 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Thu, 2013-09-26 at 19:07 -0400, Stephen Powell wrote: Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. This never happened on my machine. This won't happen if you have just one disk. ;) On a more serious note, do you really think that all the people maintaining distributions thought using sdX is far too simple and easy, let's start using human-non-parsable UUIDs?! At least 2 disks are mounted, while I prefer to use labels, sd* anyway does work too. I couldn't care less how many disks you have. Defaulting to the use of UUIDs isn't some wacky whim but a well-reasoned technical decision, unless you want to claim to know more than the developers putting together distributions. This isn't a question of /dev/sdX works for me, yay! The issue is that device names aren't NECESSARILY stable (some would say that they've never been so) so, distributions are using UUIDs in order to avoid having any Linux user anywhere be unable to boot because sda is now sdc, sdb is now sda, and sdc is now sdb... I only want to mention that this never happened on my machine within the last = 10 years and I turn my PC often on and off. How often does it switch on your machine? Does anybody experience that sda became sdb after rebooting? I don't claim that this can't happen. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380336853.689.36.camel@archlinux
Re: should an end user stick to a kernel with an initrd?
On Fri, 2013-09-27 at 19:41 -0400, Stephen Powell wrote: But the correspondence between these Linux device names and the hardware device numbers varies widely from boot to boot. I can assure you of that from personal experience. So my question, if somebody experienced it already is answered. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380338260.689.51.camel@archlinux
Re: should an end user stick to a kernel with an initrd?
I deliberately changed the subject of this message because I hope people will also pay attention to my previous message in the thread. At http://lists.debian.org/debian-user/2013/09/msg01150.html, which, I hope, this message will be a follow-up to, Stephen Powell wrote that, in general, initrd are desirable. He gave a few example where, he believes, one can not get without it. I am no expert. I do believe that, other then corner cases, most, if not all, the examples are wrong. They can be done without an initrd. I think the basic reason is that one can have udev rules that will map specific devices to specific names. Now, considering that an initrd requires a lot more software, I think that an initrd should be avoided unless absolutely necessary. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130926155734.gb21...@nt1.in
Re: should an end user stick to a kernel with an initrd?
On Thursday 26 September 2013 16:57:34 Regid Ichira wrote: I deliberately changed the subject of this message because I hope people will also pay attention to my previous message in the thread. At http://lists.debian.org/debian-user/2013/09/msg01150.html, which, I hope, this message will be a follow-up to, Stephen Powell wrote that, in general, initrd are desirable. You know more than Stephen Powell, but you do not know about threading?! Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201309262233.40454.lisi.re...@gmail.com
Re: should an end user stick to a kernel with an initrd?
On Thu, 26 Sep 2013 17:33:40 -0400 (EDT), Lisi Reisz wrote: You know more than Stephen Powell, but you do not know about threading?! Regid, What Lisi is saying is that changing the subject line of a post does not start a new thread. You have to remove the In-reply-to: tag from your e-mail header before you send it. If your e-mail client does not allow you to edit the header, then you need to do a copy and paste of the old message into a brand new e-mail with a new subject line to start a new thread. If you look on the Debian mailing list archives, you will see that your second e-mail is still part of the original thread. I learned this the same way I learned most things: by making mistakes and learning from them. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/292348606.3392457.1380234628455.javamail.r...@md01.wow.synacor.com
Re: should an end user stick to a kernel with an initrd?
On Thu, 26 Sep 2013 11:57:34 -0400 (EDT), Regid Ichira wrote: I deliberately changed the subject of this message because I hope people will also pay attention to my previous message in the thread. At http://lists.debian.org/debian-user/2013/09/msg01150.html, which, I hope, this message will be a follow-up to, Stephen Powell wrote that, in general, initrd are desirable. He gave a few example where, he believes, one can not get without it. I am no expert. I do believe that, other then corner cases, most, if not all, the examples are wrong. They can be done without an initrd. I think the basic reason is that one can have udev rules that will map specific devices to specific names. Now, considering that an initrd requires a lot more software, I think that an initrd should be avoided unless absolutely necessary. You don't seem to understand. First of all, even if you have written udev rules to map specific devices to specific names, this mapping cannot take place until udev starts. udev is not kernel code. It is not a kernel module, nor can it be built in to the kernel. It is a user-space process. That means that it must be read from a file system and executed as a command. And that means that a file system must be mounted. If you don't use an initial RAM file system, there is no file system from which to read udev until the permanent root file system is mounted (usually read-only initially). And if the permanent root file system is already mounted, it is too late to assign a name to it. You must know the name before udev gets launched. Second, this is contrary to the direction and thinking of the kernel people these days. Traditional device names, such as /dev/sda, /dev/sdb, (and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1, etc.) are not assigned in a predictable manner anymore. This device name assignment can change from one boot to the next. In order to specify which partition is to be mounted as the permanent root file system in a manner which is independent of the now-unpredictable device name assignment, you must rely on something like the uuid or label of the partition, which is presumed to be unique. For example, if your boot loader is LILO, something like root=UUID=3860da3c-b206-44d9-920c-5ed4beac34e9 can be specified in /etc/lilo.conf. This results in the following being added to the kernel command line by the LILO boot loader: root=UUID=3860da3c-b206-44d9-920c-5ed4beac34e9 But in order for the kernel to figure out which partition on which disk this is, it looks for a symbolic link called /dev/disk/by-uuid/3860da3c-b206-44d9-920c-5ed4beac34e9 If it finds it, it can determine what partition to mount as the permanent root file system. But if it can't find it, it can't mount the permanent root file system. How did that symbolic link get created? udev created it. udev, launched from the initial RAM file system, has already created this symbolic link. It might point to /dev/sda1 on this boot. But on the next boot, it might point to /dev/sdb1. In either case, it will be the correct partition to mount as the permanent root file system. But if you don't use an initial RAM file system, udev has not been launched yet, and therefore, the symbolic link does not exist yet, and therefore, the kernel can't find the permanent root file system if you refer to it by means of a uuid. The same principle applies for referring to a partition by means of a disk label. Although it is still possible to create a kernel that does not use an initial RAM file system, the design of modern Linux systems pretty much assumes that one is used. I predict that as time goes on you will continue to encounter more and more problems as the result of not using one. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287490021.3392877.1380236855592.javamail.r...@md01.wow.synacor.com
Re: should an end user stick to a kernel with an initrd?
On Thu, Sep 26, 2013 at 11:57 AM, Regid Ichira regi...@nt1.in wrote: Now, considering that an initrd requires a lot more software, I think that an initrd should be avoided unless absolutely necessary. A lot more software?! Installing initramfs-tools will just pull in klibc-utils, libklibc, and busybox! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SwjTH237aXqZ=oaa3tveg_0znh7ohtcgn_6is6+9gh...@mail.gmail.com
