Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #13743 > unrolled thread

Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore.

Back to article view | Back to comp.os.linux.misc

Contents

  Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pim <moi@free.fr> - 2015-02-23 14:18 +0000
    Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Aragorn <thorongil@telenet.be.invalid> - 2015-02-23 18:37 +0100
      Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pim <moi@free.fr> - 2015-02-23 18:32 +0000
        Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Aragorn <thorongil@telenet.be.invalid> - 2015-02-23 19:43 +0100
          Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pim <moi@free.fr> - 2015-02-23 19:30 +0000
            Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Aragorn <thorongil@telenet.be.invalid> - 2015-02-24 09:08 +0100
        Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-02-23 17:50 -0500
          Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pim <moi@free.fr> - 2015-02-24 02:41 +0000
            Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-02-24 01:29 -0500
              Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pim <moi@free.fr> - 2015-02-24 18:32 +0000
              Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Jerry Peters <jerry@example.invalid> - 2015-02-24 21:16 +0000
      Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-02-27 21:47 +0100
        Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pim <moi@free.fr> - 2015-02-27 23:43 +0000
        Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Aragorn <thorongil@telenet.be.invalid> - 2015-02-28 00:44 +0100
          Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-02-28 14:29 +0100
            Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Aragorn <thorongil@telenet.be.invalid> - 2015-02-28 21:10 +0100
              Re: Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore. Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-03-01 10:40 +0100

#13743 — Linux Wheezy just compiled 3.2.65 kernel does not see UUID of my 1st partition anymore.

Hi all.
Could you read everything please : i try to give all the details.

I'm on Debian wheezy and i just compile a knew kernel comming from debian
Distribution.
In fact it is the last dpkg update kernel source 
for the stable wheezy.

uname -a gives:
Linux Amd64 3.2.65 #1 SMP Mon Feb 16 22:04:41 CET 2015 x86_64 GNU/Linux

Unfortunately it does not sees my root partition / if I tell grub2
to search it by UUID.

Note that i have my /boot partition (where leaves the kernel and so)
different from the / partition (linux system and linux tree entry).

On boot i have a message like:
blkid : cannot find UUID=xxxxx or something like that when booting
by /dev/sdb5 : possibly that uuid is red in /etc/fstab.
But trying to boot with uuid give a kernel panic
unable to boot on (0,0) or something like that.
Note also the i did compile kernel WITHOUT initrd. 
I notice that the install process of the kernel continues
to build an initrd in anyway even if my kernel options
say that i dont want it: what the hell?
Are there any changes?

So I took of the initrd and could see that kernel boots
whithout (and really faster).
The fact to boot WITH initrd does not change anything
and gives also a panic.

May be this could also be a trick with /etc/fstab or grub.cfg
my /etc/fstab declare boot partitions with uuid.

I am using grub2 and i tried with old grub2 config before installation
of my knew kernel but it gives the same result.

When i run update-grub2, the grub.cfg writen does not tell the
kernel to boot with UUID but with /dev/sdb5 which is 
/ partition ... but it does for my old kernels.

And il works but I don't like that: not dynamic.

In general, is there a way to trace this with grub2?
I suppose on the early stage, kernel does not sees
/boot/disks/by-uuid 

Did i forget a kernel option or .... ?

I got a lot of pain reading grub2 doc because it's not my
natural langage. And there are many things confused for me.

Who could help me?

Thank you very much in advance.
Pim.

[toc] | [next] | [standalone]

#13744

On Monday 23 February 2015 15:18, Pim conveyed the following to 
comp.os.linux.misc...

