RLFrost said:
> Just to clear up the EFI misconception, Debian can be installed on EFI
> computers. I run it on three of my own-- 2 Acer desktops and 1 ASUS
> laptop. I use rEFind as a boot manager, as it it very straightforward,
> and does a very nice job with all OS entries. I understand that there
> are instructions for installing Debian with GRUB only floating around,
> but I don't find it necessary.
Hi RL. Your post puzzled me, but it forced me to dig deeper, and I think I
found the reason why both Debian and PCLinuxOS refused to boot. The version
of Debian I was using (actually antiX) uses Grub1 (ie: Grub-Legacy) rather
than Grub2 to boot. PCLinuxOS also uses Grub1. As I understand it, generic
Grub1 will not do UEFI boot, though there are unofficial modified versions
which will. Slackware uses Lilo to boot which doesn't support UEFI, but
switches to Elilo if it encounters UEFI which can handle it.
So I guess the lesson in all this for Devuan is that it should not use
Grub1 (unless it's a modified version). Default should be Grub2, or else
Lilo/elilo combination like Slackware.
Thanks for the heads-up on this, seems that I was barking up the wrong tree.
regards,
Robert
On Tue, Jan 20, 2015 at 8:00 PM, <dng-request@???> wrote:
> Send Dng mailing list submissions to
> dng@???
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> or, via email, send a message with subject or body 'help' to
> dng-request@???
>
> You can reach the person managing the list at
> dng-owner@???
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dng digest..."
>
>
> Today's Topics:
>
> 1. UEFI, GPT (Robert Storey)
> 2. Re: libsysdev preview (Isaac Dunham)
> 3. Re: libsysdev preview (Jude Nelson)
> 4. UEFI, GPT (rlfrost)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 20 Jan 2015 11:27:01 +0800
> From: Robert Storey <robert.storey@???>
> To: dng@???
> Subject: [Dng] UEFI, GPT
> Message-ID:
> <CAC39vt1wFMwoSC1ir0qZZe6AUejnDVT4E-2zwYSxuwuX=
> CEH3w@???>
> Content-Type: text/plain; charset="utf-8"
>
> Steve Litt said:
>
> > I've heard anecdotes of the UEFI system writing to persistant memory on
> > the motherboard in a way that an app misusing UEFI could brick the
> > motherboard. Therefore, the only time I use UEFI is when I absolutely
> > must have Windows on the laptop, and the Windows that came on the
> > laptop requires UEFI.
>
> Steve, I did some follow-up on this issue, and I see what you're talking
> about. It's an issue that effects some Samsung laptops, but may affect
> others:
>
> https://bbs.archlinux.org/viewtopic.php?pid=1234580
>
> Good to know about, and somewhat cools my enthusiasm for UEFI and GPT. But
> we'll still probably have to learn to live with UEFI/GPT, because it's now
> the default setup on so many machines, especially laptops, and there are
> those who think they must have Windows installed alongside Linux.
>
> Though I live without Windows just fine, I need to help others who still
> haven't quite kicked the habit. So I'll continue my experiment with
> UEFI/GPT dual-booting, and hopefully will find a way to make it work with
> Devuan.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailinglists.dyne.org/cgi-bin/mailman/private/dng/attachments/20150120/b5d58703/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 19 Jan 2015 19:55:34 -0800
> From: Isaac Dunham <ibid.ag@???>
> To: Jude Nelson <judecn@???>
> Cc: "dng@???" <dng@???>
> Subject: Re: [Dng] libsysdev preview
> Message-ID: <20150120035527.GA5071@newbook>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
> > Regarding the architecture, I have a design document here:
> > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html Is this
> what
> > you're looking for? Or did you want a more low-level document describing
> > the implementation details?
>
> I was asking about implementation details (something like the HACKING
> document that many projects have, giving an overview of how it works
> internally).
>
> Being mainly acquainted with C, I might not be able to follow it myself,
> but it may well be useful for people who want to contribute.
>
> > Regarding whitespace, my style is based on Stroustrup's adaptation of
> K&R.
> > I add whitespace where I do because it helps me read code better and add
> > comments.
>
> Ah.
> I find that the Linux kernel style (also based on K&R) seems most clear
> to me; it seems quite different on the surface.
> (Styles are styles, though. There's always variation.)
>
> > Looking forward to seeing what you do with libsysdev :) I'm seriously
> > considering moving libudev-compat out of vdev entirely, and having it use
> > libsysdev as a backend (either way, I don't want it to be coupled to
> vdev).
> >
>
> I'm getting the impression that libsysdev won't really make a good
> backend for the udev API; libudev is a much more low-level interface,
> with somewhat different logical division and flow.
> (Abstractly, I'd be happy if it did work. But wasting time for the sake
> of promoting libsysdev isn't going to help replace udev.)
>
>
> Thanks for the comments!
>
> Isaac Dunham
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 20 Jan 2015 00:01:12 -0500
> From: Jude Nelson <judecn@???>
> To: Isaac Dunham <ibid.ag@???>
> Cc: "dng@???" <dng@???>
> Subject: Re: [Dng] libsysdev preview
> Message-ID:
> <
> CAFsQEP0dwjBh8MeuhTPrZZGw1QE7dv+sUvfPMjJ9pqdrphrG_A@???>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Isaac,
>
> > I was asking about implementation details (something like the HACKING
> > document that many projects have, giving an overview of how it works
> > internally).
>
> Good idea; I'll add one.
>
> > I'm getting the impression that libsysdev won't really make a good
> > backend for the udev API; libudev is a much more low-level interface,
> > with somewhat different logical division and flow.
> > (Abstractly, I'd be happy if it did work. But wasting time for the sake
> > of promoting libsysdev isn't going to help replace udev.)
>
> Interestingly, the libudev API doesn't look that tightly coupled to the
> udev implementation to begin with, which is why I consider libudev-compat
> to be feasible. Namely, I'm going with the following implementation
> strategy:
>
> udev: library state catch-all
> udev_list: this is just a linked list implementation of (key, value)
> pairs, which some other methods in libudev happen to return
> udev_device: mostly, this is reading data from sysfs and /dev. Not sure
> yet about device properties, but I'll figure something out. Might want to
> use libsysdev here, and/or recycle parts of vdev's linux back-end.
> udev_monitor: don't even bother with netlink. Just inotify-monitor /dev
> for changes, so even a static dev will generate events.
> udev_enumerate: this is just applying a generic set of filters on a sysfs
> directory listing.
> udev_queue: don't bother connecting to udev. Just inotify-monitor /dev
> again, but do so in the background (i.e. on library init).
> udev_hwdb: read udev hwdb files
> udev_util: only one string-encoding method; nothing to see here.
>
> -Jude
>
>
> On Mon, Jan 19, 2015 at 10:55 PM, Isaac Dunham <ibid.ag@???> wrote:
>
> > On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
> > > Regarding the architecture, I have a design document here:
> > > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html Is this
> > what
> > > you're looking for? Or did you want a more low-level document
> describing
> > > the implementation details?
> >
> > I was asking about implementation details (something like the HACKING
> > document that many projects have, giving an overview of how it works
> > internally).
> >
> > Being mainly acquainted with C, I might not be able to follow it myself,
> > but it may well be useful for people who want to contribute.
> >
> > > Regarding whitespace, my style is based on Stroustrup's adaptation of
> > K&R.
> > > I add whitespace where I do because it helps me read code better and
> add
> > > comments.
> >
> > Ah.
> > I find that the Linux kernel style (also based on K&R) seems most clear
> > to me; it seems quite different on the surface.
> > (Styles are styles, though. There's always variation.)
> >
> > > Looking forward to seeing what you do with libsysdev :) I'm seriously
> > > considering moving libudev-compat out of vdev entirely, and having it
> use
> > > libsysdev as a backend (either way, I don't want it to be coupled to
> > vdev).
> > >
> >
> > I'm getting the impression that libsysdev won't really make a good
> > backend for the udev API; libudev is a much more low-level interface,
> > with somewhat different logical division and flow.
> > (Abstractly, I'd be happy if it did work. But wasting time for the sake
> > of promoting libsysdev isn't going to help replace udev.)
> >
> >
> > Thanks for the comments!
> >
> > Isaac Dunham
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailinglists.dyne.org/cgi-bin/mailman/private/dng/attachments/20150120/259f7816/attachment.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 20 Jan 2015 00:02:45 -0500
> From: rlfrost <frostrl@???>
> To: dng@???
> Subject: [Dng] UEFI, GPT
> Message-ID: <54BDE175.2020900@???>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Just to clear up the EFI misconception, Debian can be installed on EFI
> computers. I run it on three of my own-- 2 Acer desktops and 1 ASUS
> laptop. I use rEFind as a boot manager, as it it very straightforward,
> and does a very nice job with all OS entries. I understand that there
> are instructions for installing Debian with GRUB only floating around,
> but I don't find it necessary.
>
> RLFrost
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
> ------------------------------
>
> End of Dng Digest, Vol 4, Issue 35
> **********************************
>
::
Re: [Dng] Dng Digest, Vol 4, Issue …
