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

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

Learning about the Kernal

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

Contents

  Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-14 19:59 -0400
    Re: Learning about the Kernal Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2015-03-15 11:11 +0100
      Re: Learning about the Kernal ruben <nowhere@nowhere.nor> - 2015-03-15 21:14 +0000
        Re: Learning about the Kernal Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-16 10:02 +0200
          Re: Learning about the Kernal Ruben Safir <mrbrklyn@panix.com> - 2015-03-17 00:18 +0000
            Re: Learning about the Kernal Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-03-16 20:53 -0700
              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:14 +0000
              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:23 +0000
        Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-16 21:58 -0400
          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:21 +0000
            Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-17 10:51 +0000
            Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-17 09:10 -0400
              Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-17 14:12 -0400
                Re: Learning about the Kernal William Unruh <unruh@invalid.ca> - 2015-03-17 19:03 +0000
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 19:08 +0000
                    Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-17 15:17 -0400
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 01:06 +0000
                        Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-19 23:52 -0400
                        Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-20 10:52 +0000
                          Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-20 20:33 +0000
                            Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-04-20 09:48 -0400
                Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-17 15:08 -0400
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-18 03:36 +0000
                    Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-18 10:09 -0400
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 01:04 +0000
                      Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-20 10:58 +0000
                        Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-20 09:22 -0400
                          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 18:39 +0000
                          Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-20 20:04 +0000
                            Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-20 21:10 -0400
                              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 05:03 +0000
                        Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 18:42 +0000
                          Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-20 15:31 -0400
                            Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 05:13 +0000
                              Re: Learning about the Kernal The Natural Philosopher <tnp@invalid.invalid> - 2015-03-21 09:13 +0000
                                Re: Learning about the Kernal ruben <nowhere@nowhere.nor> - 2015-03-21 14:40 +0000
                                  Re: Learning about the Kernal Michael Black <et472@ncf.ca> - 2015-03-21 12:20 -0400
                                    Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 19:54 +0000
                                      Re: Learning about the Kernal Baho Utot <baho-utot@columbus.rr.com> - 2015-03-21 17:56 -0400
                                    Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 19:56 +0000
                                  Re: Learning about the Kernal Richard Kettlewell <rjk@greenend.org.uk> - 2015-03-21 16:18 +0000
            Re: Learning about the Kernal Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-17 16:10 +0200
              Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-17 14:06 -0400
                Re: Learning about the Kernal William Unruh <unruh@invalid.ca> - 2015-03-17 19:00 +0000
                  Re: Learning about the Kernal Tim Watts <tw_usenet@dionic.net> - 2015-03-17 19:05 +0000
                    Re: Learning about the Kernal Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-03-17 14:17 -0700
                    Re: Learning about the Kernal William Unruh <unruh@invalid.ca> - 2015-03-19 06:04 +0000
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 08:45 +0000
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 08:20 +0000
                    Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-21 16:09 +0000
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 20:10 +0000
                Re: Learning about the Kernal Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-17 22:39 +0200
            Re: Learning about the Kernal Chick Tower <c.tower@deadspam.com> - 2015-03-18 03:35 +0000
              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 08:47 +0000
                Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-21 20:19 +0000
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 20:30 +0000
                    Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-22 20:05 +0000
                      Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-23 01:16 -0400
                        Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-23 20:27 +0000
                          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-25 02:57 +0000
                          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-25 02:59 +0000
                            Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-25 20:59 +0000
                              Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-04-20 09:44 -0400
                  Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 00:07 +0100
                    Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-22 00:07 +0000
                      Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 01:13 +0100
                        Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-22 03:11 +0000
                          Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 04:20 +0100
                            Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-22 13:19 +0000
                              Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-22 15:13 +0000
                              Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 21:52 +0100
                            Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-22 20:13 +0000
                              Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 22:01 +0100
                Re: Learning about the Kernal Chick Tower <c.tower@deadspam.com> - 2015-03-23 04:02 +0000
                  Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-23 05:13 +0100
                    Re: Learning about the Kernal ruben <ceo@iran.gov> - 2015-04-12 13:03 +0000
        Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:18 +0000
        Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-17 01:52 -0400

Page 4 of 4 — ← Prev page 1 2 3 [4]

#14245

On Mon, 23 Mar 2015 20:27:48 +0000, Jerry Peters wrote:


> If you're going to hack the scheduler you really need to get used to
> trying, and perhaps breaking things.