> Hi all.
> Could you read everything please : i try to give all the details.
> 
> I'm on Debian wheezy and i just compile a knew kernel comming from
> debian Distribution.
> In fact it is the last dpkg update kernel source
> for the stable wheezy.
> 
> uname -a gives:
> Linux Amd64 3.2.65 #1 SMP Mon Feb 16 22:04:41 CET 2015 x86_64
> GNU/Linux
> 
> Unfortunately it does not sees my root partition / if I tell grub2
> to search it by UUID.
> 
> Note that i have my /boot partition (where leaves the kernel and so)
> different from the / partition (linux system and linux tree entry).
> 
> On boot i have a message like:
> blkid : cannot find UUID=xxxxx or something like that when booting
> by /dev/sdb5 : possibly that uuid is red in /etc/fstab.
> But trying to boot with uuid give a kernel panic
> unable to boot on (0,0) or something like that.
> Note also the i did compile kernel WITHOUT initrd.
>
> [...]

That last quoted line above says it all.  The kernel does not by itself 
support UUIDs or LABELs.  If you want to boot a kernel while using a 
UUID or a LABEL in your grub.cfg or at the kernel boot line, then you'll 
need to create an initramfs.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

#13745

Le Mon, 23 Feb 2015 18:37:33 +0100,
 Aragorn <thorongil@telenet.be.invalid> disait ceci :
> On Monday 23 February 2015 15:18, Pim conveyed the following to 
> comp.os.linux.misc...
>
>> Hi all.
>> Could you read everything please : i try to give all the details.
>> 
>> I'm on Debian wheezy and i just compile a knew kernel comming from
>> debian Distribution.
>> In fact it is the last dpkg update kernel source
>> for the stable wheezy.
>> 
>> uname -a gives:
>> Linux Amd64 3.2.65 #1 SMP Mon Feb 16 22:04:41 CET 2015 x86_64
>> GNU/Linux
>> 
>> Unfortunately it does not sees my root partition / if I tell grub2
>> to search it by UUID.
>> 
>> Note that i have my /boot partition (where leaves the kernel and so)
>> different from the / partition (linux system and linux tree entry).
>> 
>> On boot i have a message like:
>> blkid : cannot find UUID=xxxxx or something like that when booting
>> by /dev/sdb5 : possibly that uuid is red in /etc/fstab.
>> But trying to boot with uuid give a kernel panic
>> unable to boot on (0,0) or something like that.
>> Note also the i did compile kernel WITHOUT initrd.
>>
>> [...]
>
> That last quoted line above says it all.  The kernel does not by itself 
> support UUIDs or LABELs.  If you want to boot a kernel while using a 
> UUID or a LABEL in your grub.cfg or at the kernel boot line, then you'll 
> need to create an initramfs.
>
> -- 
> = Aragorn =
>
>          http://www.linuxcounter.net - registrant #223157

Thank's for reply.
Ok.
Could you explain me why that please : how does it work?

Thank You!

[toc] | [prev] | [next] | [standalone]

#13746

On Monday 23 February 2015 19:32, Pim conveyed the following to 
comp.os.linux.misc...

> Le Mon, 23 Feb 2015 18:37:33 +0100,
>  Aragorn <thorongil@telenet.be.invalid> disait ceci :
>> On Monday 23 February 2015 15:18, Pim conveyed the following to
>> comp.os.linux.misc...
>>
>>> Hi all.
>>> Could you read everything please : i try to give all the details.
>>> 
>>> I'm on Debian wheezy and i just compile a knew kernel comming from
>>> debian Distribution.
>>> In fact it is the last dpkg update kernel source
>>> for the stable wheezy.
>>> 
>>> uname -a gives:
>>> Linux Amd64 3.2.65 #1 SMP Mon Feb 16 22:04:41 CET 2015 x86_64
>>> GNU/Linux
>>> 
>>> Unfortunately it does not sees my root partition / if I tell grub2
>>> to search it by UUID.
>>> 
>>> Note that i have my /boot partition (where leaves the kernel and so)
>>> different from the / partition (linux system and linux tree entry).
>>> 
>>> On boot i have a message like:
>>> blkid : cannot find UUID=xxxxx or something like that when booting
>>> by /dev/sdb5 : possibly that uuid is red in /etc/fstab.
>>> But trying to boot with uuid give a kernel panic
>>> unable to boot on (0,0) or something like that.
>>> Note also the i did compile kernel WITHOUT initrd.
>>>
>>> [...]
>>
>> That last quoted line above says it all.  The kernel does not by
>> itself support UUIDs or LABELs.  If you want to boot a kernel while
>> using a UUID or a LABEL in your grub.cfg or at the kernel boot line,
>> then you'll need to create an initramfs.
> 
> Thank's for reply.
> Ok.
> Could you explain me why that please : how does it work?

