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

Groups > alt.os.linux > #53386 > unrolled thread

USB server install problem

Back to article view | Back to alt.os.linux

Contents

  USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 08:19 -0800
    Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 08:52 -0800
    Re: USB server install problem Dan Purgert <dan@djph.net> - 2019-01-30 17:27 +0000
      Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 09:48 -0800
        Re: USB server install problem Dan Purgert <dan@djph.net> - 2019-01-30 18:15 +0000
          Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 10:25 -0800
            Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 10:45 -0800
            Re: USB server install problem "Cybe R. Wizard" <cybe_r_wizard@WizardsTower.invalid> - 2019-01-30 14:55 -0600
              Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 13:03 -0800
                Re: USB server install problem "Cybe R. Wizard" <cybe_r_wizard@WizardsTower.invalid> - 2019-01-30 15:47 -0600
                  Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 16:00 -0800
                    Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 16:20 -0800
                      Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 17:01 -0800
                        Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-01 07:00 -0800
                          Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-01 09:01 -0800
                            Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-01 11:04 -0800
                          Re: USB server install problem Lucifer <LuciferMorningstar@bigpond.com> - 2019-02-02 06:17 +1100
                            Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-01 11:47 -0800
                      Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 17:19 -0800
                Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-02 08:55 +0100
                  Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-02 01:05 -0800
                    Re: USB server install problem Paul <nospam@needed.invalid> - 2019-02-02 10:50 -0500
                      Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-02 08:39 -0800
                    Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-02 21:38 +0100
                      Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-03 14:01 -0800
                        Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-04 21:58 +0100
                          Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-04 15:33 -0800
                            Re: USB server install problem Dan Purgert <dan@djph.net> - 2019-02-05 12:29 +0000
                              Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-05 09:34 -0800
                                Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-05 20:27 +0100
                            Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-05 20:29 +0100
                              Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-05 13:04 -0800
                                Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-05 13:29 -0800
                                Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-05 23:44 +0100
                                  Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-05 23:47 +0100
                                    Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-05 15:58 -0800
                                  Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-05 16:16 -0800
                                    Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-05 16:57 -0800
                                      Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-02-05 17:25 -0800
                                        Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-06 20:17 +0100
            Re: USB server install problem Dan Purgert <dan@djph.net> - 2019-01-30 21:44 +0000
              Re: USB server install problem Richard Kettlewell <invalid@invalid.invalid> - 2019-01-30 21:56 +0000
                Re: USB server install problem Dan Purgert <dan@djph.net> - 2019-01-30 22:04 +0000
            Re: USB server install problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-02 08:52 +0100
          Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 12:32 -0800
    Re: USB server install problem Mike Easter <MikeE@ster.invalid> - 2019-01-30 12:03 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#53493

Pascal Hambourg wrote:
> Mike Easter a écrit :
>>
>> Installing to a bootable USB involves some 'tricks' which are not 
>> employed by the net installer nor the server installer.  Those 
>> installers 'think' (are designed to perform as if) they are installing 
>> to a conventional hdd.
> 
> What kind of tricks ?

Unfortunately, I don't know the answer to that.  I see answers, but they 
don't work for me.

> AFAIK, a USB drive can be used like any other drive and does not require 
> any tricks.

Try it and see if it works for you.

My initial attempt was to use the Ubuntu server .iso which has a text 
based installer.  I wrote it to USB and booted it for the live 
installation to another USB.  I was unsuccessful in getting a USB with 
the Ub server installed to boot.  The installer went through the 
'motions' and installed and there was a grub boot loader, but it didn't 
boot.  I attempted several different preparations of the USB prior to 
trying to install to it, but none of them worked for me.

https://www.ubuntu.com/download/server Ubuntu Server 18.04.1 LTS


-- 
Mike Easter

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

#53496

