Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Boot thoughts and chroot / switch_root / pivot_root
846 views
Skip to first unread message
Peter Chant
Jan 21, 2014, 4:57:42 PM1/21/14
to
Dear AOLS,
a question. Likely about to install a new system.
1. Dislike and don't get on with initrd.
2. Like to use btrfs but can't seem to boot directly from lilo etc.
3. Tend to create a small partition with a minimal install for the odd
maintenance purpose.
4. Usually install kernel and lilo on the maintenance partition and then
set up an additional partition I normally use.
Reasonably happy with 3 & 4, but wonder if I can tweek it a little.
Thought. My maintenance partition is almost a initial ram disk. Could
I set up a script within the maintenance partition and supply a
parameter to the kernel so that I could run the script on boot? I.e.
add a parameter to the kernel in my lilo config so that would boot to
the maintenance partition but instead of running init it would run the
script, mount the final root and switch root? Alternatively could I get
init to run the script from inittab? I.e. could I set rc.S to be a
special script in certain cases?
# System initialization (runs when system boots). - Normal
si:S:sysinit:/etc/rc.d/rc.S
# System initialization switch root - only runs when specified by
#argument passed to kernel (somehow)
si:S:sysinit:/etc/rc.d/peteSwitchRootScript
I note that there is an init script in the root of some initial ram
disks that I have seen. What happens if I put one in the root of a
regular filesystem?
Pete
a question. Likely about to install a new system.
1. Dislike and don't get on with initrd.
2. Like to use btrfs but can't seem to boot directly from lilo etc.
3. Tend to create a small partition with a minimal install for the odd
maintenance purpose.
4. Usually install kernel and lilo on the maintenance partition and then
set up an additional partition I normally use.
Reasonably happy with 3 & 4, but wonder if I can tweek it a little.
Thought. My maintenance partition is almost a initial ram disk. Could
I set up a script within the maintenance partition and supply a
parameter to the kernel so that I could run the script on boot? I.e.
add a parameter to the kernel in my lilo config so that would boot to
the maintenance partition but instead of running init it would run the
script, mount the final root and switch root? Alternatively could I get
init to run the script from inittab? I.e. could I set rc.S to be a
special script in certain cases?
# System initialization (runs when system boots). - Normal
si:S:sysinit:/etc/rc.d/rc.S
# System initialization switch root - only runs when specified by
#argument passed to kernel (somehow)
si:S:sysinit:/etc/rc.d/peteSwitchRootScript
I note that there is an init script in the root of some initial ram
disks that I have seen. What happens if I put one in the root of a
regular filesystem?
Pete
Aragorn
Jan 21, 2014, 5:24:58 PM1/21/14
to
On Tuesday 21 January 2014 22:57, Peter Chant conveyed the following to
alt.os.linux.slackware...
> Dear AOLS,
>
> a question. Likely about to install a new system.
>
> 1. Dislike and don't get on with initrd.
Copy that.
> 2. Like to use btrfs but can't seem to boot directly from lilo etc.
You can use something else there. I myself always maintain a separate
/boot partition anyway. I tend to favor xfs, but if you're not familiar
with it, then just use ext2/3/4 for /boot. Or reiserfs, even.
> 3. Tend to create a small partition with a minimal install for the odd
> maintenance purpose.
Copy that.
> 4. Usually install kernel and lilo on the maintenance partition and
> then set up an additional partition I normally use.
I would propose something like...
- /dev/sda1 = /boot
- /dev/sda2 = your maintenance partition's root filesystem
- /dev/sda3 = your real root filesystem
> Reasonably happy with 3 & 4, but wonder if I can tweek it a little.
>
> Thought. My maintenance partition is almost a initial ram disk.
> Could I set up a script within the maintenance partition and supply a
> parameter to the kernel so that I could run the script on boot?
> I.e.
> add a parameter to the kernel in my lilo config so that would boot to
> the maintenance partition but instead of running init it would run the
> script, mount the final root and switch root?
Yes, that is possible. Add the parameter
init=/path/to/the/script/my_init
... (where "my_init" is the name of your script) to your kernel's
"append" line in /etc/lilo.conf.
> Alternatively could I get init to run the script from inittab? I.e.
> could I set rc.S to be a special script in certain cases?
You could do that, but I would be careful because of any udev
invocations and possibly the mounting of /proc and /sys _before_ the
chroot step.
In other words, you will want to trap the init call as early as possible
when userspace comes up, and if /proc and /sys already get mounted
before your script completes - and hopefully your script won't depend on
their presence - then you'll need to make sure they get bind-mounted
into the chroot environment _before_ you issue the chroot.
Also make sure that the last command in your script is one that invokes
/sbin/init (in the chroot environment, after the chroot itself) and that
you allow the script to terminate properly, or otherwise put, that you
daemonize /sbin/init by putting an ampersand behind it, before your
"exit" command.
> # System initialization (runs when system boots). - Normal
> si:S:sysinit:/etc/rc.d/rc.S
>
> # System initialization switch root - only runs when specified by
> #argument passed to kernel (somehow)
> si:S:sysinit:/etc/rc.d/peteSwitchRootScript
>
> I note that there is an init script in the root of some initial ram
> disks that I have seen. What happens if I put one in the root of a
> regular filesystem?
It's a different thing. The one in the initramfs is invoked by the
mechanism of the initramfs itself. Anything else [*] needs to be
invoked via a kernel parameter, because the kernel by default will run
/sbin/init if nothing else has been specified and when there is no
initramfs - the initramfs will invoke /sbin/init itself after the
switch_root command, which is specific to the initramfs environment.
[*] You could for instance also use "init=/bin/bash" in the "append"
line to simply boot up to a root shell, but this is typically
deprecated (except for real emergencies) because it will not
initialize anything else, so there is no $PATH, for instance.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
alt.os.linux.slackware...
> Dear AOLS,
>
> a question. Likely about to install a new system.
>
> 1. Dislike and don't get on with initrd.
> 2. Like to use btrfs but can't seem to boot directly from lilo etc.
/boot partition anyway. I tend to favor xfs, but if you're not familiar
with it, then just use ext2/3/4 for /boot. Or reiserfs, even.
> 3. Tend to create a small partition with a minimal install for the odd
> maintenance purpose.
> 4. Usually install kernel and lilo on the maintenance partition and
> then set up an additional partition I normally use.
- /dev/sda1 = /boot
- /dev/sda2 = your maintenance partition's root filesystem
- /dev/sda3 = your real root filesystem
> Reasonably happy with 3 & 4, but wonder if I can tweek it a little.
>
> Thought. My maintenance partition is almost a initial ram disk.
> Could I set up a script within the maintenance partition and supply a
> parameter to the kernel so that I could run the script on boot?
> I.e.
> add a parameter to the kernel in my lilo config so that would boot to
> the maintenance partition but instead of running init it would run the
> script, mount the final root and switch root?
init=/path/to/the/script/my_init
... (where "my_init" is the name of your script) to your kernel's
"append" line in /etc/lilo.conf.
> Alternatively could I get init to run the script from inittab? I.e.
> could I set rc.S to be a special script in certain cases?
invocations and possibly the mounting of /proc and /sys _before_ the
chroot step.
In other words, you will want to trap the init call as early as possible
when userspace comes up, and if /proc and /sys already get mounted
before your script completes - and hopefully your script won't depend on
their presence - then you'll need to make sure they get bind-mounted
into the chroot environment _before_ you issue the chroot.
Also make sure that the last command in your script is one that invokes
/sbin/init (in the chroot environment, after the chroot itself) and that
you allow the script to terminate properly, or otherwise put, that you
daemonize /sbin/init by putting an ampersand behind it, before your
"exit" command.
> # System initialization (runs when system boots). - Normal
> si:S:sysinit:/etc/rc.d/rc.S
>
> # System initialization switch root - only runs when specified by
> #argument passed to kernel (somehow)
> si:S:sysinit:/etc/rc.d/peteSwitchRootScript
>
> I note that there is an init script in the root of some initial ram
> disks that I have seen. What happens if I put one in the root of a
> regular filesystem?
mechanism of the initramfs itself. Anything else [*] needs to be
invoked via a kernel parameter, because the kernel by default will run
/sbin/init if nothing else has been specified and when there is no
initramfs - the initramfs will invoke /sbin/init itself after the
switch_root command, which is specific to the initramfs environment.
[*] You could for instance also use "init=/bin/bash" in the "append"
line to simply boot up to a root shell, but this is typically
deprecated (except for real emergencies) because it will not
initialize anything else, so there is no $PATH, for instance.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
Aragorn
Jan 21, 2014, 5:30:29 PM1/21/14
to
On Tuesday 21 January 2014 23:24, Aragorn conveyed the following to
>> [...]
There are a few more things to look out for, e.g. the fact that a kernel
which boots without an initramfs/initrd won't have support for partition
LABELs or UUIDs in /etc/fstab, or at the kernel command line (i.e. the
"append" line for your kernel stanza in /etc/lilo.conf).
alt.os.linux.slackware...
> On Tuesday 21 January 2014 22:57, Peter Chant conveyed the following
> to alt.os.linux.slackware...
>
>> [...]
> On Tuesday 21 January 2014 22:57, Peter Chant conveyed the following
> to alt.os.linux.slackware...
>
>> I note that there is an init script in the root of some initial ram
>> disks that I have seen. What happens if I put one in the root of a
>> regular filesystem?
>
> It's a different thing. The one in the initramfs is invoked by the
> mechanism of the initramfs itself. Anything else [*] needs to be
> invoked via a kernel parameter, because the kernel by default will run
> /sbin/init if nothing else has been specified and when there is no
> initramfs - the initramfs will invoke /sbin/init itself after the
> switch_root command, which is specific to the initramfs environment.
>
>
> [*] You could for instance also use "init=/bin/bash" in the "append"
> line to simply boot up to a root shell, but this is typically
> deprecated (except for real emergencies) because it will not
> initialize anything else, so there is no $PATH, for instance.
*Addendum:*
>> disks that I have seen. What happens if I put one in the root of a
>> regular filesystem?
>
> It's a different thing. The one in the initramfs is invoked by the
> mechanism of the initramfs itself. Anything else [*] needs to be
> invoked via a kernel parameter, because the kernel by default will run
> /sbin/init if nothing else has been specified and when there is no
> initramfs - the initramfs will invoke /sbin/init itself after the
> switch_root command, which is specific to the initramfs environment.
>
>
> [*] You could for instance also use "init=/bin/bash" in the "append"
> line to simply boot up to a root shell, but this is typically
> deprecated (except for real emergencies) because it will not
> initialize anything else, so there is no $PATH, for instance.
There are a few more things to look out for, e.g. the fact that a kernel
which boots without an initramfs/initrd won't have support for partition
LABELs or UUIDs in /etc/fstab, or at the kernel command line (i.e. the
"append" line for your kernel stanza in /etc/lilo.conf).
Peter Chant
Jan 21, 2014, 6:15:59 PM1/21/14
to
On 01/21/2014 10:24 PM, Aragorn wrote:
> On Tuesday 21 January 2014 22:57, Peter Chant conveyed the following to
> alt.os.linux.slackware...
>
>> Dear AOLS,
>>
>> a question. Likely about to install a new system.
>>
>> 1. Dislike and don't get on with initrd.
>
> Copy that.
>
>> 2. Like to use btrfs but can't seem to boot directly from lilo etc.
>
> You can use something else there. I myself always maintain a separate
> /boot partition anyway. I tend to favor xfs, but if you're not familiar
> with it, then just use ext2/3/4 for /boot. Or reiserfs, even.
I sort of dispense with a separate /boot, but in effect what I use is:
> On Tuesday 21 January 2014 22:57, Peter Chant conveyed the following to
> alt.os.linux.slackware...
>
>> Dear AOLS,
>>
>> a question. Likely about to install a new system.
>>
>> 1. Dislike and don't get on with initrd.
>
> Copy that.
>
>> 2. Like to use btrfs but can't seem to boot directly from lilo etc.
>
> You can use something else there. I myself always maintain a separate
> /boot partition anyway. I tend to favor xfs, but if you're not familiar
> with it, then just use ext2/3/4 for /boot. Or reiserfs, even.
<maintenence root>/boot
If I build a new kernel, which is not often, I have to remember to copy
over the relent bits to that boot directory on the maintenance file
system, put the kernel in place, boot to the maintenance system and
update lilo.
I know that sounds more complex than necessary, but as maintenance root
is not used except in rare cases and is rarely touched I find it is a
nice place to put lilo and kernel stuff as it is not messed around with.
I can utterly hose the rest of the system without loosing lilo etc.
>> 4. Usually install kernel and lilo on the maintenance partition and
>> then set up an additional partition I normally use.
>
> I would propose something like...
>
> - /dev/sda1 = /boot
> - /dev/sda2 = your maintenance partition's root filesystem
> - /dev/sda3 = your real root filesystem
>
/dev/sda1 swap
/dev/sda2 maintenance, ext4
/dev/sda3 btrfs pool for root, home subvolumes etc.
as the working /boot is within maintenance effectively. However, this
moves from a practical to a religious argument very rapidly...
>
>> Reasonably happy with 3 & 4, but wonder if I can tweek it a little.
>>
>> Thought. My maintenance partition is almost a initial ram disk.
>> Could I set up a script within the maintenance partition and supply a
>> parameter to the kernel so that I could run the script on boot?
>> I.e.
>> add a parameter to the kernel in my lilo config so that would boot to
>> the maintenance partition but instead of running init it would run the
>> script, mount the final root and switch root?
>
> Yes, that is possible. Add the parameter
>
> init=/path/to/the/script/my_init
>
> ... (where "my_init" is the name of your script) to your kernel's
> "append" line in /etc/lilo.conf.
script with #/bin/sh as its shell then fantastic.
I'm thinking along the lines:
. . . . . .
#!/bin/sh
mount /dev/sda3 /mnt
defaults,autodefrag,inode_cache,noatime,compress=lzo,subvol=_root_sl14.1
0 0
#Any other stuff that is nice to do here.
#But minimise if possible.
exec switch_root /newroot /sbin/init
. . . . .
So I presume after this that the system is none the wiser to these boot
shenanigans and all will be well in the world.
>
>> Alternatively could I get init to run the script from inittab? I.e.
>> could I set rc.S to be a special script in certain cases?
>
> You could do that, but I would be careful because of any udev
> invocations and possibly the mounting of /proc and /sys _before_ the
> chroot step.
I did wonder if using runlevel 5 and cutting down the initialisation for
that runlevel as much as possible. However, if init=/myscript works it
sound better.
>
> In other words, you will want to trap the init call as early as possible
> when userspace comes up, and if /proc and /sys already get mounted
> before your script completes - and hopefully your script won't depend on
> their presence - then you'll need to make sure they get bind-mounted
> into the chroot environment _before_ you issue the chroot.
experience.
>
> Also make sure that the last command in your script is one that invokes
> /sbin/init (in the chroot environment, after the chroot itself) and that
> you allow the script to terminate properly, or otherwise put, that you
> daemonize /sbin/init by putting an ampersand behind it, before your
> "exit" command.
>
>> # System initialization (runs when system boots). - Normal
>> si:S:sysinit:/etc/rc.d/rc.S
>>
>> # System initialization switch root - only runs when specified by
>> #argument passed to kernel (somehow)
>> si:S:sysinit:/etc/rc.d/peteSwitchRootScript
>>
>> I note that there is an init script in the root of some initial ram
>> disks that I have seen. What happens if I put one in the root of a
>> regular filesystem?
>
> It's a different thing. The one in the initramfs is invoked by the
> mechanism of the initramfs itself. Anything else [*] needs to be
> invoked via a kernel parameter, because the kernel by default will run
> /sbin/init if nothing else has been specified and when there is no
> initramfs - the initramfs will invoke /sbin/init itself after the
> switch_root command, which is specific to the initramfs environment.
>
>
> [*] You could for instance also use "init=/bin/bash" in the "append"
> line to simply boot up to a root shell, but this is typically
> deprecated (except for real emergencies) because it will not
> initialize anything else, so there is no $PATH, for instance.
>
in a system so limited all I can do is reboot and pray!
Thanks for that, appreciated.
Pete
Peter Chant
Jan 21, 2014, 6:20:38 PM1/21/14
to
On 01/21/2014 10:30 PM, Aragorn wrote:
> There are a few more things to look out for, e.g. the fact that a kernel
> which boots without an initramfs/initrd won't have support for partition
> LABELs or UUIDs in /etc/fstab, or at the kernel command line (i.e. the
> "append" line for your kernel stanza in /etc/lilo.conf).
Hmm, not using an initramfs now but this works in my fstab:
> There are a few more things to look out for, e.g. the fact that a kernel
> which boots without an initramfs/initrd won't have support for partition
> LABELs or UUIDs in /etc/fstab, or at the kernel command line (i.e. the
> "append" line for your kernel stanza in /etc/lilo.conf).
#Root
UUID=6496aabd-d6aa-49e0-96ca-e49c316edd8e / btrfs
autodefrag,s
sd,discard,noatime,defaults,subvol=_root_sl14.0,compress=lzo 0 0
However, when using the device mount option with btrfs partitions the
device option seemed not to work with uuid. That said, I find at
present that I don't need that parameter.
Generally I find uuid's messy as I have to cut and paste them but they
are the solution to disks that won't stay on the correct device.
Pete
Aragorn
Jan 21, 2014, 6:36:26 PM1/21/14
to
On Wednesday 22 January 2014 00:20, Peter Chant conveyed the following
to alt.os.linux.slackware...
Well, you could also use LABELs, but of course, then you would have to
make sure that they are unique. :-)
to alt.os.linux.slackware...
make sure that they are unique. :-)
Aragorn
Jan 21, 2014, 6:58:57 PM1/21/14
to
On Wednesday 22 January 2014 00:15, Peter Chant conveyed the following
operation - is a better approach, in my humble opinion.
> [...]
because some partitioning tools don't like that. I remember that cfdisk
used to complain about that when I did that too, and it stopped
complaining when I put /boot first.
>>> Thought. My maintenance partition is almost a initial ram disk.
>>> Could I set up a script within the maintenance partition and supply
>>> a parameter to the kernel so that I could run the script on boot?
>>> I.e.
>>> add a parameter to the kernel in my lilo config so that would boot
>>> to the maintenance partition but instead of running init it would
>>> run the script, mount the final root and switch root?
>>
>> Yes, that is possible. Add the parameter
>>
>> init=/path/to/the/script/my_init
>>
>> ... (where "my_init" is the name of your script) to your kernel's
>> "append" line in /etc/lilo.conf.
>
> Cool. Man pages or whatever said init was a _binary_. If it is a
> script with #/bin/sh as its shell then fantastic.
No, /sbin/init *is* indeed a binary. But the kernel allows for an
alternative init specification. Using a pre-init script - which /may/
need to invoke busybox as its shell - is a trick I picked up from the
Gentoo mailing lists, because of screwups by Poettering and Sievers
which broke the booting with a separate /usr filesystem without that
there is an initramfs.
So I do think you need busybox for that, but don't pin me down on it.
In theory you should be able to do with bash as well, but bear in mind
that no environment has been declared yet at that point, so you would
need to specify the full path to the executables you invoke from within
your script, e.g. /bin/mount.
> I'm thinking along the lines:
> . . . . . .
> #!/bin/sh
>
> mount /dev/sda3 /mnt
>
defaults,autodefrag,inode_cache,noatime,compress=lzo,subvol=_root_sl14.1
> 0 0
That would then have to be /bin/mount. There is no $PATH declared yet
at that point in time, and it's a non-interactive non-login shell.
> #Any other stuff that is nice to do here.
> #But minimise if possible.
>
> exec switch_root /newroot /sbin/init
Yes, my bad. I wrote that you had to deamonize that and then exit the
script, but I was wrong. You have to use exec, indeed, so as to make
/sbin/init PID 1.
> So I presume after this that the system is none the wiser to these
> boot shenanigans and all will be well in the world.
It should, yes.
>>> Alternatively could I get init to run the script from inittab? I.e.
>>> could I set rc.S to be a special script in certain cases?
>>
>> You could do that, but I would be careful because of any udev
>> invocations and possibly the mounting of /proc and /sys _before_ the
>> chroot step.
>
> Oooh. Don't like the sound of that. Sounds less robust than above.
I forgot to add /dev to that list. You definitely need that one mounted
too. In a normal system, this can be taken care of at any stage in the
boot process, depending on what kernel you use. With a very recent
kernel, it shouldn't be a problem because then it's mounted by the
kernel itself.
> I did wonder if using runlevel 5 and cutting down the initialisation
> for that runlevel as much as possible. However, if init=/myscript
> works it sound better.
That /should/ work, yes. The kernel does accept an "init=" parameter.
>> In other words, you will want to trap the init call as early as
>> possible when userspace comes up, and if /proc and /sys already get
>> mounted before your script completes - and hopefully your script
>> won't depend on their presence - then you'll need to make sure they
>> get bind-mounted into the chroot environment _before_ you issue the
>> chroot.
>
> I think that switch_root moves them across - but I don't speak from
> experience.
Well, I don't know, really. That's why I wrote the above as a concern.
>> Also make sure that the last command in your script is one that
>> invokes /sbin/init (in the chroot environment, after the chroot
>> itself) and that you allow the script to terminate properly, or
>> otherwise put, that you daemonize /sbin/init by putting an ampersand
>> behind it, before your "exit" command.
Discard the above paragraph, this is wrong. You need to exec /sbin/init
in order to give it PID 1.
>>> # System initialization (runs when system boots). - Normal
>>> si:S:sysinit:/etc/rc.d/rc.S
>>>
>>> # System initialization switch root - only runs when specified by
>>> #argument passed to kernel (somehow)
>>> si:S:sysinit:/etc/rc.d/peteSwitchRootScript
>>>
>>> I note that there is an init script in the root of some initial ram
>>> disks that I have seen. What happens if I put one in the root of a
>>> regular filesystem?
>>
>> It's a different thing. The one in the initramfs is invoked by the
>> mechanism of the initramfs itself. Anything else [*] needs to be
>> invoked via a kernel parameter, because the kernel by default will
>> run /sbin/init if nothing else has been specified and when there is
>> no initramfs - the initramfs will invoke /sbin/init itself after the
>> switch_root command, which is specific to the initramfs environment.
>
> So /init is specific to initramfs.
Well, it does the same thing as what you're doing, really, except that
at that stage, the initramfs is still mounted as the root filesystem,
and thus the kernel will look for /sbin/init in the initramfs. And that
particular init is a script which uses busybox to execute a number of
commands, such as mounting the real root filesystem and possibly setting
up /proc and /sys, and possibly also launching udev.
I'm not sure on the latter anymore because there has been a change in
"recent" kernels. Originally /dev was populated with static nodes which
were on-disk and which had been created using mknod. Then, when udev
came around - let's skip devfs and the 2.4 kernel generation for
convenience's sake - /dev still contained some static on-disk nodes, but
was then overlaid with a mount from udev. Then, /dev was empty and udev
did everything, launched from the initramfs. But there were problems on
account of firmware loading by udev etc, so eventually /dev was now
populated from within the kernel itself, via devtmpfs, instead of a
regular tmpfs. Modern kernels normally use devtmpfs, and then kernel
will then automount /dev and populate it, before userspace is initiated,
and thus before udev starts running.
Mind you that the booting of udev is normally also taken care of from
within the initrd/initramfs, so you'll have to keep that into account.
And that is also how you have to mount /proc and /sys - /dev will be
mounted by the kernel itself - before you run anything else.
>> [*] You could for instance also use "init=/bin/bash" in the "append"
>> line to simply boot up to a root shell, but this is typically
>> deprecated (except for real emergencies) because it will not
>> initialize anything else, so there is no $PATH, for instance.
>
> Yep, been there with bad disk errors in the past. Seem to often end
> up in a system so limited all I can do is reboot and pray!
Well, it /is/ a very minimal system that you get then. Single-user
maintenance mode and no environment set, and nothing mounted but the
root filesystem itself. Not even udev running.
> Thanks for that, appreciated.
Welcome. ;-)
to alt.os.linux.slackware...
> On 01/21/2014 10:24 PM, Aragorn wrote:
>
>> On Tuesday 21 January 2014 22:57, Peter Chant conveyed the following
>> to alt.os.linux.slackware...
>>
>>> [...] Likely about to install a new system.
> On 01/21/2014 10:24 PM, Aragorn wrote:
>
>> On Tuesday 21 January 2014 22:57, Peter Chant conveyed the following
>> to alt.os.linux.slackware...
>>
>>>
>>> 1. Dislike and don't get on with initrd.
>>
>> Copy that.
>>
>>> 2. Like to use btrfs but can't seem to boot directly from lilo etc.
>>
>> You can use something else there. I myself always maintain a
>> separate /boot partition anyway. I tend to favor xfs, but if you're
>> not familiar with it, then just use ext2/3/4 for /boot. Or reiserfs,
>> even.
>
> I sort of dispense with a separate /boot, but in effect what I use is:
> <maintenence root>/boot
>
> If I build a new kernel, which is not often, I have to remember to
> copy over the relent bits to that boot directory on the maintenance
> file system, put the kernel in place, boot to the maintenance system
> and update lilo.
Well, that's why having a common /boot - mounted read-only during normal
>>> 1. Dislike and don't get on with initrd.
>>
>> Copy that.
>>
>>> 2. Like to use btrfs but can't seem to boot directly from lilo etc.
>>
>> You can use something else there. I myself always maintain a
>> separate /boot partition anyway. I tend to favor xfs, but if you're
>> not familiar with it, then just use ext2/3/4 for /boot. Or reiserfs,
>> even.
>
> I sort of dispense with a separate /boot, but in effect what I use is:
> <maintenence root>/boot
>
> If I build a new kernel, which is not often, I have to remember to
> copy over the relent bits to that boot directory on the maintenance
> file system, put the kernel in place, boot to the maintenance system
> and update lilo.
operation - is a better approach, in my humble opinion.
> [...]
>
>>> 4. Usually install kernel and lilo on the maintenance partition and
>>> then set up an additional partition I normally use.
>>
>> I would propose something like...
>>
>> - /dev/sda1 = /boot
>> - /dev/sda2 = your maintenance partition's root filesystem
>> - /dev/sda3 = your real root filesystem
>
> I'd go:
> /dev/sda1 swap
> /dev/sda2 maintenance, ext4
> /dev/sda3 btrfs pool for root, home subvolumes etc.
>
> as the working /boot is within maintenance effectively. However, this
> moves from a practical to a religious argument very rapidly...
I wouldn't put swap as the first partition on the drive, even if only
>>> 4. Usually install kernel and lilo on the maintenance partition and
>>> then set up an additional partition I normally use.
>>
>> I would propose something like...
>>
>> - /dev/sda1 = /boot
>> - /dev/sda2 = your maintenance partition's root filesystem
>> - /dev/sda3 = your real root filesystem
>
> I'd go:
> /dev/sda1 swap
> /dev/sda2 maintenance, ext4
> /dev/sda3 btrfs pool for root, home subvolumes etc.
>
> as the working /boot is within maintenance effectively. However, this
> moves from a practical to a religious argument very rapidly...
because some partitioning tools don't like that. I remember that cfdisk
used to complain about that when I did that too, and it stopped
complaining when I put /boot first.
>>> Thought. My maintenance partition is almost a initial ram disk.
>>> Could I set up a script within the maintenance partition and supply
>>> a parameter to the kernel so that I could run the script on boot?
>>> I.e.
>>> add a parameter to the kernel in my lilo config so that would boot
>>> to the maintenance partition but instead of running init it would
>>> run the script, mount the final root and switch root?
>>
>> Yes, that is possible. Add the parameter
>>
>> init=/path/to/the/script/my_init
>>
>> ... (where "my_init" is the name of your script) to your kernel's
>> "append" line in /etc/lilo.conf.
>
> Cool. Man pages or whatever said init was a _binary_. If it is a
> script with #/bin/sh as its shell then fantastic.
alternative init specification. Using a pre-init script - which /may/
need to invoke busybox as its shell - is a trick I picked up from the
Gentoo mailing lists, because of screwups by Poettering and Sievers
which broke the booting with a separate /usr filesystem without that
there is an initramfs.
So I do think you need busybox for that, but don't pin me down on it.
In theory you should be able to do with bash as well, but bear in mind
that no environment has been declared yet at that point, so you would
need to specify the full path to the executables you invoke from within
your script, e.g. /bin/mount.
> I'm thinking along the lines:
> . . . . . .
> #!/bin/sh
>
> mount /dev/sda3 /mnt
>
defaults,autodefrag,inode_cache,noatime,compress=lzo,subvol=_root_sl14.1
> 0 0
at that point in time, and it's a non-interactive non-login shell.
> #Any other stuff that is nice to do here.
> #But minimise if possible.
>
> exec switch_root /newroot /sbin/init
script, but I was wrong. You have to use exec, indeed, so as to make
/sbin/init PID 1.
> So I presume after this that the system is none the wiser to these
> boot shenanigans and all will be well in the world.
>>> Alternatively could I get init to run the script from inittab? I.e.
>>> could I set rc.S to be a special script in certain cases?
>>
>> You could do that, but I would be careful because of any udev
>> invocations and possibly the mounting of /proc and /sys _before_ the
>> chroot step.
>
> Oooh. Don't like the sound of that. Sounds less robust than above.
too. In a normal system, this can be taken care of at any stage in the
boot process, depending on what kernel you use. With a very recent
kernel, it shouldn't be a problem because then it's mounted by the
kernel itself.
> I did wonder if using runlevel 5 and cutting down the initialisation
> for that runlevel as much as possible. However, if init=/myscript
> works it sound better.
>> In other words, you will want to trap the init call as early as
>> possible when userspace comes up, and if /proc and /sys already get
>> mounted before your script completes - and hopefully your script
>> won't depend on their presence - then you'll need to make sure they
>> get bind-mounted into the chroot environment _before_ you issue the
>> chroot.
>
> I think that switch_root moves them across - but I don't speak from
> experience.
>> Also make sure that the last command in your script is one that
>> invokes /sbin/init (in the chroot environment, after the chroot
>> itself) and that you allow the script to terminate properly, or
>> otherwise put, that you daemonize /sbin/init by putting an ampersand
>> behind it, before your "exit" command.
in order to give it PID 1.
>>> # System initialization (runs when system boots). - Normal
>>> si:S:sysinit:/etc/rc.d/rc.S
>>>
>>> # System initialization switch root - only runs when specified by
>>> #argument passed to kernel (somehow)
>>> si:S:sysinit:/etc/rc.d/peteSwitchRootScript
>>>
>>> I note that there is an init script in the root of some initial ram
>>> disks that I have seen. What happens if I put one in the root of a
>>> regular filesystem?
>>
>> It's a different thing. The one in the initramfs is invoked by the
>> mechanism of the initramfs itself. Anything else [*] needs to be
>> invoked via a kernel parameter, because the kernel by default will
>> run /sbin/init if nothing else has been specified and when there is
>> no initramfs - the initramfs will invoke /sbin/init itself after the
>> switch_root command, which is specific to the initramfs environment.
>
> So /init is specific to initramfs.
at that stage, the initramfs is still mounted as the root filesystem,
and thus the kernel will look for /sbin/init in the initramfs. And that
particular init is a script which uses busybox to execute a number of
commands, such as mounting the real root filesystem and possibly setting
up /proc and /sys, and possibly also launching udev.
I'm not sure on the latter anymore because there has been a change in
"recent" kernels. Originally /dev was populated with static nodes which
were on-disk and which had been created using mknod. Then, when udev
came around - let's skip devfs and the 2.4 kernel generation for
convenience's sake - /dev still contained some static on-disk nodes, but
was then overlaid with a mount from udev. Then, /dev was empty and udev
did everything, launched from the initramfs. But there were problems on
account of firmware loading by udev etc, so eventually /dev was now
populated from within the kernel itself, via devtmpfs, instead of a
regular tmpfs. Modern kernels normally use devtmpfs, and then kernel
will then automount /dev and populate it, before userspace is initiated,
and thus before udev starts running.
Mind you that the booting of udev is normally also taken care of from
within the initrd/initramfs, so you'll have to keep that into account.
And that is also how you have to mount /proc and /sys - /dev will be
mounted by the kernel itself - before you run anything else.
>> [*] You could for instance also use "init=/bin/bash" in the "append"
>> line to simply boot up to a root shell, but this is typically
>> deprecated (except for real emergencies) because it will not
>> initialize anything else, so there is no $PATH, for instance.
>
> Yep, been there with bad disk errors in the past. Seem to often end
> up in a system so limited all I can do is reboot and pray!
maintenance mode and no environment set, and nothing mounted but the
root filesystem itself. Not even udev running.
> Thanks for that, appreciated.
Welcome. ;-)
Eef Hartman
Jan 22, 2014, 12:30:41 PM1/22/14
to
Aragorn <thor...@telenet.be.invalid> wrote:
> Yes, that is possible. Add the parameter
>
> init=/path/to/the/script/my_init
The kernel cannot run _scripts_ (as compared to real executables)
> Yes, that is possible. Add the parameter
>
> init=/path/to/the/script/my_init
directly, so the command would have to be something like
init=/bin/bash -c /path/to/the/script/my_init
(haven't tested this so don't know aif a commandline with arguments like
this would work).
Scripts (or more complete shell-scripts) are not real executables but
lines of text with command's for the shell (or any other interpreter,
like .pl scripts for perl) to execute, the shell itself is the _real_
executable.
Compare the "system" library call with the "exec" one.
PS: for the shell to work the O/S must have activated the shared object
suport already, the shell (in almost all distributions) is a
shared-object using executable, so especially libc.so must be loadable
for it:
$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7f52000)
libdl.so.2 => /lib/libdl.so.2 (0xb7f4e000)
libc.so.6 => /lib/libc.so.6 (0xb7e02000)
/lib/ld-linux.so.2 (0xb7f73000)
and - as you see - the terminal handling must also be active
(libtermcap nowadays mostly is a frontend for the term-info database,
which is in /usr/lib/terminfo, so /usr - when a separate fs - has to be
mounted too).
Jerry Peters
Jan 22, 2014, 3:58:21 PM1/22/14
to
labels & uuids.
And I remember seeing a patch series on LKML which would allow the
kernel to use labels & uuids, don't know if it ever got applied to
mainline.
Peter Chant
Jan 22, 2014, 3:52:39 PM1/22/14
to
On 01/21/2014 11:58 PM, Aragorn wrote:
>> If I build a new kernel, which is not often, I have to remember to
>> copy over the relent bits to that boot directory on the maintenance
>> file system, put the kernel in place, boot to the maintenance system
>> and update lilo.
>
> Well, that's why having a common /boot - mounted read-only during normal
> operation - is a better approach, in my humble opinion.
>
OK, you've convinced me to give a separate boot another go. I think
>> If I build a new kernel, which is not often, I have to remember to
>> copy over the relent bits to that boot directory on the maintenance
>> file system, put the kernel in place, boot to the maintenance system
>> and update lilo.
>
> Well, that's why having a common /boot - mounted read-only during normal
> operation - is a better approach, in my humble opinion.
>
what put me off last time was trying to share it with slack and mint or
ubuntu - a lot of stuff I did not understand ended in there - it seemed
highly inadvisable to have two such different systems sharing boot.
However, slack and slack ought to be manageable.
>> I'd go:
>> /dev/sda1 swap
>> /dev/sda2 maintenance, ext4
>> /dev/sda3 btrfs pool for root, home subvolumes etc.
>>
>> as the working /boot is within maintenance effectively. However, this
>> moves from a practical to a religious argument very rapidly...
>
> I wouldn't put swap as the first partition on the drive, even if only
> because some partitioning tools don't like that. I remember that cfdisk
> used to complain about that when I did that too, and it stopped
> complaining when I put /boot first.
>
not put it first.
>>>> Thought. My maintenance partition is almost a initial ram disk.
>>>> Could I set up a script within the maintenance partition and supply
>>>> a parameter to the kernel so that I could run the script on boot?
>>>> I.e.
>>>> add a parameter to the kernel in my lilo config so that would boot
>>>> to the maintenance partition but instead of running init it would
>>>> run the script, mount the final root and switch root?
>>>
>>> Yes, that is possible. Add the parameter
>>>
>>> init=/path/to/the/script/my_init
>>>
>>> ... (where "my_init" is the name of your script) to your kernel's
>>> "append" line in /etc/lilo.conf.
>>
>> Cool. Man pages or whatever said init was a _binary_. If it is a
>> script with #/bin/sh as its shell then fantastic.
>
> No, /sbin/init *is* indeed a binary. But the kernel allows for an
> alternative init specification. Using a pre-init script - which /may/
> need to invoke busybox as its shell - is a trick I picked up from the
> Gentoo mailing lists, because of screwups by Poettering and Sievers
> which broke the booting with a separate /usr filesystem without that
> there is an initramfs.
>
> So I do think you need busybox for that, but don't pin me down on it.
> In theory you should be able to do with bash as well, but bear in mind
> that no environment has been declared yet at that point, so you would
> need to specify the full path to the executables you invoke from within
> your script, e.g. /bin/mount.
>
#!/bin/busybox sh
Assuming I put busybox within /bin.
>> I'm thinking along the lines:
>> . . . . . .
>> #!/bin/sh
>>
>> mount /dev/sda3 /mnt
>>
> defaults,autodefrag,inode_cache,noatime,compress=lzo,subvol=_root_sl14.1
>> 0 0
>
> That would then have to be /bin/mount. There is no $PATH declared yet
> at that point in time, and it's a non-interactive non-login shell.
>
>> #Any other stuff that is nice to do here.
>> #But minimise if possible.
>>
>> exec switch_root /newroot /sbin/init
>
> Yes, my bad. I wrote that you had to deamonize that and then exit the
> script, but I was wrong. You have to use exec, indeed, so as to make
> /sbin/init PID 1.
>
>> So I presume after this that the system is none the wiser to these
>> boot shenanigans and all will be well in the world.
>
> It should, yes.
>
I've snipped the rest but the next thing is to see if my ebay diskless
laptop is a runner when it arrives, and if so get a disk! Can't really
comment on the rest until I get it and have a play. Well, I could play
around with the boot of this system but I prefer not to!
Pete
Aragorn
Jan 22, 2014, 5:08:06 PM1/22/14
to
On Wednesday 22 January 2014 21:52, Peter Chant conveyed the following
to alt.os.linux.slackware...
> On 01/21/2014 11:58 PM, Aragorn wrote:
>
>>> If I build a new kernel, which is not often, I have to remember to
>>> copy over the relent bits to that boot directory on the maintenance
>>> file system, put the kernel in place, boot to the maintenance system
>>> and update lilo.
>>
>> Well, that's why having a common /boot - mounted read-only during
>> normal operation - is a better approach, in my humble opinion.
>
> OK, you've convinced me to give a separate boot another go. I think
> what put me off last time was trying to share it with slack and mint
> or ubuntu - a lot of stuff I did not understand ended in there - it
> seemed highly inadvisable to have two such different systems sharing
> boot. However, slack and slack ought to be manageable.
Yeah, Slackware gives you a choice on what boot loader to install, but
defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
says about its advantages. ;-)
to alt.os.linux.slackware...
> On 01/21/2014 11:58 PM, Aragorn wrote:
>
>>> If I build a new kernel, which is not often, I have to remember to
>>> copy over the relent bits to that boot directory on the maintenance
>>> file system, put the kernel in place, boot to the maintenance system
>>> and update lilo.
>>
>> Well, that's why having a common /boot - mounted read-only during
>> normal operation - is a better approach, in my humble opinion.
>
> OK, you've convinced me to give a separate boot another go. I think
> what put me off last time was trying to share it with slack and mint
> or ubuntu - a lot of stuff I did not understand ended in there - it
> seemed highly inadvisable to have two such different systems sharing
> boot. However, slack and slack ought to be manageable.
defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
says about its advantages. ;-)
Peter Chant
Jan 22, 2014, 4:45:49 PM1/22/14
to
On 01/21/2014 11:15 PM, Peter Chant wrote:
> I'm thinking along the lines:
> . . . . . .
> #!/bin/sh
>
> mount /dev/sda3 /mnt
> defaults,autodefrag,inode_cache,noatime,compress=lzo,subvol=_root_sl14.1
> 0 0
>
> #Any other stuff that is nice to do here.
> #But minimise if possible.
>
> exec switch_root /newroot /sbin/init
>
> . . . . .
Don't use switch_root as it nukes the the initial filesystem. I would
> I'm thinking along the lines:
> . . . . . .
> #!/bin/sh
>
> mount /dev/sda3 /mnt
> defaults,autodefrag,inode_cache,noatime,compress=lzo,subvol=_root_sl14.1
> 0 0
>
> #Any other stuff that is nice to do here.
> #But minimise if possible.
>
> exec switch_root /newroot /sbin/init
>
> . . . . .
not have minded as nothing mattered there except it is where the boot
image is located and lilo.conf lives there....
Pete
Peter Chant
Jan 22, 2014, 5:10:26 PM1/22/14
to
On 01/22/2014 09:45 PM, Peter Chant wrote:
> Don't use switch_root as it nukes the the initial filesystem. I would
> not have minded as nothing mattered there except it is where the boot
> image is located and lilo.conf lives there....
Phew - new lilo config with separate ext4 partition on /boot works.
> Don't use switch_root as it nukes the the initial filesystem. I would
> not have minded as nothing mattered there except it is where the boot
> image is located and lilo.conf lives there....
If not it would have been a good and proper pain to fix this - custom
kernel - 3.11.6 - newer than that in Slack14.1 as I'm using btrfs which
is not backwards compatible with older kernels. So although no data
lost I'd have had to build a 3.11.6 kernel or newer to boot it. Did
save the kernel and modules to a usb stick just in case.
Actually thanks for the hint guys. I never got btrfs and lilo playing,
but this thread gave me the hint, I was using UUIDs in lilo.conf.
Replaced them and no problem:
image = /boot/linux-3.11.6
label = "Sl14.1_3.11.6"
#root="UUID=6496aabd-d6aa-49e0-96ca-e49c316edd8e"
#append="root=UUID=6496aabd-d6aa-49e0-96ca-e49c316edd8e
rootflags=subvol=_root_sl14
.0"
root=/dev/sda3
append="root=/dev/sda3 rootflags=subvol=_root_sl14.1u"
read-only
Is it not amazing how you get stuck in a rut, but then a small hint
sorts things.
Still want to do the swapping root thing though. Worst part is that the
man page for switch_root told me I was being stupid:
DESCRIPTION
switch_root moves already mounted /proc, /dev and /sys to
newroot and
makes newroot the new root filesystem and starts init process.
WARNING: switch_root removes recursively all files and
directories on the
current root filesystem.
Pete
Peter Chant
Jan 22, 2014, 5:35:09 PM1/22/14
to
On 01/22/2014 10:08 PM, Aragorn wrote:
> Yeah, Slackware gives you a choice on what boot loader to install, but
> defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
> install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
> says about its advantages. ;-)
>
Exactly. I've tried Grub2 once or twice. What generally causes me
> Yeah, Slackware gives you a choice on what boot loader to install, but
> defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
> install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
> says about its advantages. ;-)
>
concern is when I feel it is necessary to wipe the partition from which
the relevent bootloader is installed. However, perhaps the common /boot
parition solves that.
Had fun on my parents machine the other day. Tried slack on a separate
hard drive as inexplicably a scanner was not working. Unplugged Mint
disk. Installed slack - no problem (still no scanner but that is a
separate issue). Unplugged slack disk and plugged Mint back in.
Despite no changes to the disk could not get the darn thing to boot.
Think it was the damn UEFI thing. Setting mobo to leagacy then UEFI did
not help. So in fairness probally not Mint's fault.
Jerry Peters
Jan 23, 2014, 4:16:57 PM1/23/14
to
to configure it, you don't need that, it's very easy to write your own
config file.
I use a grub2 script, which understands how I store kernels. The
script runs as part of grub2 boot and builds a nice menu of all the
available kernels. Whenever I build a new kernel, all I have to do is
install it to /boot to make it available. No running all of the grub2
junk scripts that build the config file, no modification to the config
file *at all*. It just works.
Peter Chant
Jan 23, 2014, 4:59:18 PM1/23/14
to
On 01/23/2014 09:16 PM, Jerry Peters wrote:
>> Yeah, Slackware gives you a choice on what boot loader to install, but
>> defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
>> install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
>> says about its advantages. ;-)
>>
> I thought that too, until I *tried* it. Forget all the crap it needs
> to configure it, you don't need that, it's very easy to write your own
> config file.
>
> I use a grub2 script, which understands how I store kernels. The
> script runs as part of grub2 boot and builds a nice menu of all the
> available kernels. Whenever I build a new kernel, all I have to do is
> install it to /boot to make it available. No running all of the grub2
> junk scripts that build the config file, no modification to the config
> file *at all*. It just works.
>
The fact that you had to chmod 755 the various scripts in the /etc/grub
>> Yeah, Slackware gives you a choice on what boot loader to install, but
>> defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
>> install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
>> says about its advantages. ;-)
>>
> I thought that too, until I *tried* it. Forget all the crap it needs
> to configure it, you don't need that, it's very easy to write your own
> config file.
>
> I use a grub2 script, which understands how I store kernels. The
> script runs as part of grub2 boot and builds a nice menu of all the
> available kernels. Whenever I build a new kernel, all I have to do is
> install it to /boot to make it available. No running all of the grub2
> junk scripts that build the config file, no modification to the config
> file *at all*. It just works.
>
directory was a little thing to catch you out.
Personally I would think that for desktops at least booting to a small
partition with enough tools to fix various things and using that to
bootstrap any other systems would sound like an excellent system.
Allocating 100M, or even 1GB or more to a bootloader is not unreasonable
with 1TB and upwards disks. Plenty of room for GUIS, command line, menu
systems or anything you fancy. Or course, not so practical on resource
limited devices.
Hence my desire to try this with my 'maintenance' partition. Assuming I
don't hose it again...
Pete
Eef Hartman
Jan 23, 2014, 7:02:04 PM1/23/14
to
Jerry Peters <je...@example.invalid> wrote:
> Only applies to the kernel command line, fsck & mount understand
> labels & uuids.
IF udev is running so it has created the /dev/disk/by-* directories.
> Only applies to the kernel command line, fsck & mount understand
> labels & uuids.
Note that the whole of /dev is _normally created BY udev (the non-udev
/dev doesn't have the disk/by-* subdirs as they have to be dynamically
determined and without udev the whole /dev tree is static).
--
*****************************************************************
** Eef Hartman, Delft University of Technology, dept. EWI/CE **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
*****************************************************************
Jerry Peters
Jan 24, 2014, 4:11:58 PM1/24/14
to
Eef Hartman <E.J.M....@tudelft.nl> wrote:
> Jerry Peters <je...@example.invalid> wrote:
>> Only applies to the kernel command line, fsck & mount understand
>> labels & uuids.
>
> IF udev is running so it has created the /dev/disk/by-* directories.
> Note that the whole of /dev is _normally created BY udev (the non-udev
> /dev doesn't have the disk/by-* subdirs as they have to be dynamically
> determined and without udev the whole /dev tree is static).
See libblkid which is now part of util-linux. It's used by mount &
> Jerry Peters <je...@example.invalid> wrote:
>> Only applies to the kernel command line, fsck & mount understand
>> labels & uuids.
>
> IF udev is running so it has created the /dev/disk/by-* directories.
> Note that the whole of /dev is _normally created BY udev (the non-udev
> /dev doesn't have the disk/by-* subdirs as they have to be dynamically
> determined and without udev the whole /dev tree is static).
fsck.
Jerry Peters
Jan 24, 2014, 4:25:14 PM1/24/14
to
Peter Chant <pe...@petezilla.co.uk> wrote:
> On 01/23/2014 09:16 PM, Jerry Peters wrote:
>
>>> Yeah, Slackware gives you a choice on what boot loader to install, but
>>> defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
>>> install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
>>> says about its advantages. ;-)
>>>
>> I thought that too, until I *tried* it. Forget all the crap it needs
>> to configure it, you don't need that, it's very easy to write your own
>> config file.
>>
>> I use a grub2 script, which understands how I store kernels. The
>> script runs as part of grub2 boot and builds a nice menu of all the
>> available kernels. Whenever I build a new kernel, all I have to do is
>> install it to /boot to make it available. No running all of the grub2
>> junk scripts that build the config file, no modification to the config
>> file *at all*. It just works.
>>
>
> The fact that you had to chmod 755 the various scripts in the /etc/grub
> directory was a little thing to catch you out.
Don't assume:
> On 01/23/2014 09:16 PM, Jerry Peters wrote:
>
>>> Yeah, Slackware gives you a choice on what boot loader to install, but
>>> defaults to LILO. Mint and Ubuntu are both Debian derivatives and they
>>> install GRUB2 instead. And GRUB2 is an ugly mess, no matter what anyone
>>> says about its advantages. ;-)
>>>
>> I thought that too, until I *tried* it. Forget all the crap it needs
>> to configure it, you don't need that, it's very easy to write your own
>> config file.
>>
>> I use a grub2 script, which understands how I store kernels. The
>> script runs as part of grub2 boot and builds a nice menu of all the
>> available kernels. Whenever I build a new kernel, all I have to do is
>> install it to /boot to make it available. No running all of the grub2
>> junk scripts that build the config file, no modification to the config
>> file *at all*. It just works.
>>
>
> The fact that you had to chmod 755 the various scripts in the /etc/grub
> directory was a little thing to catch you out.
~$ ls /etc/grub
/bin/ls: cannot access /etc/grub: No such file or directory
I *don't* use any of grub2's configuration crap, I didn't even install
any of it. The script runs when grub2 is booting. The grub2 config
file is not a real configuration file, it's a *script*. One of the
possible things it can do is build a menu dynamically by searching for
linux kernels. The grub2 scripting language is a subset of BASH with
the more esoteric features missing. But it's complete enough to find
my kernels and build the menu..
>
> Personally I would think that for desktops at least booting to a small
> partition with enough tools to fix various things and using that to
> bootstrap any other systems would sound like an excellent system.
> Allocating 100M, or even 1GB or more to a bootloader is not unreasonable
> with 1TB and upwards disks. Plenty of room for GUIS, command line, menu
> systems or anything you fancy. Or course, not so practical on resource
> limited devices.
>
> Hence my desire to try this with my 'maintenance' partition. Assuming I
> don't hose it again...
>
> Pete
>
available if / is not bootable for some reason. /alt is available as a
grub2 submenu from the main menu.
For extreme emergencies I have a USB stick that will boot a full Linux
system, X and all.
0 new messages