I'm not sure exactly, but I believe that the interpretation of UUIDs and 
LABELs is done in userspace, normally, so at boot time, the kernel 
doesn't have any idea what those UUIDs or LABELs are.  The initramfs 
however contains the tools needed for the interpretation ─ most notably, 
udev (now part of systemd).

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

#13747

Le Mon, 23 Feb 2015 19:43:54 +0100,
 Aragorn <thorongil@telenet.be.invalid> disait ceci :
> On Monday 23 February 2015 19:32, Pim conveyed the following to 
> comp.os.linux.misc...
>
>> Le Mon, 23 Feb 2015 18:37:33 +0100,
>>  Aragorn <thorongil@telenet.be.invalid> disait ceci :
>>> On Monday 23 February 2015 15:18, Pim conveyed the following to
>>> comp.os.linux.misc...
>>>
>>>> Hi all.
>>>> Could you read everything please : i try to give all the details.
>>>> 
>>>> I'm on Debian wheezy and i just compile a knew kernel comming from
>>>> debian Distribution.
>>>> In fact it is the last dpkg update kernel source
>>>> for the stable wheezy.
>>>> 
>>>> uname -a gives:
>>>> Linux Amd64 3.2.65 #1 SMP Mon Feb 16 22:04:41 CET 2015 x86_64
>>>> GNU/Linux
>>>> 
>>>> Unfortunately it does not sees my root partition / if I tell grub2
>>>> to search it by UUID.
>>>> 
>>>> Note that i have my /boot partition (where leaves the kernel and so)
>>>> different from the / partition (linux system and linux tree entry).
>>>> 
>>>> On boot i have a message like:
>>>> blkid : cannot find UUID=xxxxx or something like that when booting
>>>> by /dev/sdb5 : possibly that uuid is red in /etc/fstab.
>>>> But trying to boot with uuid give a kernel panic
>>>> unable to boot on (0,0) or something like that.
>>>> Note also the i did compile kernel WITHOUT initrd.
>>>>
>>>> [...]
>>>
>>> That last quoted line above says it all.  The kernel does not by
>>> itself support UUIDs or LABELs.  If you want to boot a kernel while
>>> using a UUID or a LABEL in your grub.cfg or at the kernel boot line,
>>> then you'll need to create an initramfs.
>> 
>> Thank's for reply.
>> Ok.
>> Could you explain me why that please : how does it work?
>
> I'm not sure exactly, but I believe that the interpretation of UUIDs and 
> LABELs is done in userspace, normally, so at boot time, the kernel 
> doesn't have any idea what those UUIDs or LABELs are.  The initramfs 
> however contains the tools needed for the interpretation ??? most notably, 
> udev (now part of systemd).

Thank's for reply.

I don't know myself but i think it is just that /dev filesystem must
be mounted and the uuid can be found in /dev/disks/by-uuid/xxx

Sorry but this entry :

title           Debian GNU/Linux, kernel 2.6.26 (single-user mode)
root            (hd0,0)
kernel          /vmlinuz-2.6.26 root=UUID=93dbe8dc-adf2-4dbe-b001-fd65006d568d
ro single

comes from and old kernel of mine i compiled without initrd
the file is menu.lst, means grub1 and i remember it booted very well.

So why should not it work too with a recent kernel 3.xxx?

I liked this kind of conf because it is very thin et very efficient.

I don't like heavy things.

Thank you very much!