Mike Easter wrote:
> Pascal Hambourg wrote:
>> Mike Easter a écrit :
>>>
>>> Installing to a bootable USB involves some 'tricks' which are not 
>>> employed by the net installer nor the server installer.  Those 
>>> installers 'think' (are designed to perform as if) they are 
>>> installing to a conventional hdd.
>>
>> What kind of tricks ?
> 
> Unfortunately, I don't know the answer to that.  I see answers, but they 
> don't work for me.
> 
>> AFAIK, a USB drive can be used like any other drive and does not 
>> require any tricks.
> 
> Try it and see if it works for you.
> 
> My initial attempt was to use the Ubuntu server .iso which has a text 
> based installer.  I wrote it to USB and booted it for the live 
> installation to another USB.  I was unsuccessful in getting a USB with 
> the Ub server installed to boot.  The installer went through the 
> 'motions' and installed and there was a grub boot loader, but it didn't 
> boot.  I attempted several different preparations of the USB prior to 
> trying to install to it, but none of them worked for me.
> 
> https://www.ubuntu.com/download/server Ubuntu Server 18.04.1 LTS

Why not install on a hard drive and clone over ?
At most, only the grub-install should differ, if at all.
A hard drive on a USB cable would be a "fixed" drive, while
a USB Flash stick would be a "removable" drive (signified by
RMB bit).

Or alternately, install a desktop version, then uninstall the desktop
metapackage leaving a server-like image. One difference is, the
server does some of its OS config stuff differently. Which may or
may not be an advantage.

    Paul

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

#53497

Paul wrote:
> Why not install on a hard drive and clone over ?
> At most, only the grub-install should differ, if at all.
> A hard drive on a USB cable would be a "fixed" drive, while
> a USB Flash stick would be a "removable" drive (signified by
> RMB bit).
> 
> Or alternately, install a desktop version, then uninstall the desktop
> metapackage leaving a server-like image. One difference is, the
> server does some of its OS config stuff differently. Which may or
> may not be an advantage.

Just today I found this one; a helper who has done a great deal with 
helping in the field of writing USBs that boot is Nio Wiklund, aka 
sudodus.  sudodus developed mkusb in its several forms and versions 
which use dd in a quasi-graphical manner.  I luv mkusb for linux just 
like I luv Rufus for Win.  He referred a qx about full install to USB in 
the Ub forum to this article he wrote.

https://askubuntu.com/questions/786986/boot-ubuntu-from-external-drive/942312#942312 
  I wrote a detailed description of a full Installation To USB Drive


I had pretty much decided to abandon the idea because my experience was 
so negative and time consuming; and because it really it mostly isn't 
necessary because of the utility of a live USB that boots to ram with 
persistence, but since sudodus has addressed the issue I'll give it 
another shot.

-- 
Mike Easter

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

#53498

Le 02/02/2019 à 10:05, Mike Easter a écrit :
> Pascal Hambourg wrote:
>> Mike Easter a écrit :
>>>
>>> Installing to a bootable USB involves some 'tricks' which are not 
>>> employed by the net installer nor the server installer.  Those 
>>> installers 'think' (are designed to perform as if) they are 
>>> installing to a conventional hdd.
>>
>> What kind of tricks ?
> 
> Unfortunately, I don't know the answer to that.  I see answers, but they 
> don't work for me.

Then how do you know it involves some tricks ?

>> AFAIK, a USB drive can be used like any other drive and does not 
>> require any tricks.
> 
> Try it and see if it works for you.

I am not going to try to install Ubuntu. I have successfully installed 
Debian on a USB drive without the need of any trick beyond the usual 
ones required with broken BIOS implementations on a fixed disk too.

> My initial attempt was to use the Ubuntu server .iso which has a text 
> based installer.  I wrote it to USB and booted it for the live 
> installation to another USB.  I was unsuccessful in getting a USB with 
> the Ub server installed to boot.  The installer went through the 
> 'motions' and installed and there was a grub boot loader, but it didn't 
> boot.

Can you elaborate ? How did you install GRUB ? Was it EFI or BIOS boot ?

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

#53526

Pascal Hambourg wrote:
> Mike Easter a écrit :
> 
>> My initial attempt was to use the Ubuntu server .iso which has a text 
>> based installer.  I wrote it to USB and booted it for the live 
>> installation to another USB.  I was unsuccessful in getting a USB with 
>> the Ub server installed to boot.  The installer went through the 
>> 'motions' and installed and there was a grub boot loader, but it 
>> didn't boot.
> 
> Can you elaborate ? How did you install GRUB ? Was it EFI or BIOS boot ?

All attempts were BIOS.  The equipment being used displays a choice of 
EFI or 'non-efi' (I have legacy enabled in the setup) for each disk in 
its boot menu and I always choose non-efi/ bios.

