45700+ entries in 0.022s
trinque: I still want
to know whether your genesis.vpatch matches mine, and
this is at least as important as whether it produced a bootable drive
☟︎ trinque: very glad
to see your experiments with using
the UUID labels btw; I'm soon
to haul
that into
the script. I do want
to remind
that
this won't change
the genesis
that is produced by
the bootstrapper.
trinque: I highly encourage you
to not accidentally haul in an artifact of "user can't be expected
to" into cuntoo
trinque: the only reason initramfs is used on personal machines is
that
the users have been lost
to sloth and "can't be expected"
to build own kernel
trinque: initramfs is used when
the kernel can't mount
the root fs without using a program
to do something complicated first, i.e. loading firmware, unpacking a squashfs in an embedded device, etc
trinque: there's all
this metaphoric content without rooting
to anything, which makes it hard
to
track where your head's at
to have what with
to help
a111: Logged on 2019-02-14 01:41 mod6:
Then I got on
the
track
that perhaps i do need
to have an initramfs.
mod6: Ok,
thank you gentlemen. I appreciate
the insight & help.
mod6: Might
take a bit, but I'll begin work on
that
tomorrow-ish. Should have something
to look at hopefully by Friday evening-ish. I'll inflate an entirely fresh cuntoo.
mod6: so, `dd`
the entire cuntoo ssd disk onto a usb,
then attempt
to boot
the USB, and
then do
the lsmod diff between
the USB cuntoo and
the SSD cuntoo?
mod6: See, I kinda
thought
the SCSI subsystem
thing meant
that SATA was ready.
mod6: So next mission is
to use a clean USB drive, and inflate cuntoo onto
that, and
then
try?
mircea_popescu: ie, from a cursory look at his published logs, my impression was
that
the kernel has sata just fine, but
the disk's not plugged in
the config-set hole or somesuch.
mircea_popescu: right ; but i expect
the sata is like
the raid, not like
the soundblaster.
mircea_popescu: well it couldn't come from
THEM, linux existed long before
they.
a111: Logged on 2019-02-14 01:56 mod6: it's like, fuck
this, I want a "GIVE_ME_EVERYTHING_YOUVE_GOT_WHORE" flag
that build every driver known.
a111: Logged on 2019-02-13 21:59 diana_coman: at least
there are no more surprises of huge differences in
timings; but I'd still
test also with some exception handling since
that's supposed
to slow sjlj down
mircea_popescu:
http://btcbase.org/log/2019-02-13#1895868 << we don't so much care, seeing how we don't intend
to have exceptions but exceptionally. if
the
thing crashes ever, your problems will be in excess of 99, but none of
them
that "it
took one half milisecond extra for burning relic
to make it back
to earth"
☝︎☟︎ mod6: The funny part is, it could jsut be
this one really obnoxious setting
that I'm missing; I feel like it was
that way back when I did gentoo in '15.
mircea_popescu: my vague memories not fresh enough
to pursue
this line.
mircea_popescu: yes, but what i mean, if it manages
to build with no sata/no ide it says ; similarily if no netcard ; and i dun recall what else.
mod6: at least I could figure out wtf and
try
to pair it down later.
mircea_popescu: i guess. honestly, i'd expect
to see logs reflecting failure
to init sata if
that were
the case.
mod6: it's like, fuck
this, I want a "GIVE_ME_EVERYTHING_YOUVE_GOT_WHORE" flag
that build every driver known.
☟︎ mod6: Could be, a solid way
to
try
to prove
that is
the USB Stick route. Because, I'm not super well versed in SATA kernel drivers.
mod6: His
thing has
the stage3 in
there iirc.
mod6: asciilifeform: everything comes with
trinque's cuntoo afaik
mod6: Which is why, in
the first place, I
thought I had a bad SSD. Which is why I ended up buying a second one just
to be sure.
mod6: So, if I
take
this route, I'll have
to make sure
those options are
turned on for sure.
mod6: I did look
through
the makemenuconfig,
there are a lot of added in USB drivers. however,
there was one option
that I noticed
that I should look hard at (all when
trying
to do
the genkernel for different reasons), which is
the Intel USB Drivers.
BingoBoingo: mircea_popescu:
ty, will
try lightening up
the payload copy for mass distribution
mod6: Ok, so you're saying: Do all of
the above steps, but instead of using a SATA SSD, inflate cuntoo onto a USB stick?
mircea_popescu: BingoBoingo "In light of
the outlaw status being forced upon your organization, it is advisable
to begin
to operate accordingly." <<
too bulky contentless.
that's supposed
to be
the closer neh.
mod6: Right, well, cuntoo expands all of
those
things and build it, you just feed it a config. So if
there is something
that is "off" about my config with some other slightly different source version,
then
that might be a part of it.
mod6: certainly possible. seems
totally wacky
to me
that
the same kernel config would boot gentoo perfectly, but not cuntoo. note in
the wotpaste above
that I copied in my /usr/src/linux/.config from gentoo directly and build
that config.
mircea_popescu: asciilifeform it'd be a lot more possible if
the same kernel on same machine didn't boot before.
mod6: But since
that was an utter failure, I'm just
trying something different because of /dev/disk/by-uuid/ or whatever it is.
mod6: The days leading up
to
the blog post, i used nothing but names: /dev/sda{1,2,3} and eschewed UUIDs
totally.
mod6: Oh, i
totally felt
the same way.
mircea_popescu: from what i gather actually setting
the correct path (ie, /sda3 or w/e it actually is) should really do it. i don't expect you can just unilaterally set uuids, gotta make
them work from
the other end
too first.
mod6: So perhaps im kindof on
the right
track - use UUIDs where I can, and build an initramfs... however, haven't had a lot of success with building
the initramfs yet. I may have
to fight
through
that. But
that's
the latest update.
mod6: But I keep getting failures
that say "Failed
to compile
the "all"
target. No matter what I do it seems.
mircea_popescu: mod6 is
the disk hanging off internal port or usb port ?
mod6: Then I got on
the
track
that perhaps i do need
to have an initramfs.
☟︎ mod6: I
think
that I might be on
the right
track here
though, and I did
try a few other
things after reading some documentation. For instance, after
the above, I changed /etc/fstab
to use only UUIDs instead of '/dev/sda{1,2,3}', and
then
tried
that. Same problem essentialy. I also found about 'PARTUUID', which is supposed
to help in certain circumstances. Nothing has worked yet...
mod6:
http://p.bvulpes.com/pastes/BoTML/?raw=true << Ok, so after installing Cuntoo, I did what I said I'd do, which was
test editing
the append section and
throwing a UUID in
there instead of 'root=/dev/sda3'. It didn't work, I did get a kern dump.
mircea_popescu: i've been
thinking about how
to correctly construct a calling
test for
this purpose, but i confess nothing i have yet is passing muster. if anyone wants
to step in.
mircea_popescu: asciilifeform yes, but it's
the job of "optimizing" compiler
to keep all
that
to a low roar.
a111: Logged on 2019-02-12 13:14 mircea_popescu: wasn't
the long jump
thing slower ~generally~ ?
mircea_popescu: i'll still want her
to fill in
the rest of
the
table ; but
tentatively yes. looks like i'll be withdrawing my objection
to bvt 's original comments (
http://btcbase.org/log/2019-02-12#1895233 ) sometime
tomorrow. in which case all
the better, we just do
that and good riddance.
☝︎ mircea_popescu: in fact in some cases it could be
the case IT IS ACTUALLY FASTER (to a very small degree)
mircea_popescu:
http://btcbase.org/log/2019-02-13#1895836 << so on
the basis of
this better
table neatly presenting data i'm concluding
that a) serpent run indeed
takes 2.8 us or so ; b)
timing data converges within 1/3 s
test runs or so ; c)
these statements equal
to foregoing earlier items which are
thus retrospectively deemed correct and finally, and most importantly d)
tentatively it seems sjlj adds no measurable
time delay on running co
☝︎ mircea_popescu: yet pantsuited hilarity STILL hasn't managed
to find
the
twitter button, seems like.