But the problem is NOT resolved :( for myself :(.

>
> -- 
> = Aragorn =
>
>          http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

#13755

On Monday 23 February 2015 20:30, Pim conveyed the following to 
comp.os.linux.misc...

> Le Mon, 23 Feb 2015 19:43:54 +0100,
>  Aragorn <thorongil@telenet.be.invalid> disait ceci :
>
>> On Monday 23 February 2015 19:32, Pim conveyed the following to
>> comp.os.linux.misc...
>>
>>> Le Mon, 23 Feb 2015 18:37:33 +0100,
>>>  Aragorn <thorongil@telenet.be.invalid> disait ceci :
>>>
>>>> On Monday 23 February 2015 15:18, Pim conveyed the following to
>>>> comp.os.linux.misc...
>>>>
>>>>> [...]
>>>>> I'm on Debian wheezy and i just compile a knew kernel comming from
>>>>> debian Distribution. In fact it is the last dpkg update kernel
>>>>> source for the stable wheezy.
>>>>> 
>>>>> uname -a gives:
>>>>> Linux Amd64 3.2.65 #1 SMP Mon Feb 16 22:04:41 CET 2015 x86_64
>>>>> GNU/Linux
>>>>> 
>>>>> Unfortunately it does not sees my root partition / if I tell grub2
>>>>> to search it by UUID.
>>>>> 
>>>>> [...]
>>>>> On boot i have a message like:
>>>>> blkid : cannot find UUID=xxxxx or something like that when booting
>>>>> by /dev/sdb5 : possibly that uuid is red in /etc/fstab.
>>>>> But trying to boot with uuid give a kernel panic
>>>>> unable to boot on (0,0) or something like that.
>>>>> Note also the i did compile kernel WITHOUT initrd.
>>>>>
>>>>> [...]
>>>>
>>>> That last quoted line above says it all.  The kernel does not by
>>>> itself support UUIDs or LABELs.  If you want to boot a kernel while
>>>> using a UUID or a LABEL in your grub.cfg or at the kernel boot
>>>> line, then you'll need to create an initramfs.
>>> 
>>> Thank's for reply.
>>> Ok.
>>> Could you explain me why that please : how does it work?
>>
>> I'm not sure exactly, but I believe that the interpretation of UUIDs
>> and LABELs is done in userspace, normally, so at boot time, the
>> kernel doesn't have any idea what those UUIDs or LABELs are.  The
>> initramfs however contains the tools needed for the interpretation
>> ??? most notably, udev (now part of systemd).
   ^^^

Apparently you are using a version of slrn without UTF-8 support. :-)

(P.S.: Please tell your newsreader to drop the signature of the poster 
to whom you are replying.)

> Thank's for reply.
> 
> I don't know myself but i think it is just that /dev filesystem must
> be mounted and the uuid can be found in /dev/disks/by-uuid/xxx

That too is part of the problem.

> Sorry but this entry :
> 
> title           Debian GNU/Linux, kernel 2.6.26 (single-user mode)
> root            (hd0,0)
> kernel          /vmlinuz-2.6.26
> root=UUID=93dbe8dc-adf2-4dbe-b001-fd65006d568d ro single
> 
> comes from and old kernel of mine i compiled without initrd
> the file is menu.lst, means grub1 and i remember it booted very well.
> 
> So why should not it work too with a recent kernel 3.xxx?

Did you enable devtmpfs support in your new kernel and told it to mount 
the devtmpfs at boot?

> I liked this kind of conf because it is very thin et very efficient.
> 
> I don't like heavy things.

I understand, but the initramfs/initrd doesn't necessarily complicate 
things.  You can easily create one with mkinitrd and it is dropped from 
memory once the kernel has fully booted, so it's not taking up any idle 
RAM.

-- 
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#13750

On Mon, 23 Feb 2015 13:32:35 -0500, Pim <moi@free.fr> wrote:

> Le Mon, 23 Feb 2015 18:37:33 +0100,
>  Aragorn <thorongil@telenet.be.invalid> disait ceci :
>> That last quoted line above says it all.  The kernel does not by itself
>> support UUIDs or LABELs.  If you want to boot a kernel while using a
>> UUID or a LABEL in your grub.cfg or at the kernel boot line, then you'll
>> need to create an initramfs.

> Could you explain me why that please : how does it work?

The kernel modules only create the /dev/sd?? entries. The
/dev/disk/by-uuid/ (and other /dev/disk/ directory entries are created
by scripts and programs in the initrd.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#13751

Le Mon, 23 Feb 2015 17:50:44 -0500,
 David W. Hodgins <dwhodgins@nomail.afraid.org> disait ceci :
> On Mon, 23 Feb 2015 13:32:35 -0500, Pim <moi@free.fr> wrote:
>
>> Le Mon, 23 Feb 2015 18:37:33 +0100,
>>  Aragorn <thorongil@telenet.be.invalid> disait ceci :
>>> That last quoted line above says it all.  The kernel does not by itself
>>> support UUIDs or LABELs.  If you want to boot a kernel while using a
>>> UUID or a LABEL in your grub.cfg or at the kernel boot line, then you'll
>>> need to create an initramfs.
>
>> Could you explain me why that please : how does it work?
>
> The kernel modules only create the /dev/sd?? entries. The
> /dev/disk/by-uuid/ (and other /dev/disk/ directory entries are created
> by scripts and programs in the initrd.

Thank's to reply David.

And how do you explain that booting  a "withount initrd" kernel,
i DO have /dev/disk/by-uuid/ fed at the end of boot process?

Thank you.

>
> Regards, Dave Hodgins
>
> -- 
> Change nomail.afraid.org to ody.ca to reply by email.
> (nomail.afraid.org has been set up specifically for
> use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#13754

On Mon, 23 Feb 2015 21:41:30 -0500, Pim <moi@free.fr> wrote:

> And how do you explain that booting  a "withount initrd" kernel,
> i DO have /dev/disk/by-uuid/ fed at the end of boot process?

I'm not positive, but I think it's done by either udev, or udisksd,
after the system starts, if the directories don't already exist.

Try booting to run level 1, so those are not started, and see if the
directory exists then. I'd test it myself, but my systems do use an
initrd.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#13756

Le Tue, 24 Feb 2015 01:29:28 -0500,
 David W. Hodgins <dwhodgins@nomail.afraid.org> disait ceci :
> On Mon, 23 Feb 2015 21:41:30 -0500, Pim <moi@free.fr> wrote:
>
>> And how do you explain that booting  a "withount initrd" kernel,
>> i DO have /dev/disk/by-uuid/ fed at the end of boot process?
>
> I'm not positive, but I think it's done by either udev, or udisksd,
> after the system starts, if the directories don't already exist.
>
> Try booting to run level 1, so those are not started, and see if the
> directory exists then. I'd test it myself, but my systems do use an
> initrd.
OK.
Thank you very much David.
>
> Regards, Dave Hodgins
>
> -- 
> Change nomail.afraid.org to ody.ca to reply by email.
> (nomail.afraid.org has been set up specifically for
> use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#13757

David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Mon, 23 Feb 2015 21:41:30 -0500, Pim <moi@free.fr> wrote:
> 
>> And how do you explain that booting  a "withount initrd" kernel,
>> i DO have /dev/disk/by-uuid/ fed at the end of boot process?
> 
> I'm not positive, but I think it's done by either udev, or udisksd,
> after the system starts, if the directories don't already exist.
> 
> Try booting to run level 1, so those are not started, and see if the
> directory exists then. I'd test it myself, but my systems do use an
> initrd.
> 
> Regards, Dave Hodgins
> 

It's done by udev, see:
 /lib/udev/rules.d/60-persistent-storage.rules

[toc] | [prev] | [next] | [standalone]

#13766

Hello,

Aragorn a écrit :
> 
> The kernel does not by itself support UUIDs or LABELs.

The kernel does not support filesystem-level UUIDs. While replying to
the OP's same question in another newsgroup, I found out that since
version 2.6.37 the kernel supports *partition* UUIDs for partition
schemes which have them, such as GPT. Since version 3.8 it can emulate
partition UUIDs for legacy MBR/MS-DOS partition scheme by combining the
disk signature and partition number. The syntax to specify the root by
its partition UUID is "root=PARTUUID=<part_uuid>".

[toc] | [prev] | [next] | [standalone]

#13767

Le Fri, 27 Feb 2015 21:47:35 +0100,
 Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> disait ceci :
> Hello,
>
> Aragorn a écrit :
>> 
>> The kernel does not by itself support UUIDs or LABELs.
>
> The kernel does not support filesystem-level UUIDs. While replying to
> the OP's same question in another newsgroup, I found out that since
> version 2.6.37 the kernel supports *partition* UUIDs for partition
> schemes which have them, such as GPT. Since version 3.8 it can emulate
> partition UUIDs for legacy MBR/MS-DOS partition scheme by combining the
> disk signature and partition number. The syntax to specify the root by
> its partition UUID is "root=PARTUUID=<part_uuid>".

True! I"ve seen that too!
Thank you!

[toc] | [prev] | [next] | [standalone]

#13768

On Friday 27 February 2015 21:47, Pascal Hambourg conveyed the following 
to comp.os.linux.misc...

> Hello,
> 
> Aragorn a écrit :
>
>> The kernel does not by itself support UUIDs or LABELs.
> 
> The kernel does not support filesystem-level UUIDs. While replying to
> the OP's same question in another newsgroup, I found out that since
> version 2.6.37 the kernel supports *partition* UUIDs for partition
> schemes which have them, such as GPT. Since version 3.8 it can emulate
> partition UUIDs for legacy MBR/MS-DOS partition scheme by combining
> the disk signature and partition number. The syntax to specify the
> root by its partition UUID is "root=PARTUUID=<part_uuid>".

That is certainly useful information ─ I have no experience yet with GPT 
─ especially for those of us who wish to roll their own kernel and 
refuse to use an initrd. [*] 


[*] Well, provided that you're not using systemd, of course, because if
    you are and you have /usr on a separate partition, you'll still need
    an initrd on RedHat/CentOS, Fedora, Mageia, Mandriva and possibly
    openSUSE.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

#13772

Aragorn a écrit :
> On Friday 27 February 2015 21:47, Pascal Hambourg conveyed the following 
> to comp.os.linux.misc...
> 
>> Aragorn a écrit :
>>
>>> The kernel does not by itself support UUIDs or LABELs.
>> The kernel does not support filesystem-level UUIDs. While replying to
>> the OP's same question in another newsgroup, I found out that since
>> version 2.6.37 the kernel supports *partition* UUIDs for partition
>> schemes which have them, such as GPT. Since version 3.8 it can emulate
>> partition UUIDs for legacy MBR/MS-DOS partition scheme by combining
>> the disk signature and partition number. The syntax to specify the
>> root by its partition UUID is "root=PARTUUID=<part_uuid>".
> 
> That is certainly useful information - I have no experience yet with GPT 

You should really give it a try. GPT is not reserved for modern UEFI
systems or disks larger than 2 TiB.

> - especially for those of us who wish to roll their own kernel and 
> refuse to use an initrd. [*] 
> 
> [*] Well, provided that you're not using systemd, of course, because if
>     you are and you have /usr on a separate partition, you'll still need
>     an initrd on RedHat/CentOS, Fedora, Mageia, Mandriva and possibly
>     openSUSE.

Actually the separate /usr issue has nothing to do with systemd. Systemd
itself works fine with a separate /usr mounted late (according to
systemd developpers [*]). The main issue is that other software such as
all the stuff which may be run by udev need /usr to be mounted early,
before filesystems in fstab are mounted.

[*] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

[toc] | [prev] | [next] | [standalone]

#13789

On Saturday 28 February 2015 14:29, Pascal Hambourg conveyed the 
following to comp.os.linux.misc...

> Aragorn a écrit :
>> On Friday 27 February 2015 21:47, Pascal Hambourg conveyed the
>> following to comp.os.linux.misc...
>> 
>>> Aragorn a écrit :
>>>
>>>> The kernel does not by itself support UUIDs or LABELs.
>>> The kernel does not support filesystem-level UUIDs. While replying
>>> to the OP's same question in another newsgroup, I found out that
>>> since version 2.6.37 the kernel supports *partition* UUIDs for
>>> partition schemes which have them, such as GPT. Since version 3.8 it
>>> can emulate partition UUIDs for legacy MBR/MS-DOS partition scheme
>>> by combining the disk signature and partition number. The syntax to
>>> specify the root by its partition UUID is
>>> "root=PARTUUID=<part_uuid>".
>> 
>> That is certainly useful information - I have no experience yet with
>> GPT
> 
> You should really give it a try. GPT is not reserved for modern UEFI
> systems or disks larger than 2 TiB.
> 
>> - especially for those of us who wish to roll their own kernel and
>> refuse to use an initrd. [*]
>> 
>> [*] Well, provided that you're not using systemd, of course, because
>>     if you are and you have /usr on a separate partition, you'll
>>     still need an initrd on RedHat/CentOS, Fedora, Mageia, Mandriva
>>     and possibly openSUSE.
> 
> Actually the separate /usr issue has nothing to do with systemd.
> Systemd itself works fine with a separate /usr mounted late (according
> to systemd developpers [*]). The main issue is that other software
> such as all the stuff which may be run by udev need /usr to be mounted
> early, before filesystems in fstab are mounted.
> 
> [*]
> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

I hear what you're saying, but the distributions I've listed higher up 
are making /bin, /lib{,64} and /sbin into symbolic links to their 
counterparts under /usr.  This was a RedHat initiative which the others 
─ as RedHat spin-offs ─ have inherited.  So the systems based upon 
RedHat and having systemd will have systemd itself parked under /usr as 
well, plus everything else that used to be on the root filesystem.

Ergo, so long as one does not have /usr as a separate filesystem, those 
distributions can be booted without an initramfs ─ provided of course 
that every module needed is built into the kernel statically ─ and if 
/usr is on a separate filesystem, then an initramfs is required to be 
able to properly initiate userspace.

It may not be systemd-specific, but it's either way related to RedHat, 
as systemd itself is (and as freedesktop.org is, for that matter).

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

#13805

Aragorn a écrit :
> On Saturday 28 February 2015 14:29, Pascal Hambourg conveyed the 
> following to comp.os.linux.misc...
>>>
>> Actually the separate /usr issue has nothing to do with systemd.
>> Systemd itself works fine with a separate /usr mounted late (according
>> to systemd developpers [*]). The main issue is that other software
>> such as all the stuff which may be run by udev need /usr to be mounted
>> early, before filesystems in fstab are mounted.
>>
>> [*]
>> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
> 
> I hear what you're saying, but the distributions I've listed higher up 
> are making /bin, /lib{,64} and /sbin into symbolic links to their 
> counterparts under /usr.

You are talking about the /usr merge. It is a different issue from the
separate /usr, although somehow related. Again, it has nothing to do
with systemd.

> So the systems based upon 
> RedHat and having systemd will have systemd itself parked under /usr as 
> well, plus everything else that used to be on the root filesystem.

So everything static will go into /usr which can be mounted read-only.
The root filesystem will contain only mount points and config files. I
like the idea.

> Ergo, so long as one does not have /usr as a separate filesystem, those 
> distributions can be booted without an initramfs - provided of course 
> that every module needed is built into the kernel statically -

And also that mounting the root does not need anything in userspace
(mdadm, lvm, cryptsetup...).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web