My uncertainty was about how to prepare the USB prior to the installer. 
My usual practice, which has mostly been with graphical installers, not 
the server-type text installer, and with hdd/s not USB, is to do a 
preliminary 'staging' of the hdd with GPartEd for formatting, setting 
boot flags, and mount point.

However, there are a lot of different guides about installing to USB 
which involve more parts and those guides caused me confusion.  So, I 
was confused about preliminary setting up of the USB and unfamiliar with 
the text installer.

That attempt resulted in an install that wouldn't boot.  A boot-repair 
tool told me there was a grub at the front, but I wasn't able to figure 
out how to fix it.

Next I tried a pathway more familiar in which I attempted to install a 
regular DE (Mate Ub) to the USB which gave me a graphical Ubiquity 
installer, but I was still uncertain about how to prepare the USB, 
unformatted (ask the installer to format), partitioned with a fat at the 
front and ext4 or ext2 or whatever with a / mount point.

That attempt also installed and put a grub at the front, but it wouldn't 
boot either.  The flash on the screen was the system telling me there 
wasn't something there it recognized as bootable.

I have no experience with 'crafting' a bootable USB by hand; I've always 
used a tool, either graphical Wins or semi-graphical text such as mkusb 
which uses dd underneath.

With my failures and uncertainties (and the inability to turn off the 
hdd from the BIOS and aversity to opening the case and doing it manually 
for such a trivial project) and my determination that it wasn't really a 
worthwhile cause since a bootable USB with persistence can do everything 
I have any interest in, I grew weary of trying to solve the mystery.

I've read a lot more since then, but my interest in full-installing to 
USB hasn't returned.  The part I don't like much is not being able to do 
it when I think I should be able to.


-- 
Mike Easter

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

#53570

Le 03/02/2019 à 23:01, Mike Easter a écrit :
> 
> My usual practice, which has mostly been with graphical installers, not 
> the server-type text installer, and with hdd/s not USB, is to do a 
> preliminary 'staging' of the hdd with GPartEd for formatting, setting 
> boot flags, and mount point.

Sounds good. Didn't you do it this way this time ?

> That attempt also installed and put a grub at the front, but it wouldn't 
> boot either.  The flash on the screen was the system telling me there 
> wasn't something there it recognized as bootable.

Did you try to boot from the USB drive on different machines ? Some 
firmwares have weird requirements about what they accept to boot.
The most common one is a partition entry with the boot flag in the MBR.
But this is not specific to boot from USB. Actually, a USB drive should 
be treated just like any other drive.

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

#53573

Pascal Hambourg wrote:
> Mike Easter a écrit :
>>
>> My usual practice, which has mostly been with graphical installers, 
>> not the server-type text installer, and with hdd/s not USB, is to do a 
>> preliminary 'staging' of the hdd with GPartEd for formatting, setting 
>> boot flags, and mount point.
> 
> Sounds good. Didn't you do it this way this time ?

Yes I did; several different ways when the first one didn't work.

>> That attempt also installed and put a grub at the front, but it 
>> wouldn't boot either.  The flash on the screen was the system telling 
>> me there wasn't something there it recognized as bootable.
> 
> Did you try to boot from the USB drive on different machines ? Some 
> firmwares have weird requirements about what they accept to boot.
> The most common one is a partition entry with the boot flag in the MBR.
> But this is not specific to boot from USB. Actually, a USB drive should 
> be treated just like any other drive.

The machine I was trying to boot the full install USB was the same one 
which booted the live USB created with mkusb.  I found myself 'randomly' 
trying different staging strategies which then entailed a slow motion 
install (both USBs were 2 not 3) and then I could only test by trying to 
boot it.

Then I realized that I didn't have sufficient skill to troubleshoot why 
a USB wouldn't boot except for using a tool such as boot-repair.  So, 
since what I was doing wasn't working, I realized I was shooting in the 
dark in slow motion and not being able to troubleshoot in any meaningful 
way.

I was getting consistently bad results and I didn't know why.  It seemed 
that it should work.  All of those guides I was reading didn't have any 
formula for troubleshooting what to do if it didn't work.  And all of 
those guides had all kinds of different ideas about how to prepare the 
USB prior to install.  Frustrating.


