> On my system I don't always get the same device at /dev/sda. Rebooting can
> change my /dev/sda to /dev/sdg, or any other device letter, without any
> physical change in the underlying disks or cabling. This is not a problem in
> the eyes of the kernel devs, and will never be "fixed", because
> Another way to work around that issue is not using static device node
> names if they don't end up being statically assigned. You can use a
> partition's Label or UUID and reference them in /etc/fstab. Running
> "blkid" will obtain the values you'll need. This makes the partitions
> persistent i
> To me, the biggest reason to use initiramfs is if you want to have the
> root fs on a sw raid device, e.g. md0. All the other reasons are fairly
> exotic. root on lvm? why? On nfs? Maybe, but still exotic.
> Encrypted? Data, yes, but why the root fs?
>
We have to be careful here. What see
I'm about to start merging Wayne's work. For the packages I've
already built, I'll add measurements, descriptions, and whatever
else I think is necessary. For the remainder, I'll only be able to
add descriptions.
As far as I can see, this should NOT interfere with other updates.
But, it's poss
Gerard Beekmans wrote:
> From our book's point of view I still like the idea of exposing a basic
> initramfs. Just enough to give a shell and some useful utilities if
> decided upon. We can leave it to hints & user's own imagination to add
> RAID, LVM, iSCSI and other such capabilities. If we
On Jan 24, 2012, at 10:01 AM, Gerard Beekmans wrote:
> If it wasn't entirely clear from other posts, Grub can also use those
> same UUIDs for its 'linux', 'linuxrd' and 'root' options. I'm not sure
> off the top of my head if it supports labels. I've always used the UUIDs
> because every parti
Zachary Kotlarek wrote:
> On Jan 24, 2012, at 10:01 AM, Gerard Beekmans wrote:
>
>> If it wasn't entirely clear from other posts, Grub can also use those
>> same UUIDs for its 'linux', 'linuxrd' and 'root' options. I'm not sure
>> off the top of my head if it supports labels. I've always used th
Nathan, et al.,
In Aug of last year (2011), you posted a bridge-utils proposal:
http://www.linuxfromscratch.org/pipermail/blfs-dev/2011-August/021129.html
And along with the script, included a patch which looks like this:
Patch for latest LFS **
#!/bin/sh
###
> I believe they still are. I don't think the kernel recognizes UUIDs, so
> an initrd (initramfs) is still needed to implement UUIDs and labels.
>
You're right, I stand corrected. I haven't booted Linux w/o an init ram
disk in so long...
> There is no 'linuxrd' command in GRUB2, only 'linux',
Qrux wrote:
> -. /etc/sysconfig/rc
> -. ${rc_functions}
> +. /lib/boot/functions
> . ${IFCONFIG}
> -# End $network_devices/services/bridge
> +# End /lib/boot/bridge
> Patch for latest LFS **
>
> I tried to figure out how this script was getting called (and how it
> was meant to
On Tue, Jan 24, 2012 at 12:32 PM, Bruce Dubbs wrote:
> Qrux wrote:
>
>> -. /etc/sysconfig/rc
>> -. ${rc_functions}
>> +. /lib/boot/functions
>> . ${IFCONFIG}
>
>> -# End $network_devices/services/bridge
>> +# End /lib/boot/bridge
>> Patch for latest LFS **
>>
>> I tried to figure
Zachary Kotlarek wrote:
> On Jan 23, 2012, at 7:56 PM, Bryan Kadzban wrote:
>
>> UGH. FWIW I really don't like this "feature".
>>
>> It causes the booted-with-initramfs case to require different
>> handling from the booted-without-initramfs case, once the
>> bootscripts are running, and theref
On Wed, Jan 25, 2012 at 4:49 PM, Bryan Kadzban
wrote:
> Zachary Kotlarek wrote:
>> On Jan 23, 2012, at 7:56 PM, Bryan Kadzban wrote:
>>
>>> UGH. FWIW I really don't like this "feature".
>>>
>>> It causes the booted-with-initramfs case to require different
>>> handling from the booted-without-init
13 matches
Mail list logo