yep, yep... that is exactly why I am asking about set ups.  



-- 
The Coin Hangout: http://www.coinhangout.com/home

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

#14254

ruben safir <dont@email.me> wrote:
> On Mon, 23 Mar 2015 20:27:48 +0000, Jerry Peters wrote:
> 
> 
>> If you're going to hack the scheduler you really need to get used to
>> trying, and perhaps breaking things.
> 
> yep, yep... that is exactly why I am asking about set ups.  
> 
> 
> 

Grub resolves the configuration at boot time unlike lilo which saves
disk addresses when you run /sbin/lilo. That means that if you use
symlinks they are resolved at *boot* time. So if you use symlinks in
grub.cfg, and change the symlink, grub will see the new kernel when it
boots. Thus you just change the symlink to point to your new kernel,
no need for update-grub. In fact, installkernel can change the symlink
for you when you do 'make install'.

So you either edit grub.cfg to add additional menuentries for your new
kernels, or you can add something like:

cat <<-EOF
	menuentry {
		kernel ...
		initrd ... ( if you're using an initrd)
		}
EOF

to the scripts in /etc/grub (I think this is correct, the update-grub
script redirects stdout to the config file it's writing).

With the symlinks there's no need to regenerate grub.cfg every time
you change the kernel, and you can keep multiple kernels around. 

I store each kernel in a directory in /boot, along with its config and
an initrd if needed. Keeps /boot relatively uncluttered and means I
can remove the kernel & everything associated with it with an rm -r
/{boot,lib/modules}/<kernel version>.

So my symlinks point to the directory and the config would contain:
	kernel /boot/test/bzImage ...
	initrd /boot/test/initrd.cgz

Where test is (currently):
lrwxrwxrwx 1 root root 6 Mar 22 15:47 /boot/test -> 3.19.2/

and /boot/3.19.2 is:
System.map  bzImage  config  version  vmlinux*

/root/bin/installkernel creates & populates the directory when I do
the 'make install' and also sets up the test symlink.

BTW, have you looked at linux/Documentation, there's a lot of useful
information in there, especially about the build process.

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

#14595

On 03/25/2015 04:59 PM, Jerry Peters wrote:
> ruben safir <dont@email.me> wrote:
>> On Mon, 23 Mar 2015 20:27:48 +0000, Jerry Peters wrote:
>>
>>
>>> If you're going to hack the scheduler you really need to get used to
>>> trying, and perhaps breaking things.
>>
>> yep, yep... that is exactly why I am asking about set ups.  
>>
>>
>>
> 
> Grub resolves the configuration at boot time unlike lilo which saves
> disk addresses when you run /sbin/lilo. That means that if you use
> symlinks they are resolved at *boot* time. So if you use symlinks in
> grub.cfg, and change the symlink, grub will see the new kernel when it
> boots. Thus you just change the symlink to point to your new kernel,
> no need for update-grub. In fact, installkernel can change the symlink
> for you when you do 'make install'.
> 
> So you either edit grub.cfg to add additional menuentries for your new
> kernels, or you can add something like:
> 
> cat <<-EOF
> 	menuentry {
> 		kernel ...
> 		initrd ... ( if you're using an initrd)
> 		}
> EOF
> 
> to the scripts in /etc/grub (I think this is correct, the update-grub
> script redirects stdout to the config file it's writing).
> 
> With the symlinks there's no need to regenerate grub.cfg every time
> you change the kernel, and you can keep multiple kernels around. 
> 
> I store each kernel in a directory in /boot, along with its config and
> an initrd if needed. Keeps /boot relatively uncluttered and means I
> can remove the kernel & everything associated with it with an rm -r
> /{boot,lib/modules}/<kernel version>.
> 
> So my symlinks point to the directory and the config would contain:
> 	kernel /boot/test/bzImage ...
> 	initrd /boot/test/initrd.cgz
> 
> Where test is (currently):
> lrwxrwxrwx 1 root root 6 Mar 22 15:47 /boot/test -> 3.19.2/
> 
> and /boot/3.19.2 is:
> System.map  bzImage  config  version  vmlinux*
> 
> /root/bin/installkernel creates & populates the directory when I do
> the 'make install' and also sets up the test symlink.
> 
> BTW, have you looked at linux/Documentation, there's a lot of useful
> information in there, especially about the build process.
> 
> 
> 
> 
Been pouring over ... and it has changed a bit over the years.

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

#14203

On Saturday 21 March 2015 21:19, Jerry Peters conveyed the following to 
comp.os.linux.misc...

> Without an initrd you need to specify the root device on the kernel
> caommand line as root=/dev/<something>, you can't use a label or uuid.

No, but if you have a GPT partition table, then you *can* use PARTUUID, 
and that is bound to be more consistent than using /dev/<something>.  

A PARTUUID is not the same thing as a UUID.  PARTUUID is the GPT ID of 
the partition itself, whereas UUID is the ID of the filesystem on that 
partition.


-- 
= Aragorn =

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

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

#14204

On Sun, 22 Mar 2015 00:07:31 +0100, Aragorn wrote:

> A PARTUUID is not the same thing as a UUID.  PARTUUID is the GPT ID of
> the partition itself, whereas UUID is the ID of the filesystem on that
> partiti

which can change from moment to moment I've learned.

I got it generally working at this point buy going over the configuration 
scripts that the Manjaro people use for their kernel upgrades.  It has 
left me with one perplexing problem though...

grub.cfg has a menue default for Linux 3.19.2 which doesn't work because 
it is not mounting the vfs

the manjaro 3.19.2, which is the same kernel that I compiled , that seems 
to work.  I've also lost may ability to cut and paste in the virtual 
system to the host, which is a PIA.

the only difference I see between the two entries is the loading of the 
initramfs disk.

Ruben



-- 
The Coin Hangout: http://www.coinhangout.com/home

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

#14205

On Sunday 22 March 2015 01:07, ruben safir conveyed the following to 
comp.os.linux.misc...

> On Sun, 22 Mar 2015 00:07:31 +0100, Aragorn wrote:
> 
>> A PARTUUID is not the same thing as a UUID.  PARTUUID is the GPT ID
>> of the partition itself, whereas UUID is the ID of the filesystem on
>> that partiti
> 
> which can change from moment to moment I've learned.

Not, neither the PARTUUID nor the filesystem UUID are variable, but for 
filesystem UUID support in your bootloader, you do need an initramfs ─ 
you do _not_ need an initramfs for PARTUUID support, but then you have 
to have a GUID partition table rather than the DOS-compatible MBR 
partition table.

The /dev/<something> designation however can indeed vary from boot to 
boot, depending on the order in which the devices are found.

> I got it generally working at this point buy going over the
> configuration scripts that the Manjaro people use for their kernel
> upgrades.  It has left me with one perplexing problem though...
> 
> grub.cfg has a menue default for Linux 3.19.2 which doesn't work
> because it is not mounting the vfs
> 
> the manjaro 3.19.2, which is the same kernel that I compiled , that
> seems to work.  I've also lost may ability to cut and paste in the
> virtual system to the host, which is a PIA.

That may be a function of the virtualization software you're using.

-- 
= Aragorn =

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

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

#14207

On Sun, 22 Mar 2015 01:13:45 +0100, Aragorn wrote:


>> which can change from moment to moment I've learned.
> 
> Not, neither the PARTUUID nor the filesystem UUID are variable,

they are when you resize them, or make them for that matter...

The name is completely random.  The naming scheme was designed by 
individuals who want to drive people away from their computers.

Ruben



-- 
The Coin Hangout: http://www.coinhangout.com/home

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

#14208

On Sunday 22 March 2015 04:11, ruben safir conveyed the following to 
comp.os.linux.misc...

> On Sun, 22 Mar 2015 01:13:45 +0100, Aragorn wrote:
> 
> 
>>> which can change from moment to moment I've learned.
>> 
>> Not, neither the PARTUUID nor the filesystem UUID are variable,
> 
> they are when you resize them, or make them for that matter...

The PARTUUID will only differ if you delete the partition and recreate 
it, not if you resize it.  The filesystem UUID will normally only differ 
if you reformat the partition.

> The name is completely random.

Yes, and that is exactly why it's unique [*], which is the idea.  What 
constitutes /dev/sda1 on one day may not be the same thing again on 
another day, depending on how the kernel enumerated the storage devices 
in the machine at boot-up.  If you however tell the kernel that the root 
partition is a partition with a given PARTUUID or a filesystem with a 
given UUID, then it'll use the correct partition/filesystem.

LABELs share roughly the same function in a more human-readable format, 
but the problem is that LABELs are not guaranteed to be unique.  LABELs 
are assigned by the system administrator, and it is always possible for 
the biological unit between the keyboard and the chair to screw up and 
use duplicate LABELs.

[*] Unless you clone a partition or filesystem, of course.

> The naming scheme was designed by individuals who want to drive people
> away from their computers.

That's not the point.  In terms of uniqueness and consistency at 
mounting the right filesystems at the right places, UUID and PARTUUID 
run rings around the old /dev/<something> designation with a radius of 
one lightyear across.

-- 
= Aragorn =

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

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

#14210

On Sun, 22 Mar 2015 04:20:54 +0100, Aragorn wrote:

>> The naming scheme was designed by individuals who want to drive people
>> away from their computers.
> 
> That's not the point.

my dear friend - that is the only point.  All the other ones you mention 
are irrelevent.  /dev/sda1 MEANS something to the humans

UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 / reiserfs defaults 0 1

is meaningless.

With regard to that, look at this example of what happens when people are 
confronted with such meaningless use of nomenclature


https://www.youtube.com/watch?v=7IgF6_jVaj8


-- 
The Coin Hangout: http://www.coinhangout.com/home

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

#14213

ruben safir <dont@email.me> wrote:
> On Sun, 22 Mar 2015 04:20:54 +0100, Aragorn wrote:

> >> The naming scheme was designed by individuals who want to drive people
> >> away from their computers.
> > 
> > That's not the point.

> my dear friend - that is the only point.  All the other ones you mention 
> are irrelevent.  /dev/sda1 MEANS something to the humans

Yes, it looks meaningful, at first glance.  But what you will learn as
you get to digging into the kernel internals is that while it looks
meaningful, it is not stable, because "sda1" is not permanently linked
to any one specific filesystem on any one specific piece of hardware. 
It is "1" only because it was the first disk partition assigned a
number by the kernel drivers.  So any stability it has is only because
if nothing changes in the hardware or software then the order in which
the hardware interfaces are assiged numbers remains stable.

What can, and will, happen is if you have plural physical disks, on
different hardware interfaces, and then you add one more disk, change
your motherboard, or change your kernal version, you will sometimes
encounter the result that the physical device partition that was sda1
is now assigned sdc3.  And your system will no longer boot because what
is now sda1 is not your root partition, and things come to a halt.

> UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 / reiserfs defaults 0 1
> is meaningless.

Yes, to the humans who did not not set it up, yes, it is meaningless. 
But it has the advantage of stability.  Because the UUID is actually
stored in the filesystem that is stored on the partition that is stored
on the physical hardware.  Because it is stored in the filesystem
itself, it no longer matters if the disk is named sda1 or sdb2 or sde5
by the kernel drivers, the filesystem that is the root filesystem will
always be mounted at the right spot.

This makes it safe to add additonal drives, upgrade to a new
motherboard, or upgrade to a new kernel. because doing any of those
things no longer has the risk of causing the sd?? numbers to be
randomly scrambled.

If you want to see who the sd?? devices are assigned to the UUID's, you
can look into the /dev/disk/by-* directories.  The by-uuid subdirectory
will tell you which UUID's is assigned which sd?? value.

Note that "plural disks" also has risk for someone with only a single
hard drive who happens to forgetfully leave a flash USB stick plugged
in.  Depending upon just exactly how their system behaves (kernel
drivers and hardware wise), that USB stick could become sda1 during a
reboot, pushing their old root partition over to sdb1, resulting in a
system that does not boot until they unplug the USB stick.

If they happen to have plural physical disks, then the USB stick, on
reboot, might become sdc1, pushing their old sdc1 to sdd1, and creating
problems of extra disks not being mounted where they belong (if at
all).

eSata interfaces present similar potential issues.

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

#14216

On Sunday 22 March 2015 14:19, ruben safir conveyed the following to 
comp.os.linux.misc...

> On Sun, 22 Mar 2015 04:20:54 +0100, Aragorn wrote:
> 
>>> The naming scheme was designed by individuals who want to drive
>>> people away from their computers.
>> 
>> That's not the point.
> 
> my dear friend - that is the only point.  All the other ones you
> mention are irrelevent.  /dev/sda1 MEANS something to the humans

No, that's the irrelevant part.  Your contention was that PARTUUIDs and 
UUIDs are not guaranteed to consistent, while in reality, it is 
/dev/sda1 (or any other such designation) which is inconsistent, and 
particularly so in machines which have more than one hard disk 
installed.

> UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 / reiserfs defaults 0 1
> 
> is meaningless.

Then use a LABEL.  Example follows.

   # Device         Mountpoint    FSTYPE   OPTIONS    DUMP  FSCK

   LABEL=rootfs     /             xfs      defaults   0     0


Nevertheless, the above is moot as this is a sample /etc/fstab entry.  
Telling the kernel what device to mount as the root filesystem in GRUB 
is an entirely different matter.  The kernel does not recognize UUIDs or 
LABELs, so if you want to provide for a persistent device name in GRUB ─ 
and again, /dev/sda1 is not guaranteed to be persistent ─ you'll need to 
either have an initramfs created with dracut (which will include the 
tools necessary to recognize and mount devices based upon a UUID or a 
LABEL) or if you don't want an initramfs then you need a GPT 
partitioning scheme and use the PARTUUID.

It's that simple.


-- 
= Aragorn =

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

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

#14215

Aragorn <thorongil@telenet.be.invalid> wrote:
> On Sunday 22 March 2015 04:11, ruben safir conveyed the following to 
> comp.os.linux.misc...
> 
>> On Sun, 22 Mar 2015 01:13:45 +0100, Aragorn wrote:
>> 
>> 
>>>> which can change from moment to moment I've learned.
>>> 
>>> Not, neither the PARTUUID nor the filesystem UUID are variable,
>> 
>> they are when you resize them, or make them for that matter...
> 
> The PARTUUID will only differ if you delete the partition and recreate 
> it, not if you resize it.  The filesystem UUID will normally only differ 
> if you reformat the partition.
> 
>> The name is completely random.
> 
> Yes, and that is exactly why it's unique [*], which is the idea.  What 
> constitutes /dev/sda1 on one day may not be the same thing again on 
> another day, depending on how the kernel enumerated the storage devices 
> in the machine at boot-up.  If you however tell the kernel that the root 
> partition is a partition with a given PARTUUID or a filesystem with a 
> given UUID, then it'll use the correct partition/filesystem.
> 
> LABELs share roughly the same function in a more human-readable format, 
> but the problem is that LABELs are not guaranteed to be unique.  LABELs 
> are assigned by the system administrator, and it is always possible for 
> the biological unit between the keyboard and the chair to screw up and 
> use duplicate LABELs.

But they're *readable*. I know what a label of 'home' means
immediately, I don't need to try to guess. So you need to be
*careful*, so what? 

> 
> [*] Unless you clone a partition or filesystem, of course.
> 
>> The naming scheme was designed by individuals who want to drive people
>> away from their computers.
> 
> That's not the point.  In terms of uniqueness and consistency at 
> mounting the right filesystems at the right places, UUID and PARTUUID 
> run rings around the old /dev/<something> designation with a radius of 
> one lightyear across.
> 
As does being a bit careful and using labels, with the added advantage
that you can tell what the partition is for, assuming you're at all
consistent in labelling them.

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

#14217

On Sunday 22 March 2015 21:13, Jerry Peters conveyed the following to 
comp.os.linux.misc...

> Aragorn <thorongil@telenet.be.invalid> wrote:
>
>> On Sunday 22 March 2015 04:11, ruben safir conveyed the following to
>> comp.os.linux.misc...
>> 
>>> On Sun, 22 Mar 2015 01:13:45 +0100, Aragorn wrote:
>>> 
>>>> [...] neither the PARTUUID nor the filesystem UUID are variable,
>>> 
>>> they are when you resize them, or make them for that matter...
>> 
>> The PARTUUID will only differ if you delete the partition and
>> recreate it, not if you resize it.  The filesystem UUID will normally
>> only differ if you reformat the partition.
>> 
>>> The name is completely random.
>> 
>> Yes, and that is exactly why it's unique [*], which is the idea. 
>> What constitutes /dev/sda1 on one day may not be the same thing again
>> on another day, depending on how the kernel enumerated the storage
>> devices in the machine at boot-up.  If you however tell the kernel
>> that the root partition is a partition with a given PARTUUID or a
>> filesystem with a given UUID, then it'll use the correct
>> partition/filesystem.
>> 
>> LABELs share roughly the same function in a more human-readable
>> format, but the problem is that LABELs are not guaranteed to be
>> unique.  LABELs are assigned by the system administrator, and it is
>> always possible for the biological unit between the keyboard and the
>> chair to screw up and use duplicate LABELs.
> 
> But they're *readable*. I know what a label of 'home' means
> immediately, I don't need to try to guess. So you need to be
> *careful*, so what?

I'm afraid you're missing the point.  

The kernel entry in GRUB can only list the root device by way of a LABEL 
(or a UUID) if the kernel utilizes an initramfs created with dracut ─ 
which will add the necessary tools for that to the initramfs ─ because 
the kernel itself doesn't understand LABELs or UUIDs.  

The point is that the OP _doesn't want to use_ an initramfs.

-- 
= Aragorn =

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

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

#14218

On 2015-03-21, ruben safir <dont@email.me> wrote:
> On Wed, 18 Mar 2015 03:35:23 +0000, Chick Tower wrote:
>> In my limited experience (and none compiling kernels), GRUB2 is pretty
>> good at finding what exists that can be booted.  After compilng your
>> kernels, and creating any initrds needed, run update-grub, if I recall
>> correctly, and it should add your new kernel to the boot options in
>> grub.cfg.
>
> How do you create the initrds?  They actually using initramfs FWIW

I don't know how to do it in Manjaro.  Sorry.  The only distro I've
created an initrd in is Slackware, where it's pretty simple.  Perhaps,
as others have suggested, you should forego the initrd and make sure
your kernel has everything it needs.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

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

#14219

On Monday 23 March 2015 05:02, Chick Tower conveyed the following to 
comp.os.linux.misc...

> On 2015-03-21, ruben safir <dont@email.me> wrote:
>
>> How do you create the initrds?  They actually using initramfs FWIW
> 
> I don't know how to do it in Manjaro.  Sorry.  The only distro I've
> created an initrd in is Slackware, where it's pretty simple.  Perhaps,
> as others have suggested, you should forego the initrd and make sure
> your kernel has everything it needs.

 $ man dracut

... will tell you (and the OP) how to create an initramfs, which is what
all modern systems use, instead of the now deprecated initrd. ;-)

-- 
= Aragorn =

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

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

#14504

On Mon, 23 Mar 2015 05:13:05 +0100, Aragorn wrote:

> On Monday 23 March 2015 05:02, Chick Tower conveyed the following to
> comp.os.linux.misc...
> 
>> On 2015-03-21, ruben safir <dont@email.me> wrote:
>>
>>> How do you create the initrds?  They actually using initramfs FWIW
>> 
>> I don't know how to do it in Manjaro.  Sorry.  The only distro I've
>> created an initrd in is Slackware, where it's pretty simple.  Perhaps,
>> as others have suggested, you should forego the initrd and make sure
>> your kernel has everything it needs.
> 
>  $ man dracut
> 
> ... will tell you (and the OP) how to create an initramfs, which is what
> all modern systems use, instead of the now deprecated initrd. ;-)

check on that... that works

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

#14113

On Mon, 16 Mar 2015 22:04:47 -0500, Chester A. Arthur wrote:

> The grub2 documentation is slim and opaque.

to say the least.  I was tempted to just hack into the config file 
directly, but the subdirectory under /etc/ seemed to be a better place to 
attack the problem.  complicating it more is that each distro seems to 
have nonstandard tools to handle the grub config.  It seesm to be tightly 
tied into the branding.


Ruben


-- 
The Coin Hangout: http://www.coinhangout.com/home

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

#14116

On 03/16/2015 11:04 PM, Chester A. Arthur wrote:
> On Sun, 15 Mar 2015 21:14:47 +0000, ruben wrote:
>  
>> I think I'm getting hung up right now on grub2.  I've managed to avoid
>> it until now.  Any advice?
> 
> The grub2 documentation is slim and opaque. Just install
> 'grub-customizer' (it's a GUI program) and let it handle the
> details of setting up grub. 


Hmmm - maybe very practical advice...


The only commands you need then
> are 'sudo grub-install /dev/sda' (or whatever disk you are
> using for your boot-disk), and 'sudo update-grub' which will
> search all disks & partitions for kernels and build a grub menu.
> You've seen the first command at install, and you've seen the
> second if your release has ever updated its kernel.
> 

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web