-- 
Mike Easter

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

#53583

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mike Easter wrote:
> [...]
> I was getting consistently bad results and I didn't know why.  It seemed 
> that it should work.  All of those guides I was reading didn't have any 
> formula for troubleshooting what to do if it didn't work.  And all of 
> those guides had all kinds of different ideas about how to prepare the 
> USB prior to install.  Frustrating.

Shouldn't need any "preparation" for this (I mean, you're just testing
afterall).

1. Fire up installer
2. Blow away /dev/targetUSB (sdc maybe?), single partition '/'
3. install grub to /dev/targetUSB
4. Reboot machine, F8 for one-time-boot menu
5. Boot off new USB.

The ugliest part is if you used a USB for the installer, you MIGHT have
the pleasure of something being "wrong" now, in terms of the USB
addressing on the host.

Might be safest to use optical media, to avoid changing the USB bus
between install and boot... 


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlxZgaEACgkQjhHd8xJ5
ooE0bQgAldT5jDtTEC5/KccE6gAmj4dSrdNQdNcOlLzkOh2M2NG+uIt2sCdZlxI5
rE2Wzk9blmD99p3o/I32iByG+A3awjE/Dka2oaPu9dDOLI/xAxxuArTOxT1Ai0yG
iVH0KylbL/pha37O8MdR/VOmtLm0xEUh7BfOO5clN5uXK8REDIzhPZweAFgRaNrt
GCOyUCBBuLrBRkQPac11Vdwghy8XYK1LZYrmtJPX/8LrZn3ycg3WZiFMV0j/RhPQ
m2EtFhy+k+ni62IWzAqfIhrNt1xXHYdK/l65tqsL2GaF7k7rVJN84iACRIgJrUw9
ZFWT2WvWBFj7cTYA6n9KoeqwoPDHTA==
=UQg8
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

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

#53591

Dan Purgert wrote:
> The ugliest part is if you used a USB for the installer, you MIGHT have
> the pleasure of something being "wrong" now, in terms of the USB
> addressing on the host.
> 
> Might be safest to use optical media, to avoid changing the USB bus
> between install and boot...

Hmmm.  None of the guides suggested NOT using a USB for the installer 
source.

I always use live USB to install something.  One desktop machine doesn't 
even have an optical drive in its case.  When that one needs something 
from an optical disk I attach a USB optical.  I prefer USB over optical 
because even USB 2 is faster than optical.

I don't yet understand how it would/might be a problem to boot a live 
USB to do an install to a different USB.  The installer can see both 
USBs and their partitions.

-- 
Mike Easter

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

#53595

Le 05/02/2019 à 18:34, Mike Easter a écrit :
> Dan Purgert wrote:
>> The ugliest part is if you used a USB for the installer, you MIGHT have
>> the pleasure of something being "wrong" now, in terms of the USB
>> addressing on the host.
>>
>> Might be safest to use optical media, to avoid changing the USB bus
>> between install and boot...
> 
> Hmmm.  None of the guides suggested NOT using a USB for the installer 
> source.
> 
> I always use live USB to install something.  One desktop machine doesn't 
> even have an optical drive in its case.  When that one needs something 
> from an optical disk I attach a USB optical.  I prefer USB over optical 
> because even USB 2 is faster than optical.

Right, optical media have awfull access time.

> I don't yet understand how it would/might be a problem to boot a live 
> USB to do an install to a different USB.  The installer can see both 
> USBs and their partitions.

Neithe do I. It makes absolutely no sense to me.

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

#53596

Le 05/02/2019 à 00:33, Mike Easter a écrit :
> 
> Then I realized that I didn't have sufficient skill to troubleshoot why 
> a USB wouldn't boot except for using a tool such as boot-repair.

bootinfoscript gathers a great amount of boot-related information. Isn't 
it included in boot-repair ?

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

#53597

Pascal Hambourg wrote:
> Mike Easter a écrit :
>>
>> Then I realized that I didn't have sufficient skill to troubleshoot 
>> why a USB wouldn't boot except for using a tool such as boot-repair.
> 
> bootinfoscript gathers a great amount of boot-related information. Isn't 
> it included in boot-repair ?

Earlier I posted one of my results from an install attempt.  Here is 
another.  The (whole) report involves sda, sdb, and sdc, where sdb is a 
4G live booted and sdc is the target install which doesn't boot.  And 
sda is a Win7 hdd.

Boot-repair is kinda dangerous to use (but not for info) to repair, 
because if you allow it to 'do things' it can do stuff without you 
telling it where to put something.  It wrote a syslinux MBR to my sda 
which doesn't seem to interfere with sda Win booting normally.  But, I 
don't want to talk about sda, so I'll only post some bootinfo about sdc 
here.

Here's sdc which doesn't boot:

Summary section:

 > Grub2 (v2.00) is installed in the MBR of /dev/sdc and looks at sector 
2048
     of the same hard drive for core.img. core.img is at this location and
     looks for (,gpt1)/boot/grub. It also embeds following components:

     modules
     ------------------------
     fshelp ext2 part_gpt biosdisk
     ------------------------

Drive section:

Drive: sdc _____________
Disk /dev/sdc: 7.6 GiB, 8100249600 bytes, 15820800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sdc1                   1    15,820,799    15,820,799  ee GPT


GUID Partition Table detected.

Partition  Attrs   Start Sector    End Sector  # of Sectors System
/dev/sdc1                 6,144    15,818,751    15,812,608 EFI System 
partition
/dev/sdc2                 2,048         6,143         4,096 BIOS Boot 
partition

Attributes: R=Required, N=No Block IO, B=Legacy BIOS Bootable, +=More 
bits set

=============

I don't have the skills to 'see' what is wrong or what I can fix.

-- 
Mike Easter

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

#53599

Mike Easter wrote:
> I don't have the skills to 'see' what is wrong or what I can fix.

There are a lot of lines of the repair info I didn't post.  Way down at 
the bottom (line 1178) is this:

========= Suggested repair
The default repair of the Boot-Repair utility would reinstall the grub2 
of sdc1 into the MBR of sdc.
It would also fix access to other systems (other MBRs) for the 
situations when the removable media is disconnected.
Grub-efi would not be selected by default because: no-win-efi
Additional repair would be performed: unhide-bootmenu-10s   fix-windows-boot
=========

I don't want to let boot repair do anything (again) because I can't 
control what it is doing.  So far whatever it previously changed about 
the MBR of sda didn't interfere with sda booting as a Win boot.  I also 
don't want to bother with opening the case and disconnecting the hdd.


-- 
Mike Easter

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

#53608

Le 05/02/2019 à 22:04, Mike Easter a écrit :
> 
> Earlier I posted one of my results from an install attempt.

I don't remember seeing it in this thread. Message-ID ?

> Here's sdc which doesn't boot:
> 
> Summary section:
> 
>  > Grub2 (v2.00) is installed in the MBR of /dev/sdc and looks at sector 2048
>      of the same hard drive for core.img. core.img is at this location and
>      looks for (,gpt1)/boot/grub. It also embeds following components:

Fine. Sector 2048 is the beginning of the BIOS boot partition, which is 
the intended location for GRUB's core image on a GPT disk.

>      modules
>      ------------------------
>      fshelp ext2 part_gpt biosdisk
>      ------------------------
> 
> Drive section:
> 
> Drive: sdc _____________
> Disk /dev/sdc: 7.6 GiB, 8100249600 bytes, 15820800 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> 
> Partition  Boot  Start Sector    End Sector  # of Sectors  Id System
> 
> /dev/sdc1                   1    15,820,799    15,820,799  ee GPT
> 
> 
> GUID Partition Table detected.
> 
> Partition  Attrs   Start Sector    End Sector  # of Sectors System
> /dev/sdc1                 6,144    15,818,751    15,812,608 EFI System partition
> /dev/sdc2                 2,048         6,143         4,096 BIOS Boot partition

Why did you use GPT ? It can be required for EFI boot with some (broken) 
UEFI firmwares, but I do not see any advantage for BIOS boot.

Also, why does sdc2 have the "EFI system partition" type ? I assume it 
is not really a ESP containing a FAT filesystem for EFI boot but an ext* 
partition (according to the embedded module list in GRUB's core image). 
So yo should change it to not confuse the UEFI firmware.

As required by the GPT specification, the boot flag of the GPT partition 
of the protective MBR is not set. But some BIOS/UEFI firmwares require 
it for BIOS/legacy boot. So you may try to set it with parted or fdisk.

# parted /dev/sdc disk_set pmbr_boot on

or

# fdisk -t dos /dev/sdc
a
w

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

#53609

Le 05/02/2019 à 23:44, Pascal Hambourg a écrit :
>>
>> Partition  Attrs   Start Sector    End Sector  # of Sectors System
>> /dev/sdc1                 6,144    15,818,751    15,812,608 EFI System partition
>> /dev/sdc2                 2,048         6,143         4,096 BIOS Boot partition
(...)
> Also, why does sdc2 have the "EFI system partition" type ?

I meant "sdc1".

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

#53614

Pascal Hambourg wrote:
> Pascal Hambourg a écrit :
>>>
>>> Partition  Attrs   Start Sector    End Sector  # of Sectors System
>>> /dev/sdc1                 6,144    15,818,751    15,812,608 EFI 
>>> System partition
>>> /dev/sdc2                 2,048         6,143         4,096 BIOS Boot 
>>> partition
> (...)
>> Also, why does sdc2 have the "EFI system partition" type ?
> 
> I meant "sdc1".

When I look at sdc1 with GPartEd to set flags, its flags say boot and 
esp.  It was not possible to set a boot flag without esp.   If I checked 
boot I got boot and esp, no choice; either boot and esp or no boot flag.

Also, GPartEd looks 'different' to me from the above.

GPE says the little sdc2 part, which is in front, file system is 
grub2core.img and has bios_grub flag.


-- 
Mike Easter

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

#53616

Pascal Hambourg wrote:
> Mike Easter a écrit :
>>
>> Earlier I posted one of my results from an install attempt.
> 
> I don't remember seeing it in this thread. Message-ID ?

I don't recall the background prior to the boot info; but here is the 
msg from another thread on this issue:

http://al.howardknight.net/msgid.cgi?ID=154941170700
From: Mike Easter
Newsgroups: alt.os.linux
Subject: Re: Examine (and fix?) non-booting USB
Date: Thu, 31 Jan 2019 11:19:19 -0800
Message-ID: <gbh01oFb4v2U1@mid.individual.net>

>>
>> GUID Partition Table detected.
>>
>> Partition  Attrs   Start Sector    End Sector  # of Sectors System
>> /dev/sdc1                 6,144    15,818,751    15,812,608 EFI System 
>> partition
>> /dev/sdc2                 2,048         6,143         4,096 BIOS Boot 
>> partition
> 
> Why did you use GPT ? It can be required for EFI boot with some (broken) 
> UEFI firmwares, but I do not see any advantage for BIOS boot.

I don't know the answer; likely some tool had it as a default.  In 
another message I explained about GPE coupling the flags for boot and 
esp together.

> Also, why does sdc2 have the "EFI system partition" type ? I assume it 
> is not really a ESP containing a FAT filesystem for EFI boot but an ext* 
> partition (according to the embedded module list in GRUB's core image). 
> So yo should change it to not confuse the UEFI firmware.
> 
> As required by the GPT specification, the boot flag of the GPT partition 
> of the protective MBR is not set. But some BIOS/UEFI firmwares require 
> it for BIOS/legacy boot. So you may try to set it with parted or fdisk.
> 
> # parted /dev/sdc disk_set pmbr_boot on
> 
> or
> 
> # fdisk -t dos /dev/sdc
> a
> w

I'll give your parted command a shot.  GPartEd doesn't show me those/any 
options for sdc.  Just for its parts.


-- 
Mike Easter

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

#53617

Mike Easter wrote:
> Pascal Hambourg wrote:
>>
>> As required by the GPT specification, the boot flag of the GPT 
>> partition of the protective MBR is not set. But some BIOS/UEFI 
>> firmwares require it for BIOS/legacy boot. So you may try to set it 
>> with parted or fdisk.
>>
>> # parted /dev/sdc disk_set pmbr_boot on
>>
>> or
>>
>> # fdisk -t dos /dev/sdc
>> a
>> w
> 
> I'll give your parted command a shot.  GPartEd doesn't show me those/any 
> options for sdc.  Just for its parts.
> 
Well, there's some progress, thanks.  And I call that parted command a 
'trick' :-)

I got a grub boot menu (which also showed me sda).  Unfortunately, it 
didn't boot to a desktop but only to a busybox initramfs prompt which 
had a limited number of available commands which did not include startx.


-- 
Mike Easter

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

#53619

Mike Easter wrote:
> Well, there's some progress, thanks.  And I call that parted command a 
> 'trick' :-)
> 
> I got a grub boot menu (which also showed me sda).  Unfortunately, it 
> didn't boot to a desktop but only to a busybox initramfs prompt which 
> had a limited number of available commands which did not include startx.

I exited the initramfs prompt and got more info.  sdc1 has errors. an 
inode with illegal blocks.  It wanted me to run fsck manually.  With 
manual fsck, there were a lot of things wrong to which I answered yes a 
dozen or so times, until eventually I got back to a initramfs prompt so 
I rebooted.

Slowly I got to a desktop; so I would definitely call that success.  The 
USB install runs the desktop more slowly than running a live with 
persistence in ram.  If someone is going to install to USB it should be 
USB 3.

I don't think this sequence is the way I would like to install to USB, 
but for some of my experiments which were originally the goal, I could 
choose to boot a live USB lightweight DE, maybe Lubuntu running in ram 
with persistence.  That will perform satisfactorily  with USB 2 and I 
believe that it is easier to create any necessary parts after such as 
mkusb has made the persistent live.




-- 
Mike Easter

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

#53645

Le 06/02/2019 à 02:25, Mike Easter a écrit :
> 
> When I look at sdc1 with GPartEd to set flags, its flags say boot and 
> esp.

I see. IIUC, you wanted to set the boot flag on partition sdc1.

This is where Gparted and other libparted-based software such as parted 
and partman, the Debian installer partitioning tool, get tricky because 
they treat partition types as "flags" :

1) With GPT, the "boot" flag is just an alias of the "esp" flag so you 
can only set none or both.

2) The "esp" flag is not an real flag in the traditional sense but 
indicates that the partition type is "EFI System Partition". Not to be 
confused with the "legacy_boot" flag which is more a real flag 
(attribute) but useless.

With GPT, a Linux filesystem partition should not have any "flag" at all.

> Also, GPartEd looks 'different' to me from the above.

Yes, because Gparted shows only the "real" GPT partition table 
(containing the BIOS boot and fake EFI partitions), not the protective 
MBR (containing the protective GPT partition).

> GPE says the little sdc2 part, which is in front, file system is 
> grub2core.img

Indeed the BIOS boot partition contains GRUB's core image, but it is not 
a filesystem.

> and has bios_grub flag

Similarly to the "esp" flag, the "bios_grub" flag is not a real flag but 
indicates that the partition type is "BIOS boot".

IMO, if you want to set up a USB drive for BIOS/legacy boot only and do 
not need more that 4 partitions not extending beyond 2 TiB, using a 
traditional DOS/MBR partition table would be simpler than GPT : no BIOS 
boot partition, the boot flag is really a boot flag...

On the other hand if you want to set up a USB drive for both BIOS and 
EFI boot, well, this is another story.

> And I call that parted command a 'trick'

Absolutely. It is a deviation from the GPT specification, used to work 
around a common deviation from the BIOS boot specification in broken 
firmwares.

While booting in BIOS/legacy mode, the firmware should ignore the 
partition table. It should just load the MBR sector, check the 0xAA55h 
boot signature at offset 510/1FEh and execute the boot program at offset 
0. Then the MBR boot program may or may not read the partition table and 
look for a partition with the boot flag set.

> I got a grub boot menu (which also showed me sda).

If you don't want other systems to be added to the GRUB menu, you can 
add the following line in /etc/default/grub and run update-grub (or 
update-grub2 depending on your distribution) :

# do not probe and include other systems in GRUB menu
GRUB_DISABLE_OS_PROBER=true

> The USB install runs the desktop more slowly than running a live with 
> persistence in ram.

Live systems often use a compressed read-only root filesystem such as 
squashfs, so reading from the medium is faster due to compression.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web